Age Verification Laws Are Coming for Your OS. Linux Doesn't Care.

For most of 2025 the age-verification conversation was about porn sites. By the end of the year it had moved up the stack. By 2026 it is at the operating system, and that is where the story gets interesting for anyone who cares about how Linux is built.

Nine US states put age-verification laws in force during 2025 alone: South Carolina (Jan 1), Florida (Jan 1), Tennessee (Jan 13), Georgia (Jul 1), Wyoming (Jul 1), North Dakota (Aug 1), Arizona (Sep 26), Ohio (Sep 30), and Missouri (Nov 30). Roughly half the country now mandates some form of age gate for adult content, social media, or both.

The research from the Phoenix Center and NYU confirms what anyone who has ever administered a network already suspected: the laws do not stop the traffic, they reroute it. VPN demand in Florida spiked 1,150% the week the state law kicked in. Users did not quit. They got a VPN.

That is the part that has been on the news. The part that has not been on the news, and that matters more for this blog, is what happened next.

The law moves down the stack

California passed a law requiring operating system vendors to collect a date of birth or age bracket for every user account, and to expose that age bracket to applications running on the device. The framing is that platforms — the social networks, the app stores — can no longer be trusted to verify age on their own, so the OS becomes the source of truth.

Colorado has a copycat bill in committee. Texas has one too. Congress is advancing an App Store Accountability Act that would push the same obligation onto Apple and Google at the store level. The Register summarized the mood with the headline that says everything:

Nanny state discovers Linux, demands it check kids’ IDs before booting.

For Apple and Microsoft this is annoying paperwork. They already have centralized accounts. They already collect a birth date when you sign in. They already telemetry every login. Wiring an “age bracket” API into macOS or Windows is a sprint, not a project.

For Linux it is something else.

Brazil’s ECA Digital — the same law, different flag

While the US was lighting itself on fire over state-by-state patchwork, Brazil went the other direction and passed a single federal statute. The ECA Digital — Lei Felca — was sanctioned in September 2025 and took effect on March 17, 2026.

The Brazilian law is more aggressive than the US ones in one specific way: autodeclaration is explicitly prohibited. “Click here if you are 16” is not a defense. Platforms must verify, app stores must verify, and the OS itself must pass an age bracket down to the application layer. The ANPD (the Brazilian data-protection authority) is the one that will define what counts as “reliable verification.”

That work has not finished. As of this writing the ANPD is still publishing the technical regulation. But the law is in force, and the obligation already exists.

So the question that lands on my desk, as a sysadmin in Belo Horizonte who happens to run Linux on every machine I own: what exactly does the ECA Digital mean for the OS that has no central vendor to call?

What Linux looks like to a regulator

Apple ships macOS from one company, signed by one certificate, distributed through one update server, gated by one account system. Microsoft does the same for Windows. The regulator can write a letter to one corporate address and the law is enforced.

Linux does not work that way.

There is no single vendor. There is no required account to boot the system. There is no central registry of who installed what distro on which machine. The kernel comes from kernel.org. The userland comes from a Linux distribution — Debian, Fedora, Arch, openSUSE, Ubuntu, NixOS, dozens of others — each of which is a community or a company in a different jurisdiction with a different governance model. The package manager pulls from mirrors that may live anywhere on Earth.

A child can install Fedora on a laptop at age 5. Or 95. Nobody asks. The OS does not phone home. The OS does not know it is running on a laptop in California. There is no opt-in flow that collects a date of birth, because there is no flow at all — you boot the installer, you partition the disk, you click “next,” and the system is yours.

This is not a bug. This is the entire design. Linux was built in a world where the assumption was that the person operating the computer owned the computer. Forty years later that assumption is what makes it structurally hard to regulate.

How the distros are reacting

The reactions, in 2026, fall into a small number of buckets.

MidnightBSD, a small BSD descendant (not Linux, but in the same family of free Unix-likes), updated its license with a clause that bans California residents from using it for desktop use. Symbolic? Yes. Enforceable? Of course not. But it is a clear “no” from the upstream, and it makes the legal question loud.

Adenix GNU/Linux — a smaller distro — has publicly declared that it will not implement age checks of any kind. The political statement is the feature.

David Heinemeier Hansson, creator of Omarchy Linux (an Arch spin) and not exactly a man who picks his words for diplomacy, called California’s law “unenforceable” on Linux and said he has no intention of changing Omarchy to comply. He is not wrong.

Canonical — the most corporate of the major Linux vendors, and the one with the most exposure if a government wants to push on a single throat — has been the most measured. Their engineer Jon Seager floated the idea of a local age-bracket flag exposed via D-Bus: no online ID check, no central registry, no phone-home, just a per-user attribute that an application could read if it asked. Seager was explicit that there are “no concrete plans on how, or even whether, Ubuntu will change.”

The Canonical proposal is the most interesting one because it shows what a good faith attempt at OS-level compliance even looks like in this ecosystem. It is a local flag. The OS does not verify the age. The user types it in. The distro just makes the value queryable. That is roughly the maximum the Linux model can absorb without becoming something else.

System76, the US Linux PC vendor that ships Pop!_OS on hardware they sell, has been actively lobbying Colorado to back off its copycat bill. Their argument is the same one I’m making here, written in the dry language of trade-association talking points: this law assumes a vendor model that does not apply to us.

Linux vs the closed systems, on this specific axis

