M1 Secure Token Check

What the Apple Silicon Secure Token check does

This Automox Worklet™ audits Secure Token state on Apple Silicon Mac endpoints and reports whether the Automox service account is positioned to perform privileged remediation. Evaluation gates the policy to arm64 hardware, and the remediation script queries Secure Token status for the console user and for the _automoxserviceaccount that the Automox agent installer provisions during enrollment.

Secure Token is the macOS credential that authorizes a user account to make changes to APFS volume cryptographic state. On Apple Silicon hardware, Secure Token gates almost every privileged action the Automox agent needs to perform – unattended macOS upgrades, FileVault key escrow, kernel extension approval, and any installer that touches a system volume. The Worklet surfaces the gap before it costs you a patch cycle.

The remediation script runs three checks in order. The first reads the console user with stat -f %Su /dev/console, then calls sysadminctl -secureTokenStatus and logs ENABLED or DISABLED without exiting, since the current user does not need a token for the service account to receive one. The second uses dscl . list /Users to confirm _automoxserviceaccount exists, exiting non-zero with errMessage when it is missing. The third re-runs sysadminctl -secureTokenStatus against the service account and exits non-zero when the token is disabled, so the result appears as a remediation in the Automox activity log.

Why verify Secure Token before patching Apple Silicon

Apple Silicon changed the rules. On Intel Macs, the Automox agent could elevate against most operations without a Secure Token grant. On M1, M2, M3, and later silicon, Apple folded Secure Token into the boot-time security model and tied volume ownership to the credential. A service account without a Secure Token can still run unprivileged shell commands, but the moment a policy needs to call softwareupdate --install --restart, fdesetup, or pkg installers that touch the system volume, the operation fails with a permissions error and the patch window closes with the endpoint unpatched.

Secure Token state is also brittle in ways that are easy to miss. A user account created locally after enrollment, a recovery partition repair, or a Migration Assistant pass that imports a personal Mac's account list can each leave _automoxserviceaccount on the endpoint without a token, even when the rest of the agent looks healthy in the console. Run this Worklet ahead of every macOS feature update wave to identify the endpoints that need a Bootstrap Token escrow from your MDM, or a one-time manual sysadminctl grant from a Secure Token holder, before the upgrade policy ever fires. The audit is read-only, so it is safe to scope broadly and re-run as a gate during a feature update rollout.

How Secure Token verification works

1. Evaluation phase: The script checks $(arch) and exits 0 on Intel Macs so the policy skips non-applicable endpoints. On arm64 hardware it exits 1, signaling Automox to run the remediation phase that performs the actual Secure Token probes. This pattern keeps the policy safe to scope broadly across a mixed Intel and Apple Silicon fleet without producing false positives on older hardware.

2. Remediation phase: The remediation script re-confirms arm64 and exits 1 on Intel as a manual-run guard. It captures the console user with stat -f %Su /dev/console, runs sysadminctl -secureTokenStatus against that user, and parses the seventh field of the output with awk for ENABLED or DISABLED, logging the result without exiting. It then calls dscl . list /Users | grep -o _automoxserviceaccount to confirm the service account is provisioned, exiting non-zero with errMessage when it is not. The final probe runs sysadminctl -secureTokenStatus _automoxserviceaccount and exits 0 only when the service account token is ENABLED, leaving a clear pass or fail signal in the Automox activity log.

Apple Silicon Secure Token requirements

• Apple Silicon endpoint (M1, M2, M3, or later) running macOS 11 Big Sur or newer; the script gates itself on arm64 and exits cleanly on Intel

• Automox agent installed via the standard PKG installer that provisions the _automoxserviceaccount local user

• sysadminctl available at /usr/sbin/sysadminctl (default on all supported macOS versions) and dscl available at /usr/bin/dscl

• An MDM that escrows a Bootstrap Token at enrollment (Jamf, Kandji, Mosyle, Intune, or Apple Business Manager paired) so Secure Token can be granted to the service account without an interactive prompt

• At least one human Secure Token holder on the endpoint to seed grants when Bootstrap Token is not yet escrowed

• FixNow capability enabled when you want to run the audit on demand against a single endpoint from the Automox console

Expected Secure Token audit outcomes

The Worklet reports one of four outcomes per endpoint. On Intel hardware, evaluation exits 0 and the policy records a no-op pass. On Apple Silicon where the service account holds a Secure Token, you will see the activity log line The Automox Service account has Secure token enabled. No further action is required., and the remediation phase exits 0. When the service account exists but lacks a Secure Token, the log captures The Automox Service account does not have Secure token enabled. and the remediation exits 1, flagging the endpoint as non-compliant. When _automoxserviceaccount is missing entirely, the log reads The Automox Service Account does not exist on the device, so it does not have a secure token. and the script exits before the third probe.

Validate the audit by running the same commands locally on a sample endpoint: sysadminctl -secureTokenStatus _automoxserviceaccount, profiles status -type bootstraptoken to confirm the MDM Bootstrap Token is escrowed with Apple, and fdesetup list to enumerate which accounts hold the FileVault unlock credential that Secure Token underwrites. Cross-check the output against the Automox activity log to confirm the two views agree.

Remediation paths depend on what the audit surfaces. When Bootstrap Token is escrowed, push an MDM command that calls profiles install -type bootstraptoken and let the platform grant Secure Token to the service account without user interaction. When Bootstrap Token is not yet escrowed, log in interactively as a Secure Token holder and run sudo sysadminctl -secureTokenOn _automoxserviceaccount -password - to seed the grant, then escrow the Bootstrap Token at next MDM check-in so the next replacement endpoint comes online ready. Re-run this Worklet after each remediation pass to confirm the endpoint is patching-ready before scheduling the macOS upgrade policy.