A Five Word Clause in the EU's New Child Safety Proposal Decides Whether Any of It Works

The short answer

The EU KIDS Act is a proposed Regulation that would set one minimum age, 15, for opening a social media account anywhere in the European Union. Children of 13 and 14 could have a guardian-controlled account with a one hour daily cap. It would require every service, platform and software a child can reach to be safe by design rather than safe by settings, and extend the same requirements to app stores, operating systems, online games, AI companions and general conversational chatbots. It would also reverse the burden of proof, so the largest platforms must show the Commission that they are safe for children rather than regulators having to prove that they are not.

It is still at proposal stage, so it is not yet law. It goes next to the European Parliament and the Council, so it is nowhere near a finished document, and there will be changes as it is reviewed. The design takes for granted that the technical foundation is already solved, relying entirely on one claim that a platform can verify a child meets the age requirement without learning anything else about them. The Act states this as a requirement. Nothing deployed at scale in Europe today meets it.

This series of articles does two things. First, it sets out, article by article, what the proposal actually obliges. We then examine the five problems standing between that text and a working system and propose an architecture that would close them. We write the second half as people who have argued for verified personhood as a design principle, and who have also argued that a child's right to privacy is not a fee payable for the right to be protected. One of us built the protocol that second half describes.

Overview

We recommend anyone writing or deciding anything about this law should be reading the primary text rather than a summary of it. There are three documents, all dated 17 September 2026.

The full name is an acronym, EU KIDS stands for Keeping Internet Digital Spaces Accountable and Trustworthy. The legal basis is Article 114 of the Treaty on the Functioning of the European Union, the internal market provision, invoked together with Article 114(3), which requires a high level of protection for health and safety. That choice matters, and we return to it.

Who the Act applies to

Article 2 lists seven categories of service and system:

1. online social networking services,
2. video-sharing platform services,
3. software application stores,
4. online games,
5. operating systems,
6. AI companions,
7. general conversational chatbots.
8. Regulating only individual apps is not enough, because apps and users can easily bypass the rules. By also holding app stores and device operating systems accountable, the law regulates both how an app is downloaded and how it runs on a device making these child safety rules practical to enforce.

Three definitional points that are important to note, but easy to overlook:

1. The definitions of online social networking service, video-sharing platform service, software application store and operating system are drawn from the Digital Markets Act, Regulation (EU) 2022/1925, not from the Digital Services Act.
2. Under the proposed framework, an "AI companion" isn't defined by how a company markets it, but by what it actually does: deliver sustained, personalized interaction that simulates an emotional or social bond. General conversational bots fall into a separate bucket based purely on scope. If a system is built to talk about anything under the sun, it's covered by the rule. If it's designed for a single, narrow task, it gets a pass. That leaves everyday single-purpose tools, customer support bots, checkout helpers, school software, search assistants, and industrial systems safely off the hook.
3. Article 2(6) provides that compliance with this Regulation is deemed compliance with Article 28(1) of the Digital Services Act for the matters it covers. That single sentence converts the Commission's July 2025 guidelines on the protection of minors, which are not binding, into hard, directly applicable obligations with a certified verification layer attached.

The Regulation applies irrespective of where a provider is established, so long as the service is offered to recipients in the Union or the AI system is placed on the Union market. Article 2(4) sets out the exemptions. They cover not-for-profit online encyclopedias, not-for-profit educational and scientific repositories, services run by or for educational establishments for primarily educational purposes, open-source software development and sharing platforms, pure scientific research and development, and services operated by public authorities for their own exclusive use.

The age ladder, and the thing the headlines got wrong

The Commission's own factsheet sets out four bands.

A great deal of the reporting has described this as a ban on social media for under 13s. However, two corrections are worth making.

First, access below the age of 3 is not permitted at all, which is the first time an EU instrument has drawn a line at the toddler end of the range rather than the teenage end.

Second, under 13 is not a total exclusion from the internet or even from video. It is an exclusion from accounts of one's own, on services designed for adults, with a narrow guardian-mediated channel preserved for services built for children. The distinction between having an account and having access runs through the whole proposal, and it is a more careful piece of drafting than it has been given credit for.

Article 6: the five triggers

Article 6(1) does not say that under 15s may not use social media. It says that providers shall not allow a person below 15 to create or use an account where the service poses a risk to the privacy, safety or security of a minor below that age. It then defines that risk, by listing five features. A service meets the test if it has any one of them.

1. It lets account holders transmit content in real time to an indeterminate number of other recipients, including live streaming.
2. It lets account holders contact and interact with recipients outside their pre-existing connections or subscriptions.
3. It uses a recommender system based on profiling within the meaning of Article 4(4) of the General Data Protection Regulation.
4. It uses a recommender system that suggests contacts or content that did not come from a pre-existing connection or subscription.
5. It deploys interface designs or features that enable uninterrupted content consumption, that incentivize interaction, or that send automated notifications designed to prompt the user to start or resume using the service.

Apply that list to any mainstream social product and the answer is not one trigger but four or five. The drafting achieves a general prohibition while remaining, in form, a risk-based rule, which is what Article 114 requires it to be. A service that has none of these five features may lawfully admit under 15s. That is a product design brief, and it is the first time European law has written one this specifically.

It is worth being concrete about what that service looks like, because the Act describes it precisely without ever naming it. No live broadcast to strangers. No contact from anyone the child has not already accepted. No feed assembled from behavior rather than from choice. No suggestions from outside the people they follow. No autoplay, no streaks, no notifications engineered to pull a child back. What remains is a service where a child sees what they asked to see, from people they chose, and leaves when they are finished. The Act does not say whether anyone will build it. It says that anyone who does may lawfully admit children under 15.

