macOS - Configuration - Enable Apple Silicon Patching

What the Apple Silicon secure token Worklet does

This Automox Worklet™ verifies that the _automoxserviceaccount has a secure token on Apple Silicon Macs, then grants the token when it is missing. Apple requires a secure token holder to authorize Apple-provided software updates on every arm64 Mac (M1, M2, M3, M4). Without the token, the Automox agent cannot install Apple-provided updates, and softwareupdate exits without applying any patches.

The Worklet detects the architecture with arch, resolves the service account with id -un (evaluation) or id -u (remediation), and queries the token state with sysadminctl -secureTokenStatus _automoxserviceaccount. When the token is absent, the remediation script attempts two grant paths in order. The first path reads the SECURE_TOKEN_ADMIN_USER and SECURE_TOKEN_ADMIN_PASSWORD secrets from the Automox console and calls /usr/local/bin/amagent --adminuser <user> --adminpass <password>.

When the secrets path is not configured or the admin call fails, the Worklet falls back to the active console user. It resolves the user with scutil show State:/Users/ConsoleUser, confirms that user holds a secure token, and prompts the user with launchctl asuser <guid> /usr/local/bin/amagent --automox-user-prompt enable. The prompt times out after 300 seconds. If both grant paths fail, the script runs fdesetup list to enumerate FileVault volume owners and profiles status -type bootstraptoken to check MDM bootstrap escrow, then writes an Automox Recommended Solution message to stderr so an admin can finish the grant through MDM.

Why enforce secure token configuration on Apple Silicon endpoints

Apple Silicon Macs treat the secure token as the authorization root for installing Apple software updates. The Automox agent cannot drive softwareupdate until _automoxserviceaccount holds that token, so an Apple Silicon endpoint without proper configuration silently drops every macOS patch policy you schedule. Common compliance baselines (CIS macOS Benchmark 1.x, NIST 800-53 SI-2, PCI-DSS 6.3.3) assume the endpoint can receive Apple security updates inside the patch SLA. A Mac without a secure token fails the control even though the policy shows as scheduled.

A new-hire laptop, a re-imaged developer machine, or an MDM enrollment that skipped the bootstrap token escrow all land in the same missing-token state, and sysadminctl reports the Automox service account as missing from the SecureToken roster on every one of them. The next evaluation pass catches the missing token, the remediation phase writes it, and the unpatched-CVE finding never reaches the next quarterly Apple Silicon audit.

How secure token enforcement works

1. Evaluation phase: The script gates on arch == arm64 and exits 0 immediately on Intel Macs so non-Apple-Silicon endpoints stay out of scope. It then runs id -un _automoxserviceaccount to confirm the service account exists and pipes the output of sysadminctl -secureTokenStatus _automoxserviceaccount through a substring check for ENABLED. The endpoint is flagged non-compliant (exit 1) when the token is not enabled, and remediation is queued.

2. Remediation phase: The remediation script re-checks the token status with secureTokenEnabled, then attempts two grant paths. (1) If SECURE_TOKEN_ADMIN_USER and SECURE_TOKEN_ADMIN_PASSWORD are set via Automox Secrets, it runs /usr/local/bin/amagent --adminuser <user> --adminpass <password>. (2) On failure or when secrets are absent, it resolves the active console user with scutil show State:/Users/ConsoleUser, validates that user holds a secure token, and triggers the macOS security prompt with launchctl asuser <guid> /usr/local/bin/amagent --automox-user-prompt enable (300-second timeout, polled every 3 seconds). When both grant paths fail, a trap on EXIT calls getVolumeOwners, which lists FileVault owners via fdesetup list and probes MDM bootstrap escrow via profiles status -type bootstraptoken, then writes an Automox Recommended Solution message to stderr that surfaces in the activity log.

Apple Silicon secure token requirements

• Apple Silicon Mac of any generation (arch returns arm64), including M1, M2, M3, and M4. Intel Macs are out of scope: evaluation exits 0 and the remediation script exits 1 with a message that secure token is not required.

• macOS 11 Big Sur or later. Apple introduced the secure-token-for-software-update requirement on the first Apple Silicon release and has not relaxed it on Ventura, Sonoma, or Sequoia.

• _automoxserviceaccount present on the endpoint. The standard Automox agent installer creates this account; if a custom installer was used, create it before running this Worklet.

• One viable grant path. Options include an Automox Secret pair (SECURE_TOKEN_ADMIN_USER + SECURE_TOKEN_ADMIN_PASSWORD) for an existing token-holding admin, a logged-in console user who holds a secure token, or an MDM with the bootstrap token escrowed to the server.

• Network reachability from the endpoint to the Automox console so policy results, exit codes, and recommendation messages return to the activity log.

• FileVault state readable. The script calls fdesetup list to enumerate volume owners when other paths fail; an FDE error surfaces as a stderr message rather than a hard failure.

Expected secure token state after remediation

After a successful grant, sysadminctl -secureTokenStatus _automoxserviceaccount returns ENABLED. The remediation exits 0 with the message 'Secure Token successfully granted and enabled for Automox service account' (or, when the secrets path succeeds, 'Secure token successfully granted to Automox service account by <admin>'). The Automox agent can now drive softwareupdate to install Apple-provided patches. Any macOS patch policy that was previously deferred begins applying on the next policy run, and the endpoint reports Apple-provided update installation in its activity log instead of an authorization failure.

To verify manually, run sysadminctl -secureTokenStatus _automoxserviceaccount from a Terminal with admin rights and confirm the ENABLED substring. Re-run the evaluation script; a compliant endpoint exits 0 silently. If the grant relied on a console-user prompt, the local user will have completed a macOS security dialog and the remediation script will have echoed the authorizing username to stdout, which surfaces in the Automox activity log.