Home > Apple File System, FileVault 2, Mac administration, macOS > Secure Token and FileVault on Apple File System

Secure Token and FileVault on Apple File System

As part of Apple File System’s FileVault encryption on mac OS High Sierra, Apple introduced Secure Token. This is a new and undocumented account attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume. To help make sure that at least one account has a Secure Token attribute associated with it, a Secure Token attribute is automatically added to the first account to log into the OS loginwindow on a particular Mac.

Users and groups preference pane only user gets secure token automatically

Once an account has a Secure Token associated with it, it can then create other accounts which will in turn automatically be granted their own Secure Token.

For the consumer user, this usually takes the following form:

  1. Secure Token is automatically enabled for the user account created by Apple’s Setup Assistant.
  2. The Setup Assistant-created user account with Secure Token then creates other users via the Users & Groups preference pane in System Preferences. Those accounts get their own Secure Token automatically.

However, Active Directory mobile accounts and user accounts created using command line tools do not automatically get Secure Token attributes associated with these accounts. Without the Secure Token attribute, those accounts are not able to be enabled for FileVault.

Filevault preference pane account without secure token cannot manage filevault


Update 1-20-2018: @mikeymikey has pointed out an exception to the rule:


Instead, the sysadminctl utility must be used to grant Secure Token to these accounts as a post-account creation action. In that case, the sysadminctl utility must be run by a user account with the following pre-requisites:

  1. Administrative rights
  2. Secure Token

For more details, please see below the jump.

There are a couple of ways to check from the command line if a particular account has the Secure Token attribute associated with it:

sysadminctl -secureTokenStatus username_goes_here

Note: The sysadminctl utility has multiple ways to provide the needed admin authorization to run. Please see this post for details.

Sysadminctl interactive secureTokenStatus otheruser

Sysadminctl interactive secureTokenStatus username

dscl . -read /Users/username_goes_here AuthenticationAuthority

Dscl authentication authority username account showing secure token

Dscl authentication authority username account showing secure token using grep

You can also check in Directory Utility to see if a Secure Token entry appears under the account’s Authentication Authority attribute.

Directory utility username account showing secure token

Once it’s been verified if an account needs Secure Token, sysadminctl‘s SecureToken functions can be used to add it.

The command shown below should add Secure Token to a specified account

sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password password_goes_here

If you want to be prompted for the account’s password, use the command shown below:

 sysadminctl -secureTokenOn username_which_needs_secure_token_goes_here -password -

To see how the process of adding Secure Token to an account which doesn’t have it works, please see the video below. It will go through the following process:

  1. Using sysadminctl to check an account for its Secure Token status
  2. Using sysadminctl to check the logged-in account for its Secure Token status
  3. Using sysadminctl to grant Secure Token to the first account, using the logged-in account’s credentials and Secure Token.
  4. Using sysadminctl to check the first account to verify that Secure Token has been added.

To see how user accounts created in System Preferences’ Users & Groups preference pane automatically get Secure Token when created by an account with Secure Token, please see the video below. It will go through the following process:

1. Creating a new user account in the Users & Groups preference pane
2. Verifying via sysadminctl that the new user account has Secure Token

  1. wes
    January 20, 2018 at 9:59 pm

    Ran the migration assistant from one machine to another and I ended up with a password protected disk and no users had secure tokens. The migration assistant threw errors (I forget which). I decrypted and encrypted the disk again and I was able to enable all users for filevault but curiously none appear to have the securetoken still.

  2. January 21, 2018 at 2:03 pm

    Thanks for the well written article. I’ve been running into this with every new system I setup. I noticed that with the systems I migrated to High Sierra That were already FileVault enabled I didn’t have any issues with user not being able to unlock FV disk. I’m guessing because the account was already on the system that a token was passed? I’ll have to use commands in this article to test.

  3. John Altonen
    January 22, 2018 at 4:17 pm

    We create mobile accounts with scripts. Here is the behavior I am observing:

    FileVault is enabled with one valid admin account

    create additional mobile accounts via script inside the existing admin account.

    use sysadminctl to turn on Secure Token for one of these scripted accounts

    enable the user for FileVault in the FileVault section of the Security and Privacy preference pane.

    restart. The mobile account user does NOT show up on the FV unlock screen.

    Create a new local account with Users and Groups GUI and restart

    Both the new local account and the mobile account show up at the FV unlock screen.

  4. January 22, 2018 at 7:14 pm

    Workflow for this feels like it’s going to be messy for those of us in JAMF environments where the users are not admins. May have to create a script to temporarily raise the enduser creds to admin to run the sysadminctl command as them to add the token to other users?

  5. jbrickley
    January 23, 2018 at 11:24 pm

    Ugh, now I guess we need a pop-up dialog prompting the user to authenticate so an elevated script can turn it on and provide the password. This is exactly what we train our users NOT to do in extensive Phishing Training. I guess I will have to put it in Self-Service and present a dialog with the company logo, etc.

  6. drewdiverDrew
    February 6, 2018 at 12:04 pm

    This nuked my occasional setup of a laptop where I install what’s needed, remove the account along with /var/db/.AppleSetupDone..

  7. Stephen Short
    February 9, 2018 at 10:03 pm

    I’ve run into some interesting behavior re: secureToken and the pycreateuserpkg tool. I create a new user with SetupAssistant, and it receives a secureToken as expected. A config profile is pushed from my MDM server that enforces Filevault. I reboot to enable FV for that user. After login, I install my admin_user.pkg created with pycreateuserpkg. I go to System Preferences and enable this second user for FV disk access. If I run -secureTokenStatus I get a positive “enabled” response, but if I reboot I am only presented with my Setup Assistant-created user.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: