By: Naveen Akkugari, Sr. Service Engineer and Michael Griswold, Principal Service Engineering Manager | Microsoft Intune

Who we are

Our internal Intune administration team at Microsoft is responsible for running Intune and Configuration Manager for the devices used by employees. We receive early access to features for evaluation and feedback using real world usage scenarios. As such, some features may be changed before the public release and be slightly different. The experience should be similar and we wanted to share our learnings when deploying platform single sign-on (PSSO). It is worth noting that since the time of this experience a new method for newer OS versions is available and you can read more about it at: New Platform SSO with registration during Automated Device Enrollment on macOS | Microsoft Community Hub.

Why we implemented Platform single sign-on (PSSO) and what we learned

As IT admins managing a growing Mac fleet, we kept running into the same gap. Our Windows devices had hardware-backed authentication, token protection, and seamless SSO through Windows Hello for Business, but our Macs were still relying on browser-based prompts with no easy way to enforce the same level of security and identity protection. Platform SSO finally closed that gap for us. It’s worth noting that new macOS allows new capabilities in this space and we are evaluating them as well. The new flow can be read about at https://aka.ms/Intune/MacPSSO-Setup.

While there were fewer pip-ups, we found the changes in the security layer to be the real value to our operations. Platform SSO binds authentication tokens (Primary Refresh Tokens) to the device’s Secure Enclave hardware. Even if a PRT is intercepted, it’s designed to not be replayed from another device. For our team, this unlocked two things we couldn’t do on macOS before:

• Token protection policies: Conditional Access can now verify that tokens are device-bound, the same enforcement we had been relying on with Windows Hello for Business
• Phishing-resistant MFA: Secure Enclave keys act as FIDO2 passkeys, so users authenticate with Touch ID instead of passwords or SMS codes

Getting from documentation to production took real effort for us. A password policy issue that silently blocked registration for half our pilot group, users who swiped away the registration banner without knowing what it was, and macOS updates that broke SSO overnight. This blog post is what we wish someone had written before we started.

How it works under the hood: Intune delivers the SSO extension profile → macOS prompts the user to register → the device registers with Microsoft Entra ID and gets a hardware-bound workplace (WPJ) certificate → a PRT is issued and bound to device hardware (not designed to be exported) → SSO works across Microsoft 365 apps, browsers, and Kerberos resources, all with token protection enforced.

Available authentication methods when we implemented

Quick setup using the Intune settings catalog

Prerequisites: macOS 13+, Intune with Microsoft Entra ID, Intune Company Portal v5.2404.0+

In the Intune admin center, navigate to Devices > Configuration > Create > macOS > Settings Catalog > Authentication > Extensible SSO

What the user experience looks like

Knowing what users see on their screen helps you write better rollout communications and cuts down help desk tickets.

First-time registration flow:

1. Profile arrives silently: After enrollment, Intune pushes the SSO extension profile to the Mac. Nothing visible to the user yet.
2. Registration banner appears: macOS displays a notification: “Registration required: Your organization requires you to register your device.” The user must click this to proceed. (This is our #1 learning point, users swipe it away, and there’s no simple way to retrigger it.)
3. Sign-in window: The user enters their Microsoft Entra ID email and password.
4. MFA challenge: Authenticator app push, phone call, or other configured method.
5. Secure Enclave key creation: macOS generates a hardware-bound key pair. The user may see a Touch ID or local password prompt to authorize this.
6. Registration completes: Device registers with Microsoft Entra ID, a WPJ certificate and PRT are issued. User sees a success confirmation.
7. SSO is active: From here, Microsoft 365 apps, Edge (natively), Chrome (with SSO extension), and Kerberos resources authenticate without prompts. Touch ID replaces password entry.

Missed the registration notification? Here is how to manually register:

This was our most common help desk ticket during rollout. If a user dismissed or missed the banner, they can still register manually through the following options:

1. (Recommended) System Settings → Users & Groups → Network Account Server: This is the easiest method. Go to System Settings → Users & Groups, scroll down to “Network Account Server” and click “Edit.” This opens a panel showing two sections: Network Servers and Platform single sign-on. If the Platform SSO policy is deployed, “Mac SSO Extension” will be listed under Platform single sign-on. If the device isn’t registered, there will be a “Register” button that can be selected to start the Platform SSO device registration flow.
2. Lock / Sign out and back in: Performing a lock or signing out of macOS followed by signing back in can retrigger the registration notification upon the next login attempt.
3. Wait for the notification to reappear: macOS retries the notification periodically around every 15 mins.
4. Last resort, reprofile: If none of the above work, an IT admin can remove and reassign the SSO extension profile in Intune. Before doing so, ensure any stale device objects are cleared from Microsoft Entra ID to avoid conflicts. Once the new profile lands on the device, the registration notification reappears.

How to verify Platform SSO registration

One of the first questions we got after rollout was “how do I know it’s actually working?” Here’s how both users and IT admins can confirm.

For IT admins (Microsoft Entra ID & Intune admin centers):

For users (on the Mac):

1. System Settings → Users & Groups → Network Account Server: Scroll down in Users & Groups to “Network Account Server” and click “Edit.” If the Platform SSO policy is deployed, they will see “Mac SSO Extension” listed under Platform Single Sign-on. A registered device shows a green dot with “Registered” status and a “Repair” button (useful if registration gets into a bad state). If not registered, they will see a “Register” button instead. This is the quickest at-a-glance check for users.
2. System Settings → Users & Groups: Click on the user account name in Users & Groups (on macOS 14+, click the info button “i” next to the user name). When Platform SSO registration is complete, a “Platform Single Sign-on” section will be listed under the account. If Platform SSO is active, the user account shows the Microsoft Entra ID identity linked to the local account.
3. Company Portal app → Devices: The device should show as “Compliant” and “Microsoft Entra ID registered.” If registration failed, it shows “Registration required.”
4. Terminal command: Run app-sso platform -s to check Platform SSO status.

Troubleshooting Platform SSO errors

If you run into issues during deployment, here’s how you can diagnose and fix issues.

Step 1: Check the Platform SSO profile in Intune device management

Before troubleshooting on the Mac itself, confirm the profile reached the device:

In Intune: Go to Devices → select the device → Device configuration. The SSO extension profile should show “Succeeded.” If it shows “Pending” or “Error,” the device hasn’t received the policy. Check assignment groups, sync status, and whether the device is enrolled.

Then on the Mac: Go to System Settings → General → Device Management (or Profiles on older macOS). Look for the SSO extension profile (com.apple.extensiblesso). It should show as “Installed” with no errors. If the profile isn’t listed, it hasn’t been delivered yet. Check Intune assignment and device sync.

Step 2: Check registration status on the Mac

Refer to the previous section “How to verify Platform SSO registration” for steps.

Step 3: Check SSO extension logs

Run in Terminal for real-time logs:

log stream --predicate 'subsystem == "com.apple.AppSSO"' --level debug

Then prompt a sign-in (open Edge or Outlook). Look for:
Error 10002: Duplicate SSO profiles. Remove the extra one from Intune.
Error 10003: Registration failed. Usually a network issue or TLS inspection blocking auth URLs.
User cancelled: User dismissed the registration banner.
Token refresh failed: PRT could not refresh. Check network and whether the Microsoft Entra ID password was recently changed.

Step 4: Verify from the admin side

Common error codes and fixes:

Best practices

1. Have newer OS devices and use the new flow: New Platform SSO with registration during Automated Device Enrollment on macOS.
   
   
2. Have users reset their password before Platform SSO registration. During initial enrollment, if password configuration or compliance policies are applied, users are required to reset their password after device enrollment and prior to initiating Platform SSO registration. Skipping this step can result in silent registration failures that are difficult to diagnose. Ensure this is communicated as the first step in your rollout guidance.
   
   
3. Assign the SSO profile during enrollment, not after. Deploying during enrollment means the registration prompt shows up at first login, a natural part of setup. Retrofitting existing devices forces users to notice and click a notification banner. Many will not. macOS Tahoe (26) Simplified Setup will auto-register, removing this friction.
   
   
4. One SSO profile per device, no exceptions. Duplicate profiles cause Error 10002. If you are migrating from a Device Features template to Settings Catalog, remove the old one first.
   
   
5. Pilot with realistic scenarios. Don’t just test “can I open Outlook.” Test registration, SSO to Microsoft 365, on-prem file shares, password change mid-session, reboot behavior, and what happens when a user dismisses the registration banner. We found issues in every one of these.
   
   
6. Align password policies end-to-end. For Password Sync, Intune compliance and Microsoft Entra ID password policies must match: length, complexity, expiration.
   
   
7. Integrate legacy Kerberos properly. If you run a standalone Kerberos SSO extension, set usePlatformSSOTGT = true in its ExtensionData to reuse Platform SSO TGT instead of running duplicate flows. Requires macOS 14.6+ and Company Portal 5.2408.0+.
   Enable Kerberos SSO to on-premises Active Directory and Microsoft Entra ID Kerberos Resources in Platform SSO.
   
   
8. Allowlist auth URLs from TLS inspection. Apple and Microsoft authentication endpoints must be excluded from proxy/TLS inspection. If they are not, registration fails silently with no error.

Challenges we faced

Conclusion

Platform SSO delivers phishing-resistant passwordless authentication, seamless cross-platform SSO, and Conditional Access compliance with hardware-backed identity. Start your implementation with Secure Enclave, deploy via Intune Settings Catalog, pilot small, then scale.

If you have questions on implementing Platform SSO, leave a comment below or reach out to us on X @IntuneSuppTeam.

Join our community! Discuss real-world scenarios, get expert guidance, connect with peers, and influence the future of Microsoft Security products. Learn more at aka.ms/JoinIntuneCommunity.