The Act does not ban children from social media. It describes, in five clauses, the kind of social media children are allowed to have, and then leaves the industry to decide whether to build it.

Where this leaves us

Four things are settled by the text above. The Union would have one minimum age, 15, for an account of your own, with a guardian-controlled account from 13 and a narrow guardian-mediated channel from 3. The rules reach past social media to app stores, operating systems, games and conversational AI, which is what makes them enforceable. Article 6 does not ban children from social media; it describes, in five clauses, the kind of social media a child may lawfully use. And a service built without those five features may admit them.

What is not settled is whether any of it can be enforced without identifying every child in Europe. That is the subject of part two, which covers safety by design, the enforcement reversal, the deadlines, and the five words in Article 28(3) that decide whether the whole structure stands up.

Safety by design: Articles 8 to 13

Article 8 outlines the default rule services must be designed to the requirements of Chapter III by default, for everyone, and may only derogate for a given user after establishing that the user is an adult using age assurance under Chapter V.

Article 9 addresses addictive design and names four categories of feature that encourage compulsive use:

1. autoplay and uninterrupted consumption without effective and regular interruption moments that let the minor deliberate on whether to continue;
2. notifications not triggered by the minor's own activity;
3. rewarding minors for broadcasting content;
4. streak mechanics that penalize or withdraw benefits for failing to engage on schedule.

Article 9(3) requires time-limited access and usage interruption designed to protect school time and core sleep hours. A provision about sleep, in an internal market Regulation, is a reasonable marker of how far the political consensus has moved.

Article 10 sets four requirements for recommender systems:

1. to give primary weight to a minor's explicitly stated preferences,
2. to disable implicit engagement-based recommendation by default,
3. not to rely on personal data collected from outside the service,
4. to include evaluation metrics capturing quality, safety and mental health outcomes.

Minors must be offered at least one recommender option not based on profiling, offered at account creation, and the interface must not be designed to entice them towards the profiling option.

Article 11 turns five things off by default:

1. geolocation and tracking,
2. microphone and camera access,
3. account recommendations,
4. contact synchronization,
5. push notifications.

Those defaults may only be changed for a minor above 15 who has been clearly informed and has explicitly consented. Article 11(3) goes further than any existing EU instrument by removing features that increase social comparison or misrepresent a minor's image, in particular by disproportionately embellishing or idealizing it. Beauty filters, in other words, named in legislation.

Article 12 sets eight rules for contact:

1. No stranger may initiate direct contact with a minor without pre-approval;
2. minors do not appear in contact recommendations;
3. they cannot be added to groups without explicit agreement;
4. they can block without their identity being disclosed to the blocked account;
5. their content is not accessible to accounts they have not accepted, or to logged-out visitors at all;
6. their contact details are not shared;
7. screenshots and downloads of their content are prevented;
8. they cannot host live streams by default.

Article 13 covers economic transactions and requires:

• real-time disclosure that a transaction is a transaction,
• virtual currency shown in the national currency of the minor's habitual residence,
• a prohibition on designs leading to excessive, impulsive or unwanted spending, expressly including variable reward systems.

AI companions, games and app stores

Article 14 is the provision that will be read most closely outside Europe, because it is the first binding text anywhere that regulates companion AI as a category rather than as an incident of general AI. Providers must avoid design features and system behaviors that simulate interpersonal relations in ways likely to create emotional dependencies. By default the system must not carry information or analysis from a minor's earlier interactions into later ones. Access for under 13s is only through guardian tools. Systems must be evaluated and tested for risks to minors before being placed on the market, and monitored after it, including detection of and response to serious incidents involving minors.

Where a companion or chatbot is embedded in a social network, a video-sharing service or a game, it must not be activated automatically, must not be displayed prominently, minors must not be encouraged to use it, and opting out must be easy and available at any time.

Article 15 extends the anti-addiction, safe-settings and contact rules to online games, and requires safeguards against a game being used to entice minors into contact on other services. Article 16 requires app stores to operate an age-rating system covering every application, to prevent minors from accessing or purchasing applications inappropriate for their age, and to assess age under Chapter V. They must also publish the methodology and sources behind their ratings and, under Article 16(6), allow the EU age verification solution to be offered in the store.

In this next article we examine how enforcement of the proposal will be applied. It is here that some of the gaps begin to emerge. Enforcement onto a currently global system (which to call complex would be a gross understatement) proves difficult. This combined with the public messaging, or lack thereof will become a key factor in difficulty of implementation. As parents/guardians ultimately control the access that children have to the various platforms and technology. The importance of reaching these people with a clear public message cannot be understated for the success of the core tenants of the proposal.

Enforcement: the reversal

The enforcement design is the part of this proposal that changes behavior fastest, because it changes who has to prove what.

Under Article 5, a designated very large online platform among social networking and video-sharing services must file a compliance plan with the Commission, within four months of designation, or within 30 days of the Regulation entering into application for platforms already designated. It must then commission an independent audit of that plan at its own expense, from auditors holding or retaining expertise in child rights and protection, pediatric medicine and child psychiatry, developmental science, age assurance, interface and recommender design, and data protection and security. The auditor reports to the Commission and to the provider simultaneously. A summary must be published. Where the Commission finds shortcomings, a corrective action plan follows within 30 days, with each measure implemented within 60 days.

Supervision is similar to already existing mechanisms Chapter IV of the Digital Services Act covers platforms, app stores and video gaming platforms, and Chapter IX of the AI Act covers AI companions and chatbots. Fines there run under Article 99 of the AI Act to 6 percent of total worldwide annual turnover. Data protection authorities keep competence over the age assurance articles, with GDPR Article 83(5) fines available. Article 35 creates an expedited procedure with a final decision inside 90 working days, and Article 36 introduces an annual supervisory fee which is, among other things, to fund the setting up and operation of the EU Age Verification Scheme.

