Intune macOS Platform SSO with Automated Device Enrollment

If you read my May note that Intune now completes Platform SSO registration during macOS Automated Device Enrollment, you probably had the same reaction most of my readers did: good, now show me the whole build. This guide is that build. It covers what Platform SSO is and what it replaces, what Apple Business Manager and the enrollment policy need to look like, every setting in the Intune settings catalog policy with the value I recommend, how device compliance and Conditional Access see a Mac afterwards, how to verify a registration, and what to do when a Mac gets stuck in Setup Assistant. Every requirement, setting name, and version number here is checked against Microsoft Learn as of October 2026. Where I add my own opinion, I say so.

What Platform SSO is and what it replaces

Platform SSO (PSSO) is a macOS capability that Microsoft lights up through the Microsoft Enterprise SSO plug-in shipped inside the Intune Company Portal app. Per the Microsoft Entra overview, users sign in to the Mac with their Microsoft Entra ID identity, the device becomes Microsoft Entra joined, and a hardware-bound Primary Refresh Token (PRT) gives single sign-on across every app and browser that authenticates with Entra ID. Microsoft describes the sign-in experience as similar to Windows Hello for Business, and it is the first time I have been able to tell a security team that Macs and Windows PCs follow the same passwordless story.

Two things it replaces. First, the old SSO app extension profile you may have deployed from the Intune Device Features template. Platform SSO includes the SSO app extension, so you do not configure it separately, and once PSSO is working Microsoft tells you to unassign the older profile to avoid conflicts. Second, the two-phase onboarding where a Mac enrolled through ADE, reached the desktop, and only then nagged the user to register through a notification. With macOS 26 and Company Portal 5.2604.0 or newer, the registration happens inside Setup Assistant.

One boundary to know before you design anything: Microsoft states that Platform SSO is supported only for Microsoft Entra join. There is no hybrid join support and no plan for it.

The three authentication methods

The authentication method decides how a user unlocks the Mac and what happens to the local account password. This comparison is condensed from the Intune configuration guide and the Entra overview.

Secure Enclave provisions a hardware-bound key in the Mac’s Secure Enclave. The local account name and password are left exactly as they are, by design, because FileVault uses the local password as the disk unlock key. After a reboot the user types the local password once, then Touch ID handles unlocks, and the hardware-backed PRT does the rest. The credential can also be used as a passkey through WebAuthn; if you restrict passkeys by AAGUID, add 7FD635B3-2EF9-4542-8D9D-164F2C771EFC for the macOS Platform Credential.

Password replaces the local account password with the Entra ID password and keeps the two in sync. Microsoft warns that any Intune password policy you deploy applies to this setting, and that your Intune password or compliance policy must match the Entra password policy, or the sync fails and users are denied access.

Smart Card uses the card certificate and PIN for both the Mac and Entra ID. It needs Entra certificate-based authentication, and Microsoft notes that smart card authentication is not supported in Setup Assistant, so registration happens after the user reaches the desktop.

My recommendation matches Microsoft’s: Secure Enclave for everyone who can. I only reach for Password when an organization has a hard requirement that the local password equals the Entra password, and I accept the password-policy coupling that comes with it.

Requirements and licensing

Apple Business Manager and Automated Device Enrollment

Automated Device Enrollment (ADE) is Apple’s method for corporate-owned Macs purchased through Apple Business Manager or a participating reseller. Per the Intune ADE overview, ADE devices are supervised by default, can ship straight to users, and start enrolling the moment someone turns them on. New enrollments also receive an ACME certificate for the management profile on macOS 13.1 or later, which is a quiet security improvement over SCEP.

The enrollment program token

The token is the trust relationship between Intune and Apple. The token setup article walks through it; the sequence is:

1. In the Intune admin center, go to Devices > Enrollment > Apple > Enrollment program tokens > Create, accept the data-sharing consent, and Download your public key as a PEM file. Keep the browser tab open; closing it invalidates the key.
2. In Apple Business Manager, open Devices > Management Services > Connect external device management, name the connection, upload the PEM, and download the .p7m server token.
3. Assign devices to that management service while you are in the Apple portal.
4. Back in Intune, enter the Apple ID that downloaded the token, upload the .p7m, and select Create.

