Enabling Phishing Resistant MFA on macOS for admins and disabling SSPR for the whole tenant

The background..

Just a while back, Merill Fernando (Product Manager at Microsoft) shared a post on LinkedIn about disabling SSPR for admin accounts. This was based off the recommendation on Maester that "Administrators with sensitive roles should use phishing-resistant authentication methods only and therefore not able to reset their password using SSPR." Now, with phishing-resistant authentication enabled, one may argue that there shouldn't be a need to disable SSPR for administrators, however, in my honest opinion it is still a good idea to disable SSPR for administrators as this will also align with both least privilege and zero trust model. But first, we are going to cover what all is involved in configuring Phishing resistant MFA.

Enabling Phishing resistant MFA for Windows devices which uses Windows Hello for Business is pretty much an out of box functionality, but what about Apple devices like Macbooks that run on macOS? Let's find out..

Platform credentials on macOS (SSO - Phishing resistant)

You see, Phishing-resistant MFA strength includes methods that require an interaction between the authentication method and the sign-in surface. One uses built-in authentication methods predefined by Microsoft in form of Windows Hello for Business, FIDO2 security key, Microsoft Entra certificate-based authentication (Multifactor). 

As part of Windows Hello for Business Platform credentials for macOS through Single Sign On (SSO) is used as an authentication strength. Therefore, to use Phishing resistant on macOS, macOS Platform Single Sign-on (PSSO) needs to be configured.

Revisiting the SSO configuration on macOS

macOS Platform Single Sign-on (PSSO) powered by Microsoft’s Enterprise SSO plug-in, works as a Platform Credentials for macOS that enables users to sign in to Mac devices using their Microsoft Entra ID credentials. This greatly simplifies the sign-in process by -

- Allowing users to go passwordless by using Touch ID.

- Using phish resistant credentials, based on Windows Hello for Business technology.

- Integrating with the Secure Enclave to achieve Zero trust as it is considered password-less and meets phish-resistant multifactor (MFA) requirements

Back in March'25, I blogged about configuring SSO for reducing Microsoft Entra ID sign-in prompts on a macOS, with a focus on Microsoft 365 apps using Intune. I had some a mixed experience while testing for the PSSO on macOS 14 and while this feature is still in preview, having upgraded to latest macOS 15.1, I wanted to revisit the configuration and see if the experience was any better or not.

First, one needs to decide the authentication method intended for use as this directly affects the user sign-in experience.

- Secure Enclave -> With this SSO authentication method, the SSO plug-in uses hardware-bound cryptographic keys. It doesn't use the Microsoft Entra credentials to authenticate the user to apps and websites.

- Password -> With this SSO authentication method, users sign in to the device with their Microsoft Entra ID user account instead of their local account password.

- Smart Card ->With this SSO authentication method, users can use the smart card certificate and the associated PIN to sign in to the device and authenticate to apps and websites.

For all intent and purposes, I am going with the Secure Enclave as the authentication method and also it is something I hadn't tested in my earlier setup. Following are the steps -

1. Sign-in to the Microsoft Intune admin center

2. Browse to Devices –> Configuration

3. Click Create -> New Policy

4. Select Platform as macOS

5. Select Profile type as Settings catalog

6. Provide a Name and hit next.

7. Click on Add settings.

8. Configure the following -

9. Assign to the macOS devices as normal.

CA policy for Phishing resistant for admins on macOS

With SSO configuration sorted, next up is to configure a conditional access policy using Phishing resistant as the authentication strength in the grant controls for admins on macOS.

1. Sign in to the Microsoft Entra admin center.

2. Select Protection > Conditional Access .

3. Select Policies > New policy to create a new policy.

4. Create a new policy and specify the intended targeted users\groups\roles. In this case, I am targeting admin roles that will require phishing resistant authentication.

5. Under Conditions, Include Windows, macOS and exclude other operating systems.

6. Under Grant controls, select Phishing resistant MFA.

Next up is to disable SSPR for admins. There are multiple ways to do this, but the easiest way I have found is to do this using PowerShell. And what better way there is than Azure cloud shell.

Azure cloud shell & Disabling SSPR

First and foremost, before you can use Azure Cloud Shell, you must register the Microsoft.CloudShell resource provider. Access to resources is enabled through provider namespaces that must be registered in your subscription.

1. Sign in to the Azure portal.

2. Search for Subscriptions and select the relevant subscription.

3. Under Settings, select Resource providers.

4. Search for cloudshell and register it.

5. Launch Cloud Shell from the top navigation of the Azure portal.

6. First time execution of Cloud Shell will require setting up an Azure Storage for Azure file share. You can use an existing storage or create a new one.

7. Start Cloud Shell and run the following command to connect to MgGraph using the ReadWrite Authorization scope.

8. Navigate to the devicelogin url to authenticate using a Entra ID account and give consent if prompted to do so.

9. Once authenticated, you can now proceed to disable SSPR for admins. To do this, let's first get the status of SSPR by running Get-MgPolicyAuthorizationPolicy | select AllowedToUseSSPR.

10. Since it is reporting as True, we are going to disable it by running Update-MgPolicyAuthorizationPolicy -allowedToUseSSPR

:$false and then validating by running Get-MgPolicyAuthorizationPolicy | select AllowedToUseSSPR again.

Testing and validation

When the device receives the SSO policy, a device registration is required.

User will also be asked to enable Company Portal as the Passkey provider.

Once done, device registration will show as completed.

After a device is rebooted, user will be required to enter the local account password. After this initial machine unlock, the device will get the hardware-backed Primary Refresh Token (PRT) for device-wide SSO. This can be verified in Keychain access under the search string for primaryrefresh. The PRT format starts with primaryrefreshtoken-29d9ed98-a469-4536-ade2-f981bc1d605 where the 29d9ed98-a469-4536-ade2-f981bc1d605 is the Application ID for the Microsoft Authentication Broker service

Platform credential will register as an authentication method for the signed in user.

SSO extension profile can be verified for the settings.

When user tries to access Defender portal using URL security.microsoft.com with Security Administrator role assigned, access is granted based on the PRT issues against the SSO for the platform credential provider for macOS. This is also evident in the Entra ID sign-in logs.

When the user tries to reset the password using SSPR, the action is not allowed.

This is evident in the SSPR audit logs as well in Entra ID.

That's all for now. Until next time..