The single most consequential sentence in the enforcement chapter is not in the enforcement chapter at all. It is in Article 6(4).

Within six months of the Regulation entering into application, providers must establish whether existing account holders are below 15, and disable the accounts of those who are, and of those in relation to whom the age cannot be established.

Every account in Europe, re-established against a threshold, Article 32 has an exception for this if providers can establish with a high degree of confidence that a user is over the minimum age, and requires very large platforms to file a plan explaining how they intend to do so. But the default is unambiguous, and it means the first visible effect of this law on ordinary users will not be a new sign-up flow. It will be a re-verification event across a continent.

The timetable

The dates in the text are still bracketed placeholders, which is normal at this stage. Treat the intervals as firm and the calendar dates as provisional.

The five words

Article 28 is headed Data protection in age assurance. Its third paragraph reads, in full:

Any age assurance measure shall be zero knowledge proof.

Recital 51 outlines this again. Recital 53 goes into detail of the purpose. The use of zero knowledge proof to prevent identity tracking and online linkability. Recital 49 applies the same technique to a different job, proving that an adult holds parental responsibility. The expert panel that advised the Commission President recommended it in July 2026, in almost the same words, and added that age assurance should not lead to the processing of identity documents or biometric data for the purpose of age estimation.

This is, as far as we can establish, the first time a named cryptographic construction has been written into the operative text of a European Regulation as a mandatory property of a compliance measure. That is a significant thing to have done, and it deserves to be taken seriously rather than treated as decoration.

What is zero-knowledge proof?

A zero-knowledge proof is a protocol by which one party convinces another that a statement is true while revealing nothing beyond the truth of that statement. It has three properties:

1. Completeness: if the statement is true, an honest prover convinces an honest verifier.
2. Soundness: if the statement is false, no dishonest prover can convince an honest verifier, except with negligible probability.
3. Zero knowledge: the verifier learns nothing that it could not have computed on its own, knowing only that the statement is true.

Think of the person at the door at a bar. You hand over an identity card, and they see your name, your address and your photograph, when the only fact they needed was that you are old enough. A zero knowledge proof is a door that turns green while the card stays in your pocket. The platform learns that the person in front of it has passed the age it asked about, and nothing else, not the birth date, not the name, not which document was used. And when that person comes back tomorrow, the platform cannot tell they were ever there

Stated precisely, the sentence being proved is not this user was born on 4 March 2011, and not this user is 15. It is that the holder of this device has a valid attestation, issued by an authority on the EU list and not since revoked, saying its subject has passed their fifteenth birthday.

It is worth being precise about what this is not, because three things are routinely described as zero knowledge in the age assurance market and none of them are.

• It is not encryption. Encrypted transmission of a passport image to a vendor who then deletes it is data in transit, protected, and then trusted to be forgotten. The verifier received the data. Zero knowledge means the verifier never receives it.
• It is not pseudonymization. A per-service identifier that is stable across sessions is exactly the linkability the recital sets out to prevent. If two presentations by the same person can be recognized as the same person, the property has not been achieved.
• It is not a deletion promise. A policy commitment to discard evidence after checking it is a governance control. It can be breached, subpoenaed, or quietly amended. A cryptographic property cannot be breached by a change of policy.

The drafting problem, in plain words

Article 28(3) says that any age assurance measure must be a zero-knowledge proof. Age assurance is defined in Article 3 to include age estimation, and the most widely deployed form of age estimation is facial analysis. A facial age estimate cannot be a zero-knowledge proof. The system necessarily receives the face, which is biometric personal data, and derives an estimate from it. The two cannot be reconciled. Facial age estimation is prohibited by Article 28(3) for every purpose under this Regulation, which is a policy decision of some magnitude to have taken in five words in a paragraph headed data protection.

Read loosely, as shorthand for strong data minimization, the words do no work at all, and every vendor in the market will claim them. We have already seen the term used in marketing material for systems that upload an identity document to a server.

Between those two readings sits the version we think the Commission intends and should say. The age signal presented to the relying party must be a cryptographic proof of a predicate, unlinkable across presentations and across relying parties. Whatever evidence established the underlying attestation, whether a passport chip, a national eID, a bank credential or an in-person check at a post office, is processed once by the issuer under its own legal basis and never reaches the relying party. That is achievable. It is not what most of the market sells today. The distinction belongs in the implementing act, not in the recitals.

What exists today, and what does not

The Commission is not starting from nothing, and the work it has done is better than some critics would suggest. In July 2025 it published an age verification blueprint, a white-label, open-source toolbox built on the same specifications as the European Digital Identity Wallet, with an app for both mobile platforms, an issuer, a verifier and a trust validator, all published openly and documented at ageverification.dev. A second release in October 2025 added passport and identity card onboarding. Commission Recommendation (EU) 2026/1035 of 29 April 2026 asked Member States to make a solution available by 31 December 2026. A trusted list is already running on the eIDAS dashboard. Denmark went live in June 2026 and is, at the time of writing, the only entry on it.

The cryptography in that blueprint is also more serious than the debate suggests. The specification now names a zero-knowledge scheme, anonymous credentials over ECDSA, published in 2026 and designed so that existing issuers do not have to change their signing infrastructure, and it uses the word shall. The app is to implement the zero-knowledge path as the preferred presentation method, with plain attestation presentation as a fallback.

