← Field Notes
Compliance · Deep dive

Five states wrote age laws. Apple built one answer, and your managed Macs cannot give it.

R Rob Flanagan · · 13 min read

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.

StateLawFamilyStatus as of 2026-08-06
TexasSB 2420App store accountabilityLive. Apple switched on June 4, 2026
LouisianaHB 570App store accountabilityLive, effective July 1, 2026
CaliforniaAB 1043OS age signalOperative January 1, 2027
UtahSB 142, as amended by HB 498App store accountabilityMay 6, 2027
IllinoisPA 104-0664OS age signalJanuary 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:

  1. 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.
  2. 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 1043Illinois PA 104-0664
Operative2027-01-012028-01-01
Retroactive interface due2027-07-012028-07-01
Who is boundOS provider, covered app store, developerCovered 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?NoYes, only if it "offers an account setup feature"
Consent to share the bracketNot required in the textRequired: "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 providersNot namedExpressly named
Age bracketsunder 13 / 13-15 / 16-17 / 18+Identical
PenaltyUp to $2,500 per affected child negligent, $7,500 intentional$50,000 per violation
EnforcementAttorney General onlyAttorney General exclusively
ExemptionsBroadband, telecoms service, physical productsNews 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.

  1. 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.
  2. Treat the AppleID skip 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.
  3. 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.
  4. 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.
  5. 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:

← Back to Field Notes