This repository is designed to consolidate everything a Jamf Pro admin might need to configure Platform SSO with Microsoft Entra, and to migrate existing Macs. I am hoping for other contributors to help make this repo a useful source of information for everything related to this framework. The repo currently focuses on using Platform SSO with the Jamf Pro MDM, but others are welcome to share configuration files, processes, and best practices for other MDMs.
of Extensible SSO vs Platform SSO
Extensible SSO is the underlying framework that allows third-party extensions to enable single sign-on (SSO) on Apple devices, while Platform SSO is an evolution of this technology that provides a more deeply integrated, device-centric SSO experience for macOS. Platform SSO offers a more seamless sign-on process for users and deeper integration with Microsoft Entra ID (formerly Azure AD), especially for organizations that have embraced hybrid work and passwordless authentication.
| Feature | Extensible SSO (SSOe) | Platform SSO (PSSO) |
|---|---|---|
| User experience | Less integrated; users typically had to sign in to unlock the device and then sign in again to activate the SSO extension. | Highly integrated; users sign in once with their Microsoft Entra ID credentials at the macOS login screen, eliminating the need for a second sign-in for apps. |
| Scope | App-centric. A third-party SSO extension could handle authentication for multiple applications, which was flexible for apps that lacked native SSO support. | Device-centric. It works at the device level and includes the underlying SSO app extension. When you configure Platform SSO, you don't need to configure the app extension separately. |
| Authentication | Supported a variety of authentication protocols, such as OAuth, OpenID Connect, and SAML2. | Supports modern authentication methods, including passwordless authentication with a hardware-bound key (Platform Credential), smart cards, and Entra ID passwords. It also supports Kerberos-based SSO for on-premises resources. |
| Credential syncing | Did not automatically sync the local account password with the cloud identity password. | With the password authentication method, the user's Microsoft Entra ID password is synchronized with their local macOS account password. |
| Prerequisites | Requires a Mobile Device Management (MDM) profile to be deployed for the SSO app extension. | Requires the macOS device to be enrolled in an MDM and the latest Microsoft Intune Company Portal app to be installed. |
| Device enrollment | Supports user and device enrollment. | Supports Entra ID Join for Macs, allowing any organizational user to sign into the device. |
| Availability | Available on iOS, iPadOS, and macOS. | Primary focus is on macOS 14+ for the best experience. |
When to use which
For most modern deployments, Platform SSO is the recommended choice for macOS devices because of its superior user experience and tighter integration with Microsoft Entra ID.
-
Choose Platform SSO if you:
- Want to simplify the login process for your Mac users.
- Are adopting passwordless authentication methods.
- Want to fully integrate your Macs with Microsoft Entra ID.
- Manage macOS devices with Microsoft Intune or another compatible MDM.
-
Use the legacy Extensible SSO framework if you:
- Need to support older Apple devices running macOS 13 or earlier.
- Need the flexibility to use a third-party SSO extension for specific applications.
- Only require the SSO app extension for authentication without the deeper platform integration.
--- End AI Generated Overview ----
• Microsoft is pushing organization-managed Macs toward the new Platform Single Sign-On (Platform SSO or PSSO) configuration to drastically improve corporate security, eliminate traditional password management headaches, and achieve Zero Trust goals across non-Windows hardware.
• This shift is heavily driven by the industry-wide depreciation of old, fragile Active Directory (AD) binding methods, moving instead toward native, cloud-first device identity architectures.
• Phishing-Resistant MFA: PSSO leverages Apple's built-in Secure Enclave hardware to provision cryptographic keys. This allows Microsoft to issue device-bound passkeys that cannot be intercepted by traditional phishing attacks.
• True Passwordless Login: Users can leverage Touch ID or hardware keys (like YubiKeys) directly at the macOS login window. This mimics the passwordless "Windows Hello for Business" security model on Windows endpoints.
• Drastic Prompt Reduction: Once a user authenticates at the hardware level, PSSO generates a primary refresh token. This automatically signs them into Microsoft 365 web apps (Safari, Edge, Chrome) and native apps like Teams and Outlook without throwing endless authentication prompts.
• Replacing Legacy AD Binding: Binding Macs to traditional Active Directory domains has long been a major pain point for IT admins, resulting in broken mobile accounts and out-of-sync local credentials.
• Real-time Password Syncing: When using password authentication, PSSO automatically syncs the user’s Microsoft Entra ID (formerly Azure AD) credentials directly with their local Mac account password. This eliminates the need for third-party password syncing tools like Jamf Connect.
• Onboarding via Setup Assistant: PSSO integrates directly into Apple's Automated Device Enrollment (ADE). Users get a streamlined out-of-the-box experience where logging into the macOS Setup Assistant automatically registers the device in Microsoft Entra.
• Early Device Trust: By embedding the Microsoft Enterprise SSO plug-in directly into the macOS operating system, Entra ID registers and evaluates device compliance before a user ever reaches the desktop.
• Conditional Access Guardrails: PSSO makes it much easier to enforce strict Conditional Access policies. Because the underlying hardware is validated and tied directly to the user's corporate account, organizations can immediately block non-compliant or unmanaged Macs from hitting corporate networks.
In order to prepare for Platform SSO deployment, you must perform the following:
- Deploy Microsoft Company Portal
- Create the Platform SSO Configuration Profile
- Configure ADE for Simplified Setup
- Remove any existing SSO Extension Profile
- Enable access to System Settings
- Make sure Touch ID is enabled
- Configure jamfAAD to use WebView
- Deliver the Platform SSO Configuration Profile
- Run Device Compliance
- Shared Mac Notes
- Modifying Config Profiles post rollout
- Check the logs for issues
- Users running Focus Mode
- Important note about Secure Enclave
- Extension Attributes
- Scripts
- Changes from Extensible SSO
- You need to install v5.2604.1 or newer in your prestage enrollment (for new enrollments) or install via policy (to existing users). Here's a direct download for the Company Portal installer: https://go.microsoft.com/fwlink/?linkid=853070
When setting up the Configuration Profile, you can use either the Microsoft docs or Jamf Pro docs. I have included screenshots of my setup for easier reference:
Please note: you must configure an Associate Domain payload, but it does NOT need to have any contents.
Update 04-01-2026 - If you want to use a different Shortname (such as first.name), you can substitute
com.apple.PlatformSSO.AccountShortNamein the ShortName field, it will give you just the username\
You will need to make some changes to your ADE (Automated Device Enrollment) setup to take advantage of pSSO:
- In the Jamf Pro console, navigate to Computers > PreStage Enrollment
- In the General section, you need to "Enable Simplified setup" and add "com.microsoft.CompanyPortalMac" in the field
- In the Configuration Profiles section, make sure that your Platform SSO profile is checked so it will get pushed down during new enrollments
- Make sure to add the Company Portal app in the Enrollment Packages section
The following workflow configuration options are available:
Attended (SSOe profile installs before enrollment) —The Platform SSO application and profile are installed prior to enrollment, and successful user registration is required to enroll with Jamf Pro.
Note: Enrollment customizations cannot be used with the attended workflow method.
Unattended (SSOe profile installs during enrollment) —Enrollment with Jamf Pro completes, then the computer is held in Setup Assistant to register with Platform SSO before setup completes.
This will "bypass" the Enrollment customization options and go straight to pSSO login before setup will continue
You need to have a configuration profile for the Platform SSO that can be deployed. IMPORTANT! You CANNOT have both SSO Extension and Platform SSO Extension deployed to all users simultaneously.
The best way to do this is to create groupings and deploy the pSSO to the users in the group, while simultenously excluding them from the SSO Extension group. Screenshot for exxample:
You will need to make sure that Sytem Settings -> Users & Groups is available to the users. Inside of there are options to repair the SSO extension for users
You can use the Repair option to fix any issues found during authentication.
You can link directly to the current user's info pane in System Settings -> Users & Groups. This is useful for pointing users to repair registration or authenticate again if tokens are expired and could be incorporated into a Self Service policy or other scripting:
#!/bin/zsh
username=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }')
open "x-apple.systempreferences:com.apple.Users-Groups-Settings.extension?showinfo*user:${username}"
On systems that have TouchID, you might need to change your existing Configuration Profiles to allow the Touch ID to be accessed and enabled on systems. If you are not going to use Secure Enclave as the preferred method for pSSO, you can ignore this setting:
I have a working EA that will determine the status of TouchID on the systems.
https://github.com/ScottEKendall/JAMF-Pro-EAs/blob/main/Touch%20ID%20Status.sh
IMPORTANT! According to MS documentation, you might need to have two pSSO config profiles, one that will support TouchID and one for systems without TouchID.
You will need to change the
Authentication Methodin the Platform SSO to use "Password" instead of "Use Secure Enclave Key"I have heard reports of admins not needing to do this though..one Config Profile seems to work OK for both TouchID & password only macs.
To avoid issues with browser redirection during the login process, you can configure the JamfAAD app to use WebView instead. The following policy will perform the following:
- Force jamfAAD to use WebView
- Eanble jamfAAD logging
- Settings to recheck for a valid Entra ID
- Fixes pre-fill authentication failure on first attempt
Create a new Configuration Profile:
Application & Custom Settings > Upload
Preference Domain: com.jamf.management.jamfAAD
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>useWKWebView</key>
<true/>
<key>logPII</key>
<string>true</string>
<key>OIDCUsePassThroughAuth</key>
<true/>
<key>OIDCNewPassword</key>
<false/>
<key>tokenRetryCount</key>
<integer>3</integer>
<key>tokenRetryWaitTime</key>
<integer>42</integer>
<key>disableUPNLoginHint</key>
<true/>
</dict>
</plist>The JAMF docs for this can be found here:
Creating a Policy Directing Users to Register Mac Computers with Microsoft Entra ID
After you have setup your Smart/Static Group for deployment, you can push it to all of the users. Once the profile gets installed on their Mac, they will see the following in their Notification Center.
And the user will need to proceed with the registration prompts.
In case the users do not see the notification center prompt (or they dismiss it), it will reappear after a period of time (I think around 15 mins), but you can "force" the prompt to reappear again. These are a few ways that you can accomplish this:
- You can have the user log out and log back in.
- You can run this "faceless" script:
#!/bin/sh
currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
currentUID=$(id -u "$currentUser")
runAsUser()
{
launchctl asuser $currentUID sudo -u $currentUser "$@"
}
pssoCheckStatus()
{
runAsUser app-sso platform -s | awk -F'.*" : "?|"|,' '/"state"/ {print $2}'
}
if [[ -z $(pssoCheckStatus) ]]; then
echo "Plugin not initialized, reloading AppSSOAgent"
pkill AppSSOAgent
sleep 1
runAsUser app-sso -l
fi
- You can show the user this GUI script I created that will force the prompt to reappear, so the users (hopefully) don't miss it again. This script is focus mode aware and will display an appropriate message. You can optionally check for TouchID registration and it will also auto-enable the Password & Autofill option for Company Portal.
- Another alternative script that you can use is called P.S.E.U.D.O. developed by Macjutsu: This script will also enforce the TouchID (if available) as well as enforce the Platform registration as well.
P.S.E.U.D.O. (or just pseudo) is an open source script that provides administrators with a solution to enforce Platform SSO registration and/or Touch ID enablement. Deployed using a single script and a required PPPC configuration profile, pseudo leverages swiftDialog and the macOS System Event, System Event UI, and Accessibility frameworks to ensure that users are registering with Platform SSO and/or enabling Touch ID.
https://github.com/Macjutsu/pseudo
- Another neat little trick that you can do is to automatically populate the Autofill selection for Company Portal In the General > AutoFill & Password section of System Settings. This takes advantage of Apple's PluginKit architecture:
https://github.com/ScottEKendall/Microsoft-Platform-SSO/blob/main/scripts/Enforce%20Portal%20AutoFill.sh
UPDATED 06/09/26 User smross adapted this for Mosyle-targeted machines: https://github.com/TheCrossing-Church/macOS-MosylePlatformSSO
In most cases, the Device Compliance should run after successful Registration, but sometimes it does fail. If you want to avoid any failures, you need to make sure that Device Compliance is run after the user(s) registers with Platform SSO. You can do this one of two ways:
- Deliver a policy that executes the command
/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/Jamf Conditional Access.app/Contents/MacOS/JAMF Conditional Access gatherAADInfo - Have the user run your Register with Entra policy from SS / SS+
If you do not run this Device Compliance, the user might get the "register your device" when trying to authenticate.
If users keep themselves in focus mode, they will never receive the pSSO Registration screen. There are a couple of ways to handle this:
- Here is an EA tha can be used so that you can setup Smart Groups and possibility take action based on the members of the group (targeted email / display prompts / etc).
#!/bin/zsh --no-rcs
LOGGED_IN_USER=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
FOCUS_FILE="/Users/${LOGGED_IN_USER}/Library/DoNotDisturb/DB/Assertions.json"
local results="off"
if [[ -f "$FOCUS_FILE" ]] && grep -q '"storeAssertionRecords"' "$FOCUS_FILE" 2>/dev/null; then
results="on"
fi
echo "<result>$results</result>"
For a GUI version that is focus aware, you can use this script found here
If you are using the Secure Enclave feature for pSSO, please observe this following note:
There is no option for password fallback while authenticating with User Secure Enclave Key when UserSecureEnclaveKeyBiometricPolicy is enabled. Therefore, users won't be able to authenticate to Microsoft Entra ID if they don't have Touch ID biometrics available.
This is taken from this MS document page
If your users don't have touch ID on their machines, you should not be using Secure Enclave as the authentication method. If you have a mixed environment, you have two choices:
- Enable password authentication for all users, thus not needing Touch ID.
- Seperate your users into Touch ID (Enabled) and no Touch ID and roll out different pSSO policies based on Touch ID hardware.
Here is an example EA that can be used to test for touch ID
#!/bin/zsh
LOGGED_IN_USER=$( echo "show State:/Users/ConsoleUser" | scutil | awk '/Name :/ { print $3 }' )
USER_UID=$( id -u "${LOGGED_IN_USER}" )
declare retval=""
function runAsUser ()
{
launchctl asuser "$USER_UID" sudo -iu "$LOGGED_IN_USER" "$@"
}
function checkTouchID() {
local hw="Absent"
retval="$hw"
local enrolled="false"
local bioCount="0"
# --- Detect Touch ID–capable hardware (internal or external) ---
bioOutput=$(ioreg -l 2>/dev/null)
# Check for the device entry indicating hardware presence
if [[ $bioOutput == *"+-o AppleBiometricSensor"* ]]; then
hw="Present"
else
# Fallback: Parse IOKitDiagnostics for class instance count
if [[ $bioOutput =~ '"AppleBiometricSensor"=([0-9]+)' && ${match[1]} -gt 0 ]]; then
hw="Present"
# Fallback: Magic Keyboard with Touch ID
elif system_profiler SPUSBDataType 2>/dev/null | grep -q "Magic Keyboard.*Touch ID"; then
hw="Present"
fi
fi
if [[ "${hw}" == "Present" ]]; then
# Enrollment check
bioCount=$(runAsUser bioutil -c 2>/dev/null | awk '/biometric template/{print $3}' | grep -Eo '^[0-9]+$' || echo "0")
[[ "${bioCount}" -gt 0 ]] && enrolled="true"
[[ "${enrolled}" == "true" ]] && retval="Enabled" || retval="Not enabled"
fi
}
checkTouchID
echo "<result>$retval</result>"UPDATE: 07/21/26 - After a very lengthy support sessions with microsoft in regards to multi-user mac support with Platform SSO, their official stance is that it only supports authenticated guest mode. If you have a true multi-user environment where all users must keep their user accounts, Platform SSO will not work properly. See this article for more: https://learn.microsoft.com/en-us/entra/identity/devices/device-join-macos-platform-single-sign-on-multi-user-device#shared-device-limitations At this time, there is no "official" workaround for this.
Standard pSSO binds to the first authenticated user, meaning that it treats a Mac as a sigle user device.
To fix the compliance tracking problem with Multi-user Macs, implement the transition to pSSO, by the following guidlines
These notes are from user @wakco on the MacAdmins Slack channel. Thanks for the clarification!
Secure Enclave is a part of every Apple Silicon Mac, and every T1/T2 based Intel Mac, regardless of if a finger print reader exists. The Secure Enclave happens to be where the fingerprints are stored. T2 and Apple Silicon allow for storing more than just fingerprints (hence why T2 is the required minimum, and T1 is identified as not compatible)
Although you can usse Secure Enclave as the authentication method, it is strongly discouraged for the following reason: "the issue with SE is every new account has to re-register the computer because the Secure Enclave is storing the Entra join key linked to the logged in user account, so each new account does not have access to it and has to create a new key. Password as such stores the key somewhere the OS can access that is not linked to the logged in user account, and as such is able to access it regardless of who is logged in."
- Set your configuration profile to use Password as the authentication method:
-
Leverage macOS 26 "Authenticated Guest Mode". If your multi-user fleet is running modern operating systems, your PSSO configuration profile can utilize Apple’s Authenticated Guest Mode.
-
Ensure "Just-in-Time" Account Creation is Enabled Within your pSSO configuration payload, make sure "Create new users" at the login windowis explicitly checked. This allows subsequent employees or students to step up to the Mac, log in with Entra ID, and have macOS dynamically generate their user context without dropping the broad "Registered" status of the physical hardware asset.
-
Check your Entra CA Policies Strict Conditional Access (CA) rules will block subsequent users from finishing their registration if they are evaluated before the system knows who they are.
-
Exclude the Registration App: In your Entra ID Conditional Access policies, you must explicitly exclude the "User registration app for Device Compliance".
-
Why this matters: If this app is not excluded, the 2nd and 3rd users will be blocked from authenticating to the broker when they attempt their initial registration, preventing Jamf from updating their compliance state.
-
-
Summary of the switch
| Scenario | Standard Extensible SSO / Registration | Platform SSO (Optimized for Shared Macs) |
|---|---|---|
| Token Type | Bound to user's local profile & Keychain | Bound deeply to the native macOS login system |
| User B Logs In | Status flips to "Unregistered" until manual action | Status remains stable via dynamic IdP validation |
| Admin Effort | High (Requires user to launch Self Service) | Low (Handled automatically during OS boot) |
If you need to modify the config profile for pSSO, you can make changes without forcing users to re-register, WITH THE FOLLOW EXCEPTIONS:
- If you switch authentication methods (ie. from Secure Enclave to Password) it will force a re-registration
- If you change the contents of this key:
enable_se_key_biometric_policyit will also force a re-registration
If you run into trouble with implementation of pSSO, one of the first things to check is the system logs. You can do that with the 'predicate' command which can be used to filter the logs:
/usr/bin/log stream --info --predicate 'process=="mdmclient" AND composedMessage CONTAINS "Processing server request: DeclarativeManagement for" AND composedMessage
Here is a utility that is MDM Agnostic and will constantly monitor the logs for issues:
https://github.com/microsoft/shell-intune-samples/tree/master/macOS/Tools/mdmCheckinMonitor
I have an EA script that I use to determine user registration status and create groups accordingly. The script is multi-user aware and can be found here: https://github.com/ScottEKendall/JAMF-Pro-EAs/blob/main/InTune%20Registration%20Status.sh
See the scripts folder for full script contents.
This script can be used to determine Device Compliance for both the extensible SSO (SSOe) and Platform SSO. (pSSO). If the system is registered with Platform SSO, it still needs to acquire the AAD token.
You can test for both (Apple) Platform SSO and (JAMF) Device Compliance in one of two ways:
- if
appleSSO=$(app-sso platform -s | grep "registrationCompleted" | awk -F ":" '{print $2}' | xargs | tr -d ",")returnstruethen it is apple SSO compliant - if
jamfSSO=$("/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/Jamf Conditional Access.app/Contents/MacOS/Jamf Conditional Access" getPSSOStatus | head -n 1)returns2then it is Device Compliant
NOTE: Suposedly the /usr/local/jamf/bin/jamfAAD getPSSOStatus command should return the sames results as step 2 above, but it doesn't, so it might be best to use the Step 2 command for a results test.
Why Check both?
- Because pSSO and Device Compliance are not the same thing.
- pSSO is between macOS and Entra ID (Proving your identity).
- Device compliance is between Jamf, Intune, and Entra ID (complying with Conditional Access requirements).
When moving away from the (old) extensible SSO method, the "workplace join key" that was present in the Keychain will no longer be there as the functionality of the (new) pSSO has been moved into the Secure Enclave on the mac. So users will (should) not see this image any longer:
If you have any Smart/Static Groups or EAs that look for the WPJ Key in the users keychain, you need to change your logic to use the app-sso platform -s terminal command to determine SSO status.
NOTE: The Verify Device Compliance via Extensible SSO and Platform SSO.sh script reports on the WPJ key in the Keychain. Those are no longer created anymore.
I am trying to stick with the company "official" docs as much as possible, but I do have an "other" section, and I will try to have comprehensive guides if possible.
- Deploying macOS Platform SSO for Microsoft Entra ID with Jamf Pro
- Deploying a Platform Single Sign-on Configuration Profile
- NEW Platform SSO for macOS
- macOS Platform Single Sign-on overview
- Add the macOS Company Portal App
- Microsoft Enterprise SSO plug-in for Apple devices
- Common Platform SSO scenarios for macOS devices
- Troubleshooting the Microsoft Enterprise SSO Extension plugin on Apple devices
- End-to-end guide to get started with macOS endpoints
- Platform SSO in macOS Setup Assistant — A Deep Dive
- New Platform SSO with registration during Automated Device Enrollment on macOS
- Configure Platform SSO with Entra ID
- Configuring Apple Enrollment - Install Library Items During Setup Assistant
- IntuneMacAdmins - Configure MacOS Platform SSO
- Aaron David Polley - How To Hold macOS User Identity in 2025
- benwhitis/Jamf_Conditional_Access - MacOS Conditional Access Best Practices
- David Crosby - macOS 26 Tahoe: Simplified Setup for Platform SSO
If you find my work useful, please consider a donation to the caffeine fund!



















