PSSO Just Got Smarter: Platform SSO in macOS Setup Assistant — A Deep Dive

Three lines pulled from a fresh Mac’s logs tell the whole story:

Starting PSSO Setup Assistant install of [Company Portal]

macOS 26.5 detected

skipping AppSSOAgent kill (Apple regression fixed in 15.5+)

Company Portal is now configuring Platform Single Sign-On in Setup Assistant phase before the user even reaches the desktop. Microsoft is silently dropping a long-standing workaround. And the Intune daemon has a brief, expected case of stage-fright right after the first boot. Setup Assistant has quietly become the new front door for Platform SSO on macOS — and there’s a lot happening behind it that’s worth unpacking.

Let’s get into it.

What’s Changed: From Click-Through to Out-of-Box

If you’ve deployed PSSO on macOS before, you know the drill. The Mac arrives, the user signs in to their local account, Setup Assistant finishes, the desktop loads — and then the real onboarding begins. They wait for the PSSO prompt to register, click through MFA, finally see the PSSO registration banner, register, and… now they’re productive. Maybe twenty minutes in, maybe two-three support tickets later.

That experience is gone. With the latest Intune release, PSSO is woven directly into Setup Assistant itself — but more importantly, it’s woven into the enrollment itself. The user’s identity is no longer something the device discovers after the fact. It’s the very thing that bootstraps the device.

The Old Flow (pre-Setup Assistant PSSO)

The classic PSSO journey looked like this:

• User completes Setup Assistant and creates a local account.
• Lands on desktop.
• Launches CP manually, signs in with Entra ID.
• Waits for the PSSO config profile to load.
• Receives the registration prompt — sometimes minutes later, sometimes not until after a logout/login cycle.
• Completes user registration
• Then the benefits of PSSO begin

Every step was an opportunity to drop off. Help desks know the shape of this pain — the “I’m logged in but nothing’s working” ticket lives here.

The New Flow (PSSO in Setup Assistant)

Apple introduced the underlying capability in their deployment guide: organisations can now activate and enforce Platform SSO during Setup Assistant with Automated Device Enrollment. Intune has now caught up and exposed it as a first-class feature in the ADE profile. Here’s what actually happens on the device:

• Mac is wiped or unboxed → first boot.
• Setup Assistant launches → device contacts Apple’s ADE service and is handed to Intune.
• During enrollment, macOS tells the MDM “I support Platform SSO”.
• Intune delivers the Platform SSO settings catalog policy with Enable Registration During Setup enabled.
• Intune Company Portal is installed automatically as a LOB app, providing the Microsoft Enterprise SSO plug-in.
• During Setup Assistant, the user signs in with their Microsoft Entra credentials. This first sign-in starts the regular enrollment process.
• A second sign-in authenticates the identity in Intune Company Portal and fetches the SSO extension.
• The device registers with Microsoft Entra ID, and a Microsoft Entra device registration certificate is issued.
• The user arrives at the desktop fully authenticated, with SSO active and Conditional Access satisfied.

The first credentials the device ever sees are the user’s real corporate credentials. The local account is provisioned fromthat identity, not bolted on afterwards. That’s the shift.

The Apple-Defined Sequence

It’s worth pausing on the order, because the mechanism isn’t a Microsoft invention — it’s an Apple-defined flow that Intune now plugs into:

1. macOS announces capability — during Automated Device Enrollment, the device explicitly tells the MDM it supports Platform SSO
2. MDM responds with a 403 and a redirect — instead of completing enrollment, Intune returns an authentication-required response containing the location of the SSO extension package (Company Portal) and the PSSO configuration
3. Device downloads & installs SSO extension + config — this happens during Setup Assistant, with no user present
4. Device registration — the SSO extension registers the device with Entra ID; silent if attestation is in play
5. User registration prompt — macOS surfaces the IdP login UI as a native Setup Assistant pane
6. Bearer token returned — successful IdP auth produces a bearer token
7. Enrollment completes using the bearer token — the same token authenticates both the MDM enrollment and (optionally) the Managed Apple Account sign-in
8. Local account created from IdP identity — short name, full name are derived from the IdP attributes you configure

The key point: users cannot proceed past this stage without a successful PSSO registration. It’s not a “nice to have” prompt that can be dismissed. It’s the gate. That’s by design — it guarantees every enrolled device starts life with a known, registered IdP identity.

What You’re Trading Off

There’s no free lunch. A few things to understand before flipping the switch:

• Single-user devices only. Apple is explicit about this — the SA-based PSSO flow is intended for one-to-one deployments because the first authenticator becomes the device’s primary user account. Shared iPad-style scenarios stay on the old “create local account, then register” path.
• Network at first boot is mandatory. The device must reach Apple’s ADE service, Intune, and Entra ID before Setup Assistant even shows the PSSO pane. No network → no enrollment → user is stuck.
• FileVault and the iCloud pane matter. For the Managed Apple Account sign-in to chain off the same bearer token, the iCloud Setup Assistant pane must be left visible. Skipping it via your ADE skip-keys breaks the silent MAA login.
• The PSSO config profile itself is unchanged. Authentication method, registration token, extension identifier, team identifier, URLs — all still configured the same way. The new thing is when the profile is delivered, not what’s in it.

Why It Matters

A few things change in practice, not just on paper:

• Zero-touch becomes actually zero-touch. Apple Business Manager ships the Mac → user boots → user logs in with Entra ID → done. No “now install Company Portal” step. No second login required.
• Time-to-productivity collapses. From ~20 minutes of onboarding fumble to roughly the duration of Setup Assistant itself.
• The “I forgot my local password” ticket disappears — there isn’t a separate local password to forget. The Entra ID credential is the login. (If password sync is used)
• PSSO registration state is predictable. Because registration happens during a controlled, scripted phase rather than after the user starts opening browsers and clicking around, you get a far cleaner success/failure signal in the logs.
• Managed Apple Account sign-in chains off the same auth event. One IdP authentication → MDM enrolled + PSSO registered + MAA signed in. Previously this was three separate user-driven steps.
• Help desk scripts get shorter. The first-day script used to be a page. Now it’s a sentence.

