Jamf Connect and macOS identity: getting it right in 2026

Identity is the piece that makes or breaks a Mac deployment — and it's also the piece most organisations configure last. The zero-touch deployment guide on this site says it plainly: identity is where most deployments go wrong. This post explains why, what the current options are, and how Jamf Connect fits into a 2026 Apple stack.

What the identity problem actually is

On Windows, Group Policy and Active Directory handle the link between a device and a user's corporate identity. On macOS, that link has never been as clean, and the gap has widened as organisations moved away from on-premises Active Directory.

When a user opens a new Mac, macOS creates a local account. That account has no inherent connection to your identity provider — no link to Entra ID, no Okta session, no SSO. If you do nothing, the user ends up with a local password that drifts from their corporate password, no MFA at the login screen, and a device that your identity provider doesn't know about.

The traditional workaround — binding Macs to Active Directory — is dead. Apple deprecated the built-in AD plugin years ago, and it's increasingly broken on modern macOS. If your organisation is still using directory binding, you're managing technical debt that will fail unpredictably.

The replacement is Platform SSO, and Jamf Connect is the tool that makes it work reliably.

Platform SSO explained

Platform SSO is Apple's framework for tying the macOS login screen directly to a cloud identity provider. Instead of a local password, the user authenticates against your IdP — Entra ID, Okta, or PingFederate — at the FileVault pre-boot screen or macOS login window.

This does several things at once:

• Single password — the user's macOS account password stays in sync with their corporate password automatically. No more password drift, no more helpdesk tickets after a password reset.
• MFA at the login screen — the IdP can enforce whatever MFA policy you've set. The Mac isn't a gap in your MFA coverage.
• Conditional Access token — when a user logs in, macOS retrieves a Kerberos ticket or SSO extension token. Browser sessions and native apps that support SSO extension pick this up, giving silent SSO across your app estate.
• Device registration — as of Jamf Pro 11.26, devices using Simplified Setup for Platform SSO are automatically registered with Microsoft Entra during enrolment. No end-user action, no manual helpdesk step.

Platform SSO is an Apple framework. It sets the standard and the APIs. Jamf Connect is the implementation that makes it production-ready.

What Jamf Connect does

Jamf Connect is two products packaged together: a login window replacement and a menu bar application.

The login window replaces macOS's standard login screen. At boot, the user sees your organisation's branded login page — or your IdP's authentication page directly — instead of the default macOS field. Authentication happens against your IdP before the desktop loads. If the user's IdP account is disabled, they cannot log in. No local admin backdoor, no password mismatch.

The menu bar app handles the session after login. It monitors the IdP session state, shows the user their account status, and prompts for re-authentication if the session expires or the password changes. It also handles Kerberos ticket renewal if you still have on-premises Kerberos dependencies.

Together, they give you something that macOS doesn't provide natively: continuous enforcement of corporate identity, not just identity at enrolment time.

Managed Apple Accounts vs Jamf Connect

With Apple Business now shipping Managed Apple Accounts as a first-class feature, the question comes up: do you still need Jamf Connect?

The answer depends on what you're trying to achieve.

Managed Apple Accounts are for Apple services — App Store, iCloud for Work, FaceTime, and the data separation between work and personal content. They're the mechanism that lets an employee use one iPhone without IT touching their personal data. They federate with your identity provider for provisioning, but they're not a macOS login mechanism.

Jamf Connect handles the macOS login screen, local account management, and SSO extension. It's what connects the login window to your IdP session and keeps local credentials in sync.

In practice, you need both. Managed Apple Accounts handle Apple's ecosystem. Jamf Connect handles the macOS login and corporate identity layer. They're complementary, not competing.

The exception is very simple deployments where Managed Apple Accounts plus a basic Configuration Profile for SSO extension is sufficient — think a ten-person company with a uniform app estate and no compliance requirements. For anything larger or more nuanced, Jamf Connect is the right tool.

Conditional Access: what it actually requires

Conditional Access is the policy that says "this device must be compliant before it can access corporate resources." It's implemented by your IdP (usually Entra ID or Okta) and enforced at the browser or application layer.