Use an organizational Apple ID, not a personal one, and write down which one you used. The token must be renewed yearly, and also whenever that Apple ID’s password changes or its owner leaves. Do not click Download Token in Apple Business Manager unless you intend to renew; doing so invalidates the token Intune is using.

Intune syncs with Apple automatically every 12 hours; you can trigger a manual sync no more than once every 15 minutes, and a full sync runs no more than once every seven days. Devices released from Apple Business Manager disappear from Intune within 30 to 45 days.

The enrollment policy

Create the policy under Devices > Device onboarding > Enrollment > macOS > Enrollment program tokens > your token > Enrollment policies > Create policy > macOS. Microsoft is retiring the older Profiles experience, so build new work under Enrollment policies. The ADE setup article describes every option; these are the ones Platform SSO cares about:

• User Affinity: Enroll with User Affinity. Userless enrollment disables Company Portal, and Microsoft explicitly says not to target registration-during-setup profiles at userless ADE devices.
• Authentication method: Setup Assistant with modern authentication. After the user signs in to Company Portal the device registers with Entra ID, is added to the user’s device record, can be evaluated for compliance, and gains access to Conditional Access-protected resources.
• Await final configuration: Yes.
• Locked enrollment: Yes, so users cannot remove management from System Settings or Terminal. You cannot change this after enrollment without a wipe.
• Device group: optionally a static Microsoft Entra security group for enrollment-time grouping; this needs the enrollment time device membership assignment RBAC permission.
• Account settings: optionally create a local administrator managed by Intune’s macOS LAPS, which gives each Mac a unique, random 15-character admin password rotated every six months by default. If you configure any account settings, Await final configuration is forced on in the background.
• Setup Assistant panes: enter a Department Name and Phone, then hide what you do not want users to see. On macOS 15.4 and later the Restore pane cannot be hidden.

Assign the policy to devices under the token, or set it as the token’s default policy. A synced Mac that powers on without an assigned policy fails enrollment, so I always set a default before the first device ships.

What Await final configuration actually does

Microsoft describes it precisely: just before the home screen loads, Setup Assistant pauses and lets Intune check in with the device, and the experience is locked while the user waits. Users can watch policies download, there is no minimum or maximum time limit, and in Microsoft’s validation most devices were released within 15 minutes. It is the default for new enrollment policies and off for existing ones, so check any policy you created before 2026. This pause is the hook that makes Platform SSO registration happen before the desktop, and it is the setting I see missed most often when a deployment “mostly works”.

The Platform SSO settings catalog policy

Create it under Devices > Manage devices > Configuration > Create > New policy, platform macOS, profile type Settings catalog. In Add settings, expand Authentication and select Extensible Single Sign On (SSO). You can assign only one SSO policy to a group, so if you already have a Platform SSO policy, add the new settings to it rather than creating a second one.

Required settings and recommended values

The values below come from the Intune Platform SSO configuration guide and the registration-during-enrollment article.

Two notes on Token To User Mapping. The alternative preferred_username value overwrites what you set in LAPS account settings, and the LAPS SamAccountName is ignored. If you need the on-premises SamAccountName as the local account name, Microsoft says you must run Company Portal 2608.0 or newer and set Enable Create First User During Setup to false, at the cost of the user authorizing three times during enrollment. And if you change Authentication Method or Use Shared Device Keys on a policy that is already deployed, every device re-registers. Decide those two settings before the pilot.

Registration during Setup Assistant

With Enable Registration During Setup on, the Platform SSO registration runs during the ADE flow instead of after it. Microsoft notes that users will enter their Entra credentials at least twice: once to start enrollment and once in Company Portal, which delivers the SSO extension. When Intune detects Company Portal assigned as a line-of-business app to the enrolling user, it sends the app with priority during enrollment. If any of the three policies is missing or misconfigured, enrollment fails and the only fix is to correct the policies, wipe, and re-enroll.

Account modes: admin or standard users

The Platform SSO scenarios article documents the end-user settings. Microsoft adds that undocumented Platform SSO settings are not supported, so resist the urge to experiment with Apple keys that are not listed.

My pattern: let the ADE enrollment policy create a LAPS-managed local administrator, list that account under Non Platform SSO Accounts, and set both authorization modes to Standard. The LAPS account satisfies the “at least one Admin” rule, the user runs as standard, and the help desk can look up the admin password in Intune when they need it.

A few more scenarios live in the Extension Data dictionary of the same policy: enable_se_key_biometric_policy = true forces Touch ID whenever the Secure Enclave key is used (macOS 14.6 and Company Portal 2504 or newer, with no password fallback, and it requires a full re-registration if you turn it on after the fact); AppPrefixAllowList = com.microsoft.,com.apple. plus browser_sso_interaction_enabled = 1 and disable_explicit_app_prompt = 1 carry over the broker settings most of us had in the old SSO extension profile; and custom_tgt_setting controls Kerberos ticket mapping to on-premises Active Directory and Entra ID Kerberos resources on Company Portal 2508 or newer.

Shared devices and userless Macs

Use Shared Device Keys makes Platform SSO use the same signing and encryption keys for every user on the Mac, which is what you want on a device that several people sign in to with Enable Create User At Login. Shared Macs enrolled without user affinity are a different case: Microsoft says not to target the registration-during-setup profile at userless ADE devices, Company Portal does not run on them, and device compliance evaluation is not supported for userless macOS. If you must manage userless Macs, give them a separate Platform SSO policy without Enable Registration During Setup, assigned to device groups as the configuration guide allows for devices enrolled without user affinity.

Assignment: static user groups, not device groups

This is the point that trips up the most people, and it is one where I need to correct my own May post, which suggested a static device group. Microsoft’s instruction for registration during Setup Assistant is unambiguous: assign the Platform SSO policy, the Company Portal app, and the enrollment profile to the same Assigned (static) user groups. Device groups do not work, dynamic groups do not work, and if the three policies land on different groups, Platform SSO during enrollment fails. Assignment filters are allowed on those static user groups. The broader configuration guide adds that for any Mac with user affinity, device-group or filtered assignment can leave users unable to pass Conditional Access because Company Portal may skip Entra device registration. Create a dedicated group such as macOS-PSSO-Pilot, add the pilot users, and point all three policies at it.

Conditional Access and device compliance for Macs

The pay-off for all of this is that Conditional Access can trust the Mac. The Intune compliance overview explains the chain: when a device enrolls, it registers in Entra ID; Intune reports its compliance state to Entra ID; a Conditional Access policy with the grant control Require device to be marked as compliant uses that state to allow or block. Conditional Access itself needs Microsoft Entra ID P1, which Microsoft 365 Business Premium customers also have.

Before you build a device-based policy, open Endpoint security > Device compliance > Compliance policy settings and change Mark devices with no compliance policy assigned as from the default Compliant to Not compliant. Microsoft says to do this when you use Conditional Access, because the default treats every unpoliced device as compliant. The Compliance status validity period defaults to 30 days and can be set from 1 to 120.

Then create a macOS compliance policy. From the macOS compliance settings reference, the settings I use on almost every engagement are Require a system integrity protection, a Minimum OS version (or build, when a Rapid Security Response matters), Require encryption of data storage on device for FileVault, Firewall enabled, and Gatekeeper set to Mac App Store and identified developers. One warning deserves bold type: Microsoft states that requiring a password in a compliance policy expires the existing password for every account on the device, including the accounts LAPS and Platform SSO created. Manage passwords through a settings catalog policy with Change At Next Auth set to False instead.

What Conditional Access sees after a Platform SSO enrollment is a Microsoft Entra joined Mac with a hardware-bound workplace join certificate that only the SSO plug-in can use. Browsers need the broker too: Edge users must sign in to their Edge profile, and Chrome needs the Microsoft Single Sign On extension, which you can force-install with a preference file policy. If you still have per-user MFA enabled on accounts, turn it off and use Conditional Access MFA; Microsoft documents per-user MFA as a cause of password sync failure during registration.

Deployment order and the policies to create

Build in this order so that nothing arrives at a Mac before its dependencies do. If you script any of this through Graph, read my note on Multi Admin Approval now enforcing on app-only Graph calls first; a protected resource created from an unapproved service principal returns HTTP 403.

Run the Conditional Access policy in report-only mode for the first wave, read the sign-in logs, then switch it on. I track the Intune-side changes to this stack in my Intune What’s New series, and Microsoft’s own What’s new page recorded the registration-during-ADE feature in the week of May 11, 2026.

Verification

