Platform SSO with Secure Enclave: a macOS Intune onboarding flow that actually works

Platform SSO has been around since macOS Ventura, but most Intune deployments I see still treat it as an afterthought: a profile pushed sometime after enrollment, registration left to whenever the user notices the notification. Then everyone wonders why Conditional Access behaves inconsistently for the first week of a device’s life.

This post documents the flow I now deploy for macOS fleets on Intune — Platform SSO with the Secure Enclave key authentication method, registered during onboarding rather than after it.

Why Secure Enclave keys

The Platform SSO payload supports three authentication methods: Password, UserSecureEnclaveKey, and SmartCard. Password sync is what most people start with, because it feels familiar. It is also the weakest option: the local account password and the Entra ID password are kept in sync, which means your cloud password ends up typed at the login window, and password rotation events propagate in ways users don’t expect.

UserSecureEnclaveKey instead provisions a hardware-bound key in the Secure Enclave and registers it with Entra ID as a passkey-style credential. The result:

• The Mac becomes a phishing-resistant factor. Authentication requests from the device satisfy MFA without a prompt.
• The local password stays local. No sync, no surprise lockouts.
• Conditional Access policies requiring phishing-resistant MFA pass on device credentials.

The trade-off is conceptual, not technical: users keep their local password for FileVault and the login window, and some helpdesks struggle with “your Mac password is not your Microsoft password”. Document it once and move on — it is the correct architecture.

The payload

The Platform SSO settings live in the com.apple.extensiblesso payload. In Intune, use a settings catalog profile — the relevant settings are under Authentication > Extensible Single Sign On (SSO). The key settings, shown here as the equivalent profile XML:

<key>ExtensionIdentifier</key>
<string>com.microsoft.CompanyPortalMac.ssoextension</string>
<key>Team Identifier</key>
<string>UBF8T346G9</string>
<key>Type</key>
<string>Redirect</string>
<key>URLs</key>
<array>
    <string>https://login.microsoftonline.com</string>
    <string>https://login.microsoft.com</string>
    <string>https://sts.windows.net</string>
</array>
<key>PlatformSSO</key>
<dict>
    <key>AuthenticationMethod</key>
    <string>UserSecureEnclaveKey</string>
    <key>UseSharedDeviceKeys</key>
    <true/>
</dict>

Two things people miss:

1. Company Portal must be present before the payload lands. The SSO extension ships inside Company Portal. If the profile arrives first, the extension silently does nothing until the app exists. Deploy Company Portal as a required app and make it a blocking install during enrollment.
2. Type must be Redirect. The older Credential type is for Kerberos. Mixing them up produces an extension that loads and never triggers.

Registration during onboarding, not after

By default, Platform SSO registration starts when the user next interacts with something that needs it — which in practice means a passive notification that most users dismiss for days. During that window the device authenticates like an unregistered Mac, and Conditional Access policies keyed on device registration fail.

The fix is to force the registration prompt during your onboarding flow. app-sso ships with the OS and tells you where you stand:

app-sso platform -s

The JSON output includes registrationCompleted, loginDate, and the SSO tokens’ validity. In the onboarding script (mine runs under SwiftDialog, see the ESP post), poll that state and hold the “you’re done” screen until registration reports complete:

until app-sso platform -s 2>/dev/null | grep -q '"registrationCompleted" : true'; do
    sleep 5
done

The user experience: enrollment finishes, the Platform SSO registration panel appears as part of onboarding (“Register this Mac with your organization”), the user authenticates once with MFA, and the Secure Enclave key is provisioned. Total added time: under a minute. Devices leave onboarding fully registered, every time.

Verifying the result

On the device:

app-sso platform -s | grep -A2 registrationCompleted

In Entra ID, the device object shows a join type of Microsoft Entra registered (or joined, depending on your setup) and the authentication method appears on the user as a passkey credential named after the device.

The test that matters: sign in to a Microsoft 365 web app in Safari on the enrolled Mac. You should land in the portal without a password prompt — the SSO extension satisfies the request with the device credential. If you get an interactive prompt, check app-sso platform -s first, then the Console logs for com.microsoft.CompanyPortalMac.ssoextension.

Known sharp edges

• FileVault unlock ≠ login. Secure Enclave keys are only usable after first unlock. On cold boot the first authentication after FileVault unlock can be interactive. Users notice this once and never again; not worth engineering around.
• Local admin rotation tools that reset the login keychain will not break the Platform SSO key (it lives in the Enclave, not the keychain), but they can break the Company Portal token cache. If SSO stops working after a keychain reset, app-sso platform -d followed by re-registration recovers it.
• Don’t combine with password sync “just in case”. Pick one authentication method. Switching methods after deployment forces re-registration across the fleet.

This flow has been in production across two customer fleets since February. Registration completion at end of onboarding: 100%. Conditional Access noise in the first device week: gone.