There is, however, a catch — three of them, actually. They only show up in the logs. But before we get there, we need to look at the configuration that makes this flow possible in the first place.

Prerequisites & Configuration

Setup Assistant PSSO might be the headline feature, but it sits on top of the same PSSO building blocks you’ve been working with — the com.apple.extensiblesso payload, Apple’s PlatformSSO dictionary, and the Microsoft SSO extension that ships inside Company Portal.

This part walks through three things: what needs to be true in your tenant before you flip the switch, the Intune-side configuration to enable it, and a closer look at the PlatformSSO dictionary itself so you actually understand what each setting is doing rather than just copying screenshots.

Prerequisites

The simplified Setup Assistant PSSO experience is only fully available when all of the following are true. Miss one and the flow either degrades to the post-desktop registration prompt or breaks entirely.

Important: the existing PSSO Settings Catalog policy from your “classic” deployment carries over. You’re not creating a new profile from scratch — you’re adding one setting to it. If you don’t have a PSSO policy yet, build the base policy first using the configuration in the next section, then enable the Setup Assistant toggle.

Step 1 – The ADE Enrollment Profile

This is where the chain starts. In the Intune admin center, head to Devices > macOS > Enrollment > Enrollment program tokens, open your ABM token, and edit (or create) the enrollment profile:

• User affinity: Enroll with user affinity. The whole point of SA-PSSO is binding the device to a real user identity.
• Authentication method: Setup Assistant with modern authentication. This is non-negotiable.
• Await final configuration: Yes. The locked Setup Assistant pause is what gives Intune time to deliver the SSO extension and PSSO profile before the user is dropped at the desktop.
• Account settings: This is where Intune pre-populates the local account fields that show up in Setup Assistant. The values you set here are what the user sees when the PSSO pane in SA hands off to account creation. Pre-populating them produces a clean, tidy first-user account without depending on Apple’s EnableCreateFirstUserDuringSetup key.

Step 2 – Company Portal as a Required App

Push Company Portal version 5.2604.0 or newer as a required app to user group.

• Download the Company Portal for macOS PKG app from https://go.microsoft.com/fwlink/?linkid=853070
• In the Intune admin center, go to Apps > All Apps > Create.
• Add Intune Company Portal as a macOS LOB app.
• Make it a required app and assign it to the same groups as the Platform SSO policy.

In the SA-PSSO flow, Microsoft’s enrollment service detects PSSO capability and arranges for Company Portal to be pre-installed during Setup Assistant — but it still needs to know which version to deliver, and that comes from your Intune app catalogue. If you’re publishing an older Company Portal, the SA flow will use it and fail.

Step 3 – The PSSO Settings Catalog Policy

This is the same policy shape from the classic PSSO deployment, with one new setting at the end that turns the whole Setup Assistant flow on.

Create (or edit) a Settings Catalog policy under Devices > Configuration, platform macOS, profile type Settings catalog. In the settings picker, expand Authentication > Extensible Single Sign On (SSO) and configure the following.

Top-level extension settings

These describe the SSO extension itself — they sit at the root of the com.apple.extensiblesso payload, not inside the PlatformSSO dictionary:

• Extension Identifier: com.microsoft.CompanyPortalMac.ssoextension
• Team Identifier: UBF8T346G9
• Type: Redirect
• URLs: https://login.microsoftonline.com, https://login.microsoft.com, https://login.windows.net
• Registration Token: {{DEVICEREGISTRATION}} — the Intune variable that becomes the per-device registration token at deployment time. This is what enables silent device registration in the SA flow.
• Screen Locked Behavior: Do Not Handle (recommended — let macOS manage the lock screen).

The PlatformSSO dictionary — the heart of the configuration

Apple’s ExtensibleSingleSignOn.PlatformSSO dictionary is where you describe everything about how SSO behaves once the extension is active. Every key below is a child of that dictionary:

• AuthenticationMethod: Password, UserSecureEnclaveKey, or SmartCard. For Setup Assistant PSSO, UserSecureEnclaveKeyis the best end-user experience on Apple Silicon — TouchID-backed, phishing-resistant, no separate password to forget. Password is the safe default if you need the local password to stay synced to Entra ID for FileVault unlock.
• UseSharedDeviceKeys: true. Required for the registration to happen before any user exists on the device — shared device keys are the only keys available pre-user-creation. This is the setting that makes silent device registration during SA technically possible.
• AccountDisplayName: Entra ID (or whatever you want shown in the System Settings PSSO pane).
• EnableCreateUserAtLogin: true. Tells macOS that if the IdP-authenticating user doesn’t have a local account yet, create one from the IdP identity. This is the setting that turns the first Entra ID sign-in into a provisioning event.
• NewUserAuthorizationMode / UserAuthorizationMode: Standard, Admin. Microsoft currently supports Standard and Admin.
• EnableAuthorization: true.
• LoginFrequency: Integer in seconds. How often a full IdP re-authentication is required. Default is 18 hours (64800s); minimum is 1 hour.
• OfflineGracePeriod / AuthenticationGracePeriod: Integers in seconds. The first defines how long after a successful SSO login the local password can be used offline; the second defines a grace window after a policy change during which unregistered accounts can still log in.
• TokenToUserMapping (dictionary — see below)

⚠️ The new setting: Enable Registration During Setup → True. Without this, none of the SA-PSSO behaviour kicks in. The policy will still install, PSSO will still work — but post-desktop, the old way.

A note on EnableCreateFirstUserDuringSetup (and why you won’t find it in Intune)

If you’ve read Apple’s developer documentation or other blogs covering SA-PSSO, you’ll have come across the key EnableCreateFirstUserDuringSetup. Apple’s own warning is unambiguous — enabling registration without enabling user creation can lead to “incomplete or broken setup flows.”

So how does the Intune-based SA-PSSO flow work without it?

Look at the Microsoft Graph metadata for the com.apple.extensiblesso category — EnableCreateFirstUserDuringSetup is referenced in the parent PlatformSSO group’s child IDs, but the actual setting definition isn’t exposed in the Settings Catalog UI. Today, Intune surfaces these three SA-relevant keys:

• EnableRegistrationDuringSetup ✅
• EnableCreateUserAtLogin ✅ (the older key, predates SA-PSSO)
• ❌ EnableCreateFirstUserDuringSetup (referenced in the schema but not configurable)

