Update: my flowchart below is only talking about whether or not you end up with a secure token holder at initial deployment. This taking into account we are NOT yet enabling FileVault. Some readers had some confusion about the mobile accounts, but yes, enabling FV will grant a token to the enabling user... if no other token holder exists on the mac, but this is outside the scope of this flowchart. I’m only showing what happens at initial deployment WITHOUT enabling FV by any means.

Yes, I could not resists. After having a chat with some people, I still felt like there is soo much confusion on Secure Tokens, so I decided to try to put in into a flow chart.

I’m going to keep this post short. I only want to share the flow chart I made. Against based on all my testing and observations over the last few months, and cross checking my statements with Apple’s Official guide.

As said in my previous post, Apple should tweak their document to mention that if the very first interactive logging on the machine, or at the end of the Setup Assistant, is done by a LOCAL ADMIN, this account always gets a Secure Token. Regardless of whether or not there is another user with UID greater than 500 present on the mac (created by MDM during the DEP pre-stage, such as the Jamf Pro Management Account or any additional Admin).

IMO, based on all my testing, the additional +500 UID user only impacts Standard Users at the very first interactive login.

Apart from that, we have the behaviour of the Jamf Pro Pre-Stage Enrolment, which does not honour the User Initiated Enrolment settings as discussed in my previous post.

So, with that knowledge, here is my final wrap up on Secure Tokens. First flow chart showing how it should be. Second with Jamf Pro Pre-stage behaving a little different.

How Secure Tokens should behave.
Secure Token behaviour if you create the Management Account in Jamf Pro (User Initiated Enrollment settings) + add the “Account Payload” in the Jamf Pro settings.

That’s it! On this note, mic drop, Secure Token out.