Jamf Moves Platform SSO Into the Enrollment Gate

Jamf’s attended Simplified Setup for Platform SSO is worth paying attention to because it changes when identity becomes part of Mac enrollment.

For years, the normal deployment pattern has been device-first. Automated Device Enrollment gets the Mac into MDM, the MDM profile installs, management starts, and then the rest of the identity experience gets layered on top. That might involve Jamf Connect, a Platform SSO registration prompt after setup, a policy that installs the identity app, a profile that arrives after enrollment, or a help desk runbook that tells the user what to click if the registration prompt appears later.

That approach can work, but it has always had a sequencing problem. The Mac becomes managed before the organization has finished proving who the primary user is. If the identity app is delayed, the SSOe profile is wrong, the user skips a prompt, or the identity provider blocks the sign-in, the device may still be in Jamf while the identity state is incomplete.

The attended Simplified Setup workflow moves that decision earlier. In Jamf’s current documentation, the attended method installs the Platform SSO profile before enrollment, requires the user to complete Platform SSO registration, sends the resulting token back to Jamf Pro, and only then allows the MDM profile installation to continue.

That is the news here. Platform SSO is no longer just a post-enrollment login improvement. In this workflow, it becomes part of the enrollment gate.

The Old Pattern Was Enroll First, Identity Later

Before Simplified Setup, Platform SSO could only be configured after a local account existed. Jamf’s macOS 26 Platform SSO article explains the change plainly: earlier Platform SSO setup happened after the user had already created a local account on the Mac. That meant the first-run path still had a gap between device enrollment and identity registration.

In a traditional Jamf enrollment, the sequence usually looks like this:

The Mac is assigned in Apple Business Manager or Apple School Manager.
Setup Assistant reaches Remote Management.
Jamf installs the MDM profile.
Jamf starts sending configuration profiles, packages, apps, and policies.
The identity app and Platform SSO configuration arrive after the device is already managed.
The user completes identity registration after enrollment, or Jamf Connect handles account creation and password alignment depending on the environment.

That is a familiar pattern for Mac admins, but the evidence is spread across multiple places. You verify the MDM profile in Jamf. You verify the authentication app package. You verify the SSOe profile. You check Platform SSO state locally. You check the identity provider’s logs. You check whether User and Location in Jamf matches the person who actually received the device.

The operational risk is not that any one piece is bad. The risk is that the enrollment story depends on the pieces arriving in the right order after the Mac is already past the most important setup screens.

The New Attended Pattern Makes Identity the Gate

Jamf documents two Simplified Setup workflows for Platform SSO: attended and unattended.

The unattended workflow still enrolls the Mac first. Jamf keeps the computer in Setup Assistant until the Platform SSO app and configuration profiles install. Registration happens during setup, but after Jamf Pro enrollment has already completed.

The attended workflow is stricter. When the Mac tries to enroll, Jamf Pro returns a 403 response and rejects enrollment until Platform SSO registration is complete. That response includes secured download links for the Platform SSO configuration profile and the Platform SSO app package. macOS downloads and installs those pieces automatically. The user then registers with Platform SSO, the Mac sends an authentication token back to Jamf Pro, Jamf validates it against the server’s SAML SSO integration, and enrollment is authorized.

That order matters:

Automated Device Enrollment starts.
Jamf refuses to complete enrollment until Platform SSO registration succeeds.
macOS installs the SSOe profile and identity provider app package from secured links.
The user signs in through the identity provider flow.
The Mac returns an authentication token to Jamf.
Jamf validates the token through SAML SSO.
The MDM profile installs.
Setup Assistant continues with account creation and the configured PreStage screens.

The key difference is not cosmetic. The old pattern asked identity to clean up after enrollment. The attended pattern asks identity to authorize enrollment.

Why This Is Bigger Than a Cleaner Setup Screen

The obvious user-facing win is fewer disconnected prompts. A new employee should not have to understand why Remote Management, the identity provider, the local account, FileVault, Self Service, and the Jamf inventory record all appear to be separate worlds.

