Prove you are the parent. Without proving who you are.

A privacy law written to stop companies collecting data about children now requires companies to collect a payment card, a government document, or a video call from the child's parent. Every approved method verifies an instrument. None of them verifies a parent. Here is the gap, and what closing it actually looks like.

It is a Tuesday evening and a nine year old wants to play the game his friends are playing. His mother gets as far as the consent screen. The screen explains, politely and at some length, that to comply with federal law protecting her son's privacy, the company needs her credit card number. She will be charged fifty cents. The fifty cents will be refunded. This is, the screen says, for verification only.

She reads it twice. Then she closes the tab, because handing a card number to a game studio she had never heard of forty seconds ago in order to protect her son's data does not feel like protecting her son's data. Her son does not get to play. The studio records an abandoned signup and, in the aggregate, concludes that consent flows cost them somewhere between a third and half of their under thirteen funnel.

Two streets away, an eleven year old takes his father's card out of the wallet on the hall table, types the number into the same screen, and is playing within a minute. The studio's records now show a verified parental consent for that account. It is signed, dated, and legally sufficient. It is also completely false, and nobody involved will ever find out.

Both of those are failures of the same control, and they fail in opposite directions. The honest parent was blocked. The child was waved through. That is not a story about a badly built product. Every approved method under the rule has this shape, because of what the methods are actually built to verify.

What actually changed in COPPA on 22 April 2026?

The Federal Trade Commission finalised amendments to the Children's Online Privacy Protection Rule in early 2025. The amended Rule took effect on 23 June 2025, and most operators had until 22 April 2026 to reach full compliance (Federal Trade Commission, Children's Online Privacy Protection Rule). If you build anything that children under thirteen touch, three of those changes matter more than the rest.

Consent is no longer one thing

The amended Rule requires separate verifiable parental consent before disclosing a child's personal information to third parties, where that disclosure is not integral to the service. In practice this splits the old single checkbox into at least two decisions: may we collect this to run the service, and may we pass it to anyone else. A parent can now say yes to the first and no to the second, and the operator has to build a product that works when they do.

This is the provision with the most product design consequence, because a great many children's apps were financially dependent on the second answer always being yes, and were structured so that the parent could not distinguish the two questions. That structure is now specifically addressed.

You cannot keep the data forever

The amendments added retention obligations: a written retention policy, and a prohibition on holding children's personal information indefinitely. Data collected for a specific purpose has to go when that purpose is done.

Read that next to the consent methods and the irony arrives quickly. The Rule tells operators to minimise what they hold about children, and separately tells them to verify parents using methods that produce a payment card record, a scanned government document, or a recorded video call. The verification artifacts are frequently more sensitive than the child data they exist to protect.

Enforcement is real and it is expensive

The Commission has brought substantial COPPA actions. Epic Games agreed to a record 275 million dollar civil penalty in 2022 over alleged COPPA violations, and the FTC announced a settlement with Disney in 2025 that was reported at ten million dollars (Federal Trade Commission press releases). Earlier actions against Musical.ly, later TikTok, established that operators cannot hide behind a self declared birthdate when they have actual knowledge of child users.

The pattern across those cases is worth sitting with. Enforcement lands on the operator. It does not land on the child who typed a false birthdate, and it does not land on the adult who was not actually a parent. The operator carries the whole risk of a determination it was given no reliable way to make.

What counts as verifiable parental consent?

The Rule's standard is that the method must be reasonably calculated, in light of available technology, to ensure that the person providing consent is the child's parent. The Rule then enumerates methods that satisfy that standard, and provides a formal process by which new methods can be submitted to the Commission for approval, which is how several of the currently accepted methods arrived.

The enumerated and approved set includes, broadly: returning a signed consent form by post, fax, or electronic scan; using a payment card or online payment system in a transaction that provides notification to the account holder; calling a toll free number staffed by trained personnel; connecting to trained personnel by video conference; checking a government issued identification against a database and then promptly deleting it; answering knowledge based authentication questions; and matching a face image against a verified photo identification. A lighter method sometimes called email plus is permitted only where the child's information is used internally and not disclosed.

