Digital Age Assurance Act of 2026
- Sponsor
- Sen. Kim, Andy [D-NJ]
- Committees
- Commerce, Science, and Transportation Committee (primary)
- Last action
- Jul 22, 2026
Bottom line
The Digital Age Assurance Act of 2026 establishes a standardized, privacy-preserving digital age verification system across operating systems, applications, and websites to protect children online and prevent anticompetitive behavior by platform providers.
What it actually does
This bill mandates that operating system providers collect age information from users, classify it into non-personally identifiable "age bracket data," and provide this data as a "signal" to app developers, browser providers, and certain website operators upon request. It requires these entities to use the signal as a primary age indicator to enforce age-appropriate access to content and services. The bill also prohibits targeted advertising to and data monetization of children, and includes provisions against anticompetitive practices related to age verification.
Proponents argue
Supporters argue this bill creates a much-needed, consistent framework for age verification online, protecting children from inappropriate content and targeted advertising without requiring intrusive personal data collection like government IDs or biometrics. They contend it empowers parents and ensures platforms are accountable for age-appropriate experiences, while also fostering fair competition by preventing dominant platforms from leveraging age data anticompetitively.
Opponents contend
Critics might argue that mandating age collection by OS providers, even with privacy safeguards, could lead to a "digital ID" system that could be misused or become a target for data breaches. They may also raise concerns about the practicalities and potential for false positives/negatives in age verification, and the impact on user privacy even with "zero-knowledge proofs," fearing it could lead to a less anonymous internet experience for all users.
The bill is moderately complex due to technical definitions and interconnected requirements across multiple entities, but its length makes it accessible for a thorough read within a reasonable timeframe.
Section 3(a)(1)(A) and (B)
Mandatory Age Collection and Age Bracket Signal Provision by OS Providers
Operating system providers must require users to provide their date of birth or age when creating new accounts or, for existing accounts, if their age isn't already known. This information is then classified into non-personally identifiable "age bracket data" (e.g., under 13, 13-15, 16, 17). OS providers are then required to provide this age bracket data as a "signal" to app developers, browser providers, or covered internet website operators upon request, using privacy-enhancing technologies like verifiable credentials or zero-knowledge proofs.
Supporters argue
Supporters argue this creates a foundational, consistent, and privacy-preserving method for age verification at the operating system level, which is crucial for protecting children across the digital ecosystem. By using age bracket data and zero-knowledge proofs, it avoids collecting sensitive personal information.
Critics contend
Critics might express concern that mandating age collection at the OS level, even with privacy safeguards, could normalize a system where age is always known, potentially leading to a less anonymous internet experience and creating a honeypot for data breaches.
Tradeoffs
Balances the need for robust age verification to protect children against concerns about universal age collection and potential privacy implications, even with de-identified data and cryptographic proofs.
Section 3(a)(1)(C)
Mandatory Parental Account Linking for Child Users
If an operating system provider determines a user is a child (under 17), the bill requires that child's account to be linked to an account of a parent or legal guardian. This provision aims to give parents oversight and control over their child's online experience.
Section 4(a) and (b)
Mandated Request and Use of Age Signals by Developers and Website Operators
App developers and covered internet website operators must request an age signal from the OS provider (or browser provider for websites) when a user first accesses their service. This signal becomes the primary indicator of the user's age. It becomes unlawful for these entities to allow a user to access content or features deemed inappropriate for their age bracket based on the signal and the entity's own policies.
Section 7
Ban on Targeted Advertising to and Data Monetization of Children
This section makes it unlawful for any person to engage in targeted advertising to a user they know or reasonably should know is a child (under 17). It clarifies that contextual advertising is still permitted. Additionally, it prohibits the sale, licensing, or sharing of personal data of a known or reasonably known child with a data broker.
Section 9
Prevention of Anticompetitive Practices by OS and App Store Providers
This section prohibits operating system providers and application store providers from imposing more restrictive age-related requirements on third-party applications than they do on their own. It also forbids them from using age bracket data collected from third parties to engage in anticompetitive behavior, such as favoring their own applications or services. Furthermore, it prevents them from requiring proprietary software development kits or exclusive technical dependencies for signal verification, unless strictly necessary for security or integrity.
If a developer or covered internet website operator receives an age signal for a user, they are deemed to have "actual knowledge" of that user's age bracket data across all their platforms and points of access for that application or website.
Section 4(a)(2)
Why it matters:This is a standard legislative technique to ensure broad applicability and prevent entities from claiming ignorance of a user's age across different parts of their service once a signal has been received.
Case for: Proponents would argue this prevents developers from creating silos of information to avoid compliance, ensuring that once a user's age bracket is known, it's consistently applied across all relevant parts of their service.
Case against: Critics might argue this creates a significant compliance burden, especially for large, complex services with many sub-platforms or legacy systems, and could lead to unintended over-blocking if age data is applied too broadly.
Estimated impact: Significantly expands the scope of age-gating enforcement for developers and website operators, requiring consistent application of age restrictions across their entire digital footprint once an age signal is received.
Operating system providers, covered internet website operators, and developers acting in good faith to comply with the Act are not liable if a user inputs inaccurate age information under Section 3(a)(1).
Section 8(c)
Why it matters:This is a crucial protection for regulated entities, ensuring they are not penalized for user deception, but it's often placed in enforcement or miscellaneous sections.
Case for: Proponents would highlight this as essential to make the bill workable, as platforms cannot realistically verify every user's age with 100% accuracy against fraudulent input without resorting to highly intrusive methods. It encourages good faith compliance.
Case against: Critics might argue that this safe harbor could be exploited by platforms to avoid stricter age verification measures, potentially allowing some children to bypass protections if they lie about their age.
Estimated impact: Reduces the legal risk for platforms, potentially influencing the stringency of their age verification methods, as long as they act in good faith.