California’s Digital Age Assurance Act, passed in late 2025 as Assembly Bill 1043, is scheduled to take effect on January 1, 2027. A follow-up amendment, Assembly Bill 1856 introduced on February 11, 2026 by Assembly Member Buffy Wicks, narrows the original law so that freely redistributable operating systems fall outside the new rules. The amendment does not repeal the statute. Commercial app stores, hybrid platforms, and any app that reaches California users still need to plan for an incoming age bracket signal piped up from the operating system layer.
What the law actually requires
For the past twenty years, age gating has lived at the website or app level. Each product decided for itself whether to ask for a birth date, check an ID, or rely on a self-attested checkbox. AB 1043 moves that decision below the application, into the operating system. Starting in 2027, compliant OS vendors must emit a standardized age bracket to every app and storefront on the device. The brackets defined in the statute are under 13, 13 to 15, 16 to 17, and 18 plus.
For a site owner or app developer, that signal is a new input your stack has never had before. You will need to decide whether to read it, where to log it, how long to retain it, and what downstream behavior to trigger for each bracket. The original law does not spell out per-bracket duties for apps, but ad networks, app store review policies, and future regulations will almost certainly use the signal as an enforcement lever.
Why AB 1856 matters, and what it leaves intact
The amendment, read a second time on May 19, 2026, redefines “operating system provider” so the term excludes any entity that distributes an OS under terms permitting users to copy, redistribute, and modify the software. That phrasing matches the language in common open-source licenses such as GPL, MIT, and Apache. As a result, Debian, Fedora, Ubuntu, Arch Linux, Mint, and similar mainstream distributions are no longer treated as covered OS providers under the statute.
The carve-out does not touch the vendors most product teams build for. Apple, Google, and Microsoft remain squarely inside the rule. SteamOS is the open question: the underlying system is Linux-derived and open source, but the bundled Steam storefront is proprietary. Whether regulators treat SteamOS like Debian or like iOS will probably be settled by guidance or a test case after the 2027 effective date. AB 1856 still has committee reviews in June and a third reading before reaching the governor, and the latest revision date in the legislative record is May 18, 2026.
How to read this for an SEO and compliance audit
The age bracket signal is not a ranking factor, and search engines do not yet consume it. What it changes is the surface area of your digital presence. Once a compliant OS sends an under 18 bracket to your app, your gated flows, ad targeting, analytics events, and consent strings need to handle that case correctly. Auditors should treat this the same way they treat cookie consent: a new client- or device-level signal that flows into your measurement, your content rules, and your ad stack.
Three places where the signal will surface in a typical SEO audit:
- Structured data and business listings. AI overviews, assistants, and compliant OSes read the same structured data feeds. If your age-appropriate audience, service area, or content categories are not declared, downstream systems will guess, and regulators will assume the worst.
- App store metadata. Commercial storefronts will likely require apps to acknowledge the incoming bracket signal and document how each bracket is handled. Treat app metadata the same as your robots.txt: a compliance surface that needs its own audit pass.
- Ad and analytics pipelines. Bracket data is sensitive personal information under most state privacy frameworks. Logging it without a documented legal basis is a liability the first time it leaks into a debug dashboard or a support ticket.
A pre-2027 audit checklist for site owners and app teams
Use this as a working list for the next six months. None of the items depend on AB 1856 passing; all of them apply whether the amendment clears committee or stalls.
- Map every surface where California users land. Marketing pages, app store listings, deep links, AI assistant citations. Note which ones currently display age-gated content or run age-targeted ad campaigns.
- Document your current age handling per surface. Self-attestation, third-party verification, declared birth date at signup, or nothing. The gap between today and the 2027 signal is the work.
- Decide how each age bracket will behave inside your product. Content filters, purchase blocks, ad suppression, and account upgrade flows all need a documented rule, not a runtime guess.
- Audit structured data feeds for business identity, hours, and audience. Compliant OSes and AI assistants will read the same feeds your local SEO depends on. Run an AI contactability check to find the gaps before regulators do.
- Review app store metadata for disclosures about age handling. Plan to update listing text once storefronts publish their bracket signal requirements.
- Update your privacy notice and data retention policy. The bracket signal is a new category of personal data. Add it to your records of processing and your user-facing disclosures.
- Set up monitoring. Quarterly reviews will miss the policy clarifications that land between now and January 2027. Automated agents that watch listings, reviews, and policy pages beat calendar reminders.
The strategic view
California rarely legislates in isolation. Other states tend to follow, and the open-source carve-out is a useful signal about how the political pressure points work. Open source won an exemption because its maintainers could argue, convincingly, that software anyone can fork cannot be forced into a centralized identity check. Commercial vendors did not win that argument, and the businesses that build on top of them inherit the resulting rules.
The practical posture for the next year is to assume bracket signals are arriving on January 1, 2027, and to audit your product, your listings, and your data flows as if they already have. The teams that do the audit work now will spend 2027 shipping features. The teams that wait will spend it in compliance triage.
FAQ
Does California’s age verification law apply to my website or app?
If your product reaches consumers in California, the Digital Age Assurance Act will reach it through the operating system layer starting January 1, 2027. The original law (AB 1043) covers commercial operating system providers. AB 1856 exempts only OSes distributed under licenses that permit copying, redistribution, and modification, which covers projects like Debian, Fedora, Ubuntu, Arch Linux, and Mint. Most commercial apps, websites, and storefronts are downstream of the covered OS vendors and will receive age bracket data from devices.
When does California’s age verification law take effect?
The Digital Age Assurance Act takes effect January 1, 2027. AB 1856, the open-source carve-out amendment introduced by Assembly Member Buffy Wicks on February 11, 2026, would take effect on the same date if it clears its remaining committee reviews, third reading, and the governor’s signature. The latest revision in the legislative record is dated May 18, 2026.
Is SteamOS exempt under AB 1856?
SteamOS is not explicitly addressed. The base operating system is Linux-derived and open source, but the bundled Steam storefront is proprietary. Whether regulators treat SteamOS like Debian or like a commercial OS such as iOS will likely be settled through guidance or a test case after the 2027 effective date. Businesses operating hybrid platforms should plan for compliance rather than rely on the open-source carve-out.











