← PS C:\Blog\rksolutions> cd ..

Why macOS Platform SSO Fails the First Time During Setup Assistant

· 8 min read ·
Intune Entra ID Security M365

You configured the new macOS Platform SSO inline-registration flow exactly the way Microsoft’s GA blog describes it. The U-scope Settings Catalog policy with Enable Registration During Setup turned on, assigned to a static user group. Company Portal staged as a line-of-business app. An ADE profile with Setup Assistant, modern authentication, and Await final configuration set to Yes. You factory-reset a test Mac, walk into Setup Assistant, and wait for the Microsoft Entra prompt to appear inline.

It appears. You sign in. The sheet closes for a second, then a new one replaces it with an error about the single sign-on extension. Your stomach drops. Did the profile not land? Is the user in the wrong group? Did Company Portal fail to install? You dismiss the sheet, retry, and hit the same error. By now you have a browser tab open to start re-checking the policy.

Don’t. Click retry once or twice more. The sheet almost always succeeds by the third attempt, Setup Assistant moves to “Preparing your device”, and the user lands on the desktop fully registered. What looks like one bug is really a few timing edges in a feature that went GA only a month ago. Microsoft documents one of them in a troubleshooting note most admins never scroll to. The others you learn by hitting them.

This post describes Intune and macOS behavior observed in test environments during June 2026, shortly after Microsoft’s GA of Platform SSO inline registration during ADE. The timing here may be tightened in a future Intune service release or macOS update. Re-test on your own build before assuming any of it still applies.

Table of Contents

What Microsoft shipped at GA

In May 2026 Microsoft made Platform SSO with registration during ADE generally available for macOS. Instead of the legacy flow, where a user reached the desktop and registered Platform SSO afterward, registration now happens inline during Setup Assistant. The user signs in with their Entra account before they ever see the desktop, and arrives already registered.

The feature requires macOS 26 or newer and three policies that all target the same static user group:

  • A Settings Catalog policy with Enable Registration During Setup enabled (the U-scope Platform SSO policy)
  • Company Portal as a line-of-business app, version 5.2604.0 or newer, with only com.microsoft.CompanyPortalMac as the app bundle ID. Company Portal carries the Microsoft Enterprise SSO extension that Platform SSO depends on.
  • An ADE enrollment profile with user affinity, Setup Assistant with modern authentication, Await final configuration set to Yes, and locked enrollment

The setting that gates the whole flow is a single Settings Catalog key, shown here as the setting fragment (not a complete importable policy) inside your U-scope Platform SSO profile:

{
  "settingDefinitionId": "com.apple.extensiblesso_platformsso_enableregistrationduringsetup",
  "choiceSettingValue": {
    "value": "com.apple.extensiblesso_platformsso_enableregistrationduringsetup_true"
  }
}

Miss any one of those and the flow genuinely fails. Get all four right and it works, but not always on the first click, which is where the confusion starts.

Two assignment shapes, two flows

Before the error, understand which experience you signed up for. The assignment scope of the Platform SSO policy decides where registration happens, and the two paths feel completely different.

Assignment Where registration happens What the user sees
User-assigned (U-scope, recommended) Inline, during Setup Assistant The registration sheet appears and completes during Setup Assistant (with the retry behavior below). The user reaches the desktop already authenticated.
Device-assigned (D-scope) After Setup Assistant, on the desktop The user reaches the desktop without Platform SSO completing. macOS posts a notification to “complete the required registration”; the user clicks it, then signs in. A two-step experience.

Microsoft’s inline flow is built on the U-scope path, and that is what this post covers. The D-scope path is worth knowing exists, because if you assigned the policy to a device group you will not get the inline prompt at all, you will get the post-desktop notification instead. That is not a failure, just a different flow, and one some users miss or dismiss. If you want the smooth inline experience, assign to a static user group.

The error you will actually see

When the inline sheet fails, the wording points straight at the SSO extension. Microsoft documents it as:

“Unable to sign-in. There was an issue with the extension while registering your account for single sign-on. Try again in a few moments or contact your administrator.”

Microsoft Learn - Configure Platform SSO during ADE

In test environments during June 2026 the message also appeared as a blunter variant:

Unable to sign in.

This Mac does not have the necessary single sign-on application or
extension. Contact your administrator to help get single sign-on set up.

Either wording reads like a configuration disaster. It usually is not. When you see this during Setup Assistant, and you have the four config elements in place, it is almost always timing.

First: is Company Portal even on the device yet?

There are two distinct timing problems hiding behind that one error, and it pays to separate them.

