Age verification and age assurance: what it means for a small shop, a game or an open-source project

Four words that decide it

The best definitions we have found are in Brazilian law, because Brazil regulates the whole ladder and names each rung separately. Decreto nº 12.880 of 18 March 2026, Article 2º, defines six terms; four of them are the ones the rest of the world argues about.

Attestation — autodeclaração de idade: The user states their age or bracket and nothing else confirms it. The decree says so expressly: a method limited to the indication of age or bracket supplied by the user, without additional evidence.
Assurance — aferição de idade: The umbrella term: procedures to check, estimate or infer an age or bracket, directly or indirectly, by a set of methods and technologies — including documents, biometrics and patterns of use.
Verification — verificação de idade: The narrow, heavy term: a procedure of high reliability, defined by the regulator, based on confirming that the age attribute is true.
Age signal — sinal de idade: Information or a credential that attests an age or bracket to a provider without revealing additional personal data. This is the part a normal app actually receives.

Keep those apart and most confusion disappears. A date-of-birth box is attestation. A card reader at a bar is verification. A yes/no answer arriving from an operating system is a signal. In this field, "age verification" is routinely used to mean all three, including by the people writing the laws — California's statute is literally titled "age verification signals" while the duty it writes is a declaration by the account holder.

Why the difference matters commercially. Attestation costs you a form field. Verification costs you an identity vendor, a data-protection assessment and a breach risk. If a supplier, a marketplace or a platform asks you to "implement age verification", the first question is which of the four they actually mean — and who told them it was needed.

In force, adopted, proposed

Everything below is sorted by stage, not by importance. "Proposed" means nothing is due from you today, whatever a page or a webinar says.

In force — Brazil, since 17 March 2026: Lei nº 15.211 (ECA Digital) applies from 17 March 2026 under its Article 41-A. Its Article 12 puts age assessment duties on app stores and on operating systems of terminals: proportional, auditable, technically secure measures to ascertain age or age bracket, parental controls, and an age signal over a secure interface. The decree of 18 March 2026 adds the free-of-charge signal, the declaration at account creation and the duty to assess by a reliable method set by the ANPD.
In force — the DSA, for platforms: Inside the EU the live layer is the Digital Services Act, and its youth protection duty attaches to online platforms accessible to minors, not to operating systems. App stores can be online platforms. See the EU section.
Adopted, applies from 1 January 2027 — California: AB 1043, the Digital Age Assurance Act, as amended by AB 1856 (Chapter 184, signed 10 September 2026). Operating systems with an account setup feature must offer an interface requiring the account holder to indicate the user's birth date, age or both, and expose the resulting bracket over a real-time interface; app stores relay it; developers must request it and are treated as knowing the age range. Open-source systems distributed under licences allowing copying, redistribution and modification are outside the definition of "operating system provider".
Adopted, applies from 1 July 2028 — Colorado: SB26-051, "age attestation for users of computing devices", with the same four brackets and the same open-source carve-out, and penalties of up to $2,500 or $7,500 per harmed minor. The copy we read is the act prepared for signature, so treat the date as announced rather than final.
Proposed — the EU Kids Act: COM(2026) 681, published 17 September 2026, listed as seven categories including operating systems, app stores and games, with certified age assurance and no small-enterprise exemption. It is a proposal with Parliament and Council; the Commission's feedback window closes 26 November 2026. Our note has the detail.
Proposed — US states beyond California and Colorado: A New York bill is reported to require age assurance at the point of device activation, with self-reporting excluded and methods set by the attorney general; other states are reported to be moving too. We have not verified any of those, and say so where we mention them. See the note's unverified section.

Watch the DSA's size carve-out. The Digital Services Act exempts micro and small enterprises from several duties, which is why many one-person sellers have never had to think about it. The EU Kids Act proposal deliberately drops that exemption for youth protection. That single change is what would put a solo developer inside a regime written for platforms.

If you are a one-person shop

If you sell jewellery, tea, prints or furniture into the EU, the honest answer is that none of the age rules on this page ask anything of you today. They are addressed to operating systems, app stores and apps. Your packaging duties are a separate file with its own deadlines, and those are the ones that actually bite.

