Bootstrap token quietly never escrows when you skip account creation in Setup Assistant

Zero-touch macOS flows that suppress the account-creation pane can leave no bootstrap token in your MDM — and nothing tells you. The token only escrows at the next login of a SecureToken-enabled account, so kernel extension approval, managed software updates and FileVault automation break later, on a seemingly random subset of the fleet. Here is what the two tokens actually are, and the one command that turns this from a mystery into a checklist item.

The problem

Your Automated Device Enrollment flow looks healthy: the Mac enrols, profiles land, apps install. Weeks later, failures start appearing that seem unrelated and random:

• Kernel extension installs that should be silent on Apple silicon stall or prompt, but only on some Macs.
• Managed software update commands queue and never complete on part of the fleet.
• FileVault enablement and SecureToken handoff behave inconsistently between machines that were provisioned identically.
• sudo profiles status -type bootstraptoken returns escrowed to server: NO on the misbehaving devices and YES on the healthy ones.

The common thread: these Macs went through a Setup Assistant flow that skipped local account creation — an MDM-created admin account, a shared or lab Mac, a kiosk build, or a Platform SSO enrolment. This bites Intune-first admins especially hard, because Windows Autopilot has no equivalent concept: on macOS, a critical device credential is minted as a side effect of a human logging in, and if your flow removes that login, the credential simply never exists.

Why it happens

Two tokens with confusingly similar names do different jobs:

That last row is the trap. Apple's deployment guide states the bootstrap token is generated and escrowed automatically "on the first login by any secure token-enabled user". If Setup Assistant never creates an account, no SecureToken-enabled user logs in during provisioning — and, as FileWave's documentation puts it, the SetBootstrapToken request is never transmitted to the MDM server. As the Travelling Tech Guy documented when testing macOS 11.0.1:

"Bootstrap however, is NOT immediately enabled" when account creation is skipped — it escrows "at the next login of a SecureToken-enabled account."
— Travelling Tech Guy, "FileVault, SecureToken and Bootstrap in macOS 11.0.1 Big Sur"

This is why the failures look random: on some Macs a human eventually logged in with a token-enabled account and escrow quietly happened; on others nobody ever did, so the MDM holds no bootstrap token. On Apple silicon that matters doubly, because the bootstrap token holder gets volume ownership — the thing MDM needs to authorise kernel extensions and software updates without a user present. Note the prerequisites too: the Mac must be enrolled via Automated Device Enrollment (supervised), and your MDM must support bootstrap token escrow.

The fix

1. Verify escrow — do not assume zero-touch handled it

On the Mac:

sudo profiles status -type bootstraptoken

You want two YES lines: Bootstrap Token supported on server: YES and Bootstrap Token escrowed to server: YES. Cross-check the device record in your MDM — Intune and Jamf both surface a bootstrap-token-escrowed flag.

2. If it says NO, force the escrow

• Easiest: log in once with a SecureToken-enabled account. Escrow fires at that login. Check which accounts qualify with sysadminctl -secureTokenStatus <username>.
• Manually: run sudo profiles install -type bootstraptoken and supply the credentials of a SecureToken-enabled admin. Success reports the token as created and escrowed.

3. Fix the flow, not just the device

• Make "bootstrap token escrowed: YES" a named post-enrolment verification step in your build checklist — not an assumption.
• If your flow must skip account creation, deliberately plan the first SecureToken-enabled login (who, when, with which account) as part of provisioning, not as something that happens whenever a user gets round to it.
• Script the check into your provisioning-complete criteria (an extension attribute, compliance script or inventory query on the profiles status output) so a NO is flagged before the device ships, rather than discovered when a kext deployment fails months later.

How Decolla handles it

Straight answer: it doesn't. Decolla provisions Windows devices over your own Intune and Autopilot tenant — it does not manage Macs, so it will never run this check for you on macOS.

What Decolla is built against is exactly this class of failure: a provisioning step that silently doesn't happen and only surfaces weeks later as apparently random breakage. Every Decolla deployment starts from a written, itemised plan — each item with its delivery method and reversibility class stated — approved before anything runs, and The Library bakes in recurring helpdesk fixes so known silent-failure patterns on the Windows side are checked rather than assumed. If you run a mixed fleet, apply the same discipline to your Mac builds: verification as a named step, never an assumption. Decolla is pre-launch; there is a waitlist at decolla.app.

Sources

• Travelling Tech Guy — FileVault, SecureToken and Bootstrap in macOS 11.0.1 Big Sur
• Apple Platform Deployment — Use secure token, bootstrap token and volume ownership
• FileWave KB — Bootstrap token management on macOS