The first is the cruder one: Company Portal may not be installed yet. During Setup Assistant you can watch the management profile install and the Entra prompt arrive, but the Company Portal LOB app installs in parallel and can lag behind. Company Portal is what carries the SSO extension, so if you click the sign-in prompt the instant it appears, there may be no extension on the device for the sheet to talk to. The error looks identical to the race below, but no amount of retrying fixes it until the app actually lands.

Practical guidance: after you see the management profile install, give it a couple of minutes before clicking the inline prompt for the first time. Pre-staging Company Portal through VPP does not meaningfully help; LOB delivery during ADE is already prioritized, and the wait is just the install completing.

The mechanism: a race, and the retry that wins it

Once Company Portal is on the device, the second timing problem is a genuine race. The Platform SSO Settings Catalog policy tends to arrive early in Setup Assistant, but the SSO extension inside Company Portal needs a moment more to finish loading into Apple’s SSO framework. Until it does, the registration sheet has nothing to register against, and it fails.

Microsoft actually documents this one, in the troubleshooting section of the configuration article: it explains that “the Platform SSO settings catalog policy is delivered, and the Company Portal is still downloading or installing”, and the resolution is to “select the Try again button on the error message until the Company Portal finishes downloading and installing.” It is easy to miss, because the GA blog and the main setup steps describe the happy path as if the first attempt succeeds.

In practice that means clicking through the error one to three times. Each retry simply buys the extension a few more seconds to load. You are not changing any config between attempts; you are waiting, with extra steps. The “always around three attempts” pattern is community-observed rather than a fixed number, so treat it as “retry a handful of times”, not a guarantee.

What success looks like

The clearest success signal is a Setup Assistant screen the legacy post-login flow never produced: “Preparing your device”. When the inline sheet finally takes, Setup Assistant transitions into that stage and then drops the user onto a fully registered desktop. If you reach “Preparing your device”, inline registration worked.

For the device-assigned path it looks different: the user lands on the desktop first, and the success cue is the absence of the “complete the required registration” notification once they have followed it through.

When the retry does not help

If you are on the fourth attempt with the same error, stop retrying and start checking. At that point the error is real, not racing, and one of the four required elements is wrong:

  • The Settings Catalog Platform SSO policy has Enable Registration During Setup enabled and is U-scope, assigned to a static user group that contains the signing-in user. Device groups and dynamic groups do not work for this feature.
  • Company Portal is deployed as a required LOB app, version 5.2604.0 or newer.
  • The SSO extension configuration lists only com.microsoft.CompanyPortalMac. If you inherited an older Platform SSO config with extra bundle IDs, prune them.
  • The ADE profile has Await final configuration set to Yes (plus user affinity and Setup Assistant with modern authentication). Without it, Setup Assistant rushes past the prompt before the policies land.

All four must point at the same static user group. If they target different groups, the inline flow fails.

Diagnostic commands

Run these on the Mac after enrollment (or during Setup Assistant if you can reach Terminal) to confirm state and to write up a clean post-mortem.

# Current Platform SSO state, as the standard user.
# Reports registered=true once the sheet has succeeded.
app-sso platform -s

# Is Company Portal actually installed, and is it new enough?
ls /Applications/Company\ Portal.app 2>/dev/null && \
  defaults read /Applications/Company\ Portal.app/Contents/Info.plist \
    CFBundleShortVersionString
# Expected: 5.2604.0 or higher. "No such file or directory" means the
# LOB install has not finished, so the error is upstream of the race.

# Which assignment shape did you actually deploy?
sudo system_profiler SPConfigurationProfileDataType 2>/dev/null | \
  grep -A 30 -i "ExtensibleSingleSignOn" | \
  grep -E "PayloadScope|EnableRegistrationDuringSetup"
# PayloadScope=User   -> user-assigned (inline Setup Assistant flow)
# PayloadScope=System -> device-assigned (post-desktop notification flow)

# Watch Apple's SSO framework as the sheet runs.
log stream --predicate 'subsystem == "com.apple.AppSSO"' --info --debug

Conclusion

Features go GA fast in this ecosystem, and the documentation catches up afterward. Platform SSO inline registration is a good feature: when it lands, the user is registered before they reach the desktop, and your help desk stops fielding “Platform SSO never finished” tickets. But the first-run experience has a few timing edges, and the instinct to treat “first attempt failed” as a misconfiguration sends admins tearing down a config that was correct all along.

Wait for Company Portal to install, retry the sheet a few times, watch for “Preparing your device”, and only reach for the config checklist once you are genuinely past the timing window. As of June 2026 that is the difference between a five-minute enrollment and an afternoon of chasing a bug that was never there.

References

← back to all posts next: macOS LAPS vs. Intune Password Compliance... →
PS Select-String -Pattern
↑↓navigate ↵open escclose