On July 28, 2026, New York published the final rules implementing the Stop Addictive Feeds Exploitation (SAFE) for Kids Act. The headlines wrote themselves: another state, another addictive-feeds law, another age gate. Operators filed it next to California’s SB 976 and moved on. The rules take effect January 25, 2027, and platforms have 180 days to comply — a countdown that reads, at first glance, like every other children’s-safety deadline of the past eighteen months.
Read the actual text and a different requirement surfaces, one that most of the platforms racing to build a child gate have not built at all. New York’s rules do not just regulate how you determine that a user is a minor. They regulate how you determine that the adult granting consent is who they say they are — an adult, and specifically a parent of this child. The consenting parent is now a verification subject with a spec of their own. And the single most common way minors defeat parental-consent flows — clicking “I’m the parent” themselves — is now, by design, non-compliant.
The child gate got a year of engineering attention. The parent gate is the part that was left as a checkbox. The final rules just moved the frontier onto it.
What the final rules actually demand on the parent side
The SAFE for Kids Act restricts “addictive feeds” and nighttime notifications for minors unless a platform obtains verifiable parental consent. The rules apply to “Addictive Online Platforms” — user-generated-content services where users spend at least 20% of their time on addictive feeds over a six-month window — which is a deliberately broad net, not a carve-out for a handful of named apps (Inside Privacy).
The process runs in a specific order. A minor must affirmatively seek access to a prohibited feature and consent to their parent being notified; only then may the platform seek consent from the parent. And the verifiable-parental-consent method itself must, per the final rules, do several things at once (ID Tech Wire):
- Determine the parent’s age status — the consenter has to clear age assurance too, not merely assert adulthood.
- Be reasonably calculated to ensure the person providing consent is a parent of the covered minor — not just an adult, but this child’s adult.
- Account for the likelihood of circumvention, fraud, or misuse of the method — a live obligation to model how the flow gets gamed, not a one-time attestation.
- Include at least one option that does not require the parent to furnish a government ID — an ID-only parent path is explicitly insufficient.
- Delete or de-identify any information used to determine age or obtain consent immediately after its intended use, and use only the minimum data necessary.
That is a materially harder standard than “reasonable,” and it is aimed squarely at the weakest joint in every parental-consent regime. It is worth noting how far this has traveled from the June draft, which was mostly about the child-side accuracy spec — accuracy minimums, annual testing, an audit trail. The final rules keep all of that (age-assurance methods must hit a high accuracy rate, be tested annually, and the test results retained for at least five years) and then extend the same rigor to the adult on the other side of the transaction.
Why “click here, I’m the parent” is the whole ballgame
Here is the failure mode the rules are built to kill. In the overwhelming majority of consent flows shipped to date, the “parent” is whoever is holding the phone. The minor requests access, an email or SMS goes to an address the minor controls or can reach, and someone clicks Approve. The child is on both sides of the transaction. It is self-consent wearing a parent’s name tag.
This is not a hypothetical. Parent impersonation is one of the most documented ways minors circumvent age and consent controls, alongside VPN spoofing and shared devices (Pandectes). And the regulatory posture has caught up to it. The FTC’s February 2026 COPPA policy statement makes the distinction explicit at the federal level: age verification is not the same thing as verifiable parental consent, and confirming that a user is an adult does not confirm that the adult is entitled to consent for a particular child (FTC). With COPPA 2.0 having cleared the Senate in March 2026 and the House passing the broader KIDS Act in June, the “prove the parent” requirement is not a New York peculiarity — it is the direction the entire US framework is converging on.
New York put teeth on it. Violations carry civil penalties of up to $5,000 each, and because the rules require you to account for the likelihood of fraud and misuse, a consent flow that any teenager can complete solo is not a design choice a regulator has to accept. It is a documented gap in a control you were obligated to harden.
The three things operators keep getting wrong
Translate the requirement into an implementation review and the same three mistakes show up.
Treating a payment instrument as proof of parenthood. The classic COPPA-era move — charge a nominal amount to a credit card and call the cardholder a verified parent — was never strong, and it is weaker now. A card proves a payment instrument was issued to someone; teenagers hold authorized-user and prepaid cards routinely, and a card number reveals nothing about a parent-child relationship. We’ve written before about why a card is not proof of age; it is even less proof of parenthood. Under a rule that demands the method be “reasonably calculated to ensure the individual providing consent is a parent of the covered minor,” a payment charge answers the wrong question.
Making government-ID upload the only parent path. Many teams, told to “verify the parent,” reach straight for a driver’s-license scan. The final rules foreclose that as a sole method — you must offer at least one option that does not require a government ID. There is a deeper reason this matters beyond the letter of the rule: an ID-only parent flow concentrates exactly the data you least want to hold. You are now collecting government identity documents from adults and linking them to named children, which is a uniquely toxic pairing to store. And a naive photo-of-ID step inherits the synthetic-ID problem — AI-generated documents now pass a large share of upload-and-selfie stacks on the first try, so an ID upload can launder a fabricated “parent” straight through your consent gate.
Retaining the evidence instead of the assertion. The rules mandate deletion or de-identification immediately after use, and minimum-necessary collection. A consent flow that files away the parent’s ID image, the child’s details, and the linkage in a durable store has not satisfied the rule — it has built a breach. 2025 and 2026 have already delivered a run of incidents where the verification layer itself became the breach surface, and a parent-consent vault is a higher-value target than a plain age-gate log because it maps adults to specific children. The privacy-first posture — keep the signed result, discard the material that produced it — is not a nice-to-have here. It is written into the rule.
The part nobody specs: proving the relationship
Proving the adult is an adult is a solved problem. Proving the adult is this child’s parent is the genuinely hard one, and it is the requirement almost no consent flow addresses head-on.
There is no clean, fraud-proof way to assert a parent-child relationship from a cold start, and the rule does not pretend otherwise — it asks for a method “reasonably calculated” to establish it and one that “accounts for” circumvention, which is the same proportionate-effort standard that runs through age-assurance law generally. Nobody is required to build the unbreakable; everybody is required to build the defensible. That is the same “reasonable steps, not unbypassable” logic we unpacked around the VPN surge, applied to the parent instead of the perimeter.
The defensible options cluster into a few patterns, best used in combination: household and device linkage (the consent request lands on a distinct, previously established adult account or device, not a channel the requesting minor controls); a verified adult identity bound to a prior, independent check rather than issued fresh inside the child’s session; a knowledge or possession factor tied to the household; and re-consent friction that makes silent self-approval expensive. None of these is a silver bullet. The point is to make “the child approved their own request” a path the system actively resists and logs, rather than the path of least resistance it is today.
The architecture that survives January 2027
The way through is to give the parent side the same two-tier structure the child side already needs, because the economics are identical: most consenting adults are easy to resolve, a minority are contested, and you do not want to spend maximum friction — or hoard maximum data — on everyone to catch the few.
Lead the parent flow with the lightest resolving check. If the consenting adult is already a known, cryptographically bound account — a returning, verified user, or one arriving through an authenticated handoff — that is a low-friction Check: it confirms adulthood and account continuity without a fresh document upload, and it satisfies the “at least one non-government-ID option” requirement directly. Reserve the higher-assurance Verification — a chip-read document or a mobile driver’s licence with selective disclosure, which returns “over-18” without surrendering the whole document — for the contested band where the light check cannot confidently place the adult. This is the same layered waterfall that governs the child side, pointed at the parent: cheap check first, real verification only when needed, and a deliberate relationship-linkage step layered on top.
Two design commitments make the whole thing hold. First, the parent should not have to re-prove themselves from scratch for every platform and every child. A reusable, privacy-preserving credential — an adult who verified once, presenting a bound proof — collapses the friction that otherwise makes families abandon the flow and drives them toward the self-consent shortcut. Second, retain the assertion, not the evidence: what you keep is a signed, timestamped record that a verified adult granted consent for a specific minor and when — the auditable event a regulator can inspect — not the ID image or the biometric that produced it. If a breach of your consent system tomorrow would yield “a log of consent decisions” rather than “a vault of parent IDs mapped to children,” you have built to the rule instead of around it.
This is the split Xident is built on. A Check — a browser-based age check, on-device liveness, a returning-user lookup, an OAuth handoff — resolves the easy majority of both children and consenting adults cheaply. A Verification — document read plus face match — is the higher-assurance step-up reserved for the contested cases on either side. Keeping those as distinct operations is what lets you verify a parent thoroughly without forcing every household through a document scan, and issuing the result as a reusable credential is what stops a parent from re-uploading for the third app this month.
What to have in place before the clock runs out
The 180-day window closes around January 25, 2027. A parent-side readiness list is short and specific: offer at least one parent-consent path that does not require a government ID; verify both the adult status and the parent-child linkage, not one or the other; instrument your consent flow’s circumvention and fraud rate, because the rule obligates you to account for it and you cannot account for a number you do not measure; collect the minimum data and delete or de-identify it immediately after use; and retain a durable, auditable record of the consent event — alongside the annual accuracy-test results the rules require you to keep for at least five years — rather than the raw material behind it.
The takeaway
For a year, “age assurance” has meant the child gate — estimate the user, escalate the uncertain, keep minors out of what they should not see. New York’s final SAFE for Kids rules quietly redraw the boundary. The consenting parent is now a subject to be verified with the same rigor, and the laziest pattern in the entire category — a consent email the requesting minor can approve themselves — is precisely what the rules were written to end. The platforms that treated the parent as a checkbox are non-compliant by design, and they have until January to notice. The child gate was the easy half. The parent is the part you actually have to build.
Building verifiable parental consent that can survive the SAFE for Kids final rules — and the COPPA 2.0 wave behind them? Talk to Xident — a low-friction Check to resolve most parents, a chip-grade Verification for the contested ones, and a reusable credential so no family pays the friction twice.