Microsoft has effectively taken a hybrid path that achieves the same outcome without using Apple’s new key:

The Intune approach is:

• Trigger the PSSO pane in SA via EnableRegistrationDuringSetup
• Pre-populate the local account fields via the ADE enrollment profile’s Account Settings (Step 1)
• Create the local account via the classic EnableCreateUserAtLogin mechanism at the SA login window

Same outcome, different mechanism. EnableCreateFirstUserDuringSetup is in the Intune schema scaffolding, so it’s almost certainly coming as a configurable setting in a future release — but you don’t need it today, and your policy doesn’t need to set it.

TokenToUserMapping — turning IdP claims into local account properties

This sub-dictionary tells macOS which JWT claim from Entra ID becomes the local short name and the local full name. It’s the difference between a tidy username local account and a error like user.nam@abc.com.

Two keys live here:

• AccountName: The claim used for the local username (short name). Two common values in the wild:
  • preferred_username — straightforward but uses the full UPN. Many admins find this produces ugly home-folder paths.
  • com.apple.PlatformSSO.AccountShortName — a synthetic claim Apple derives from the IdP response, which strips the domain off the UPN. Generally a cleaner result.
• FullName: The claim used for the user’s full display name. name is the typical Entra ID choice; AccountName works in some tenant configurations.

Step 4 – Assignment

This is where SA-PSSO breaks slightly from the classic PSSO assignment pattern.

For classic PSSO (post-desktop registration), you assigned the policy to user groups. That still works for existing devices.

For Setup Assistant PSSO, the policy must reach the device before any user has authenticated — so user-group assignment still works. This guarantees the profile is delivered during the ADE policy push.

That’s the configuration side complete. The device is ready, the profile is ready, the user is ready to sign in for the first time. What actually happens next — what the logs reveal about how the pieces fit together at runtime — is where it gets interesting. 

The Deep Dive: What the Logs Actually Show

Configuration is one thing. What the device actually does between first boot and a working PSSO session is another. Three log files tell the full story:

• Company_Portal.log — the new Setup Assistant installer script’s own audit trail
• install.log — macOS’s install.log showing the PackageKit work
• IntuneMDMDaemon_*.log — the Intune MDM daemon’s structured runtime log

Pull them together and a clean timeline appears.

The Timeline

Three things in this sequence are worth pulling apart in detail.

Company Portal Pre-Installs Before the User Exists

The headline change. Pre-2604, Company Portal was something the user installed (or that Intune pushed as a required app after enrollment completed). In the new flow, it lands during Setup Assistant itself, with the Intune MDM Agent as its parent process. The evidence is unambiguous.

From Company_Portal.log — Microsoft’s own installer script writes its own header:

##############################################################
# Wed May 13 13:57:54 PDT 2026 | Starting PSSO Setup Assistant install of [Company Portal]
##############################################################
Wed May 13 13:57:54 PDT 2026 | Downloading Company Portal
Wed May 13 13:57:57 PDT 2026 | Download complete
Wed May 13 13:57:57 PDT 2026 | Downloading MAU
Wed May 13 13:57:57 PDT 2026 | Installing MAU
installer: Package name is Microsoft AutoUpdate
installer: The install was successful.
Wed May 13 13:58:06 PDT 2026 | MAU installed
Wed May 13 13:58:06 PDT 2026 | Installing Company Portal
installer: Package name is Intune Company Portal
installer: Upgrading at base path /
installer: The upgrade was successful.
Wed May 13 13:58:16 PDT 2026 | Install complete

Note the explicit phrasing — "PSSO Setup Assistant install of [Company Portal]". This is a distinct, named installer mode. Microsoft isn’t just opportunistically pushing CP earlier; they’ve branched the installation pipeline specifically for this scenario.

The smoking gun for who triggered the install lives in install.log — when PackageKit prepares to run Company Portal’s preinstall script, it stamps the responsible process:

2026-05-13 13:58:08-07 installd[685]: PackageKit (package_script_service): Preparing to execute script "./preinstall" in .../com.microsoft.CompanyPortalMac.T1eNBA
2026-05-13 13:58:08-07 package_script_service[1234]: Set responsibility to pid: 1270, 
   responsible_path: /Library/Intune/Microsoft Intune Agent.app/Contents/MacOS/IntuneMdmDaemon
2026-05-13 13:58:08-07 package_script_service[1234]: Hosted team responsibility for script set to team:(UBF8T346G9)

IntuneMdmDaemon is the parent. The team identifier UBF8T346G9 is Microsoft Corporation. Company Portal isn’t being installed by a user, by softwareupdated, or by some App Store mechanism — it’s being installed by the Intune agent itself, executing entirely in system context, during Setup Assistant, before any user account has been created.

The preinstall script then prepares a clean slate:

./preinstall: Looking for Company Portal with old bundle ID...
./preinstall: Did not find existing Company Portal with old bundle ID
./preinstall: Killing SSO Ext.
./preinstall: SSO Extension not running
./preinstall: Killing Autofill Ext.

And the postinstall script wires up the SSO plumbing — including the Entra identity broker XPC service that the SSO extension relies on:

./postinstall: Beginning to copy microsoft single sign-on mach service plist
./postinstall: /Applications/Company Portal.app/Contents/Resources/com.microsoft.entraidentitybrokerxpc.plist 
   -> /Library/LaunchAgents/com.microsoft.entraidentitybrokerxpc.plist

Why this matters: by the time Setup Assistant surfaces the PSSO authentication pane to the user, every piece of Microsoft’s identity stack is already in place — Company Portal, MAU, the SSO extension, the Entra identity broker XPC service, and the browser native messaging hosts for Chrome and Edge. The user types their Entra credentials into a fully-staged environment, not an empty one.

The Disappearing AppSSOAgent Kill

A single line in Company Portal’s postinstall script reveals a long-standing workaround quietly retiring:

2026-05-13 13:58:15-07 package_script_service[1234]: 
   ./postinstall: macOS 26.5 detected - skipping AppSSOAgent kill (Apple regression fixed in 15.5+)