Then there is the gap between the specification and the running code, and it is wide enough to matter. In the shipped application the zero-knowledge path has been a test build behind its own button, and the Commission's own age verification manual for the Wallet has described support for it as upcoming. The default live privacy mechanism is not zero knowledge at all. It is batch issuance, a bundle of about thirty single-use attestations, spent one per presentation. That defeats correlation by identifier. It does not defeat correlation by timing, and it is not what Article 28(3) says. The Commission's own published threat model states that the reference implementation is not a production-ready service and accepts by design that a willing adult can always pass a check on a child's behalf.

Three further facts should be on the table before anyone assumes the plumbing is nearly finished:

1. The European Digital Identity Wallet's core identity dataset carries no age threshold attribute at all. It was removed deliberately when the implementing regulation was adopted, so proving age from the Wallet's own personal identification data means disclosing a full date of birth. Threshold proofs come from a separate age attestation, which is exactly what the blueprint supplies. The mini-wallet is not a stopgap beside the Wallet. It carries the credential the Wallet was designed not to carry.
2. The binding technical framework for the Wallet, as amended in July 2026, mandates formats built on salted-hash selective disclosure. Those give attribute minimization and not unlinkability, because the issuer's signature travels with every presentation and is a stable correlator. Sixteen cryptographers, including several of the people who invented anonymous credentials, said so publicly in 2024 and have not been answered on the substance.
3. The blueprint's architecture states plainly that it does not support revocation or re-issuance, because that would add complexity and slow adoption. For an adult-content gate that is arguable. For a scheme that must express a child moving from one band to the next, and must cope with a lost phone, it is not.

What does not yet exist is precisely what Article 29(2) obliges providers to rely on exclusively: an EU Age Verification Scheme, a public-authority certification route operating in more than one Member State, and the two EU lists that Article 30 requires the Commission to maintain. The trusted list running today was created under a non-binding Recommendation; the Article 30 lists are a different instrument, populated by certification against a Scheme that has not been adopted. And the deployed application is, in its current form, an over-18 proof for adult content, not a ladder of 3, 13 and 15 with a guardianship relationship attached to it.

Anyone telling a board that the EU app already satisfies the KIDS Act has not read Article 29. The honest position is that the Act's central mechanism is a specification the Commission has committed to write, on a timetable shorter than the legislative process that will produce the Act itself.

Where this leaves us

The obligations in part one are enforced by the machinery in this part. There is a compliance plan filed with the Commission, an independent audit paid for by the platform, fines reaching 6 percent of worldwide turnover, and a six month clock on every account that already exists. All of it depends on age assurance that satisfies Article 28(3).

Five words carry that weight. Nothing deployed at scale in Europe meets them today, the certified scheme they point to has not been adopted, and the wallet everyone cites deliberately carries no age attribute. Part three sets out the five problems standing between the text and a working system, and what we think should be built.

Five problems between the text and a working system

We set these out as problems rather than objections. Each is solvable. None is solved.

One. Proving a predicate without producing a person

Almost every age check in production today works by establishing identity and then discarding it. The document is read, the face is matched with the document, the date of birth is extracted, the threshold is computed, and the evidence is deleted according to a retention schedule.. Article 28(1) does not ask for a promise. It says age assurance solutions shall not enable the identification of the recipient, nor locate, track, target, advertise to or profile them. That standard can only be met by a system in which the relying party is structurally incapable of identification, because the only thing it ever receives is a proof of a predicate..

Two. Unlinkability, in both directions and over time

There are three distinct linkability risks:

1. The relying party must not be able to recognize the same holder across two presentations. Otherwise, the age proof becomes a stable identifier, which is worse than the cookie it replaces, because it is attached to a verified human being.
2. The issuer must not learn where the attestation was presented. If the age is checked by calling back to the authority that issued it, the state acquires a log of which child visited which service, which is a far graver privacy harm than the one the Act sets out to prevent. The blueprint's design goal of ending communication with the issuer after issuance is the right instinct and should become a requirement.
3. Colluding relying parties must not be able to correlate presentations with each other, whether by a shared identifier, by proof reuse, or by timing.

The last of these is where naive implementations fail. Issue a holder a batch of single-use tokens and you have defeated correlation by identifier while leaving correlation by timing wide open, particularly for small populations. A fourteen-year-old in a village of four hundred people is not anonymous because their token was fresh.

The European Data Protection Board has already established protocol and requirements in this regard, in its statement on age assurance of February 2025. It recommends device-based architectures delivering unlinkability and selective disclosure and says that batch-issued single-use credentials or zero-knowledge protocols should be made available where the privacy risk is high. Then it adds: the unlinkability should hold even in the case of collusion or a data breach. No national framework in Europe currently meets that standard on its own terms. For example the French regulator says in its own technical reference that its scheme is not anonymous in the sense of the General Data Protection Regulation, and the French data protection authority asked for the properties to be guaranteed under breach and collusion and did not get it.

Three. The guardianship link, and the families it will exclude

Articles 6 and 7 require a guardian to create and control a minor's account, and Article 26 outlines details for providers on how to establish that the adult in front of them actually holds parental responsibility. The options are signals from official databases, signals the provider already holds from past engagement, and, until the Commission adopts a delegated act, self-declaration. Article 31 then obliges Member States to provide at least one free, privacy-preserving electronic means for a guardian to obtain and present an attestation of parental responsibility, based on authentic sources, disclosing nothing beyond the confirmation that parental responsibility exists.

This is a harder cryptographic object than age. Age is a predicate about one person. Guardianship is a predicate about a relationship between two people, at least one of whom is a child, and the proof has to be presented by one of them about the other without identifying either. It also has to survive the ordinary complexity of family life: separation, shared custody, kinship care, foster placement, a grandmother raising a grandchild under an informal arrangement recognized by a local authority and by no database in the country.

