On 16 September 2026, Ursula von der Leyen used her State of the Union address in Strasbourg to announce the EU KIDS Act, short for Keeping Internet Digital Spaces Accountable and Trustworthy. Most of the coverage reduced it to a headline: Europe wants to ban social media for children under 13.
That headline is accurate and it is the least useful part of the proposal for anyone who has to build the gate. The interesting part is the shape of the answer your age check now has to return.
Today almost every age gate in production answers one question with one bit. Is this user old enough, yes or no. The column is called age_verified or is_adult, it is a boolean, and everything downstream reads it that way. The KIDS Act asks for something different. It asks for a position on a staircase.
The staircase
The Commission’s own explainer sets out four states (European Commission):
| Age | What the user gets |
|---|---|
| Under 13 | No social media account at all |
| 13 to under 15 | An account a guardian sets up and keeps control of. Parental tools always on, a daily limit of at most one hour, and parental approval of contacts |
| 15 and over | Their own account, on a service that must be safe by law |
| Under 13, narrow exception | On video platforms built for young children, a parent may allow limited access through the parent’s own account. The child has no account, personalised feeds and search are off, the parent sets a limit of up to one hour and can cut access at any moment |
Read that as data rather than as policy. You need an ordered value with at least four members, not a flag. And the fourth state is not really about the child’s age at all. It describes a relationship between two accounts where only one of them exists.
The proposal still has to go through Parliament and Council, so the numbers can move. The shape is much less likely to move, because France arrived at the same shape independently. After its Constitutional Council struck down the under-15 blanket ban on 14 August 2026, the revised French text notified to the Commission on 14 September dropped the access prohibition and targeted about ten specific product features instead. Granularity is what survived judicial review in Paris. Granularity is what the Commission proposed a fortnight later.
Unknown stops being a safe default
Here is the line in the proposal that quietly rewrites your migration plan. Within six months of the rules applying, providers must check whether existing account holders are under 15, and disable the accounts of those who are or whose age cannot be established.
In almost every age gate we have looked at, unknown behaves like a pass. The user signed up in 2019, nobody ever checked, the boolean is null, and null falls through to the adult experience because that was the only experience. Under the KIDS Act, null and under-15 land in the same bucket, and that bucket is deactivation.
So your enum needs five members, not four. Under-13, 13-to-14, 15-plus, adult-by-inference, and unresolved. Unresolved has to be a real state that the product can render, not an absence that the product ignores. If you cannot select every account in the unresolved state today, and count them, you cannot size the work at all.
We wrote separately about what a back-book sweep does to a user base when the selection criterion is a model with a known error rate. The KIDS Act version has a softer edge than the one in that piece. It says disable rather than delete. It also says that where a provider can already tell with high confidence that a user is an adult, no new check is needed.
That last sentence is worth more than it looks. An inference layer built from signals you already hold, such as account age or a card on file, becomes a compliance asset rather than a shortcut. It also means you have to show the inference afterwards, which brings you back to keeping decision records rather than flags.
The 13-to-14 band is a graph edge, not an age
This is the part most teams will underestimate.
For the middle band, an age proof is not enough. The account belongs to the child, the control belongs to a guardian, and something in your system has to hold the link between them. The Commission requires every Member State to give parents a free, privacy-preserving way to prove parental responsibility. That is a second credential, issued to a different person, on a different schedule from the child’s age proof.
A link has a lifecycle that an attribute does not:
- It can be created, and something must record which guardian credential created it.
- It can be revoked, by the guardian or by the child on their fifteenth birthday.
- It can be contested. Separated parents do not always agree, and the proposal does not resolve that for you.
- It can go stale. Parental responsibility ends. The credential that proved it does not automatically notice.
None of that fits in a column on the users table. It is a separate entity with its own audit trail. If you model it as parent_email on the child record, you will be rebuilding it within a year.
There is a fairness problem underneath the engineering one, and it is worth saying plainly rather than designing around silently. Verifiable parental consent has never worked well at population scale. The methods that exist all lean on documents, cards, or bank identity. The families least likely to complete them are the ones in foster care, in non-standard arrangements, or without a bank account.
The Commission’s answer is that Member States must supply a free route, and that parental tools complement provider obligations rather than replace them. Whether that holds in practice is an open question. What is not open is that your product needs a path for a 13-year-old whose guardian cannot or will not complete the link. The default for that path is an account that does not open.
The band has to reach the feature layer
Half the proposal is not about who gets in. It is about what the product does once they are in. The prohibitions are named rather than described in general terms, which is unusual and helpful. For minors, services may not use endless autoplay or infinite scrolling without real breaks. They may not send notifications engineered to pull a child back, reward posting to mass audiences, or run streak mechanics that penalise a child for missing a day.
Recommender systems for minors have their own list. Optimise for safety and mental health rather than engagement. Tracking-based personalisation off by default. No data from outside the service. At least one feed with no profiling at all. On top of that, nobody can message a child without pre-approval, and minors cannot livestream by default.
Now look at where those behaviours are controlled in your codebase. The notification scheduler. The recommender config. The messaging permission check. The livestream entitlement. The autoplay flag in the video player.
Ask which of those systems can currently read an age band. In most products the answer is none of them. Feature flags key on plan, country, platform version, and experiment bucket. Age reaches signup and stops there. Getting a band from the identity layer into five or six product systems, with a consistent value and a sane behaviour when the band is unresolved, is a larger piece of work than integrating any verification vendor. It is also work you can start before the regulation is final, because the plumbing is the same whatever numbers the Parliament settles on.
Zero-knowledge proofs take away the birthdate you were going to use
The proposal is explicit about method. Platforms do not check identity documents and do not learn who the user is. Age comes from certified solutions independent of the platform, including a free EU age verification app and, later, the European Digital Identity Wallet. The text requires zero-knowledge proof technology that cannot identify, locate, track or profile anyone. The platform learns one thing: above or below a threshold.
That is the right design and it removes something you were probably relying on without noticing. You will not have a date of birth. So you cannot compute that this user turns 15 on 4 March and schedule the band change.
Band transitions are the only age event you can predict exactly, and a zero-knowledge proof is the one architecture that hides the prediction from you. Two ways out, and you should pick deliberately rather than discover the choice later:
- Hold an attestation with an expiry. The proof you received answers “is this user 15 or older”, and if the answer was no, the earliest date it could become yes is unknown to you. So you set a re-check interval and ask again. Cheap per check, wrong for a while between checks.
- Ask for the next threshold too. At 13, request both the 13 predicate and the 15 predicate. The second one comes back false, and you re-evaluate it on a cadence. Same cost shape, but the question you are asking is the one you actually care about.
Either way, what you store is the predicate, the outcome, the method, the policy version, the issue time and the expiry. Not a birthdate. We went through the four separate clocks in an age decision in a previous piece on age check expiry; the KIDS Act makes those clocks mandatory rather than merely sensible, because it takes away the alternative.
For the largest platforms, the burden of proof flips
One more thing that changes the deliverable rather than the design. Platforms with 45 million or more monthly active users in the EU cannot declare themselves compliant. Before their service comes into contact with children under the new regime, they must file a detailed compliance plan and have it checked by independent auditors, paid for by the platform. The Commission can object to an auditor whose independence it doubts. AI companions and chatbots cannot be placed on the market at all until the provider can demonstrate compliance and has a monitoring mechanism for emerging risks.
Enforcement runs through the existing DSA and AI Act structures, with fines up to 6% of worldwide annual turnover and an expedited timetable: preliminary findings within 30 days, a final decision targeted at 90.
If you are a VLOP, the artefact you owe is not a working age gate. It is a document an auditor can check against a running system. That is a different job, and it is the same job Ofcom has been quietly converging on in the UK, where every 2026 age assurance fine arrived with a second penalty for failing the information request.
What to do before the text is final
The proposal will change. Parliament and Council have not touched it yet, and the age numbers are the most politically contested part of it. None of the following depends on the numbers.
- Replace the boolean with an ordered band. Five states including unresolved. Migrate the column before you migrate the logic.
- Count your unresolved accounts. Right now. That number is the size of the six-month sweep, and it is the only input to that estimate you can get without a vendor.
- Model the guardian link as its own entity. Created by, revoked by, expires when, contested how. Not a column on the child record.
- Get the band into the feature layer. Pick the two systems with the longest lead time, which is usually the recommender and the notification scheduler, and start there.
- Stop storing the birthdate. If you have one today, you are holding data the new method will not give you anyway, and it is the single field that makes a breach worse.
- Keep decision records instead of flags. Outcome, method, predicate, confidence, policy version, timestamp. A flag cannot answer an auditor’s question about which rule produced which result.
At Xident the band output is native rather than a wrapper over a yes/no. A Check covers the cheap paths: browser-based age checks, liveness, a returning-user Xident ID lookup, OAuth. A Verification is the document path with optical character recognition and a face match. On the Growth plan those are 0.02 EUR and 0.20 EUR, a factor of ten apart, which is the whole reason a layered flow is cheaper than a single-method one. Most users resolve on the cheap path and only the ones near a band boundary reach the expensive one.
The free sandbox grants 1,000 Checks and 100 document Verifications as one-time allowances rather than a monthly quota. The 100 document Verifications exist so you can exercise the expensive path end to end, including the branch where it fails, before you pay anything.
The short version
The KIDS Act is a proposal, not a law, and the dates in it are not real yet. The schema change is real now.
An age gate that answers yes or no cannot express a guardian-controlled account, cannot express the difference between a 13-year-old and a 14-year-old on the same band, and cannot distinguish a user it checked from a user it never asked. All three of those distinctions carry consequences in the proposed text, and the third one carries account deactivation.
Everything else in the KIDS Act is product work that depends on knowing the band. The band is the dependency. It is also the piece that takes longest, because it touches the identity layer, the user table, the feature flags, the recommender, and the notification scheduler, and those five systems have never had a reason to agree about anything before.
Xident provides age verification and age estimation infrastructure that returns an age band and a decision record rather than a boolean, with a cheap Check path for returning users and a separate document Verification path. The free sandbox includes a one-time allowance of 1,000 Checks and 100 document Verifications. Talk to us if the KIDS Act timeline is on your roadmap.