To understand what this is, you need a bit of history. AppSSOAgent is the macOS daemon that hosts every SSO extension on the system — Microsoft’s, Apple’s built-in Kerberos one, Okta’s, and so on. For a long time, when an SSO extension was updated (e.g. a new Company Portal version), macOS’s daemon-loading logic had a regression where the agent would continue running with the old extension cached in memory. The fix from Microsoft’s side was a sledgehammer: their postinstall script would force-kill AppSSOAgent so that when launchd re-spawned it, the new extension would be loaded fresh.

That workaround had side effects. Killing AppSSOAgent mid-session interrupts every SSO extension on the device, not just Microsoft’s. Active authentications fail, in-flight token requests get dropped, and any Kerberos tickets being acquired vanish. It worked, but it was disruptive.

Apple fixed the underlying regression in macOS 15.5 (Sequoia) and the fix has carried forward into macOS 26 (Tahoe). Microsoft’s installer now detects the OS version and skips the kill on patched systems — letting launchd handle the extension reload natively.

In our log, the version check fires, the kill is skipped, and the install completes without disrupting any other identity services that might be coming up in parallel.

Why this matters: if you’ve ever blamed a flaky SSO experience on “Company Portal updated and now my Kerberos session is broken”, that pattern is now gone on supported OS versions. The conditional is also a useful diagnostic — if you see the opposite line (Killing AppSSOAgent...) in a postinstall log, your device is on an OS version below 15.5 and Microsoft’s old workaround is still active. That’s a hint the OS itself needs updating.

The pattern is consistent. Every ~10 seconds, the daemon launches, attempts a bootstrap, fails on a data-store write, and exits. From the IntuneMDMDaemon log:

2026-05-13 14:01:57:188 | IntuneMDM-Daemon | I | 3481 | SidecarDaemonLifecycleManager | Initializing service.
2026-05-13 14:01:57:200 | IntuneMDM-Daemon | I | 3492 | BootstrapSequence | Starting bootstrap sequence. Context: daemon
2026-05-13 14:01:57:200 | IntuneMDM-Daemon | I | 3492 | BootstrapSequence | Starting data sync.
2026-05-13 14:01:57:202 | IntuneMDM-Daemon | E | 3492 | InMemoryDataWithDiskPersistence+Extensions | 
   Data store error encountered. Error: StorageError.unableToWriteRecord(id: "b8ad7d85-6678-4fcc-a8e4-5bb278210a92"), 
   PolicyID: b8ad7d85-6678-4fcc-a8e4-5bb278210a92, Context: add
2026-05-13 14:01:57:202 | IntuneMDM-Daemon | E | 3492 | InMemoryDataWithDiskPersistence+Extensions | 
   Data store error encountered. Error: StorageError.unableToWriteRecord(id: "64bc3d31-786d-4c61-a6f4-ec5882af721d"), 
   ...
2026-05-13 14:01:57:203 | IntuneMDM-Daemon | E | 3492 | ExecutionClock | 
   Sequence measurement. Error: StorageError.unableToWriteRecord(...), Context: daemon bootstrap, 
   Duration: 0.0028, Status: failure

The bootstrap dies in 2.8 milliseconds. Same PolicyIDs cycle through each attempt — b8ad7d85-..., 64bc3d31-..., fef458c1-..., a7d24151-.... The daemon is trying to write the policy records it cached during the pre-reboot bootstrap into its on-disk store (InMemoryDataWithDiskPersistence+Extensions) and being told the disk isn’t ready to receive them.

What’s actually happening? During this window:

• The data volume the Intune daemon writes to is still being mounted and made available
• FileVault on Apple Silicon Macs has just unlocked and the keybag is still warming up
• The daemon’s launchd job starts immediately at boot — before user-session services are guaranteed ready

So the daemon launches, tries to persist its in-memory policies to disk, finds the store unwritable, fails fast, and launchdrespawns it. After ~17 attempts and roughly three minutes, the underlying storage becomes available and the next bootstrap proceeds cleanly:

2026-05-13 14:04:48:936 | IntuneMDM-Daemon | I | 15978 | BootstrapSequence | Starting bootstrap sequence. Context: daemon
2026-05-13 14:04:48:938 | IntuneMDM-Daemon | I | 15978 | BootstrapSequence | Establishing train. Domain: pulse
2026-05-13 14:04:54:122 | IntuneMDM-Daemon | I | 15983 | BootstrapSequence | Establishing train. Domain: afd
2026-05-13 14:05:14:794 | IntuneMDM-Daemon | I | 23688 | BootstrapSequence | Completed bootstrap sequence.
2026-05-13 14:05:14:794 | IntuneMDM-Daemon | I | 23688 | ExecutionClock | 
   Sequence measurement. Duration: 25.857735991477966, Status: success

25.8 seconds end-to-end, completes normally, and from this point onward the daemon syncs every 7 hours as configured.

Why this matters: this retry loop is expected behaviour, not a failure. The daemon is designed to be resilient against exactly this race condition — start fast, fail fast, get respawned, eventually succeed once the system settles. Three pieces of practical advice from this:

1. Don’t ship monitoring alerts on StorageError.unableToWriteRecord in the first 5 minutes after a SA-PSSO enrollment. You’ll wake up your SOC for nothing.
2. If the loop doesn’t resolve after ~5 minutes, now you have a real problem — usually FileVault not unlocking properly, or a corrupt Sidecar Core Data store from a prior failed enrollment.
3. Same PolicyIDs cycling = the policies themselves are fine (they’re cached in memory). Different PolicyIDs appearing each cycle would indicate the daemon is also failing to retrieve policy from the service, which is a network or auth problem, not a storage one.

What the Logs Tell Us Overall

Pulling all the logs together, a picture emerges of what “PSSO in Setup Assistant” actually is under the hood:

• It’s not a single new feature — it’s a coordinated pipeline.
• Intune Agent triggers Company Portal installation, which stages the SSO extension and Entra identity broker, which the OS then activates during the PSSO Setup Assistant pane.
• Microsoft is starting to lean on Apple’s platform fixes rather than carrying workarounds forward. The retired AppSSOAgentkill is the visible example; expect more of these as the OS matures.
• Race conditions during the first boot are designed-in and self-healing. The daemon’s retry behaviour is doing its job.

