Most age-assurance law is written in adjectives. The UK’s Online Safety Act asks for methods that are “highly effective.” COPPA asks for “reasonable” efforts. State after state has settled on “commercially reasonable and technically feasible.” These phrases are legally load-bearing and engineering-useless: you cannot unit-test an adjective, you cannot certify against one, and you cannot defend one to a regulator who has decided, after the fact, that your reasonable was not reasonable enough.
New York just tried to fix that. In its proposed rules to implement the Stop Addictive Feeds Exploitation (SAFE) for Kids Act, the Office of the Attorney General did something no US authority had done before: it attempted to convert “reasonable age assurance” into a measurable, certifiable, auditable specification. The Knight-Georgetown Institute, which submitted formal comments, called it “the most significant effort to date by a US public authority to operationalize an age assurance mandate.”
The comment period closed on December 1, 2025. The OAG now has up to a year to finalize, and the law takes effect 180 days after the final rules publish — so this is not yet enforceable, and the text will move before it lands. But the timeline is the least interesting thing about it. What matters for anyone who has to build age assurance is that New York wrote down, in numbers and named standards, what the rest of the regulatory world has only gestured at with adjectives. This is the draft that turns age assurance into a spec sheet, and it is worth reading as one.
First, Scope It Down — This Is a Feed Gate, Not a Door
Before the engineering, the scoping, because the most expensive mistake here is over-building. The SAFE for Kids Act does not require you to verify age at the front door. It regulates two specific features for users under 18: algorithmically personalized “addictive” feeds, and nighttime notifications between 12:00 a.m. and 6:00 a.m. ET. A minor can still use the platform, search it, and see all the same content — they just get a non-algorithmic feed (follows-only or chronological) unless a parent consents. The rules apply to operators of user-generated-content platforms whose users spend at least 20% of their time on addictive feeds. Penalties run up to $5,000 per violation.
That scoping has a direct architectural consequence. Age assurance here is an eligibility check for a feature, not a gate on access. You are not blocking entry; you are deciding whether to serve the personalized feed or the chronological one. If you architect this as a hard verification wall on signup, you have built the wrong system and imported a conversion problem the law never required. The correct mental model is the one Discord arrived at independently when it rebuilt its age assurance around silent determination: segment the population, serve the safe default to anyone you can’t clear, and spend real verification budget only where it changes an outcome.
“Commercially Reasonable” Was Never a Spec
The reason this rulemaking matters is that the standard it replaces is unbuildable. Tell an engineering team to ship “commercially reasonable” age assurance and you have handed them a requirement with no acceptance criteria. Reasonable by whose benchmark? Measured how? Passing at what rate? The team picks a vendor, the vendor asserts it is accurate, and everyone discovers the real definition of “reasonable” only when a regulator litigates it years later. That is not a compliance program; it is a deferred argument.
Vague standards also fail asymmetrically. They are cheap for the regulator to write and expensive for the operator to satisfy, because the burden of proof lands on you at the worst possible moment — during an enforcement action, reconstructing what you did and why. We have written before about how age-assurance enforcement increasingly turns on evidence rather than intentions. An adjective gives you nothing to evidence. A spec gives you something to test, log, and produce. New York’s draft, whatever its flaws, is an attempt to move the proof forward in time — to let you demonstrate compliance before you are accused of failing it.
The Five Things New York Made Measurable
Strip the draft down to what an architect actually has to satisfy, and five requirements stand out. Together they are the closest thing the US has to a buildable age-assurance specification.
1. A certified accuracy floor, tested annually. The rules require operators to offer one or more age-assurance methods, at least one of which meets a “total accuracy minimum” demonstrated through annual certification and testing. This is the load-bearing shift: accuracy stops being a vendor’s marketing claim and becomes a number you certify against and re-test every year. The draft also requires you to retain records of those tests — including false positives, false negatives, inconclusive results, and the circumvention attacks you tested — so the accuracy claim is auditable, not asserted.
2. Certification against named international standards. Rather than invent its own conformance regime, the draft points at existing technical standards — ISO/IEC 27566 (the international age-assurance standard) and IEEE 2089.1, or equivalents. This is the first time a US age-assurance rule has anchored itself to a testable external standard instead of a homegrown adjective. For vendor selection that is a gift: “are you certified to ISO/IEC 27566?” is a question with a real answer, where “are you accurate?” never was.
3. Circumvention resistance as a metric. The draft treats resistance to circumvention as something you measure, with the working version setting a high quantitative bar (on the order of detecting 98% of attempted circumventions). Whether a hard percentage is the right instrument is genuinely contested — more on that below — but the intent is clear: a method that a determined 14-year-old defeats with a borrowed device or a 3D avatar is not “effective” no matter how accurate its underlying model. Circumvention is now part of the test plan, not an afterthought.
4. A 10-year evidence trail. Operators must keep records of method usage, outcomes, and testing results for a minimum of ten years. Read that as an architecture requirement, not a filing requirement. Your age-assurance system now needs a durable, queryable audit log of decisions — what was checked, when, by which method, with what result — retained for a decade. If your design throws away the decision after it gates the feed, you have a gap you will have to retrofit under pressure.
5. Method pluralism, a non-ID path, and an appeals route. You cannot make government ID the only way through. The draft requires at least one age-assurance option that does not depend on a government-issued ID (and, where you do accept ID, you must accept non-US documents too), plus an appeals process for users wrongly classified as minors — and that appeal cannot itself be ID-only. This is accessibility and fairness encoded as a requirement: a system that works only for people holding a particular country’s driver’s license is not compliant, however accurate it is for them.
The Inconclusive-Result Rule Is the One to Read Twice
Buried in the draft is the provision that separates people who have actually built verification from people who have only specced it. When a method returns inconclusive and you have no actual knowledge that the user is a minor, you may presume the user is an adult — but only if all required methods were completed and at least one met the total-accuracy minimum. That is not a checkbox. It is a state machine with a default-deny posture and a documented escape hatch.
It forces three design decisions most teams defer. What counts as “inconclusive” versus “fail” for each method? Which methods are “required” before the adult presumption is allowed to fire? And how do you log that the presumption was applied legitimately — that the conditions were met — so you can reproduce the decision a decade later when it is the only thing standing between you and a per-violation penalty? If you have ever built a real verification flow, you know inconclusive results are the majority of your hard cases, not an edge case. New York wrote a rule specifically about them, which is a good sign the people drafting it talked to people who ship.
What This Does to Vendor Selection
The practical effect of a spec is that it changes what you are buying. Under an adjective standard, you buy a widget and a confident sales deck. Under New York’s draft, you are buying a certifiable, testable, auditable system — and the questions you put to a vendor change accordingly. Can you produce a current certification against ISO/IEC 27566 or an equivalent? What is your measured accuracy by age band, and will you stand behind it in an annual test you don’t control? What is your false-positive rate near the 18 boundary, where every estimation method is weakest and the NIST FATE benchmarks show real divergence between providers? Do you expose a decision-level audit log I can retain for ten years, or do you hand me a yes/no and keep the reasoning?
These are the questions our vendor security checklist already argues you should ask of any provider; New York’s draft is what happens when a regulator agrees and writes them into law. A vendor that cannot answer them was always a risk. Now the risk has a price tag and a statute number.
The Honest Limits
Three caveats keep this from being a victory lap. First, the rules are not final and will change. The KGI comments — and they are worth reading — argue the draft is technically improvable in specific ways: move circumvention detection from a brittle quantitative metric to a qualitative certification standard (a fixed 98% can be both gamed and missed in ways a percentage hides), require that certification reports be complete and public so anyone can verify them, and require zero-knowledge proofs once mobile operating systems support them so that age can be proven without revealing identity. That last point matters: a spec that mandates accuracy without mandating data minimization can push operators toward collecting more than they should. Quantifying a requirement is progress; quantifying the wrong requirement precisely is its own failure mode.
Second, accuracy and availability trade off, and a floor set too high excludes real users. Every age-estimation method has an error band, and tightening the accuracy requirement to eliminate false adults also produces false minors — adults wrongly downgraded to a chronological feed. The appeals route exists precisely because that error is unavoidable, and a serious implementation treats it as a number to manage, not a corner case to ignore.
Third, this is one state. New York’s draft does not harmonize the US compliance patchwork; in the near term it adds a well-specified node to it. The bet worth making is that a measurable standard from the most-watched state AG becomes a template others copy, the way Ofcom’s “highly effective” language propagated — which is exactly why building to it now is cheaper than retrofitting to it later.
How Xident Fits
New York’s draft reads like a description of an architecture we already build toward, because the spec and the right design converge on the same place. Xident does threshold classification across bands (+12, +15, +18, +21, +25), so the same integration that decides “old enough for an addictive feed” also serves a 13+ rule or a 21+ gate without a second mechanism. Most users clear a threshold through on-device facial age estimation that returns a band in seconds and never sends a face to your servers, with a buffer-zone escalation to stronger evidence only near the boundary — the design that keeps both accuracy and availability high where the law cares most.
On the requirements that are hardest to retrofit, the fit is direct. The non-ID path the rules mandate is the default in this model, not a bolted-on alternative. The 10-year evidence requirement is met by retaining the decision — an exportable, session-level record of what was verified, when, and how — rather than warehousing the documents and biometrics that turn a compliance system into a breach liability. And because the result is a durable, bound, privacy-preserving age assertion, a user can verify once and present it again rather than re-running a check at every wall, while the appeals and inconclusive-result paths the draft demands are decisions the flow already records. For the parental-consent half of the law, our verifiable parental consent guide covers the flow the rules require — minor pre-consent, parent notice, multi-method consent, easy withdrawal.
The shift underneath all of this is the one worth internalizing: age assurance is moving from a thing you assert to a thing you certify. New York wrote the first US spec sheet for it, flaws and all, and the operators who treat it as an engineering document rather than a legal one will be the ones who can answer the test instead of arguing about the adjective.
If you want to build to a measurable age-assurance standard instead of a vague one, start here.
