Age assurance bills are moving down the stack, and developers are in the blast radius

Governments are increasingly targeting age assurance requirements at the infrastructure layer rather than just at individual websites. Several U.S. states have introduced or advanced bills that would require operating systems and app stores to collect age data at setup and then pass an age signal to applications through a real-time API. The intent is to protect minors from grooming, violent content, and bullying—harms that are real and serious. But as written, some of these proposals could sweep in software distribution models that look nothing like consumer app marketplaces.

“Age assurance” covers a spectrum of techniques, from self-attestation (users state their age) to higher-confidence verification methods like ID matching, and age estimation based on behavior or facial scanning. Each approach carries tradeoffs around accuracy, privacy, and accessibility. Bills also differ in which services are covered, what age thresholds apply, and how parental consent factors in. For developers, the technical details matter less than the scope question: does the law apply to you, and what are you required to build or transmit?

Four state bills to track

Legislation is moving quickly across U.S. states. These four proposals are the most relevant for anyone building operating systems, app stores, or developer tools.

  • California AB 1043 (Digital Age Assurance Act) and AB 1856 (2026 amendment): Operating system providers, in coordination with covered app stores, must collect self-declared age at account setup and send an age-range signal to applications via a real-time API.
  • Colorado SB 26-051 (Age Attestation on Computing Devices): Operating systems and covered app stores must generate and share an age-bracket signal with applications through a real-time interface. Definitions of “covered application” and “covered application store” remain in flux.
  • Illinois HB 4140 (Digital Age Assurance Act): Closely mirrors California’s model, applying to operating system providers and requiring transmission of an age-category signal to developers via a real-time API.
  • New York S 8102 / A 8893 (Device-Level Age Assurance): Applies broadly to device manufacturers, operating systems, and app stores, requiring “commercially reasonable” age assurance (stronger than self-reporting) at device activation and transmission of a verified age signal to apps and websites.

Separate app-store-focused laws have also passed in Texas (SB 2420), Louisiana (HB 570), and Utah (SB 142). These are still actively evolving. Colorado’s SB 26-051 saw a committee hearing on April 23, 2026, where legislators signaled that open source operating systems and developer infrastructure were not the intended targets. The latest amended text there clarifies that software installed outside app stores—including downloads from public repositories—is out of scope.

Open source OSS and developer infrastructure are caught in the crossfire

The core problem is definitional. Age assurance bills written for consumer platforms often use language broad enough to capture code collaboration platforms, package managers, and open source indexing services—simply because they allow users to access or download software. But hosting source code, libraries, frameworks, and utilities is not the same as operating a centralized, consumer-facing marketplace. These are upstream building blocks, not end-user products, and the services that host them do not control distribution or presentation the way traditional app stores do.

Regulators appear to be aiming at consumer-facing services that collect and monetize user data and rely on engagement-driven systems. The risk profile is materially lower for platforms built around collaborative development, where users create, share, and maintain code rather than consume content passively. Yet the statutory language in several proposals does not yet draw that distinction cleanly. The practical consequence is uncertainty for volunteer-driven projects with limited legal resources.

That uncertainty has already produced real-world effects. Brazil’s Digital Statute for Children and Adolescents (Digital ECA), enforceable as of March 2026, applies broadly to digital services “likely to be accessed by children and adolescents,” including operating systems, app stores, and platforms. It excludes essential internet functionalities like open technical protocols. The Brazilian National Data Protection Agency (ANPD) has not formally clarified whether free and open source software is in scope, though its regulatory agenda has prioritized “app stores and proprietary operating systems,” and draft guidance under public consultation indicates collaborative, free-software-based systems may not face the same obligations. Despite that, some open source projects have already restricted access in Brazil, uncertain about compliance feasibility for non-commercial ecosystems. ANPD’s public consultation remains open, and input from developers will shape how implementation treats decentralized projects.

Exemptions exist, but the defaults matter

Several jurisdictions have already carved out open source collaboration from age restrictions. Australia’s Social Media Minimum Age legislation explicitly excludes open source code collaboration platforms, and France’s current Social Media Minimum Age proposal includes the same exclusions for code collaboration sites and online encyclopedias that appear in the EU Copyright Directive. Policymakers in these cases recognized that the risks minors face in open source development communities differ from those on consumer social platforms, and that the public benefits—education, innovation, security—are significant.

But the push for device- and OS-level regulation is a newer trend, and the definitions in those bills are less mature. The key fights are over two terms: what counts as an “application store” and what counts as an “application.” If making software available for download qualifies as operating an app store, then apt, npm, and GitHub all fall in scope. If downloading a library counts as downloading an “application,” then the law reaches every upstream component in the software supply chain. Neither outcome matches legislative intent, but statutes that fail to define these terms precisely leave the question to enforcement or litigation.

There is precedent for getting this right. The EU Cyber Resilience Act went through an iterative process to balance obligations for open source maintainers, and the result was a workable framework that distinguishes commercial distribution from non-commercial upstream contributions. State-level age assurance bills are still early enough in their lifecycles for similar refinement—provided developers engage with the legislative process and point out where the language fails to match technical reality.

Where developers can still shape the outcome

The regulatory conversation is far from settled, and there are still practical avenues for developers to influence how age assurance rules take shape. The strongest impact will likely come from direct participation in the places where policy is actually being drafted.

Specific opportunities include:

  • Contacting elected representatives in states actively weighing these proposals, such as California, Colorado, Illinois, and New York.
  • Submitting comments to Brazil’s Digital ECA public consultation.
  • Engaging with policy-focused organizations like the Open Source Initiative.
  • Reaching out to project stewards such as the FreeBSD Foundation and Debian, whose communities could feel the effects of these rules.

The goal of that engagement is straightforward: make sure the final rules reflect both the intent to protect minors and the practical constraints of how open source software is actually built and distributed. Without that input, there is a real risk that a well-meaning law creates technical obligations that are impossible or unreasonable to meet.

GitHub says it intends to keep working with both policymakers and the open source community on approaches that balance child safety with the ability to develop openly. The company also points developers to its developer policy repository for questions and concerns, and to a Maintainer Month livestream on May 22 featuring panelists from the FreeBSD Foundation and the Open Source Initiative, where the broader issues raised by these proposals will be discussed.