The admin-facing win is more interesting. If the user’s identity is established before the MDM profile installs, then account creation, user affinity, and the early management record can line up with the person who authenticated. For 1:1 Mac deployments, that is a better starting point than enrolling a device and hoping later inventory, extension attributes, directory lookups, or manual corrections get the user relationship right.

This also changes the ownership conversation. A working attended Platform SSO deployment is not only a Jamf configuration. It depends on the identity provider app, the SSOe payload, SAML SSO in Jamf Pro, device certificates, package delivery, network access during Setup Assistant, and the identity provider’s policies for registration and MFA. The Jamf admin and the identity admin have to agree on the first-run contract before the workflow is exposed to users.

That is why I would not treat this as a simple tutorial item. The checkbox in PreStage is the visible part. The real story is the change in trust order.

The Profile Evidence Matters More Than Screenshots

Screenshots can show where the checkbox lives, but they do not prove that the deployment is correct. For this workflow, the evidence is in the profiles, package, SAML configuration, and local Platform SSO state.

Jamf’s Okta Concepts guide is the best step-by-step reference I found for the Okta version of this workflow. I would point admins there instead of recreating every click path in a blog post. The useful part for review is the shape of the configuration.

For Okta, the Single Sign-On Extensions payload uses values like these:

Payload type: SSO
Extension Identifier: com.okta.mobile.auth-service-extension
Team Identifier: B7F62B65BN
Sign-on Type: Redirect

URLs:
https://<org-tenant>.okta.com/device-access/api/v1/nonce
https://<org-tenant>.okta.com/oauth2/v1/token

The same profile needs the Platform SSO settings that make Setup Assistant registration possible. In the Jamf Concepts guide, that includes Use Platform SSO, Enable registration during setup, Create first user during Setup, Use Shared Device Keys, and the FileVault, user login, and screensaver unlock policies.

The Associated Domains payload is also not optional decoration. The guide shows app identifiers for the Okta extension and app, both tied to the authsrv:<org-tenant>.okta.com associated domain. If that part is wrong, Jamf’s troubleshooting note says the user may see an error that the single sign-on extension could not validate the domain.

The managed app configuration is just as important. The guide includes Application & Custom Settings payloads for both com.okta.mobile.auth-service-extension and com.okta.mobile. The extension payload includes keys like this:

<key>OktaVerify.EnrollmentOptions</key>
<string>SilentEnrollmentEnabled</string>
<key>OktaVerify.OrgUrl</key>
<string>https://<org-tenant>.okta.com</string>
<key>OktaVerify.UserPrincipalName</key>
<string>$USERNAME</string>
<key>OktaVerify.PasswordSyncClientID</key>
<string>replace-with-PSSO-app-client-id</string>
<key>PlatformSSO.ProtocolVersion</key>
<string>2.0</string>

Those details are why this should be reviewed as an enrollment architecture change, not as a prettier login screen. If the SSOe payload, associated domains, SCEP configuration, app configuration, and PreStage settings do not agree, Setup Assistant is exactly where the user will find out.

The PreStage Setting Is Only the Switch

The Jamf Pro side lives in the Computer PreStage enrollment. Jamf’s documentation points admins to Computers > PreStage Enrollments, where the General payload includes Enable Simplified Setup for Platform Single Sign-on.

For attended setup, Jamf requires a Platform SSO configuration profile in the PreStage and SAML-based SSO configured for end users in Jamf Pro. The attended configuration also asks for the package manifest URL for the Platform SSO app package. Jamf’s documentation notes that Okta Verify and Microsoft Company Portal are supported app examples, but the identity provider’s current implementation still matters.

This is where I would compare the old and new approaches during a design review:

Area	Enroll first, identity later	Attended Simplified Setup
First authority	MDM enrollment	Identity registration
MDM profile timing	Installs before Platform SSO registration	Installs after token validation
User affinity	Can depend on later inventory, lookup, or correction	Established from the authenticated enrollment flow
Failure point	Often after the device is already managed	Before enrollment is authorized
User experience	Several prompts can feel unrelated	Work identity becomes the main setup path
Troubleshooting	Jamf, local Mac, and IdP evidence may be separated by timing	Dependencies are exposed early in Setup Assistant