Article 31(2) requires the means to be effectively accessible to all, expressly including persons with limited digital access or skills and families in vulnerable situations such as refugee and displaced families. Article 31(3) requires Member States to provide alternative procedures where parental responsibility cannot be demonstrated through standard civil status documentation. Those two paragraphs are, in our view, the most important sentences in the Regulation for children's rights, and they are the ones most likely to be under-resourced in implementation. A protection regime that quietly excludes undocumented, displaced and informally-cared-for children from the online world is not protecting them. Article 24 of the Charter takes the best interests of the child as a primary consideration, and the best interests of a displaced fourteen-year-old are not served by a proof system that has no path for her.

Four. The audit paradox

Article 5 requires a platform to prove, to an independent auditor and then to the Commission, that its age assurance works. Article 28(1) forbids it from keeping the records that would ordinarily constitute that proof. A compliance function asked to demonstrate that a hundred million checks were performed correctly, while being prohibited from retaining anything that identifies a single one of them, is being asked to produce evidence without a witness.

The tension is not new, it is inherited. Article 28(3) of the Digital Services Act, a provision almost never quoted in this debate, says that compliance with the duty to protect minors shall not oblige providers to process additional personal data in order to assess whether a recipient is a minor. The KIDS Act now requires exactly that assessment. Reconciling the two is only possible if the assessment produces a proof rather than a dossier, and if the evidence of compliance is built the same way.

This is genuinely novel and it has no off-the-shelf answer. It is also, we would argue, the most interesting engineering problem in the whole proposal, because the solution is not a compromise between the two requirements. It is a different kind of record, one that is verifiable in aggregate and empty in particular.

Five. Redress, when the proof says no

Article 29(5) gives every recipient the right to complain, free and by electronic means, where they believe the outcome of an age check was wrong. Consider what that requires. A sixteen-year-old is refused. She wants to appeal. The system has kept nothing about her, by design. On what basis is her appeal decided, and by whom, and how does she prove she is sixteen to the appeal body without handing over precisely the identity data the architecture exists to protect?

The obvious answer, that she simply repeats the check, is not an answer if the reason for the refusal is a defect in the check itself. It might be a document her country issues in a format the system reads badly, a name in a script the pipeline mangles, a disability that defeats a liveness test. Every age assurance system in production today has a failing population, and the people in it are disproportionately those who are already least able to argue with an institution. A right of complaint without a mechanism behind it is a right on paper.

We are not speculating about the size of that population. The United States National Institute of Standards and Technology has been running a rolling evaluation of facial age estimation across more than fifty algorithms and roughly eleven million photographs. Its headline is that mean absolute error has fallen from about 4.3 years to about 3.1. Its findings underneath the headline are the ones that matter here. Error rates near a threshold vary by two orders of magnitude between submitted algorithms. They rise by roughly a factor of ten as a subject ages from 14 to 20, which is to say they are worst exactly where a teenage threshold sits. For most algorithms tested, false positive rates are markedly lower for men than for women, and they differ substantially by region of birth, in some pairings by more than an order of magnitude. NIST itself warns that mean absolute error is not an appropriate metric for age verification at all. And it notes that the thresholds relevant to online child safety, the 13 to 16 band, are still to be addressed in a future report. The thresholds this Regulation is built on are the ones the world's reference evaluation has not yet measured.

The regulator with the most operational experience has already found the redress gap in practice. In its statutory report of July 2026, covering more than 69 million age checks, the United Kingdom's communications regulator reported that only six services were able to provide any data at all on how many appeals they had upheld. Many services offer no appeal route, and in some cases a user's only option is to try the same method again. That is the state of the art we are proposing to make mandatory across a continent.

Does any of this work?

A piece written by people who build trust infrastructure has an obligation to say where the evidence currently stands, including where it is uncomfortable.

Age assurance demonstrably works at the level of the individual service. Where it is deployed properly, traffic from minors to that service falls. The same regulator's finding, from the same report, is that it is not yet working at the system level, because users migrate to services that have not deployed it, and that the proportion of children encountering harmful content online has not changed.

Australia's under-16 restriction is the closest thing to a natural experiment. Survey work published through the National Bureau of Economic Research found that four months in, around two thirds of 14- and 15-year-olds had used a banned platform in the previous week, and that three quarters considered circumvention easy. Independent measurement of United States state-level age verification for adult sites found that of the activity that existed before restrictions, roughly half simply moved to non-compliant sites, roughly a third persisted through circumvention tools, and about one part in ten stopped.

And the documented harm from the checks themselves is not hypothetical. In 2025 a major messaging platform disclosed a breach at a third-party support vendor that exposed tens of thousands of government identity photographs. Those documents existed because users had submitted them to appeal age-related restrictions. A Spanish data protection authority fined a leading age assurance vendor most of a million euros in early 2026, finding that matching a live selfie against a stored template is identification rather than mere authentication. When the same regulator that ran the 69 million checks asked adults who had abandoned them why, 94 percent gave a data-related reason and 71 percent said plainly that they did not trust the third-party providers.

We draw two conclusions from this, and they point the same way. First, an age assurance regime that requires people to hand over identity documents will be circumvented by the determined and abandoned by the cautious, and will build exactly the databases that make the next breach worse. Second, the case for the architecture Article 28(3) gestures at is not that it is elegant. It is that it is the only version of this policy that does not make the problem it is solving worse. That is why the five words matter more than the age number everyone is arguing about.

What we propose

We should say plainly what our interest is and what our protocol does today. The Trust Identity Protocol, developed by The AI Lab, is an open standard for proving that a real human being stands behind an identity and for declaring how a piece of content was made. It signs with post-quantum cryptography, ML-DSA-65 under FIPS 204, from the browser through the verification provider to the network. It hashes with SHAKE-256. Its genesis state is sealed with SLH-DSA. It runs a zero-knowledge circuit today, a proof used to prevent one person holding two identities without the network ever seeing the underlying identity data. It records to a federated network under Byzantine fault tolerant consensus, and it carries a six-role human adjudication system for contested records.