Do not treat that paragraph as legal advice or as a substitute for the Rule text. Read 16 CFR Part 312 directly, and check the Commission's current guidance, because the approved list is not static and the details of each method carry conditions that matter. What follows is not a compliance opinion. It is an engineering observation about what these methods can and cannot establish.

Why does every approved method verify an instrument instead of a parent?

Line the methods up and ask a single question of each: at the moment consent is granted, what fact has actually been established?

A payment card transaction establishes that whoever completed the flow had access to a card and, if the notification requirement works as intended, that the account holder can find out afterwards. It does not establish that the person at the keyboard is the account holder, and it very specifically does not establish that the account holder is anyone's parent. A card is a bearer instrument sitting in a wallet in a hallway.

A government ID check establishes that a real document exists and, with a face match, that the person presenting it resembles the document photo. This is the strongest method in the set at establishing adulthood and identity. It establishes nothing whatsoever about a relationship to a child, because identity documents do not encode parenthood.

Knowledge based authentication establishes that the person can answer questions drawn from public and commercial records about a named adult. In an era where those records have been breached repeatedly, this establishes considerably less than it did when the method was approved, and it never established a family relationship in the first place.

A video call with trained personnel establishes that a person who appears to be an adult appeared on camera. Video as evidence of presence has weakened sharply, for reasons we have written about at length in the context of injection attacks against identity verification, where synthetic frames are fed directly into the capture pipeline and never pass in front of a real camera at all.

A signed form returned by post establishes that someone with access to the household's postbox owns a pen.

The two assertions nobody separates

Verifiable parental consent, if you take the phrase seriously, requires two entirely different facts to be true at once.

The first is this person is an adult. This is a hard but tractable problem. Several of the approved methods do it reasonably well, identity vendors compete on it, and we have written separately about how to establish an age threshold without collecting a document.

The second is this adult holds parental authority over this specific child account. This is a completely different kind of problem, and almost nothing in the approved set touches it. A payment card does not encode it. A driving licence does not encode it. A face match does not encode it. Trained personnel on a video call cannot see it.

The industry has collapsed these two assertions into one because the first is purchasable and the second is not. Vendors sell adulthood checks, operators buy them, everyone writes the word consent on the resulting record, and the second assertion is quietly inferred from the fact that an adult bothered to complete the flow at all. That inference is doing enormous load bearing work, and it is not stated anywhere in the compliance file.

Be clear about the consequence: an unrelated adult, an older sibling of eighteen, a paid stranger, or a child with access to any of these instruments passes every approved method. The Rule's standard is reasonableness rather than certainty, and these methods are defensible under that standard, which is exactly why the gap persists without anybody being obviously at fault.

Why does a privacy law make you collect more data?

Here is the perverse outcome stated plainly. To comply with a statute whose purpose is to limit the collection of children's personal information, an operator ends up holding a parent's payment card details, or a scan of a parent's passport, or a recording of a parent's face, or a set of answers to questions about a parent's mortgage history.

Then the amended Rule's retention limits arrive and tell the operator it cannot keep children's data indefinitely, while the verification artifacts it collected to protect that data sit in a different bucket with different rules and, very often, worse hygiene, because they were treated as a compliance byproduct rather than as a crown jewel.

Every operator that runs its own consent flow becomes a small, badly defended repository of adult identity data. Multiply that by every app a family uses. A household with two children and a dozen apps has scattered card details and document scans across a dozen independent security postures, in exchange for a set of consent records that, as established above, do not prove the thing they claim to prove.

The Commission has clearly seen the shape of this. Its February 2026 policy statement addressed a specific circularity that had been paralysing operators: collecting information in order to determine a user's age might itself be construed as collecting personal information from a child, which would trigger the consent obligation that the age check exists to determine the need for. The statement signalled enforcement forbearance where information is collected solely to determine age (Federal Trade Commission news releases; commentary from Mayer Brown and other firms).

That is a meaningful and constructive move. It removes a genuine chicken and egg problem. It does not, on its own, cause the underlying methods to start verifying guardianship.