The user, meanwhile, sees none of this. They typed their Entra ID credentials into Setup Assistant and arrived at a fully provisioned desktop. The complexity is entirely backstage — which is exactly where it should be.

That’s the deep dive. Lets moves to verification — how to confirm the whole pipeline succeeded, and what a healthy app-sso platform -s looks like in the SA-PSSO world.

Verifying SA-Based PSSO

A successful Setup Assistant PSSO deployment is, ironically, almost invisible. The user signs in once during Setup Assistant, lands on the desktop, opens Outlook, and it just works. There’s no “Registration required” notification waiting in Notification Center. No popup nagging them through System Settings. No second login.

That’s the intended outcome. Confirming you actually got there — and not the “PSSO is technically configured but didn’t register during SA” near-miss — needs a deliberate checklist. Here’s how to verify it properly, in the order I run through it on every test device.

The First Five-Second Check

Before opening Terminal, look at the screen. If the device is healthy, three things should be true the moment the desktop loads:

• No “Registration required” notification in the top-right of the screen. If you see one, SA-PSSO didn’t complete — the classic post-desktop registration flow has kicked in as fallback, and you’re back where you started.
• The local account name reflects the IdP identity. Open the Apple menu — the username shown should match what your TokenToUserMapping produced (a clean short name, not firstname.lastname_contoso.com).
• No password prompt for Company Portal when you open it. CP should launch already signed in to the same Entra ID identity that completed Setup Assistant.

If all three are true, you almost certainly have a working SA-PSSO registration. The rest is just confirmation.

Command-Line Verification: app-sso platform -s

The single most useful PSSO diagnostic command, unchanged from the classic flow but now expected to return a populated state right after first login rather than after a manual registration. Open Terminal and run:

app-sso platform -s

A healthy SA-PSSO registration returns output along these lines:

Last login: Wed May 13 23:59:26 on console
someshpathak@intuneirl.com@Someshs-MacBook-Air ~ % app-sso platform -s
Time: 2026-05-13 23:15:25 +0000
Device Configuration:
 {
  "_accessTokenTerminalIdentityKeySEP" : false,
  "_accessTokenTerminalIdentityKeySystem" : false,
  "_deviceEncryptionKeyData" : "q4+XRcVUjf3UodxDwBtUeESVpb4N4ts=",
  "_deviceSigningKeyData" : "8BMnjnJEZxxUaficcyl6B8JnS+F+cao=",
  "accountDisplayName" : "Corp Account",
  "allowAccessTokenExpressMode" : false,
  "allowDeviceIdentifiersInAttestation" : true,
  "authGracePeriodStart" : "2026-05-13T21:58:00Z",
  "authorizationEnabled" : true,
  "created" : "2026-05-13T23:15:25Z",
  "createFirstUserDuringSetupEnabled" : true,
  "createUserLoginTypes" : [
    1,
    3
  ],
  "createUsersEnabled" : true,
  "deviceSigningCertificate" : "MIIDNzCCAh-IQ7vVfppBaxKPNICH4zANBgkqhkiG9w0BAQsFADB4MXYwEQYKCZImiZPyLGQBGRYDbmV0MBUGCgmSJomT8ixkARkWB3dpbmRvd3MwHQYDVQQDExZNUy1Pcmdhbml6YXRpb24tQWNjZXNzMCsGA1UECxMkODJkYmFjYTQtM2U4MS00NmNhLTljNzMtMDk1MGMxZWFjYTk3MB4XDTI2MDUxMzIxMjgzM1oXDTM2MDUxMzIxNTgzM1owLzEtMCsGA1UEAxMkYzgwYWY2YjItYmNlZS00MjFmLTk0MzMtMzFmNWU0YTVlNmJhMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEe92Ep5o6gPn0Xx6kN9uiT8M72eFIRCZ6u0JMX-c_rR4Wk0aOk9eg168jvA9f9mbJvIKMmefw55DH0epmw1F8kKOB0DCBzTAMBgNVHRMBAf8EAjAAMBYGA1UdJQEB_wQMMAoGCCsGAQUFBwMCMA4GA1UdDwEB_wQEAwIHgDAiBgsqhkiG9xQBBYIcAgQTBIEQsvYKyO68H0KUMzH15KXmujAiBgsqhkiG9xQBBYIcAwQTBIEQCCY6eEsQbUiQwxV-qIznPjAiBgsqhkiG9xQBBYIcBQQTBIEQDJA06P-R10-sPcOVxF_XezAUBgsqhkiG9xQBBYIcCAQFBIECQVMwEwYLKoZIhvcUAQWCHAcEBASBATEwDQYJKoZIhvcNAQELBQADggEBAEtjBaP0KerlA_qD7FtiyLsO_SNweDOiFlyyYNE1Ltev-shjQUwYvT9CRTKW_u7_CiU4ikM96nk9RmOCgXRX6xw9urZeUlMGUj4IB6LO9CQjDGd-kwG-8kUT4bI7xFa4BHh4lWumQRyXSH255mxOP0JwVvL8io2xy8Vo0jmo3Qwc7z1rXVivDTeHbrdBF3_1LzY1inO9SZBXwUzkvmNORE2q4b8GFHuTjYs1OWWiZzYvmIx1WfDP-xcfKOFLHEnjb6SdtOBxLGSXYsI4OMc2g3XaJM-oiDslK1REWhYeekQE9sh_0gBcg_TWYHdI6NbDa00nB_my-CfISNd-vc2C1vQ",
  "encryptionAlgorithm" : "ECDHE-A256GCM",
  "extensionIdentifier" : "com.microsoft.CompanyPortalMac.ssoextension",
  "fileVaultPolicy" : "None (0)",
  "lastEncryptionKeyChange" : "2026-05-13T21:57:59Z",
  "loginFrequency" : 64800,
  "loginPolicy" : "None (0)",
  "loginType" : "POLoginTypeUserSecureEnclaveKey (2)",
  "newUserAuthorizationMode" : "Admin",
  "nonPlatformSSOAccounts" : [
    "admin"
  ],
  "offlineGracePeriod" : "0 hours",
  "pendingEncryptionAlgorithm" : "none",
  "pendingSigningAlgorithm" : "none",
  "protocolVersion" : 1,
  "registrationCompleted" : true,
  "requireAuthGracePeriod" : "0 hours",
  "sdkVersionString" : 99.900000000000006,
  "sharedDeviceKeys" : true,
  "signingAlgorithm" : "ES256",
  "synchronizeProfilePicture" : false,
  "temporaryAccountCredentials" : {
  },
  "temporarySessionQuickLogin" : false,
  "tokenToUserMapping" : {
    "AccountName" : "preferred_username",
    "FullName" : "name"
  },
  "unlockPolicy" : "None (0)",
  "userAuthorizationMode" : "Admin",
  "version" : 1
}
Login Configuration:
 {
  "accountDisplayName" : "Microsoft Entra",
  "additionalScopes" : "aza urn:aad:tb:update:prt/.default profile offline_access openid",
  "audience" : "login.microsoftonline.com",
  "clientID" : "29d9ed98-a469-4536--f981bc1d605e",
  "created" : "2026-05-13T23:15:25Z",
  "customAssertionRequestHeaderClaims" : {
    "typ" : "JWT",
    "use" : "ngc"
  },
  "customKeyExchangeRequestBodyClaims" : {
    "aud" : "https://login.microsoftonline.com/e834900c-9-ac3d-c395c45fd77b/getkeydata"
  },
  "customKeyExchangeRequestHeaderClaims" : {
    "typ" : "JWT"
  },
  "customKeyExchangeRequestValues" : {
    "client_info" : "1",
    "prt_protocol_version" : "4.0",
    "tgt" : "true",
    "x-client-brkrver" : "3.17.0",
    "x-client-OS" : "26.5.0",
    "x-client-SKU" : "MSAL.OSX",
    "x-client-Ver" : "2.10.0"
  },
  "customKeyRequestBodyClaims" : {
    "aud" : "https://login.microsoftonline.com/e8340c-91ff-4fd7-ac3d-c395c45fd77b/getkeydata"
  },
  "customKeyRequestHeaderClaims" : {
    "typ" : "JWT"
  },
  "customKeyRequestValues" : {
    "client_info" : "1",
    "prt_protocol_version" : "4.0",
    "tgt" : "true",
    "x-client-brkrver" : "3.17.0",
    "x-client-OS" : "26.5.0",
    "x-client-SKU" : "MSAL.OSX",
    "x-client-Ver" : "2.10.0"
  },
  "customLoginRequestHeaderClaims" : {
    "typ" : "JWT"
  },
  "customLoginRequestValues" : {
    "client_info" : "1",
    "prt_protocol_version" : "4.0",
    "tgt" : "true",
    "x-client-brkrver" : "3.17.0",
    "x-client-OS" : "26.5.0",
    "x-client-SKU" : "MSAL.OSX",
    "x-client-Ver" : "2.10.0"
  },
  "customNonceRequestValues" : {
    "client_info" : "1",
    "prt_protocol_version" : "4.0",
    "tgt" : "true",
    "x-client-brkrver" : "3.17.0",
    "x-client-OS" : "26.5.0",
    "x-client-SKU" : "MSAL.OSX",
    "x-client-Ver" : "2.10.0"
  },
  "customRequestJWTParameterName" : "request",
  "deviceContext" : "rASWrp/uks2eHNvstyG66+CFkJqaLG+E8sTLQ=",
  "federationMexURLKeypath" : "federation_metadata_url",
  "federationPredicate" : "account_type = 'Federated'",
  "federationRequestURN" : "urn:federation:MicrosoftOnline",
  "federationType" : 2,
  "federationUserPreauthenticationURL" : "https://login.windows.net/common/UserRealm?api-version=1.0&checkForMicrosoftAccount=false",
  "includePreviousRefreshTokenInLoginRequest" : true,
  "invalidCredentialPredicate" : "error = 'invalid_grant' AND suberror != 'device_authentication_failed'",
  "issuer" : "https://login.microsoftonline.com/e834-91ff-4fd7-ac3d-c395c45fd77b/v2.0",
  "jwksEndpointURL" : "https://login.microsoftonline.com/e83491ff-4fd7-ac3d-c395c45fd77b/discovery/v2.0/keys",
  "kerberosTicketMappings" : [
    {
      "clientNameKeyName" : "cn",
      "encryptionKeyTypeKeyName" : "keyType",
      "messageBufferKeyName" : "messageBuffer",
      "realmKeyName" : "realm",
      "serviceNameKeyName" : "sn",
      "sessionKeyKeyName" : "clientKey",
      "ticketKeyPath" : "tgt_cloud"
    },
    {
      "clientNameKeyName" : "cn",
      "encryptionKeyTypeKeyName" : "keyType",
      "messageBufferKeyName" : "messageBuffer",
      "realmKeyName" : "realm",
      "serviceNameKeyName" : "sn",
      "sessionKeyKeyName" : "clientKey",
      "ticketKeyPath" : "tgt_ad"
    }
  ],
  "keyEndpointURL" : "https://login.microsoftonline.com/e834900cfd7-ac3d-c395c45fd77b/getkeydata",
  "loginRequestEncryptionAlgorithm" : "ECDHE-A256GCM",
  "nonceResponseKeypath" : "Nonce",
  "previousRefreshTokenClaimName" : "previous_refresh_token",
  "serverNonceClaimName" : "request_nonce",
  "serverNonceExpirationTime" : 300,
  "tokenEndpointURL" : "https://login.microsoftonline.com/e834900c-91ff-4c395c45fd77b/oauth2/v2.0/token",
  "uniqueIdentifierClaimName" : "oid",
  "userSEPKeyBiometricPolicy" : "None (0)"
}
User Configuration:
 {
  "_sepKeyData" : "mnSdzaP5qL2ccRbe7oi5U86HTzRu8LYqgI=",
  "created" : "2026-05-13T23:15:25Z",
  "kerberosStatus" : [
    {
      "exchangeRequired" : false,
      "failedToConnect" : false,
      "importSuccessful" : false,
      "realm" : "KERBEROS.MICROSOFTONLINE.COM",
      "ticketKeyPath" : "tgt_cloud"
    }
  ],
  "lastLoginDate" : "2026-05-13T22:00:36Z",
  "loginType" : "POLoginTypeUserSecureEnclaveKey (2)",
  "pendingSigningAlgorithm" : "none",
  "signingAlgorithm" : "ES256",
  "state" : "POUserStateNormal (0)",
  "uniqueIdentifier" : "992F9D80-CD5C-4887FBA2E479F65",
  "userLoginConfiguration" : {
    "created" : "2026-05-13T23:15:25Z",
    "loginUserName" : "s***k@intuneirl.com"
  },
  "version" : 1
}
SSO Tokens:
Received:
2026-05-13T22:00:36Z
Expiration:
2026-05-27T22:00:35Z (Not Expired)