It does not do age assurance. Not today, not in any form. TIP verifies adults, and the age rule in the current implementation is a checkbox. We are not describing a product that is ready for this law, and we are not claiming certification under a scheme that does not yet exist and whose certification decisions belong to public authorities and notifying Member States, not to us.

What we are proposing is an extension, and we are publishing it as a contribution to the implementing-act debate rather than as a sales document. We describe it here as a profile, a defined way of using the protocol for attestations about a person's attributes and about the integrity of a compliance process, rather than about the provenance of a file. Seven components.

One. Issuance once, from an authentic source, with a human path

The attestation is minted by an issuer on the EU list, from an authentic source: a passport chip, a national eID, a bank or mobile credential, or an in-person check at a counter for the people whom none of those reach. This is the only moment at which identity documents are processed, it happens under the issuer's own legal basis, and it happens once rather than once per service. The offline path is not an afterthought. It is the difference between a system that covers a population and a system that covers the documented part of one.

Two. The proof is computed on the holder's device

The attestation lives in the holder's wallet, wrapped by the device's secure element. When a service asks, the device computes a proof of the predicate and hands over the proof. Nothing leaves the device but the proof. TIP already wraps keys this way, through a WebAuthn platform authenticator with a password-based recovery path for the real-world case where a platform credential disappears. A child's proof of age must not be destroyed by a lock screen change, which is an unglamorous requirement that decides whether a system survives contact with actual families.

Three. Fresh proof per presentation, and a defense against timing

Each presentation produces a new proof with no reusable identifier. Where a device is too weak to compute a proof at interactive speed, and many of the devices children actually use are, the fallback is a pre-computed batch, obtained in a way that does not tell the issuer where the batch will be spent. Batches must be large enough, and refreshed on a schedule that is independent of use, so that the moment of refresh does not itself become a signal.

Four. Bands, rollover and revocation

The proof asserts a band, not an age: below 13, 13 to 14, 15 to 17, 18 and over. Bands expire at their own boundary. A stored age signal of the kind Article 28(4) permits must carry that expiry. Without it a platform will still be treating a seventeen-year-old as fifteen years old two years after the check, and, more seriously, a fourteen-year-old as fourteen when she has become entitled to her own account. Revocation for a lost or stolen device must be available without the revocation list becoming a register of children.

This is the component the current European toolbox explicitly does not have. Its architecture document states that the solution does not support revocation or re-issuance, on the reasoning that adding them would slow adoption. For a single adult threshold that is a defensible trade. For a ladder with boundaries at 13 and 15, crossed by every child in Europe twice, it is not a trade at all, it is a missing requirement.

Five. A log of counts, not of people

This is our answer to the audit paradox. The platform writes, to an append-only transparency log, a periodic signed statement saying that in this period, this many age checks were performed, this many succeeded, this many failed, this many were appealed, against these issuer keys and this scheme version. Each statement commits to the underlying set cryptographically, so that it cannot be revised later, while containing nothing that identifies any person. The auditor verifies the commitments, checks that the counts reconcile with the platform's own account-creation figures, and can compel the platform to open a random sample of proofs for validity checking without those proofs identifying anybody. The record is verifiable in aggregate and empty in particular.

TIP's network already does the hard part of this. It exists to make signed statements permanent, publicly verifiable and impossible to revise quietly after the fact. Pointing that capability at compliance evidence rather than at content provenance is a profile, not a new protocol.

Six. The compliance artefact Article 5 asks for

From that log, a platform can generate what Article 5 actually demands: a signed, timestamped bundle showing which certified solutions were used, in which periods, against which scheme version and which issuer keys, with what outcome rates, and what happened when something failed. Today that document is assembled by hand from screenshots and vendor assurances. It should be an artifact.

Seven. A redress path with a human being at the end of it

A refused user should be able to lodge an appeal that carries a proof that a refusal occurred, without carrying her identity, and have it examined by a person. TIP already implements a staged human adjudication ladder, with reviewers, a seeded jury and an expert panel, built for disputes about content. The same machinery answers Article 29(5), and it should be paired with a rule the Act does not currently contain, that the fallback route offered to a person the automated system refuses must not require more personal data than the route that was refused, only different data. Otherwise, every failure quietly converts into a demand for a passport, and the people who fail are the people least likely to have one.

Seven things the implementing act should specify

Article 30(2) empowers the Commission to adopt implementing acts laying down the specifications for the EU Age Verification Scheme, and it is there, not in the Regulation, that this law will be made to work or not. We would put seven items on that list.

1. A definition of zero knowledge proof for the purposes of Article 28(3), stated as testable properties rather than as a named scheme: predicate-only disclosure, unlinkability across presentations, unlinkability across relying parties, and issuer-blindness at presentation.
2. An explicit statement of where age estimation may and may not be used, resolving the tension between the literal words of Article 28(3) and the definition of age assurance in Article 3(1)(i).
3. A required set of age bands, including 13 and 15 and not only 18, so that the ladder in Articles 6 and 7 can actually be expressed by a certified attestation.
4. A machine-readable format and a public endpoint for the two EU lists under Article 30(1), with key rotation and revocation semantics, so that verification does not require a call to the issuer.
5. A specification for the Article 29(6) operating system age signal: what may be shared, on what consent, with what expiry, and with what prohibition on re-use for any purpose beyond the check.
6. An evidence standard for Article 5 audits that does not require retention of personal data: aggregate commitments, sampling, and reconciliation, so that compliance can be proved without surveillance.
7. A crypto-agility requirement with a migration path to post-quantum proof systems, and a rule that attestations issued under one version remain verifiable under the next.