How do the methods actually compare?

The table below is an engineering comparison, not a compliance ranking. Every method listed is capable of being implemented in a compliant way. The columns that matter for design are the last two.

Notice that the bottom row does not solve the last column either. It moves the guardianship question to one place, once, where it can be done properly, instead of being silently assumed eight different ways.

What would consent look like if you modelled it as delegation?

Step back from the compliance framing and describe what is actually happening in the world. A parent is granting a company a limited, conditional, revocable authority to do specific things with data about their child. That is not a form. That is a delegation, and delegation is a well understood object with well understood properties: it has an issuer, a subject, a scope, a validity window, and a revocation identifier.

Once you see it that way, the amended Rule's separate consent for third party disclosure stops being an awkward second checkbox and becomes what it obviously is, which is a second entry in a scope array. The retention limits stop being a separate policy document and become an expiry field. Withdrawal of consent stops being a support ticket and becomes a revocation.

Here is what the object looks like. The parent enrolls once, on their own device, using a passkey and an on device face match that produces a one way key. No document is stored. No face template is stored. Then they sign this:

{
  "typ":     "manav/delegation+v1",
  "iss":     "did:manav:guardian:8f3ca7...91d",   // the enrolled adult
  "sub":     "acct:kidsgame.example/child/44219", // this child account
  "scope": {
    "collect":  ["profile", "gameplay", "voice_chat"],
    "disclose": []                                 // third party: refused
  },
  "notBefore":    "2026-09-19T18:04:11Z",
  "notAfter":     "2027-09-19T18:04:11Z",
  "revocationId": "rv_01JQ8T2M6K",
  "attester":     "did:manav:school:riverside-usd" // who vouched for guardianship
}

The operator stores the resulting receipt against the child account. When it later needs to answer the question am I permitted to do this, it does not query a consent table it wrote itself. It verifies a signature:

receipt = consent_store.get(child_account_id)
chain   = manav.verify(receipt, published_key)    # offline, no callback

assert chain.ok                                    # signature is valid
assert "voice_chat" in chain.scope.collect         # scope covers this use
assert "adtech" not in chain.scope.disclose        # third party consent absent
assert chain.not_after > now()                     # inside validity window
assert not revoked(chain.revocation_id)            # parent has not withdrawn

Three properties of that check are worth drawing out, because they are the entire argument.

First, it verifies offline. The operator checks an Ed25519 signature against a published key with no callback to us and no dependency on our availability. If we disappear tomorrow, every consent receipt already issued remains verifiable. We have written about why verification that phones home creates availability coupling and privacy leakage, and consent records are a textbook case: an operator should not have to ask a third party for permission to answer a question about its own user.

Second, the scope is explicit and structured, so the separate third party consent obligation is enforced by the check rather than by a developer remembering to read a boolean. The disclose array in the example above is empty. An advertising integration that tries to run against this account fails the assertion. That is a control, not a policy.

Third, revocation is a first class field. Today, a parent withdrawing consent contacts support, and an operator's ability to honour that promptly across its systems depends entirely on internal plumbing nobody audits. With a revocation identifier, withdrawal becomes something the operator checks rather than something it remembers to do. This is the same argument we made about why revocation has to be an anchored property rather than a series of independent local deletions.

What the receipt does for the compliance file

There is a quieter benefit that will matter to anyone who has been through an inquiry. Today, an operator's proof that consent was obtained is a row in its own database, written by its own code, attesting to its own good behaviour. It is not nothing, but it is self generated evidence, and it has the evidentiary weight of a note you wrote yourself.

A signed receipt is different in kind. It is an artifact the operator did not author, verifiable by a regulator without trusting the operator's logs. The same distinction we drew about what an electronic signature actually attests applies exactly here: the question is not whether you have a record, it is whether anyone other than you can check it.

What does a signature not fix?

This section is the important one, and it is where a vendor would normally start describing a solved problem. It is not solved.

A signature does not establish guardianship. Say it plainly. If an adult signs the delegation above, the cryptography proves that this specific enrolled human signed this specific scope for this specific child account at this specific time. It proves nothing about whether that human is the child's parent or guardian. The parental relationship is a social and legal fact, and no cryptographic operation can conjure it out of nothing.

