Microsoft has announced plans to move storage of the Workplace Join Key out of the user’s Login Keychain and into Apple’s Secure Enclave:
Microsoft Enterprise SSO plug-in for Apple devices - Microsoft identity platform
Announced in March 2024, Microsoft Entra ID will be moving away from Apple’s Keychain for storing device identity keys. Starting in Q3 2025, all new device registrations will use Apple’s Secure Enclave. There will be no opt-out of this storage location.
Applications and MDM integrations that have a dependency on accessing Workplace Join keys via Keychain will need to start using MSAL and the Enterprise SSO plug-in to ensure compatibility with the Microsoft identity platform.
In the same document, Microsoft provides guidance on how to test the Secure Enclave today to ensure the change will be compatible with your environment when the change goes live:
If you would like to enable Secure Enclave based storage of device identity keys before it becomes mandatory, you can add the following Extension Data attribute to your Apple devices’ MDM configuration profile.
Action Item: SSO extension is required for new registrations
With this change, it will no longer be possible to register computers without using the Microsoft SSO extension or PlatformSSO. Many environments already use the SSOe/PSSO, but if you don’t, now is the time to build, test, and deploy the SSO extension:
Configure macOS Enterprise SSO app extension with MDMs
Recommended testing: Secure Enclave
In order to ensure full support across all apps in your environment, we recommend testing Secure Enclave scenarios today on test devices and/or pilot groups. There are a few ways to test moving the WPJ key to the Secure Enclave.
Here is an example PLIST including the typical recommended settings for macOS SSO extension plus the new optional key:
<?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>AppPrefixAllowList</key>
<string>com.microsoft.,com.apple.,com.jamf.management.</string>
<key>browser_sso_interaction_enabled</key>
<integer>1</integer>
<key>disable_explicit_app_prompt</key>
<integer>1</integer>
<key>use_most_secure_storage</key>
<true/>
</dict>
</plist>
Note: We would recommend building a new SSO extension configuration to hold this additional key, and ensure it is first scoped to test machines and/or pilot users until all use cases in your environment are tested.
How to test Secure Enclave Storage
After pushing out either PlatformSSO or the SSO extension plus the optional key, there are a few steps to take to ensure the Workplace Join Key is moved to the Secure Enclave.
New registrations
New registrations with either Platform SSO or the SSO extension with the optional key will store the WPJ key in the Secure Enclave upon registration
Existing registrations
NOTE: To reiterate, it is not required to migrate existing registrations to secure enclave storage. The instructions below are intended solely to provide a means of testing secure enclave storage on a computer that is already registered.
If testing with a computer that currently has a Workplace Join Key in the login keychain, the following steps should be taken to move the WPJ key to the Secure Enclave (depending on SSOe/PSSO):
Checking registration state:
Items in the Secure Enclave are not accessible via script or UI, which adds some complexity when trying to report on the registration state of computers storing the Workplace Join Key in the Secure Enclave. However, PlatformSSO registration state can be validated via Terminal using app-sso platform -s. The following extension attribute can check for device compliance registration status if the computer is registered via either the Login Keychain or using PlatformSSO (but not using SSOe with Secure Enclave storage):
#!/bin/bash
#Original script obtained on 03/04/2025 from https://github.com/benwhitis/Jamf_Conditional_Access/blob/main/EA_registrationStatus
#get user
loggedInUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
#get user home directory
userHome=$(dscl . read "/Users/$loggedInUser" NFSHomeDirectory | awk -F ' ' '{print $2}')
#check if registered via PSSO:
platformStatus=$( su $loggedInUser -c "app-sso platform -s" | grep 'registration' | /usr/bin/awk '{ print $3 }' | sed 's/,//' )
if [[ "${platformStatus}" == "true" ]]; then
#Check if jamfAAD registered too
psso_AAD_ID=$(defaults read "$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist" have_an_Azure_id 2>/dev/null)
if [[ $psso_AAD_ID -eq "1" ]]; then
#jamfAAD ID exists
echo "<result>Registered with Platform SSO - $userHome</result>"
exit 0
fi
#PSSO registered but not jamfAAD registered
echo "<result>Platform SSO registered but AAD ID not acquired for user home: $userHome</result>"
exit 0
fi
#check if wpj private key is present
WPJKey=$(security dump "$userHome/Library/Keychains/login.keychain-db" | grep MS-ORGANIZATION-ACCESS)
if [ ! -z "$WPJKey" ]
then
#WPJ key is present
#check if jamfAAD plist exists
plist="$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist"
if [ ! -f "$plist" ]; then
#plist doesn't exist
echo "<result>WPJ Key present, JamfAAD PLIST missing from user home: $userHome</result>"
exit 0
fi
#PLIST exists. Check if jamfAAD has acquired AAD ID
AAD_ID=$(defaults read "$userHome/Library/Preferences/com.jamf.management.jamfAAD.plist" have_an_Azure_id)
if [[ $AAD_ID -eq "1" ]]; then
#jamfAAD ID exists
echo "<result>Registered - $userHome</result>"
exit 0
fi
#WPJ is present but no AAD ID acquired:
echo "<result>WPJ Key Present. AAD ID not acquired for user home: $userHome</result>"
exit 0
fi
#no wpj key
echo "<result>Not Registered for user home $userHome</result>"
Additional reporting options are in progress
Jamf is exploring additional options to provide a way to check for the existence of a workplace join key in the Secure Enclave. We anticipate having more to share in Q2 2025.