What a platform should do in the next six months

The legislative process will take longer than this, and the age threshold may move. None of the following is wasted if it does:

• Run the Article 6(1) test honestly against each product surface and record the answer. If a surface has none of the five features, that is a strategic asset and should be understood as one. If it has four, the product decision is now a board-level question rather than a compliance one.
• Inventory every existing account against an age signal you can already justify, and find out how large the unknown population is. That number, not the sign-up flow, is the Article 6(4) exposure.
• Do not procure an age verification vendor on the promise of KIDS Act compliance. Nothing can be compliant with Article 29(2) until the Scheme and the lists exist. Procure for integration and for exit instead. Can you swap the attestation provider without re-enrolling your users?
• Decide now whether the AI features embedded in your product are AI companions within the meaning of Article 3, and whether they are activated by default. Article 14(2) makes default activation itself the infringement.
• Build the audit record now, in the shape the Act will want, rather than reconstructing it later. Evidence gathered after the question is asked is worth a fraction of evidence generated as the thing happens. That is the same lesson the Digital Services Act taught the first cohort of designated platforms, and it was expensive for them.

Where the argument still is

Three honest disagreements remain live, and a reader deciding what to support should know about them.

The threshold. The expert panel recommended an EU-wide restriction below 13, with optional national precaution above that. The European Parliament, in its resolution of 26 November 2025, called for 16 as the default with parental authorization as the exception, and 13 as an absolute floor. The Commission has proposed 15. Any summary saying the proposal implements the panel's recommendation on age overstates the alignment; it landed between the panel and the Parliament, and the Council will pull at it from both sides.

Exclusion. Every mandatory verification regime has a failure population, and this one will be measured against Article 24 of the Charter. In March 2026 more than four hundred security and privacy researchers across thirty-two countries signed an open letter warning that age assurance as currently conceived risks excluding the elderly, non-citizens, people without a national digital credential, asylum seekers and undocumented people. The French regulator's own technical reference sets a coverage floor of 80 percent of the adult population for its privacy-preserving route, which is an admission in writing that as many as one adult in five may be left to the less private path. The safeguards in Article 31(2) and 31(3) are the answer to this, and they depend entirely on national implementation budgets rather than on anything the Commission can enforce directly.

Expression. Article 42(1)(d) commits the Commission to evaluate the impact of the Regulation on freedom of expression and information by 2030. That clause exists because the risk is real. A proof-of-age layer in front of ordinary speech is an access control on public discourse, and the case for it rests on the proposition that it can be built so that nobody learns who spoke. If that proposition turns out to be false in implementation, the safeguard clause is where the reckoning will be recorded.

Why we think this is worth getting right

There is a version of the next two years in which Europe requires age assurance everywhere, the specification arrives late and loosely drawn, the market fills the gap with document uploads and face scans, and a continent's children are cataloged in the name of protecting them. There is another version in which the five words in Article 28(3) are taken at face value, the implementing act gives them testable meaning, and Europe ends up with the first piece of digital infrastructure that proves a fact about a person while learning nothing about them.

The difference between those two futures is not political will. The political will is evident: an expert panel, a Parliament resolution, twenty-five Member States signing a declaration, and now a Regulation. The difference is whether the technical work is done properly and early, by people who will say out loud which parts do not exist yet.

That is the spirit in which we offer the architecture above. It is not finished. We would rather it were argued with than adopted quietly.

Frequently asked questions

What is the EU KIDS Act?

A proposed EU Regulation, published by the European Commission on 17 September 2026 as COM(2026) 681 final. It sets a harmonized minimum age of 15 for creating a social media account, requires safety by design for services minors can reach, and extends those duties to app stores, operating systems, online games, AI companions and chatbots. It also harmonizes the rules for age assurance. KIDS stands for Keeping Internet Digital Spaces Accountable and Trustworthy.

Is the EU KIDS Act law yet?

No. It is a Commission proposal at the start of the ordinary legislative procedure. It must be agreed by the European Parliament and the Council, and it will be amended. Once adopted it enters into force twenty days after publication in the Official Journal and generally applies six months after that.

What is the EU KIDS Act age limit?

Fifteen for an account of one's own. Thirteen- and fourteen-year-olds may have a guardian-created account with limited features and a maximum of one hour a day. Children from 3 to under 13 have no account of their own, and may access video-sharing services designed for their age group through a guardian's account, also capped at an hour a day. Below 3 there is no access at all.

Does the EU KIDS Act ban social media for under 13s?

It bans accounts, not access. A child under 13 cannot hold a social media account and cannot be the holder of one created for them, but guardian-mediated access to child-specific video-sharing services remains possible under Article 7 with recommender systems and personalization switched off.

What does the EU KIDS Act require for age verification?

For the minimum age rule in Article 6, providers must rely exclusively on an EU age verification solution using an EU proof of age attestation issued by a third party, certified as conforming with the EU Age Verification Scheme by a public authority, and listed by the Commission. Self-declaration is expressly excluded. For the broader safety-by-design duties, other age assurance methods may be used if they meet the requirements of Articles 27 and 28.

What does Article 28(3) of the EU KIDS Act mean?

It states that any age assurance measure shall be zero knowledge proof. The relying party should learn only that an age threshold is met, and should be unable to identify, locate, track, profile or recognize the person across presentations. The precise technical meaning is left to the implementing acts under Article 30(2), and resolving it is the central unfinished task of this Regulation.

What happens to existing accounts?

Article 6(4) requires providers, within six months of the Regulation entering into application, to establish whether existing account holders are below 15 and to disable the accounts of those who are and of those whose age cannot be established. Article 32 allows verification to be skipped where the provider can establish with a high degree of confidence that the user is above the minimum age.