Establishing it requires an attester: an institution that already knows the relationship and is willing to say so. Schools know it, because they maintain enrolment records with guardian contacts. Paediatric practices know it. Mobile carriers with family plans know something adjacent to it. A government registry would know it, and in the United States no such usable registry exists. The attester field in the delegation exists precisely to record which institution vouched, so a regulator can evaluate the strength of that link rather than guessing.

What the delegation model changes is that guardianship gets established once, by somebody positioned to actually know, and then travels. It does not get re asserted by inference at every app signup by a company with no visibility into the family at all.

It does not handle every family. Shared custody produces two adults with legitimate authority who may disagree. Foster placements change. Grandparents raise children without formal documentation. Some children have no engaged guardian at all, and a system that fails closed on them has harmed exactly the children the statute exists to protect. Any real implementation needs a staffed human path, and that path has to be treated as a normal route rather than a rare exception, because for a meaningful minority of children it is the only route.

It does not stop a determined child. A twelve year old with access to a parent's unlocked phone and a compliant parent's finger on a sensor is not defeated by any of this. Presence checks raise the cost and make the moment deliberate rather than invisible, which matters, but a motivated adversary with physical access to the authenticator and a cooperative or inattentive adult still wins. Nobody should claim otherwise.

Regulatory acceptance is not automatic. The Rule enumerates methods and provides a formal process for approving new ones. A delegation based flow is not on the enumerated list. An operator would need either to map it onto an existing approved method, which is plausible for the enrollment step, or to seek approval through the Commission's process, likely with a safe harbor programme's support. That is a real, slow, uncertain path and it would be dishonest to describe it as a shortcut.

Selective disclosure is roadmap, not shipped. The delegation object, the offline verifiable receipts, the revocation identifiers and the passkey enrollment with an on device face match are shipped today. Doing this with zero knowledge predicates, so the operator learns strictly that a valid guardian consented without learning a persistent identifier, is roadmap. We would rather say that than let you discover it during procurement.

Who could actually make this work?

The honest competitive answer is that Apple and Google are the obvious incumbents here, and their position is strong. Family account structures already assert a guardian to child relationship inside each ecosystem, already carry age signals, and already sit at the point of app installation. If either exposed a durable consent API to third party operators, they would cover a large fraction of the problem immediately.

What that would leave unaddressed is worth naming, because it is where independent infrastructure earns its place. Ecosystem consent is bounded by the ecosystem: it does not travel to a browser game, a connected toy, a school issued device managed by a district, or a service the family reaches on a device the child does not own. It also leaves the operator holding an assertion it must trust the platform for, rather than a receipt it can verify itself and produce to a regulator later. And it concentrates the guardianship graph inside two companies, which is a policy outcome worth thinking about before it happens by default.

The realistic entry points are therefore schools and districts, which already hold guardian records and already act as consent agents for educational technology under specific conditions, and safe harbor programmes, whose business is certifying methods and who have both the standing and the incentive to shepherd a new one. We wrote about the school angle in the context of identity assurance in education, where the same institutions hold the same authoritative records.

What to do this week

Regardless of whether you ever adopt a delegation model, these are worth doing:

1. Separate your two consents in the data model, not just the interface. If collection consent and third party disclosure consent are the same column with two flags, an accidental join will eventually disclose data you had no consent to disclose. Make them different objects with different lifecycles.
2. Inventory what your consent flow retains. Write down every artifact: card tokens, document scans, video recordings, KBA logs. For each one, name the deletion trigger and the person accountable. Most teams discover at least one artifact nobody knew was being kept.
3. Measure completion, by method, and share it with legal. Consent drop off is usually treated as a product metric and a legal non issue. It is both. A method with a twenty percent completion rate is a method that is pushing families toward the app that does not ask.
4. Test your own flow as a child would. Have someone attempt each of your consent methods without being a parent. Use a card from a wallet, an adult who is not related to any child, a document from a colleague. Record which ones you pass. Bring that to the next compliance review.
5. Build the withdrawal path before you need it. Time how long it takes, from a parent's request to the data actually stopping. If that number is measured in days, or is unknown, that is the finding.
6. Record who vouched. Even inside today's methods, store which method established adulthood and on what basis. When a regulator asks how you concluded the consenter was a parent, an honest recorded answer is a far better position than a reconstructed one.
7. Read the Rule text, not a summary. Including this one. 16 CFR Part 312 is short and readable, the Commission's business guidance is good, and the conditions attached to each method are where the compliance risk actually sits.

