Platform SSO not working on macOS: the failures, in order

Platform SSO not working on macOS rarely announces itself. The Registration required notification never appears, or it appears every few hours, or registration completes and the password never syncs, and in at least one case Microsoft documents, the failure shows no error message at all. This post works through every cause Microsoft documents for Platform SSO, in the order I would check them, and names the places where the documentation and the public answers disagree.

Rereading the configuration guide rarely helps, because most of these failures sit outside the settings catalog policy: in Entra device settings, in a passcode payload, in the network path, or in the Secure Enclave itself. If the symptom is broader than single sign-on, start from working out which Intune layer a fault sits in. Every Microsoft fact below was checked against Microsoft Learn on 25 October 2026.

First, ask the Mac what state it is in

Before changing any policy, read the device. Microsoft’s Platform SSO known issues and troubleshooting page gives one command for checking the current Platform SSO state at any time, run in Terminal:

1# Show the current Platform SSO registration state for this Mac and user.
2app-sso platform -s

Read that output, and the device record in Entra, before touching the policy. The problems below present identically to the user, as a Mac that will not sign in to Microsoft 365 without prompting, and a device that never registered, one that registered and later lost its keys, and one that registered but never completed password sync each need a different fix. Treating all three as “run registration again” is how a short fault turns into a wipe.

For anything deeper, Microsoft documents a log capture in a fixed order: raise the logging level, reproduce the fault while noting the time, collect a sysdiagnose, then put logging back.

1# 1. Turn on debug logging for the AppSSO subsystem.
2sudo log config --mode "level:debug,persist:debug" --subsystem "com.apple.AppSSO"
3# 2. Reproduce the problem now, and note the time.
4# 3. Collect the diagnostic bundle.
5sudo sysdiagnose
6# 4. Return logging to its default.
7sudo log config --reset --subsystem "com.apple.AppSSO"

Registration never starts

When the Registration required notification never appears at all, the cause is usually upstream of the Mac. Check these four in order.

1. The user is not allowed to join devices. Microsoft is unusually blunt about this one: “If a user has insufficient permissions to complete Microsoft Entra ID join and registration, no error message is shown.” The setting is Users may join devices to Microsoft Entra, under Entra ID, Devices, Overview, Device Settings. If it is scoped to selected users, the person at the keyboard has to be in scope.
2. Company Portal is too old. The Intune guide to configuring Platform SSO requires Company Portal 5.2404.0 or newer and states plainly: “If you have an older version of the Company Portal app installed, Platform SSO fails.” Deploy it as a required app rather than relying on what was installed at enrolment.
3. The policy is assigned to the wrong kind of group. “For Platform SSO settings on devices with user affinity, it’s not supported to assign to device groups or filters.” That runs against the instinct most administrators bring to macOS configuration, and a device-group assignment produces a profile that arrives and does nothing useful. Shared Macs without user affinity are the exception and do take device groups, which is why how Intune decides which user owns a device matters more here than almost anywhere else on the platform.
4. The registration token is wrong. The value is {{DEVICEREGISTRATION}}, and Microsoft notes that you must include the curly braces.

Intune reports error 10001 or 10002

These are the two payload errors Microsoft documents for the policy itself.

10002 is the one that catches tenants which adopted the Enterprise SSO plug-in early. Their original profile was built from the Device Features template, while Platform SSO lives in the settings catalog, which has replaced the older templates for most new work. Microsoft’s instruction is to unassign the template profile once the settings catalog policy works, because “If you keep both policies, conflicts can occur.” The same guide says “You can assign only one SSO policy to your groups”, so Kerberos SSO and the other scenario settings belong inside the one policy, not in a second.

Third-party write-ups also circulate an error 100001, with an extra zero. Microsoft’s page documents 10001 and 10002 only, and I could not find 100001 in Microsoft documentation, so I would not build a runbook entry around it.

Platform SSO not working after sign-in: the password never syncs

With the Password authentication method, registration can succeed and the sync step still fail. Microsoft documents three causes.

A local password policy stricter than Entra. Microsoft’s wording: “There’s a known issue where an applied MDM configuration specifies a local password policy with a higher degree of complexity than the Microsoft Entra account used to sign-in to the machine. In this case, the password synchronization operation between Microsoft Entra ID and the local machine fails.” The remedy given is to make the two sets of requirements identical.

This is where the public answers go wrong. A Microsoft Q&A thread, Can’t sign PSSO using Entra ID to enable PSSO, getting repeated notifications, reports the dialog “Configuration Error – Your password doesn’t meet the local password policy requirements.” The accepted answer attributes it to the Sequoia re-registration bug. The text on screen points instead at the complexity mismatch, which is a separate known issue on the same Microsoft page. The reporter had already removed compliance password policies with no change, and Microsoft’s wording names “an applied MDM configuration” rather than compliance, so the next place I would look is any configuration profile carrying a passcode payload. I cannot prove which cause applied in that tenant. I would rule out the mismatch first, because it matches the error and costs nothing to check.

