
Five states wrote age laws. Apple built one answer, and your managed Macs cannot give it.
Everyone is reading the Illinois act and circling 2028. The date that already passed is June 4, and Apple's own support note says why it does not reach a managed device.
Illinois signed an age signal law on July 31 and every summary circled the same date: January 1, 2028. That is the wrong date to be reading, and I say that as someone who spent two days reading the Illinois act.
The date that matters already passed. Here is Apple's own support note, published June 4, 2026:
Due to Texas law, these age requirements apply to new Apple Accounts created in Texas on or after June 4, 2026.
Apple switched Texas on two months ago. Louisiana's act took effect on July 1. California is operative on January 1. Illinois is the last of the five to land, not the first.
Worth being precise about that June date, because it is easy to garble. It is not SB 2420's effective date. The statute's own date came earlier and sat under a preliminary injunction; the Fifth Circuit stayed that injunction on May 28, and Apple switched the flow on a week later. So June 4 is the day the first of these laws started changing what a device does, which is a different and more useful fact than when a legislature said it should.
The map, and the two different laws on it
Five states have passed something in this space, and they are not all the same statute wearing different jackets. They split into two families with genuinely different mechanics.
| State | Law | Family | Status as of 2026-08-06 |
|---|---|---|---|
| Texas | SB 2420 | App store accountability | Live. Apple switched on June 4, 2026 |
| Louisiana | HB 570 | App store accountability | Live, effective July 1, 2026 |
| California | AB 1043 | OS age signal | Operative January 1, 2027 |
| Utah | SB 142, as amended by HB 498 | App store accountability | May 6, 2027 |
| Illinois | PA 104-0664 | OS age signal | January 1, 2028 |
App store accountability acts (Texas, Louisiana, Utah) put the duty on the store. It verifies the account holder's age, sorts them into a category, links minors to a parent account, and collects parental consent per download and per in-app purchase.
Age signal acts (California, Illinois) put the duty on the operating system. It asks at account setup, derives an age bracket, and hands that bracket to developers over an API.
Different theories, different defendants. Utah is worth a footnote of its own. HB 498, signed March 18, 2026, pushed the duties out to May 6, 2027 and rewrote enforcement. The enrolled copy deletes the line making a violation a deceptive trade practice under section 13-11a-3, drops the Division of Consumer Protection from the definitions, and repeals the division's rulemaking section outright. What survives is a private civil action: only a harmed minor, or that minor's parent, may sue, and a prevailing parent recovers the greater of actual damages or $1,000 per violation, plus fees and costs.
Worth saying plainly, because secondary coverage garbles it: this was not the Attorney General losing a power. The phrase "attorney general" does not appear in HB 498 at all. Utah's public-enforcement route ran through consumer protection, and that is the route the amendment closed.
Apple did not build five things
This is the part that reframes the whole problem.
Apple shipped Declared Age Range in macOS, iOS and iPadOS 26.0, before any of these five laws was operative. It is one API. Apple did not write a Texas build and a California build. It built the mechanism once and switches it on jurisdiction by jurisdiction.
You can watch it happen. Texas is the first activation, and Apple's implementation there is account-shaped: adults confirm they are 18 or older, under-18 accounts must sit in a Family Sharing group, Ask to Buy turns on and cannot be turned off, and, in Apple's words, "your age range is always shared with developers and can't be turned off."
So the honest read is that the mechanism is already national. The statutes only decide when it wakes up in a given state. Which is why the correct posture is to build to the strictest reading rather than track five compliance calendars, and I want to be careful about why that is right, because the obvious reason is wrong.
Does state law actually converge? Mostly, but not the way people think
The intuition is that state rules eventually go national. Seat belts and smoking bans get cited for this a lot. Both are shakier than they look.
There has never been a federal adult seat belt mandate. New Hampshire still does not require adults to buckle up, and enforcement elsewhere splits 36 states plus DC on primary enforcement against 13 on secondary. Federal involvement was equipment standards and grant money, not a national rule. Indoor smoking bans never went federal either, and remain a genuine patchwork.
The precedent that actually fits is data breach notification. California passed SB 1386 in 2002. No federal breach notification law has ever passed. And yet by 2018 every state had one, with Alabama and South Dakota bringing up the rear. Convergence happened without Congress ever showing up.
It happened through two mechanisms, and both are already visible here:
- Legislatures copy text. Illinois lifted California's "account holder" definition nearly word for word. This is not a coincidence of parallel drafting. It is a port.
- Vendors ship one build. Nobody maintains fifty variants of Setup Assistant. Apple built Declared Age Range once, and every state that passes a law gets pointed at the same plumbing.
So the stance holds. The reasoning is not "this will be federal law someday." It is "the vendor already collapsed five statutes into one implementation, and that implementation is on every device you own."
California and Illinois, side by side
These are the two age signal acts, and they are close relatives with a few consequential differences.
| California AB 1043 | Illinois PA 104-0664 | |
|---|---|---|
| Operative | 2027-01-01 | 2028-01-01 |
| Retroactive interface due | 2027-07-01 | 2028-07-01 |
| Who is bound | OS provider, covered app store, developer | Covered manufacturer (device maker, OS provider, app store) and covered operator |
| Device scope | "a computer, a mobile device, or any other general purpose computing device" | "a smartphone, tablet, or personal laptop or desktop computer" |
| Is the duty conditional? | No | Yes, only if it "offers an account setup feature" |
| Consent to share the bracket | Not required in the text | Required: "separate prior consent of the user" for "a specific covered operator" |
| Is "user" defined? | Yes: "a child that is the primary user of the device" | No. "Primary user" appears five times, undefined |
| Non-profit OS providers | Not named | Expressly named |
| Age brackets | under 13 / 13-15 / 16-17 / 18+ | Identical |
| Penalty | Up to $2,500 per affected child negligent, $7,500 intentional | $50,000 per violation |
| Enforcement | Attorney General only | Attorney General exclusively |
| Exemptions | Broadband, telecoms service, physical products | News media entities, broadband |
A note on those penalty figures, because the coverage got this wrong across the board. Every tracker quoting "$2,500 and $7,500" at Illinois is quoting California. Those numbers did sit in Illinois House Floor Amendment 1, but Senate Floor Amendment 2 replaced everything after the enacting clause and took the per-affected-child structure with it. The enrolled Illinois penalty is $50,000 per violation.
Neither act is uniformly stricter. California is broader on device scope, imposes the duty unconditionally, mandates that developers request the signal on download and launch, deems them to have actual knowledge even if they willfully disregard it, and lands twelve months sooner. Illinois carries the far larger per-unit penalty, expressly reaches non-profit OS providers, and adds a consent gate California never wrote.
The one definition that decides this for a fleet
Everything above is context. This is the line that matters if you manage devices.
California defines who this is about. Section 1798.500(i):
"User" means a child that is the primary user of the device.
Illinois uses the phrase "primary user" five times and never defines it, in a Section 5 that carefully defines twenty-six other terms including account holder, covered user, covered minor and known adult.
Illinois took a source statute that anchored the term and dropped the anchor while keeping the phrase. Whatever the drafting reason, the effect is real: on a fleet of adult employees, California's duty is arguably about nobody, because there is no child who is the primary user of a corporate MacBook. Illinois says only "primary user," and every device you own has one.
So when you ask which law to build to, the answer for a fleet is Illinois, on the axis that actually reaches you, even though California bites first.
What your managed Macs actually answer
Nothing. And it is worth being precise about why, because there are three independent reasons and none of them is an administrator decision.
The pane is skipped. From Apple's enterprise release notes for macOS Tahoe 26.4, iOS 26.4 and iPadOS 26.4:
The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.
There is no key to change that. Apple's published skip key schema carries 51 keys and not one of them is age related. At the macOS 27 seed it is 53 keys, still none. This was never exposed as policy.
The answer lives in the account, not the device. Apple derives the age range from Apple Account information. Enterprise ADE profiles have carried the AppleID skip key for years, which skips Apple Account setup entirely. No account, nothing to declare. Note what that means for Texas specifically: the requirement attaches to "new Apple Accounts created in Texas," so a device that never creates one never enters the flow.
And the result is not "adult." AgeRangeService.Response is a two-case enum, .sharing(range:) and .declinedSharing, with .notAvailable as an error. There is no unknown band and no adult default. Even a genuine 18+ result is encoded as an absent upper bound rather than a positive assertion of adulthood.
Apple Legal says the same thing in plain language: if the feature "has not been enabled and configured, or you have declined to share, the device will indicate that the feature is not available."
Every liability clause was written for a wrong answer
Here is what makes this more than a curiosity.
Both acts protect the party that relies on a bad signal. California's good faith provision at 1798.503(b) shields an operating system provider or app store from liability for "an erroneous signal indicating a user's age range." Illinois covers inaccuracies at 20(a), an inaccurate determination at 20(c), and at 20(b) tells a covered operator it may rely on a received signal and need not verify age itself.
Every one of those is keyed to a signal that exists and is wrong.
Neither act drafted anything for a signal that never arrives. Illinois makes the operator's request mandatory at 10(b) while conditioning the relief at 20(b) on actually receiving something. A managed device sits precisely between those two verbs.
The shared-device clauses do not rescue it either. Illinois 10(g) and California 1798.504(g) both remove liability for use by "a person who is not the user to whom a signal pertains." That phrasing presupposes a signal exists and pertains to somebody. A skipped pane produces none.
So what does a fleet manager actually do?
Start by getting the legal posture right, because it is not what people assume.
You are not a regulated party. Read the definitions. The duties fall on operating system providers, covered application stores, developers, covered manufacturers and covered operators. "Account holder" means an individual at least 18, or a parent or legal guardian. A company that owns 500 Macs is none of those things. Enforcement in both age signal states runs through the Attorney General against manufacturers and operators. Nobody is getting fined over a shared iPad.
What you are managing is not liability. It is behaviour.
- Know what your devices answer today. Sort the fleet by whether an Apple Account is signed in. That, not the state a device sits in, determines whether it can produce a bracket at all.
- Treat the
AppleIDskip key as a live decision. It has been on autopilot in most ADE profiles for years. It is now the switch that decides whether your fleet can answer an age question. Skipping it is still defensible, and on a shared or hot-desk device it is clearly right. Just make it deliberately. - Expect app behaviour, not enforcement action. Under California a developer must treat the signal as the primary indicator of age and is deemed to have actual knowledge of it. Developers facing that exposure and receiving nothing will pick a default, and the safe default for them is the restrictive one. The failure mode on a corporate Mac looks like an app quietly behaving as though a teenager is using it.
- Do not build per-state device policy. Devices travel, employees relocate, and the vendor did not build per-state either. Scoping MDM configuration to state boundaries buys you a maintenance burden and no protection.
- Test it rather than assume it. Enroll a device through ADE, skip the Apple Account, and call the API. First-hand beats a vendor doc describing the happy path.
The account-vs-device split shows up elsewhere too: Platform SSO's authentication method is selected by the identity-provider extension, not by anything the device is — and the age-range flow turns on the same kind of non-device fact: whether enterprise enrollment provisions the Apple Account or, as here, skips it.
The question I could not settle
Does a Managed Apple Account carry an age range?
Apple's Declared Age Range documentation never mentions a managed device, Apple Business Manager, or Apple School Manager. The Apple Business Manager service access table is rendered client side and defeats automated retrieval, so I could not confirm it either way without an authenticated session.
There is also one unreproduced field report worth flagging rather than repeating as fact: a Jamf Nation thread from April 2026 describes the Age Range pane appearing to new users at login on directory-bound Macs running 26.4. Apple's own schema treats device-setup Setup Assistant and new-user-login Setup Assistant as distinct contexts, which makes it mechanically plausible. The thread offers a competing explanation, and I have not reproduced it.
If your organization uses Managed Apple Accounts and you can check what the API returns, I would genuinely like to know.
The short version
Five states, two legal theories, one Apple implementation, and it started switching on two months ago. Your managed Macs are outside all of it, not because anyone in Springfield or Sacramento decided they should be, but because the vendor built the answer into an account your enrollment profile has been skipping for years.
The statutes protect a wrong answer. Nobody wrote the paragraph for no answer at all.
Sources
Primary sources, retrieved 2026-08-04 and re-verified live on 2026-08-06. Statutory text is quoted from the enrolled or chaptered version in every case, not from a tracker summary:
- California Legislature: AB 1043, Digital Age Assurance Act, Civ. Code 1798.500-1798.505, Chapter 675
- Illinois General Assembly: Public Act 104-0664, Children's Online Social Media Safety Act
- Apple Support: Age requirements for managing an Apple Account in the United States (Texas)
- Apple Developer: Declared Age Range
- Apple Support: macOS Tahoe 26.4 enterprise release notes
- Apple: device-management schema, other/skipkeys.yaml
- Louisiana Legislature: HB 570, App Store Accountability Act
- Utah Legislature: HB 498 (2026), App Store Accountability Act Amendments