9 min read

Minimum Age, Enforced: The DSA's Meta Breach Finding and the End of the Birthday Field

The EU Commission's preliminary finding that Meta breached the DSA by letting under-13s onto Facebook and Instagram turns 'enter your date of birth' from a UX detail into a compliance failure. Here's what Article 28 actually requires, why proportionality makes it harder than it looks, and how to build minimum-age assurance you can defend.

Illustration of a platform signup screen with a self-declared date-of-birth field crossed out and replaced by an assessed-age shield, representing DSA Article 28 minimum-age enforcement

For years the birthday field at signup was treated as a UX detail — one more line in the account form, filled in by whoever was creating the account, believed by no one. In late April 2026 the European Commission made it a compliance failure. Its preliminary finding that Meta breached the Digital Services Act — for failing to prevent minors under 13 from using Facebook and Instagram — is the clearest signal yet that the era of self-declared minimum age is over. The question regulators are now asking is not “did you collect a date of birth?” but “did you do anything to find out whether it was true?”

This is a different kind of enforcement than most platform teams have been planning for. The national social-media bans and the adult-content laws made headlines, but they targeted specific categories of service. Article 28 of the DSA applies to any online platform accessible to minors, and the Commission is now enforcing it against the largest consumer products in the world. If you operate a platform that European children can reach, the Meta case is a preview of the standard you’ll be held to.

What Article 28 actually requires

Article 28(1) of the DSA obliges platforms accessible to minors to put in place “appropriate and proportionate measures to ensure a high level of privacy, safety, and security of minors.” That sentence sat mostly dormant until 14 July 2025, when the Commission published its guidelines on the protection of minors and gave it operational teeth.

The guidelines are built on a risk-based approach: the measures a platform owes depend on its nature, size, purpose, and user base. A platform that surfaces adult content, enables stranger contact, or runs engagement-maximising recommender systems carries higher risk and owes stronger age assurance than a low-risk utility. Crucially, the Commission ranked the methods. Self-declaration — a date-of-birth box or an “I am over 18” checkbox — is treated as an unreliable control that does not, on its own, discharge the duty. Age estimation sits in the middle. Age verification against official identity or a trusted digital credential — including the EU Digital Identity Wallet — sits at the top for high-risk cases.

Two features of the framing matter. First, the guidelines exempt micro and small enterprises, so this is squarely a duty for platforms at scale. Second, the obligation is continuous, not a launch checkbox: platforms are expected to define metrics, monitor risk over time, and re-assess at least annually or whenever the service changes materially. This is the same performance-based posture that the UK’s Ofcom and ICO have adopted — the control has to work in production, and you have to be able to show it does.

The Meta finding, decoded

The Commission’s preliminary conclusion against Meta is worth reading closely, because it is effectively a list of the specific things that now count as failure. The core defect is exactly the one the guidelines warned about: when creating an account, a minor can enter a false birth date and there are no controls in place to check it. Self-declaration, standing alone, is the breach.

The Commission went further. It found Meta’s account-reporting path for flagging an underage user “difficult to use” — reportedly requiring up to seven clicks to reach the form — which undercuts the argument that reactive removal compensates for weak gating at the door. And it found Meta’s own risk assessment incomplete: it did not reflect available EU evidence indicating that roughly 10–12% of children under 13 access Meta’s platforms. In other words, the platform’s paperwork claimed a smaller problem than the data showed, which is its own kind of exposure. The DSA lets the Commission fine confirmed breaches up to 6% of total worldwide annual turnover — a figure that turns “we ask for a birthday” from a cost-saving shortcut into a material financial risk.

Meta is not alone. In March 2026 the Commission opened a formal investigation into Snapchat over the same under-13 access problem, and over whether it adequately assesses when users are under 17 — a reminder that the relevant line is often not 18. These are preliminary steps, not final penalties, and the platforms will respond. But the direction is unambiguous: the Commission is treating the absence of real age assurance at signup as a standalone compliance failure, independent of any specific harmful-content complaint.

Why “enter your date of birth” became a documented failure

The deeper shift here is legal, not technical. For a decade, platforms operated on asserted age: the user stated a birthday, the platform recorded it, and the record was treated as a good-faith allocation of responsibility. The DSA — like the ICO’s £14.47M Reddit decision before it — collapses that model. Regulators now expect assessed age: the platform must take a positive step to form a reasonable belief about whether the user is a child, proportionate to the risk of the service.

That reframing changes what your logs need to contain. A recorded date of birth is now evidence of the problem, not evidence of diligence — it shows you knew age mattered and chose not to check it. What discharges the duty is a record that you applied an age-assurance method appropriate to your risk tier, what that method returned, and what you did with the result. If a regulator asks how you keep under-13s out and your honest answer is “we have a birthday field,” you are, by the Commission’s current reasoning, describing a breach.