Start with what the user sees, because it tells you which stage failed. Microsoft’s out-of-box tutorial describes the flow: the Hello screen, region and network, a Remote Management prompt that downloads the Intune profile, an Entra sign-in with MFA (Authenticator recommended), and account creation. With registration during setup enabled, the Platform SSO registration and the Company Portal sign-in happen before the Awaiting final configuration screen releases the Mac to the desktop. On the Secure Enclave method the user types the local password once after a reboot and uses Touch ID after that.

Then check the Mac itself:

1. Settings > Users & Groups, select Edit next to Network Account Server, and confirm Platform SSO reads Registered. Select the Information icon beside the user to see the method: Secure enclave, Smart Card, or Password.
2. Settings > Privacy & Security > Profiles: the policy appears as the com.apple.extensiblesso Profile, and you can open it to confirm the URLs and identifiers.
3. In Terminal, as the signed-in user, run the status command. Microsoft says you should see SSO tokens retrieved at the bottom of the output, and on macOS 13 this command is the only way to check.

app-sso platform -s

4. If the Mac was previously registered the old way, open Keychain Access and confirm the legacy Workplace Join key is gone; Microsoft lists this as a validation step for migrated devices.

Then check the cloud side. In the Microsoft Entra admin center under Entra ID > Devices > All devices, the Mac shows as Microsoft Entra joined and is attached to the user’s device record. In Intune, the device page should show the Company Portal app installed, the Platform SSO configuration profile succeeded, and the compliance state as Compliant; Devices > Monitor > Setting compliance shows the Is active check that tracks the validity period. Finally, open Teams or Outlook and a Conditional Access-protected site in Edge with no credential prompt.

Troubleshooting

Microsoft maintains two troubleshooting pages, Platform SSO known issues and the Enterprise SSO extension guide. These are the failures I see in the field, with the documented fix.

If the three ADE policies were misconfigured and Macs are stuck, Microsoft’s recovery is specific: unassign the Platform SSO policy that has Enable Registration During Setup enabled and sync, set the setting to disabled (and Enable Create First User During Setup to disabled on the Password method) and sync again, then wipe the device. The wipe is required because only a fresh enrollment picks up the corrected profiles.

Collecting logs

For a Mac that reached the desktop, enable persistent debug logging, reproduce the problem, capture a sysdiagnose, then reset:

sudo log config --mode "level:debug,persist:debug" --subsystem "com.apple.AppSSO"
sudo sysdiagnose
sudo log config --reset --subsystem "com.apple.AppSSO"

To watch the SSO extension in real time while you reproduce an issue:

tail -F ~/Library/Containers/com.microsoft.CompanyPortalMac.ssoextension/Data/Library/Caches/Logs/Microsoft/SSOExtension/*

Company Portal has two helpers under its Help menu: Save diagnostic report writes CompanyPortal.zip with SSOExtension.log inside, and Send diagnostic report uploads the logs to Microsoft and gives you an incident ID for a support case. For a Mac stuck inside Setup Assistant, press Control + Option + Command + Shift + Period to trigger a sysdiagnose; the archive lands in /private/var/tmp/ as sysdiagnose_YYYY.MM.DD_*.tar.gz, a Finder-like window opens so you can AirDrop it, and from that same window you can open Company Portal and send the diagnostic report.

Migrating Macs already enrolled without Platform SSO

Most fleets are not starting from zero. Here is how I move existing, Intune-enrolled Macs, following Microsoft’s Company Portal registration tutorial and its SSO extension guidance.

Assign the Platform SSO settings catalog policy to the pilot static user group. At the next Intune check-in the Mac shows the Registration Required notification; the user selects Register, authenticates with MFA, and the device is Entra joined with Platform SSO. Microsoft states that this removes the old SSO registration and that the legacy workplace join registration is deleted from the keychain. Users can defer the notification, so set an expectation with a short email and a deadline. The Enable Registration During Setup setting is harmless on an already-enrolled Mac, so one policy can serve both new and existing devices with user affinity.

Microsoft’s caution is blunt: do not target users with a Platform SSO policy until it is tested and ready, because it can break existing users and their compliance conditions. Treat it like a Conditional Access change. Pilot with IT, then early adopters, then by department. When the pilot proves out, unassign the Device Features SSO extension profile so you never hit error 10002. If a Mac needs Platform SSO removed afterwards, remember that editing the existing profile in place does nothing once registration is complete; you must remove the targeting, sync, target a new profile with the Platform SSO settings disabled, and sync again, after which the legacy workplace join registration has to be redone for compliance to work.

Older hardware stays on the post-enrollment flow. Registration inside Setup Assistant needs macOS 26, but Platform SSO itself runs back to macOS 13, so a mixed fleet simply registers at the desktop on older Macs. If you have corporate Macs that were set up without ADE but are listed in Apple Business Manager and assigned an enrollment policy, sudo profiles renew -type enrollment on macOS 10.13 or later triggers ADE enrollment on a Mac that already went through Setup Assistant; the user then finishes Entra registration in Company Portal.

Move a mixed Intel and Apple silicon fleet in waves and keep the Conditional Access policy in report-only mode until the last wave has registered. Expect the most common ticket to come from users who dismissed the notification; the fix is to sign out and back in so it reappears.

What to do about it

1. Inventory your Macs by macOS version and Company Portal version; anything below macOS 26 or Company Portal 5.2604.0 registers after enrollment, not during it.
2. Confirm the Apple MDM push certificate and enrollment program token expiry dates and record which Apple ID owns the token.
3. Decide the authentication method now, because changing Authentication Method or Use Shared Device Keys later re-registers every device. Default to Secure Enclave.
4. Create an assigned (static) user group for the pilot. Do not use device groups or dynamic groups.
5. Add Company Portal as a required macOS line-of-business PKG app with only the com.microsoft.CompanyPortalMac bundle ID, assigned to the pilot group.
6. Build the Platform SSO settings catalog policy from the required-settings table, add Enable Registration During Setup, and assign it to the same group.
7. Create or update the ADE enrollment policy: user affinity, Setup Assistant with modern authentication, Await final configuration Yes, Locked enrollment Yes. Set it as the token default.
8. Create a LAPS-managed local administrator in the enrollment policy and list it under Non Platform SSO Accounts.
9. Set Mark devices with no compliance policy assigned as to Not compliant and deploy a macOS compliance policy without a compliance password requirement.
10. Confirm Users may join devices to Microsoft Entra covers the pilot users and that they have an MFA method registered.
11. Exempt the Microsoft and Apple association URLs from TLS inspection.
12. Wipe one Mac, enroll it, and verify with app-sso platform -s, the Entra device record, and a Conditional Access policy in report-only mode before you widen the rollout.
13. After the pilot, unassign any Device Features SSO extension profiles and move the Conditional Access policy to On.

Want this as a printable checklist? The Intune macOS Onboarding Checklist turns the steps above into twenty items, from the Apple Business Manager token to the pilot and migration plan.

Need a second pair of hands? Big Hat Group provides Microsoft Intune consulting for organizations in the United States and Canada, from a two-week health check to a full migration. Book a discovery call to talk through your environment.

Sources

• macOS Platform Single Sign-on (PSSO) overview - Microsoft Entra ID
• Configure Platform SSO for macOS devices - Microsoft Intune
• Add Platform SSO policy to ADE Profile on macOS devices - Microsoft Intune
• Platform SSO scenarios for macOS devices - Microsoft Intune
• Set up automated device enrollment (ADE) for macOS - Microsoft Intune
• Set up a macOS ADE token in Intune - Microsoft Intune
• Manage macOS ADE devices and tokens in Intune - Microsoft Intune
• Overview of Apple Automated Device Enrollment for macOS in Intune - Microsoft Intune
• Add the Company Portal for macOS app - Microsoft Intune
• Device compliance policies in Microsoft Intune - Microsoft Intune
• macOS device compliance settings in Microsoft Intune - Microsoft Intune
• Microsoft Entra Conditional Access overview - Microsoft Entra ID
• Join a Mac device with Microsoft Entra ID during the out of box experience with macOS PSSO - Microsoft Entra ID
• Join a Mac device with Microsoft Entra ID using Company Portal - Microsoft Entra ID
• macOS Platform single sign-on known issues and troubleshooting - Microsoft Entra ID
• Troubleshooting the Microsoft Enterprise SSO Extension plugin on Apple devices - Microsoft Entra ID
• What’s new in Microsoft Intune, week of May 11, 2026