Does the EU KIDS Act apply to AI chatbots?

Yes. AI companions and general conversational chatbots are in scope in their own right under Article 2, and Article 14 requires them to avoid designs likely to create emotional dependency and to not carry over a minor's earlier interactions by default. They must gate under-13 access through guardian tools, and be tested before release and monitored after it. Where a chatbot is embedded in another service it must not be activated by default or displayed prominently to minors.

What are the penalties under the EU KIDS Act?

Enforcement borrows existing machinery. For platforms, app stores and video gaming platforms, Chapter IV of the Digital Services Act applies. For AI companions and chatbots, Chapter IX of the AI Act applies, with fines under Article 99 of that Regulation up to 6 percent of total worldwide annual turnover. Data protection authorities keep competence over the age assurance articles, with GDPR Article 83(5) fines available. Article 35 provides for expedited decisions within 90 working days.

Is the EU age verification app zero knowledge?

Partly, and less than the policy language implies. The specification names a zero-knowledge scheme based on anonymous credentials over ECDSA and requires apps to implement it as the preferred presentation method. In the shipped application it has been available as a test path rather than the live default, and the Commission's own wallet documentation has described support as upcoming. What runs in production today is batch issuance: a bundle of roughly thirty single-use attestations, spent one at a time. That prevents a relying party from recognizing a returning user by a reused identifier. It does not by itself defeat correlation by timing, and it is not the same property as a zero-knowledge proof.

Does age verification actually reduce harm to children?

The honest answer is that it reduces access to the services that deploy it, and has not yet been shown to reduce system-level access or harm. The United Kingdom regulator's statutory report of July 2026, covering more than 69 million checks, found age assurance effective at the individual service level and not yet effective at the system level, because users migrate to services without it. It reported no change in the proportion of children encountering harmful content. Survey evidence from Australia's under-16 restriction found a majority of 14- and 15-year-olds still using banned platforms months after it took effect. This is an argument for getting the architecture right, not for abandoning the objective.

How does the EU KIDS Act relate to the Digital Services Act?

It specifies and complements it. Article 2(6) provides that compliance with the KIDS Act is deemed compliance with Article 28(1) of the DSA for the matters it covers. That turns the Commission's July 2025 guidelines on the protection of minors from non-binding guidance into hard obligations with a certified verification layer attached.

Primary sources

• Proposal for a Regulation, EU KIDS Act, COM(2026) 681 final, 17 September 2026, procedure 2026/0286 (COD). https://ec.europa.eu/newsroom/dae/redirection/document/132530
• Communication, An EU approach to online child safety, COM(2026) 680 final, 17 September 2026. https://ec.europa.eu/newsroom/dae/redirection/document/132528
• Commission Staff Working Document, Analysis of Impacts, SWD(2026) 681 final, 17 September 2026. https://ec.europa.eu/newsroom/dae/redirection/document/132529
• European Commission, KIDS Act policy page. https://digital-strategy.ec.europa.eu/en/policies/kids-act
• European Commission, The KIDS Act explained, FAQ, 17 September 2026. https://digital-strategy.ec.europa.eu/en/faqs/kids-act-explained
• Press release IP/26/1890 and factsheet FS/26/1891, 17 September 2026. https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1890
• Report by the Co-Chairs of the Special Panel on Child Safety Online, July 2026. https://commission.europa.eu/document/download/d833504d-5ec3-4fac-945f-38e7d0bd5326_en
• European Parliament resolution on the protection of minors online, P10_TA(2025)0299, 26 November 2025. https://www.europarl.europa.eu/doceo/document/TA-10-2025-0299_EN.html
• The Jutland Declaration, Shaping a Safe Online World for Minors, 10 October 2025. https://www.digmin.dk/Media/638956829775203140/DIGMIN_The%20Jutland%20Declaration%20Shaping%20a%20Safe%20Online%20World%20for%20Minors%20101025.pdf
• Commission guidelines on the protection of minors under Article 28(4) DSA, C/2025/5519, OJ 10 October 2025. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:C_202505519
• EU age verification blueprint and technical toolbox. https://digital-strategy.ec.europa.eu/en/factpages/blueprint-age-verification-solution-help-protect-minors-online and https://ageverification.dev/
• Commission Recommendation (EU) 2026/1035 on a common framework for EU wide age verification technologies, 29 April 2026, OJ L of 8 May 2026. https://eur-lex.europa.eu/eli/reco/2026/1035/oj
• EU age verification technical specification, including Annex B on zero-knowledge proofs, and the published threat model. https://github.com/eu-digital-identity-wallet/av-doc-technical-specification
• EU Age Verification Trusted List, eIDAS dashboard. https://eidas.ec.europa.eu/efda/trust-services/browse/av-tl
• European Data Protection Board, Statement 1/2025 on age assurance, adopted 11 February 2025. See in particular paragraph 34. https://www.edpb.europa.eu/our-work-tools/our-documents/statements/statement-12025-age-assurance_en
• Ofcom, report on the use of age assurance under section 157 of the Online Safety Act 2023, 16 July 2026. https://www.ofcom.org.uk/online-safety/protecting-children/
• NIST, Face Analysis Technology Evaluation, Age Estimation and Verification, NISTIR 8525, rolling revision. https://pages.nist.gov/frvt/reports/aev/fate_aev_report.pdf
• Frigo and shelat, Anonymous Credentials from ECDSA, IACR Communications in Cryptology, 2026, the scheme named in the EU specification. https://github.com/google/longfellow-zk
• Open letter of security and privacy researchers on age verification, March 2026. https://csa-scientist-open-letter.org/ageverif-Feb2026