The proportionality trap: you can’t over-collect either

Here is the part teams tend to miss, and it is where naive implementations get themselves into a second kind of trouble. Article 28 is a two-sided obligation. You must keep minors out of what they shouldn’t reach, and your measures must not disproportionately restrict children’s rights — their freedom of expression, access to information, and participation — or sweep up the entire adult user base into an identity dragnet. The guidelines explicitly require platforms to monitor whether their controls over-restrict, with input from minors, guardians, and experts, reviewed annually.

This is a genuine engineering tension, not a rhetorical one. The lazy fix for “we let under-13s in” is to demand a government ID from every user at signup. That over-collects catastrophically: it builds a honeypot of identity documents, excludes legitimate users who won’t or can’t produce ID, and is itself disproportionate for a low-or-medium-risk service. So the DSA pushes you toward a narrow target — assess age accurately enough for your risk level while collecting as little as possible, ideally proving a single threshold (“over/under 13”, “over/under 16”) without retaining the underlying identity at all. Meeting one half of Article 28 by violating the other is not compliance; it’s a different finding waiting to happen. This is why surveillance-free architecture is not a nice-to-have here — it’s how you satisfy both duties at once.

What this means operationally

For any platform that European minors can reach, the Meta case turns a handful of abstract principles into a concrete to-do list. Start by honestly risk-tiering the service: content type, contact features, recommender behaviour, and known minor usage set the level of assurance you owe. Match the method to the tier rather than applying one control everywhere — estimation-first flows for lower-risk surfaces, step-up to verification or an EU Digital Identity Wallet credential for higher-risk ones. Instrument the whole thing: define the metrics that show the control is working, watch false acceptance near the threshold and the drop-off it costs you, and keep a per-decision evidence trail you can hand a regulator. Then schedule the annual reassessment the guidelines demand, and make sure your written risk assessment matches your real data — because Meta’s did not, and that gap was part of the finding.

Two design points deserve emphasis. First, minimum age is not one number. The DSA’s relevant lines are 13 and, for some obligations, 16 or 17 — not the 18 that the adult-content debate has trained everyone to focus on. A control that only knows “adult or not” fails a duty framed around children of 13. You need a method that can classify at multiple thresholds, and that is exactly where estimation near a low age line gets hardest and a conservative challenge-age buffer becomes essential. Second, the reporting-and-remediation path is part of the control. The Commission faulted Meta’s seven-click removal flow specifically; a hard-to-use “this account belongs to a child” mechanism will not save a weak gate.

How Xident is built for Article 28

Xident is designed for exactly the two-sided obligation Article 28 imposes: keep minors out, without turning every user into a stored identity record. Age is returned as a threshold classification — over or under 12, 15, 18, 21, or 25 — so you can gate at the minimum age that your service and jurisdiction actually require, not just at 18, and configure a challenge-age buffer where estimation is weakest near a low line. Lower-risk surfaces can run estimation-first; higher-risk ones escalate automatically to document OCR, face match, NFC chip read, or a wallet-based credential, matching assurance to risk tier the way the guidelines expect.

The proportionality half is handled by architecture, not policy. Xident returns the threshold result, the method, and the assurance level to an audit log — never a retained date of birth or ID image — so you produce the evidence a DSA investigation asks for while holding almost nothing that a breach could expose. A reusable token lets returning users re-prove the same fact without re-collecting identity, keeping coverage high without inflating your data footprint. That combination — accurate at multiple thresholds, minimal by default, and instrumented to be measured — is what lets a platform answer the Commission’s real question: not “what birthday did the user type,” but “what did you do to know.”


The DSA didn’t add a new rule in April 2026; it started enforcing one that was already on the books, against the platforms best resourced to comply. The lesson for everyone smaller is that the birthday field has quietly flipped from a defensible default into documented evidence that you knew age mattered and left it unchecked. “We ask users their age” is a statement about intentions. “Here is the age-assurance method we apply at signup, tuned to our risk, holding no identity we don’t need, with the metrics and audit trail to prove it works” is a statement about outcomes — and outcomes are now what the Commission is enforcing.

This post is general information about age-assurance practice and public policy, not legal advice. DSA obligations, enforcement priorities, and Commission findings continue to evolve, and preliminary findings are not final determinations; consult qualified counsel for your specific obligations.

Share this article

Ready to implement age verification?

Get started in minutes with our simple SDK. Free trial includes 100 verifications.

Book a 20-minute demo