Per-user MFA. “If a user has per user MFA enabled on the account where PSSO is being set up, you won’t be able to enter Microsoft Entra ID credentials in the next steps, causing an error.” Microsoft’s fix is Conditional Access MFA in place of per-user MFA.

Temporary passwords. “Temporary passwords issued during password reset can’t be synced to the local device.” A user who is mid-reset will look like a sync failure until the reset is finished.

One behaviour that is not a fault: after an Entra password change, Microsoft says the user is prompted for the new password within four hours. A helpdesk that does not know this will open tickets for it.

Registration keeps coming back

Repeated prompts have two documented causes, one fixed and one by design.

The Sequoia concurrency bug. On macOS 15, simultaneous updates from the AppSSOAgent and AppSSODaemon processes could corrupt the device configuration and trigger re-registration. Microsoft’s page now says “Apple confirmed the fix is deployed in macOS 15.3” and directs anyone still affected on 15.3 or later to Apple support. The signature in a sysdiagnose is Error Domain=com.apple.PlatformSSO Code=-1001 with the description “Error deserializing device config.” Any Mac below 15.3 should be updated before anything else is investigated.

Lost Secure Enclave keys. “Because Secure Enclave keys are protected by your local account password, password resets that occur without providing this password (such as FileVault or MDM-based recovery) resets the Secure Enclave.” Microsoft continues that devices whose keys are lost “must be reregistered to use Platform SSO.” This is by design, and it turns a routine helpdesk action, the FileVault recovery, into a Platform SSO incident. It belongs in the password reset runbook, not the SSO one.

Two smaller causes from the same page: if the user closes the authentication dialog mid-registration, they need to sign out and back in before the notification works again, and if registration fails through the Settings app, the prompt returns after about ten minutes.

It works at home and fails in the office

That pattern means TLS inspection. Microsoft states that the device registration URLs must be “explicitly exempted from TLS interception or inspection”, and that this is “critical for registration and device auth flows that rely on TLS challenges to complete successfully.” Token acquisition also depends on Apple’s app-site-association domains, which Microsoft calls “critical for SSO extension functioning.” The page also carries a note that Microsoft recently changed the TLS endpoint used in registration, so an allowlist written last year may already be stale.

Setup Assistant says the single sign-on application is missing

When registration runs during Setup Assistant, the Platform SSO profile can arrive before Company Portal does. Microsoft’s guidance is that the Try again button “should succeed once Company Portal arrives.” The harder case is a profile changed while setup is in progress: those changes “won’t take effect until the device is wiped and started clean.” The documented recovery is to unassign the profile that enables registration during setup, assign one with it disabled, and wipe. All of this runs through Automated Device Enrollment, so it also depends on the Apple Business Manager token that enrolment relies on being current.

What Platform SSO does not support

• Hybrid join. “No, macOS PSSO is only supported in Microsoft Entra join deployments. There are no plans to support hybrid-join deployments.”
• AD-bound mobile accounts. Neither Microsoft page cited here addresses them. A public Apple developer forum report describes registration stalling at the password sync step on AD-bound mobile accounts, with no error shown and no answer posted. Until either vendor documents it, I would treat AD binding and Platform SSO as incompatible.
• Changing the local password under Secure Enclave. Secure Enclave leaves the local account password as it is, which Microsoft describes as “by design due to Apple’s FileVault disk encryption, which uses the local password as the unlock key.” Users expecting one password everywhere will not get it with that method.

What I would do differently

Most reports of Platform SSO not working trace back to something an administrator could have checked before the pilot started. I would set the Entra join permission, match every passcode payload to the Entra password policy, retire per-user MFA, and get the TLS exemptions in place before the first Mac registers, then pilot on a user group rather than a device group.

I would still choose Secure Enclave as the method, because it is phishing-resistant and is the method the Intune configuration guide marks as recommended, but I would tell the helpdesk on day one that a FileVault recovery now costs a reregistration. And I would put app-sso platform -s into the first-line script, because it is the cheapest first look at what the device itself believes about its registration. If you want registration state visible in Intune rather than on the Mac, a custom compliance script for macOS is the mechanism I would try first. I have not built one for this.

I have not run Platform SSO across a Mac fleet, and my own tenant is a lab, so everything above is what Microsoft documents and what practitioners report publicly. The order of checks is my judgement about where it is most likely to bite.

Last verified: 25 October 2026.