The two states that matter are Device Registration: REGISTERED and User Registration: REGISTERED. Anything else — PENDING, FAILED, or missing entirely — means PSSO is not fully wired up. Note that on an SA-PSSO device, these should be REGISTERED the very first time you run the command, with no manual user action in between. That’s the differentiator from the classic flow.

Verify in the Logs (Quick Spot-Check)

For a clean retroactive check that PSSO actually completed during Setup Assistant and not afterwards, run the unified log filter we covered earlier and look for the device registration timestamp:

bash

log show --predicate 'subsystem == "com.apple.AppSSO" AND eventMessage CONTAINS "beginDeviceRegistration"' --last 1h

The timestamp on the first beginDeviceRegistration call should be before the first user-session login event. If it’s after, your “Enable Registration During Setup” setting didn’t take effect and registration is happening post-desktop.

The Quick “Did SA-PSSO Actually Work?” Checklist

For a fast yes/no on whether you got the simplified flow versus the classic fallback, this is the minimum I check:

Tick all seven and you’ve got a clean SA-PSSO registration. Tick the first three but miss the rest, and you almost certainly have the classic fallback flow doing its work post-desktop — functional, but not the simplified experience.

Of course, things don’t always tick cleanly.

Troubleshooting

The SA-PSSO flow is more reliable than the classic one because there are fewer moving parts at the user-facing surface — but the parts that can fail tend to fail silently. A device that “looks fine” but quietly fell back to classic PSSO is the most common scenario you’ll hit, and it’s the one most easily missed.

This section walks through the failure modes I’ve actually seen, what they look like in the logs, and how to recover.

Failure Mode #1 – SA-PSSO Silently Falls Back to Classic Flow

Symptom: The device enrols, the user reaches the desktop, and there’s a “Registration required” notification waiting in Notification Center. app-sso platform -s eventually returns REGISTERED after the user clicks through — but PSSO didn’t happen during Setup Assistant.

Cause: One of the SA-PSSO prerequisites isn’t met, and the flow gracefully degrades. The most common culprits, in order of frequency:

• Company Portal version below 5.2604.0. Intune’s Required Apps assignment is still pointing at an older CP package. The pre-2604 CP doesn’t know what to do with the SA installer hook and the flow falls back.
• Enable Registration During Setup not set in the PSSO policy. The settings catalog policy is otherwise correct but this single key is missing. Easy to miss because the policy still installs and “works”.
• macOS version below 26. Earlier macOS supports classic PSSO but not the SA-integrated flow. You’ll see the policy install and PSSO work post-desktop.
• ADE profile using legacy Setup Assistant. Make sure you’ve selected Setup Assistant with modern authentication. Legacy mode silently disables SA-PSSO.

How to confirm: Run the log spot-check from Part IV:

log show --predicate 'subsystem == "com.apple.AppSSO" AND eventMessage CONTAINS "beginDeviceRegistration"' --last 1h

If the first beginDeviceRegistration timestamp is after the first user-session login event, you’ve fallen back. If it’s before, you got the real SA-PSSO flow.

Failure Mode #2 – Setup Assistant Hangs on the PSSO Pane

Symptom: Setup Assistant displays the Entra ID sign-in pane, the user enters credentials, MFA prompts succeed, and then the pane spins indefinitely. Eventually the user gets an error like “Could not complete sign-in” and Setup Assistant either retries or fails outright.

Causes:

• No network egress to required Microsoft endpoints. SA-PSSO needs login.microsoftonline.com, enterpriseregistration.windows.net, device.login.microsoftonline.com, and Intune’s regional endpoints reachable during Setup Assistant — before the user can manually configure proxies. Captive portals and Zero Trust agents that need a logged-in user will both break this.
• Conditional Access blocking the registration. A CA policy that requires a compliant device, a specific location, or an Entra ID joined device will block a brand-new Mac that hasn’t yet completed any of those. You need a “device registration” or “macOS PSSO bootstrap” exclusion for the registration flow.
• MFA method not available. If your tenant requires phone-based MFA but the user only has Authenticator app configured (or vice versa), the Setup Assistant pane has no fallback path. The user is stuck.
• RegistrationToken not flowing. If you didn’t use the Intune variable {{DEVICEREGISTRATION}} in the PSSO profile, the silent device registration can’t happen, and the user-facing prompt fails because there’s no device context to attach the user registration to.

Recovery: Setup Assistant does let you skip the PSSO pane on the third failed attempt — the user can complete SA with a local account, reach the desktop, and finish registration via the classic post-desktop flow. Not ideal, but it gets the user productive while you fix the underlying issue.

Failure Mode #3 – Local Account Name is Garbled

Symptom: Setup Assistant completes, user lands on the desktop, but the username at the Apple menu reads something like user.name_contoso.com or user@contoso.com. The home folder at /Users/ mirrors the same ugliness.

Cause: TokenToUserMapping is set to preferred_username for AccountName. Entra ID returns the full UPN in that claim, and macOS uses it verbatim for the local short name.

Fix: Edit the PSSO Settings Catalog policy and change TokenToUserMapping > AccountName to com.apple.PlatformSSO.AccountShortName. This is a synthetic claim Apple computes by stripping the @domain.tld portion of the UPN, leaving a clean short name (user).

Caveat: existing enrolled devices will not automatically rename their local accounts when this policy changes. The mapping is evaluated at account creation time, not on every login. The new mapping only applies to future enrolments — anyone already on the device is stuck with the original name unless you wipe and re-enrol them.

Failure Mode #4 – Device Registration Succeeds, User Registration Doesn’t