The attended flow is cleaner, but it is not softer. A broken package manifest URL, missing profile, bad associated domain, IdP registration issue, SAML problem, or blocked network path can stop the Mac before enrollment completes. Jamf also notes that enrollment customizations cannot be used with the attended workflow, so teams that rely on custom enrollment panes need to account for that tradeoff.

How I Would Prove It Worked

The verification work should be command and record based.

On the Mac, start with the local Platform SSO status:

app-sso platform -s

That command is called out in Jamf’s Okta Concepts guide and is the first local check I would want from a pilot machine after Setup Assistant completes.

Then confirm the profiles that make the workflow possible:

profiles show -type configuration | grep -A12 -B6 "com.okta.mobile"
profiles show -type configuration | grep -A12 -B6 "com.apple.extensiblesso"
profiles show -type configuration | grep -A12 -B6 "authsrv:"

For local troubleshooting during a pilot, I would also collect recent SSO-related log entries:

log show --last 1h --style compact \
  --predicate 'process == "app-sso" OR eventMessage CONTAINS[c] "Platform SSO" OR eventMessage CONTAINS[c] "single sign-on"'

In Jamf Pro, I would verify four records before calling a test successful:

The computer completed Automated Device Enrollment through the intended PreStage.
The MDM profile installed after successful identity registration.
The expected Platform SSO, Associated Domains, SCEP, and app configuration profiles are present.
The Jamf inventory record shows the expected user relationship in User and Location.

In the identity provider, I would review the registration event, MFA behavior, device certificate or device trust state, and any conditional access policy decisions. Attended Platform SSO puts the IdP in the enrollment path, so IdP logs are not optional troubleshooting evidence.

Good Resources To Read And Watch

Jamf’s official documentation should be the source of truth for the workflow. The most useful page is the current Configuring Simplified Setup for Platform Single Sign-On documentation because it explains the attended and unattended flows, the 403 gate, the PreStage settings, macOS requirements, app support, and the enrollment customization limitation.

For a step-by-step Okta build, Jamf’s Concepts guide is stronger than a screenshot-heavy blog post. It covers Okta app setup, associated domains, the SSOe payload, managed app configuration, SCEP, PreStage setup, and the app-sso platform -s verification command.

For the broader identity direction, Rocketman’s LaunchPad recording with Adam Derrick is useful because it treats Platform SSO as an identity architecture topic, not only a profile payload. It also covers Simplified Setup during Setup Assistant and the direction of macOS identity management.

I would also keep Jamf’s release-note video pages nearby. The Jamf Pro 11.20 release-note video page lists Simplified Setup for Platform SSO as featured content, and the Jamf Community 11.29 release-note post describes continued movement toward identity-first enrollment. Those are good release context links even when the real implementation details live in the docs and profiles.

What I Would Pilot First

I would not make attended Platform SSO the first test of a new Platform SSO deployment. Jamf recommends validating the Platform SSO configuration profile with the unattended workflow first, and that recommendation makes sense. Unattended gives the team a safer place to prove the SSOe payload, identity app, profile scope, package install, and IdP registration behavior before making registration the pre-enrollment gate.

Once unattended works, I would move to a very narrow attended pilot:

One PreStage.
One identity provider configuration.
One test user group.
One known-good Mac model.
A clean network path that represents a real user’s first setup location.
A documented erase-and-retry path for devices that cannot complete Setup Assistant.

The pilot should produce evidence, not just a good feeling. Save the PreStage configuration, profile payload details, package manifest URL, IdP app assignment, SAML SSO settings, local app-sso platform -s output, Jamf inventory record, and identity provider registration logs.

The Takeaway

Attended Simplified Setup for Platform SSO is a meaningful shift because it changes Mac enrollment from a device-first flow to an identity-gated flow.

The older model enrolled the Mac and then tried to attach identity cleanly afterward. The attended model requires the user to register with Platform SSO before Jamf authorizes the MDM enrollment. That means the MDM profile, account creation, and Jamf user relationship can start from a stronger identity signal.

That does not make the deployment effortless. It raises the standard for the profiles, package delivery, SAML setup, IdP configuration, and pilot evidence. But that is exactly why the change matters. When identity is part of the enrollment gate, Mac admins get a cleaner first-run experience and a more defensible management record from the beginning.