Use secure token, bootstrap token, and volume ownership in deployments
Secure token
For Mac computers with APFS volumes, encryption keys are generated either during device enrollment, user creation, setting the first user’s password, or during the first login by a user of the Mac. This implementation of the encryption keys, when they’re generated, and how they’re stored are all part of a feature known as secure token. Specifically, a secure token is a wrapped version of a key encryption key (KEK) protected by a userʼs password.
To prevent this from happening, add ;DisabledTags;SecureToken to the programmatically created user’s AuthenticationAuthority attribute before setting the user’s password, as shown below:
sudo dscl . -append /Users/<user name> AuthenticationAuthority ";DisabledTags;SecureToken"Bootstrap token
A bootstrap token enables macOS to grant a secure token to accounts including accounts created on-demand using Platform Single Sign-on and mobile accounts without needing to authenticate separately with an already secure token-enabled administrator account. If your device management service supports the bootstrap token feature and one has not yet been generated by macOS and stored with the service, macOS attempts to generate one and store it any time any currently secure token-enabled user logs into the Mac. In most cases, this means that a bootstrap token is be available for use by Mac computers in your organization.
On a Mac with Apple silicon, a bootstrap token can also be used to:
Authorize the installation of software updates.
Silently authorize an Erase All Content and Settings device management command (macOS 12.0.1 or later).
Create new users when they first log in with Platform SSO (macOS 13 or later).
On a Mac with macOS 26 or later, it creates a bootstrap token already during device management enrollment if the device management service supports it. The bootstrap token is used in turn to grant the first created user account a secure token.
Volume ownership
Mac computers with Apple silicon introduce the concept of volume ownership. Volume ownership in an organizational context isn’t tied to the true legal ownership or chain of custody of the Mac. Instead, volume ownership can loosely be defined as the user who first claimed a Mac by configuring it for their own use, along with any additional users. You need to be a volume owner to make changes to the startup security policy for a specific install of macOS, authorize the installation of macOS software updates and upgrades, initiate an Erase All Content and Settings on the Mac, and more. The startup security policy defines the restrictions around which versions of macOS can boot, as well as how and if third-party kernel extensions can be loaded or managed.
The user that first claimed a Mac by configuring it for their use is granted a secure token on a Mac with Apple silicon and becomes the first volume owner. When a bootstrap token is available and in use, it also becomes a volume owner and then grants volume ownership status to additional accounts as it grants them secure tokens. Because both the first user to be granted a secure token and the bootstrap token become volume owners, as well as the bootstrap token’s ability to grant secure tokens to additional users (and thus volume ownership status as well), volume ownership should not be something that needs to be actively managed or manipulated in an organization. Previous considerations for managing and granting secure tokens should generally align with volume ownership status as well.
It’s possible to be a volume owner and not be an administrator, but certain tasks require checking the ownership of both. For example, modifying startup security settings requires being both an administrator and a volume owner, while authorizing software updates is allowed by standard users and only requires ownership.
To view the current list of volume owners on a Mac computer with Apple silicon, you can run the following command:
sudo diskutil apfs listUsers /The GUIDs listed in the diskutil command output of type “Local Open Directory User” map back to GeneratedUID attributes of user records in Open Directory. To find a user by GeneratedUID, use the following command:
dscl . -search /Users GeneratedUID <GUID>You can also use the following command to see user names and GUIDs together:
sudo fdesetup list -extendedOwnership is backed by cryptography protected in the Secure Enclave. For more information, see:
Command-line tool usage
Command-line tools are available for managing bootstrap tokens and secure tokens. The profiles command-line tool has a number of options to interact with the bootstrap token:
sudo profiles install -type bootstraptoken: This command generates a new bootstrap token and escrows it to the device management service. This command requires existing secure token administrator information to initially generate the bootstrap token, and the service needs to support the feature.sudo profiles remove -type bootstraptoken: Removes the existing bootstrap token on the Mac and the device management service.sudo profiles status -type bootstraptoken: Reports back whether the device management service supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.sudo profiles validate -type bootstraptoken: Reports back whether the device management service supports the bootstrap token feature, and what the current state of the bootstrap token is on the Mac.
The sysadminctl command-line tool can be used to modify secure token status for user accounts on a Mac computer. This should be done with caution and only when necessary. Changing the secure token status of a user using sysadminctl always requires the user name and password of an existing secure token–enabled administrator, either interactively or through the appropriate flags on the command.
Both sysadminctl and System Settings prevent the deletion of the last administrator or secure token–enabled user on a Mac. If the creation of additional local users is scripted using sysadminctl, for those users to be enabled for secure token, current secure token–enabled administrator credentials are required to be supplied either using the interactive option, or directly with the -adminUser and -adminPassword flags with sysadminctl.