Symptom: app-sso platform -s returns Device Registration: REGISTERED but User Registration: PENDING or FAILED. The WPJ certificate is present in the system keychain but the user’s login keychain has no Microsoft SSO tokens.

Causes:

• The user authenticating during Setup Assistant doesn’t have an Intune licence. Device registration uses the bootstrap token and doesn’t strictly need a per-user licence; user registration does.
• Conditional Access blocking user registration after device registration succeeded. A common pattern when CA policies allow Entra ID device registration but require MFA-compliant sessions for SSO token issuance, and the SA session’s MFA event has already expired.
• UseSharedDeviceKeys set to false with EnableCreateUserAtLogin set to true. Without shared device keys, user-specific keys are required for registration, and those can’t be provisioned before the user account exists — chicken and egg.

Recovery: Ask the user to manually trigger user registration from System Settings > the PSSO account > “Sign in again”. This restarts just the user-registration leg of the flow with a fresh MFA token.

Failure Mode #5 – The StorageError Loop Doesn’t Recover

Symptom: Post-reboot, the IntuneMDMDaemon log shows the same StorageError.unableToWriteRecord pattern we saw in Part III — but instead of recovering after ~3 minutes, the loop continues indefinitely. The device shows up in Intune as enrolled but never reports compliance, never receives policy updates, and Company Portal hangs on launch.

Causes:

• FileVault didn’t unlock. On Apple Silicon, the data volume holding the Sidecar Core Data store isn’t readable until FileVault unlocks. A bootstrap token failure or a stuck Setup Assistant means the volume stays locked.
• Corrupted Sidecar Core Data store from a prior failed enrolment. If this device was previously enrolled and the unenrollment was incomplete, leftover store files in /Library/Application Support/Microsoft/Intune/ can be unreadable.
• Disk space exhaustion. Rare but real — if the device’s data volume is critically full, the Core Data store can’t be written to. Usually only seen on devices with tiny SSDs that have been heavily used.

Recovery:

1. Check FileVault status: fdesetup status. If it’s locked, manually unlock.
2. If the store is corrupted, the clean fix is to wipe the Intune state and re-sync: stop the daemon, remove /Library/Application Support/Microsoft/Intune/, restart the daemon. It will rebuild from the service.
3. Always check df -h / before assuming anything else.

Failure Mode #6 – iCloud Setup Assistant Pane Was Skipped, MAA Sign-In Broken

Symptom: PSSO works correctly, the user is signed in, but the Managed Apple Account is not signed in even though the tenant is federated. The user has to manually enter their iCloud credentials.

Cause: The iCloud pane in Setup Assistant was disabled via your ADE skip-keys. The bearer token from PSSO authentication chains into MAA only if Apple’s Setup Assistant gets the chance to surface the iCloud pane. Skipping it bypasses the chain.

Fix: Edit your ADE enrolment profile and ensure the iCloud Setup Assistant pane is NOT in your skip-keys list. This is the one place where “fewer setup steps” actively works against you — leave the pane visible.

General Diagnostic Order

When SA-PSSO misbehaves in ways that aren’t on the list above, run through this sequence:

1. Visual check first. Did the device reach the desktop? Is there a “Registration required” popup? What does the Apple-menu username look like?
2. app-sso platform -s. Two REGISTERED lines = mostly fine; anything else = follow the specific failure mode.
3. Check Company Portal version. Open CP, About box. Below 5.2604.0 means you’re not on SA-PSSO regardless of what the rest of the config says.
4. Check Intune device record. Primary user set? Entra ID Device ID populated? Compliance reporting?
5. Wipe and retry. When in doubt, EACS-wipe the device and re-enrol with logging running from the start. SA-PSSO is timing-sensitive and a half-failed first enrolment is rarely worth salvaging.

Conclusion

Platform SSO for macOS started life as a clever workaround for the Mac’s identity gap — a way to bolt Microsoft Entra ID onto a system that was never designed to think in terms of corporate identity providers. With the 2604 release of Intune and Company Portal, paired with macOS 26 and Apple’s evolving Setup Assistant integration, it has finally become what it always wanted to be: a first-class, out-of-box experience that treats the user’s corporate identity as the starting point of the device’s life, not an afterthought bolted on at the desktop.

The three log lines we opened with told the whole story:

Starting PSSO Setup Assistant install of [Company Portal] — Microsoft is now sequencing Company Portal as part of Apple’s Setup Assistant pipeline, not a post-enrolment afterthought.

macOS 26.5 detected - skipping AppSSOAgent kill (Apple regression fixed in 15.5+) — workarounds carried for years are quietly being retired as the platform catches up.

For Mac admins, the practical impact is significant. Onboarding ceases to be a multi-step ritual that the user has to be coached through. The “I logged in but Outlook is asking me to sign in again” support ticket fades away. Conditional Access policies that depend on a registered device just work, because the device is registered before the user even reaches the desktop. Time-to-productivity collapses from twenty minutes of fumbling to roughly the duration of Setup Assistant.

There are still rough edges. The fallback to classic PSSO is silent when prerequisites aren’t met, which means audit and verification need to be deliberate. Standard-user devices are harder to troubleshoot from the user’s seatl. And the post-reboot stabilisation window is loud enough in the logs to trigger false alarms if you’re not expecting it. None of these are showstoppers — but they’re the kind of things you only learn by deploying.

If you’re rolling SA-PSSO out across an estate for the first time, the best advice I can offer is to wipe one test device, run the log-collection script on it from the moment Setup Assistant ends, and read through the timeline yourself. You’ll see the three nuggets fire in sequence. You’ll see what “healthy” looks like. And the next time something deviates from that pattern in production, you’ll spot it in seconds.

For deeper reading on the underlying mechanisms, Apple’s Platform SSO deployment guide and the Apple developer documentation for the PlatformSSO dictionary are the authoritative sources — everything else, including this post, is interpretation. Microsoft’s Configure Platform SSO for macOS page covers the Intune side and is kept up-to-date with each service release.

As always, the Mac admin community is where most of the real learning happens — drop your questions, your journey, and your weirder log lines in the comments. Setup Assistant PSSO is new enough that we’re all still building the playbook.