This is the table that explains why the law works on two of these columns and not on the third. It is not that Linux developers are more principled than Apple’s. It is that the shape of the product is different. The law was drafted with two of these columns in mind.

The thesis, said plainly

The reason the California law (and the federal App Store Accountability Act, and most of the Brazilian implementation guidance the ANPD will eventually publish) does not reach Linux is not that Linux is morally superior. It is that the enforcement model assumes a centralized vendor with remote control over the user experience.

That model is true of macOS. It is true of Windows. It is true of iOS and Android. It is not true of Linux.

There is no vendor to subpoena. There is no centralized user database to audit. There is no update server the government can threaten to take offline if compliance does not arrive by a deadline. There is no app store that, if pressured, will gate the ecosystem.

Linux is immune to this specific enforcement model because this model breaks the moment the assumption of a single vendor breaks. That is the whole argument. It is not “Linux is immune to regulation.” It is “Linux is immune to this regulation, because this regulation was written for a different shape of product.”

The honest trade-off

I do not believe this immunity is permanent. I do not believe it is absolute. There are three threats I think are real, and I want to be honest about them because pretending Linux has won something it has not is exactly the kind of triumphalism that gets a community blindsided.

Threat one: the ISP layer. If governments force ISPs to block downloads of “non-compliant” operating systems — i.e. the ISO of any distro that has not implemented an age-bracket API — the game shifts. You can still download via VPN, mirror, sneakernet, BitTorrent. But the default user experience of “I went to fedoraproject.org and downloaded the ISO” stops working. That is a real cost even if it is technically circumventable. The 1,150% VPN spike in Florida suggests circumvention is now mass-market behavior, but mass-market behavior is not the same as friction-free.

Threat two: hardware attestation. This one is the one I worry about. Modern PCs have a TPM. Intel ships Pluton. Apple Silicon has the Secure Enclave. If a future law mandates that hardware sold in a jurisdiction must boot only an OS that cryptographically attests to having implemented age verification at the kernel level, Linux’s vendor-less model becomes a liability. The hardware refuses to boot the unattested OS. No subpoena needed. The law moves below the OS.

This is not science fiction. Secure Boot already does the shape of this, just for malware rather than compliance. Microsoft Pluton already exists. The infrastructure to make this happen is in every laptop sold this year. All that is missing is the political will, and the political will is being built right now.

Threat three: the Brazilian wrinkle. If the ANPD’s implementing regulation specifies that hardware sold in Brazil must include age-verification firmware — embedded in the BIOS, in the SoC, in something below the OS — then “Linux on Brazilian hardware” would face the same pressure as Windows. The OS is incidental. The fight is for the silicon.

So when I say “Linux does not care,” I mean today, on the current enforcement model, against the current generation of laws. I am not predicting that this is forever. I am predicting that the next round of regulation will move the fight one layer deeper, and the next argument I have to write will be about Secure Boot keys and TPM attestation instead of OS-level age brackets.

That argument is going to be harder.

What I think the right posture is

I run Linux on every machine I own. I have for two decades. I do not run it because I am hiding from regulators — I run it because it is, on a daily basis, a better tool for my work and my life. The fact that it is also resistant to a class of regulation I find badly designed is a bonus, not the goal.

I think the right posture for the Linux ecosystem in 2026 is:

• Document the asymmetry. Make it clear, in writing, to regulators and to the press, that the law as drafted does not apply to a vendor-less ecosystem. Do not pretend to comply with something you architecturally cannot.
• Engage on the next fight, not this one. Hardware attestation, Secure Boot lockout, mandated TPM-backed compliance — that is where the real risk lives. The OS-level fight is mostly already won by the architecture.
• Do not panic-implement an “age bracket API” because a regulator demanded it. The Canonical proposal is the right ceiling — a local, opt-in, user-supplied flag that distros may expose, with no verification claim attached. Anything beyond that imports the centralized-vendor assumption into a decentralized system. That is the actual capitulation, not the surface compliance theater around it.
• Fund the legal organizations that will fight this when it reaches the hardware layer. EFF, FSFE, Software Freedom Conservancy in the US. Instituto de Tecnologia & Sociedade do Rio and similar groups in Brazil. The fight that matters next is going to be litigated.

The closing thought

Age verification at the OS level is going to become mandatory on macOS and Windows. There is no version of the next two years where it does not. Apple and Microsoft will roll it out, gracefully, with a UX flow that is annoying but tolerable, and billions of people will click through it without much thought.

Linux will not do this. Linux cannot do this in the shape the law expects, because the law expects a vendor, and there is no vendor. The distros that are reacting — MidnightBSD, Adenix, DHH’s Omarchy — are reacting to a problem they don’t structurally have. The Canonical proposal is the only one that even looks like compliance, and on close reading it is a local flag with no verification — which is to say, the maximum amount of theater the Linux model permits before becoming a different operating system.

The law was written for a world that exists. It just doesn’t exist on my laptop.

That is going to hold, on this specific issue, for as long as the fight stays at the OS layer. The day it moves to the silicon — the day a TPM refuses to load an unsigned, unattested kernel — is the day we have to have a much more uncomfortable conversation about what free software on the computer you own still means.

I think that day is coming. I think we have a few years to get ready. And I think the first step of getting ready is naming the thing clearly: Linux is not immune to regulation. It is immune to this particular shape of it. The next shape is going to be designed by people who learned from this round.

The age-verification fight at the OS layer is the warm-up.