Where you will meet it anyway: Signing up for a payment provider or a marketplace, or installing an age check on your own web shop because a plug-in suggests it. If somebody asks you to collect a date of birth, ask them which duty requires it — under the GDPR you also need a reason to hold it.
What is genuinely new for a shop with a community: If you run something with accounts — a forum, a members' area, a Discord — the platform you use may start handing you age signals. Your decision is not how to check anyone's age; it is what you do differently for a 15-year-old once the platform has told you.
Do not buy verification you do not need: Price it properly if you ever do: verification means an identity vendor under contract, a data-protection assessment, a retention rule, and breach exposure. Attestation means a form field. The gap between those two is the whole market for age-check software, which is why so much advice blurs them.

If you make a game or an app

This is where the US laws land. Read the developer duties in California's § 1798.501(d) and Colorado's Article 30 and they are short — and they assume the platform, not you, runs the age check.

You request a signal, you do not collect an age: When your app is downloaded and launched, it asks the operating system or the app store for the signal. The store relays it if it has it. You never see a date of birth in the model the two states describe.
Receiving it changes your legal position: Both texts treat a developer that receives a signal as knowing the user's age range. From that moment, "we did not know" stops being available to you as an argument about what your app showed a 13-year-old.
What you may not do: Ask for more information than the law requires; share the signal for a purpose it does not require; or prompt the user to change their age information. California adds that you must not willfully disregard clear internal information contradicting the signal.
What a small team should build now: A single place in the code that answers "what may this user see", fed by whatever the platform says — so that the day a signal starts arriving, the behaviour change is one configuration, not a rewrite. That is a few days' work, and it is also what the EU proposal would want from you in the end.

The date that matters is not the deadline

A deadline tells you when the rules apply. It does not tell you when the platforms you depend on start sending signals — and the store's API will change before your own deadline does. Track the platform changelog, not just the statute.

If you run an open-source project

Here the picture is genuinely uneven, and it is the part of this field most likely to change. Two regimes have carved open source out of the definition of an operating system provider; one, as far as we can find, has not.

California: excluded by the licence: "Operating system provider" does not mean a person or entity that distributes an operating system or application under licence terms that permit a recipient to copy, redistribute and modify the software (§ 1798.500(g)(2)).
Colorado: the same, with less room to argue: The article does not apply where the licence permits copying, redistribution and modification without platform-imposed technical or contractual restrictions on installing modified versions (§ 6-30-105(3)(e)). A locked bootloader or a mandatory signing step may put a build outside that description.
Brazil: no exemption we could find: Neither Lei 15.211 nor Decreto 12.880 contains a corresponding carve-out. Article 12 speaks of "operating systems of terminals" without qualification. That does not tell us who would be the addressee for a community distribution with no legal entity — and we have found no regulator statement on it.
What an open-source project can be asked to do: In practice: expose whatever the platform already knows, document it honestly, and refuse to collect more than you need. What a project cannot sensibly be asked to do is appoint the responsible adult a mandate like this assumes exists — decide whose age to record, hold it, and answer for it.

The Linux question

Every operating-system mandate runs into the same wall: a Linux distribution or a BSD has no central account administrator. Who is the "operating system provider" of Debian, Fedora or FreeBSD? Nobody holds the accounts, so nobody is sitting at the screen the law describes.

The two answers so far: Exempt the licence model (California, Colorado) or say nothing (Brazil). The first is elegant and creates a new edge: a system that is mostly free but has locked, proprietary components near the account layer may not read as exempt at all. That is the reading the Linux trade press took of SteamOS in May 2026.
The scope is wider than phones: Both US definitions speak of general-purpose computing devices and app stores that distribute third-party applications, and the comment around both laws points out that "operating system" now covers servers, watches, televisions, speakers, fridges, car head units and routers wherever an app store comes attached.
A stock answer for a maintainer: Do not implement an age gate you have no addressee for, and do not collect an age to be helpful. Document that your distribution collects no age data, and treat any signal your desktop environment receives from a nearby account layer as a pass-through you neither store nor decide on.