For Conditional Access to work correctly on macOS, three things need to be true:

1. The device is registered with the IdP. Entra ID needs to know the device exists and which user it's assigned to. Without registration, Entra can't evaluate device compliance. 2. The compliance state is reported. Something — Jamf Pro's compliance integration — needs to tell Entra whether the device meets your policy. If Jamf Pro isn't connected to the Intune/Entra compliance flow, the device shows as "unknown" and may be blocked or allowed based on your fallback policy. 3. The SSO token reaches the browser. When the user opens Chrome or Edge, the browser needs to pick up the SSO extension token that Platform SSO issued at login. Without this, the user gets prompted to authenticate against Entra separately — a second login that breaks the experience.

Jamf Connect and Platform SSO handle points one and three. Jamf Pro's compliance integration handles point two. All three need to be wired correctly before Conditional Access is reliable.

The most common failure mode is partial setup: devices are registered, but compliance isn't reporting, so Entra is making access decisions based on stale or missing data. Run a sample query in Entra's device list and check how many of your Macs show as "compliant." If it's less than your enrolled fleet, you have a gap.

First-login experience when everything is correct

When Platform SSO and Jamf Connect are properly configured alongside a zero-touch enrolment, the first-login experience should look like this:

1. Device boots from a wipe or factory state. 2. Setup Assistant runs — the user signs in with their Managed Apple Account (work account, provisioned from your IdP). 3. Jamf Pro enrols the device via ADE and applies the MDM profile chain. 4. Jamf Connect configuration profile lands, and the login window is replaced. 5. The user reaches the desktop. Their local macOS password is now their IdP password. Their browser has a valid SSO session. Entra sees the device as registered and compliant.

Total time: under ten minutes for a fast network and a lightweight policy chain. If it's taking longer, the bottleneck is almost always heavy software installs during enrolment — move those to a policy that runs post-enrolment, not during Setup Assistant.

Migrating existing devices

The above covers new enrolments. For devices already in the field, the story is harder.

If users currently have local accounts with local passwords, transitioning them to Platform SSO requires either a re-enrolment (wipe and start over) or an in-place migration using Jamf Connect's migration flow. The migration flow is viable but has edge cases: accounts created outside the standard provisioning path, FileVault recovery key state, and local admin accounts that predate the MDM enrolment.

Our recommendation for existing fleets: set a target for the next refresh cycle. New devices get the full Platform SSO experience from day one. Existing devices are migrated opportunistically during upgrades or hardware replacements, not forced on a hard deadline that creates a support surge.

Where to start

If you're setting this up from scratch:

1. Enable SCIM sync between your IdP and Apple Business (if you're using Managed Apple Accounts) — this provisions accounts before devices arrive. 2. Deploy Jamf Connect via a Configuration Profile through Jamf Pro. The profile specifies your IdP, the login window settings, and the menu bar app behaviour. 3. Configure the Jamf Pro compliance integration with Entra ID. This is under Jamf Pro's Integrations settings and requires a service principal in Entra with the right API permissions. 4. Test the full flow on a dedicated test device before rolling to the fleet. Check: login works, SSO extension token is issued, browser gets silent SSO, Entra shows device as compliant. 5. Set a Conditional Access policy in Entra scoped to macOS devices, starting in report-only mode. Review what would be blocked before enforcing.

If you've already got Jamf Pro deployed but haven't wired in Jamf Connect or the compliance integration, the compliance integration is the easier first step — it doesn't touch user-facing login behaviour. Jamf Connect is a bigger change and benefits from a pilot group before fleet-wide rollout.

The short version

Platform SSO and Jamf Connect together give you what Active Directory binding used to promise but rarely delivered: a macOS fleet where the login screen is controlled by your identity provider, credentials stay in sync automatically, and Conditional Access can make reliable decisions. The pieces are now all available and production-ready. The main work is the integration plumbing — connecting Jamf Pro's compliance reporting to Entra, configuring the SSO extension profile, and migrating existing local accounts on a sensible timeline.

If you want a review of your current identity setup or help designing the migration plan, get in touch — this is one of the areas we spend the most time on with clients moving from legacy AD binding to a modern cloud identity stack.