If you want to see what a signed, scoped, revocable consent receipt looks like in practice, the signing demo shows the mechanics of binding a signature to an exact payload, and the developer documentation covers the delegation object and offline verification.

Frequently asked questions

What counts as verifiable parental consent under COPPA in 2026? A method reasonably calculated, in light of available technology, to ensure the person consenting is the child's parent. The Rule enumerates methods including a signed form, a payment card transaction with notification, a call or video call with trained personnel, a government ID checked then deleted, knowledge based authentication, and a face match to a verified photo ID, and provides a process for approving new methods.

Can parental consent be reused across apps? Not today. Each operator independently obtains and stores its own consent, which is why families repeat the process for every app and why verification data accumulates across many operators. A portable, signed consent receipt is technically straightforward. The obstacles are regulatory acceptance and the absence of an agreed attester for the guardianship relationship, not cryptography.

How do I prove a parent, not a child, consented? With current methods, you largely cannot. Approved methods establish access to an instrument such as a card, a document, or a phone, and adulthood, but not the parental relationship. The stronger position is to record which institution attested to guardianship, such as a school or a paediatric practice, and to keep that attestation in the compliance file rather than inferring the relationship.

Does a credit card charge actually verify a parent? It verifies that whoever completed the flow had access to a card and, where the notification requirement functions, that the account holder can learn about it afterwards. A child with access to a parent's wallet passes. The method is defensible under the Rule's reasonableness standard, which is a different claim from saying it establishes the relationship.

What changed in COPPA on 22 April 2026? That was the full compliance date for the amended Rule, which took effect on 23 June 2025. The most consequential changes are a separate consent requirement for disclosing children's data to third parties where not integral to the service, new data retention obligations including a written policy and a prohibition on indefinite retention, and expanded definitions and security programme requirements.

Does the FTC's February 2026 policy statement mean age checks are now safe? It signalled enforcement forbearance where information is collected solely to determine a user's age, which resolves a genuine circularity that had discouraged operators from checking age at all. It is not a blanket authorisation, it does not change the consent methods themselves, and operators should read the statement and current guidance directly rather than relying on summaries.

Is a consent receipt better evidence than a database record? For an inquiry, yes, in one specific respect. A database row is evidence you generated attesting to your own compliance. A signed receipt can be verified by a third party without trusting your logs, which is a different evidentiary category. It does not make the underlying consent any more valid than the method that produced it.

Sources

1. Federal Trade Commission, Children's Online Privacy Protection Rule (COPPA): ftc.gov/legal-library/browse/rules/childrens-online-privacy-protection-rule-coppa
2. Electronic Code of Federal Regulations, 16 CFR Part 312, including the verifiable parental consent methods at 312.5: ecfr.gov/current/title-16/chapter-I/subchapter-C/part-312
3. Federal Trade Commission, children's privacy business guidance: ftc.gov/business-guidance/privacy-security/childrens-privacy
4. Federal Trade Commission press releases, including the Epic Games civil penalty and the 2025 Disney settlement: ftc.gov/news-events/news/press-releases
5. Federal Register, rulemaking documents for the amended COPPA Rule: federalregister.gov
6. Information Commissioner's Office, Age Appropriate Design Code (UK Children's Code): ico.org.uk children's code guidance
7. General Data Protection Regulation, Article 8, conditions applicable to child's consent: gdpr-info.eu/art-8-gdpr

Every approved method answers the question "is there an adult here?" None of them answers the question the law actually asks, which is "is this the parent?"