The EU side, without the noise

Two things are real inside the EU, and neither of them is an age check in your operating system.

What applies now: The Digital Services Act, Regulation (EU) 2022/2065, whose youth protection duty sits with providers of online platforms accessible to minors (Article 28), backed by the Commission's guidelines on the protection of minors. App stores can be in scope; an operating system as such is not the addressee.
What is proposed: The EU Kids Act (COM(2026) 681) would make age assurance explicit for seven categories of service, would set age tiers at 13 and 15 for the riskiest features, and would cover operating systems only narrowly — our note reads Article 29(6) as requiring, in essence, a user's consent before an age signal the system already holds is passed on. The feedback window runs to 26 November 2026, and this is the moment when a small business's view is still cheap to submit.
What is not true: That the EU already requires age verification to use a general-purpose computer. It does not. If a US or Brazilian signal reaches an app used by someone in the EU, the GDPR governs what that app may do with it — there is no EU answer to the spill-over, and we say so plainly rather than guess at one.

One further file is routinely confused with this one: the CSA Regulation — "Chat Control" — is about scanning the content of private communication, not about verifying who a user is, and we track its state separately.

Where to look next, in order

First the Commission's feedback page for the Kids Act, then the Council's general approach when it appears, then the Parliament's committee draft. Those three documents, in that order, tell you what an EU age-assurance duty would actually say. Everything else is prediction.

What we could not establish

How Brazil applies to free software: No ANPD statement, no enforcement practice, no carve-out in the text. Our reading of the absence is not an answer.
What the platforms will actually send: Neither California nor Colorado requires the signal at log in after the first request, and both let a developer re-request it periodically. How app stores will implement that in practice is not published.
The New York text and four other states: Reported only. We have no bill numbers and have read no bill text outside California and Colorado.
Cost figures: We have no named, openable cost estimate for implementing an age signal in a small app or a distribution, so we publish none. If you have run one, that is the single most useful thing you could send us.

Sources

Planalto — Decreto nº 12.880, 18 March 2026 (Portuguese) Source for the four definitions in Article 2º (age assessment, age verification, age signal, self-declaration), the design requirements in Article 24 and the app-store and operating-system duties in Article 25. Read in full for this page
Planalto — Lei nº 15.211, 17 September 2025 (ECA Digital), consolidated text Source for the scope in Art. 2º, the Article 12 duties on app stores and operating systems, the Article 13 purpose limitation, and entry into force on 17 March 2026 under Art. 41-A. Read in full for this page
California Legislative Information — AB 1856, Chapter 184 (approved 10 September 2026) Source for the developer duties in § 1798.501(d), the retrofit dates in § 1798.502, the penalties in § 1798.503 and the open-source definition in § 1798.500(g)(2). Read in full for this page
Colorado General Assembly — SB26-051 (PDF, act prepared for signature) Source for the 1 July 2028 effective date, the age-bracket definition, the age signal definition and the open-source carve-out in § 6-30-105(3)(e). Read in full for this page
EUR-Lex — Regulation (EU) 2022/2065, the Digital Services Act The live EU layer. The youth protection duty for online platforms is Article 28; the Commission's guidance on it is described in our Kids Act note, which is where the detail on Article 29(6) and the operating-system duty lives
KontorBund — The EU Kids Act: what the Commission proposed on 17 September 2026 Our own note on COM(2026) 681, read from the proposal, the press release and the Commission's explainer. The source for the seven categories, the age tiers, the missing size exemption and the 26 November 2026 deadline
KontorBund — Age checks move into the operating system Our note on California, Colorado, Brazil and the Windows Age API, with a separate section for what we could not verify
GamingOnLinux — Colorado and California age verification bills exempt open source operating systems Secondary, 25 May 2026. Source for the SteamOS reading and for the trade-press scope discussion about devices with app stores

Help us finish this page

The gap that matters most is Brazil and free software: a regulator's sentence would settle it. The second is a real cost figure for adding an age signal to a small app. Either one turns this page from careful into complete.

Send us a source on Discord Back to the Library