Planned Microsoft change
Why this deserves attention before October
Microsoft 365 Message Center notice MC1450134 says Microsoft Entra is expected to begin recognising Windows Hello for Business (WHfB) and macOS Platform SSO (PSSO) as standalone MFA factors in supported scenarios from early October 2026, with rollout expected to complete by late November 2026.
The change can reduce unnecessary additional prompts during step-up authentication, Authentication Strength evaluation and sign-in-frequency checks. It can also expose an assurance gap: Windows users may already possess managed, device-bound WHfB credentials while Mac users still rely on passwords, browser prompts or conventional MFA.
Planned dates can change
Confirm MC1450134 in your tenant's Microsoft 365 Message Center and recheck Microsoft Learn before changing production policies. “Standalone MFA factor” does not mean every sign-in will stop requesting additional authentication; the result still depends on the credential, policy and supported scenario.
Use the correct terminology
Platform SSO is not “Windows Hello for Mac”
WHfB applies to managed Windows devices. On macOS, Microsoft provides Platform SSO through the Enterprise SSO plug-in. Its platform credential can use a hardware-bound key in Apple's Secure Enclave and provide a broadly comparable passwordless, phishing-resistant experience, but the technologies and deployment requirements remain distinct.
Secure Enclave
Microsoft's recommended PSSO method. It uses a hardware-bound cryptographic key, supports passwordless authentication and can satisfy phishing-resistant MFA requirements. The local Mac password remains necessary after restart.
Smart card
A passwordless, phishing-resistant option using a compatible card or hardware token. It introduces separate hardware, support and recovery considerations.
Password
Synchronises the Microsoft Entra password with the local Mac account and provides SSO, but Microsoft does not classify this PSSO mode as passwordless or phishing-resistant.
Windows Hello for Business
Uses a device-specific key protected by a PIN or biometric gesture. It is an enterprise-managed Windows credential—not a feature installed on a Mac.
Mixed-estate assurance
Check for two authentication standards inside one organisation
A mixed estate does not automatically have a problem. The risk arises when administrators assume Windows and Mac users receive equivalent phishing resistance without verifying registration, authentication method, device management and policy outcomes.
A useful assurance question
Can the organisation show which Windows and Mac users have a registered, managed and phishing-resistant device credential—and explain the approved alternative for anyone who does not?
Readiness checklist
Six checks to make before the rollout
Measure the current Windows and Mac position
Identify managed Macs, their operating-system versions, ownership and existing Enterprise SSO or PSSO configuration. Compare this with WHfB registration and usage on Windows.
Choose the intended PSSO authentication method
Do not treat “PSSO enabled” as sufficient evidence. Record whether Secure Enclave, smart card or password mode is appropriate and why.
Verify prerequisites and conflicting profiles
Check supported macOS versions, Microsoft Authenticator, Company Portal, device registration permissions and whether an older SSO extension profile conflicts with the settings-catalog policy.
Review Authentication Strength policies
Identify applications and users subject to phishing-resistant or passwordless strengths. Confirm actual sign-in results rather than assuming policy names prove platform coverage.
Retain a portable recovery method
Device-bound credentials cannot help when the registered device is unavailable. Keep an approved portable method and document Temporary Access Pass, replacement and identity-verification procedures.
Pilot, communicate and evidence
Test representative Mac models, versions, user roles and care workflows. Record registration success, sign-in behaviour, support demand, exceptions and rollback criteria before wider deployment.
RACF-CC implementation
Improve phishing resistance without creating a recovery problem
Use the Safe Enforcement Pattern
Audit/report-only → pilot → validate → enforce → monitor → reviewStart with inventory and sign-in evidence, pilot PSSO with representative users, validate Conditional Access and recovery, then expand in controlled stages. Open the Safe Enforcement guide →
This work primarily supports RACF-CC Domain 1: Identity and Access Management, with dependencies on endpoint management, monitoring, incident recovery and governance. The desired result is not simply “PSSO deployed”; it is demonstrable, sustainable authentication assurance across both platforms.
Sources and status
Recheck the live guidance before enforcement
- Microsoft 365 Message Center archive: MC1450134 — archived copy of the planned standalone-MFA-factor announcement.
- Microsoft Learn: macOS Platform SSO overview — authentication methods, requirements and security model.
- Microsoft Learn: Configure Platform SSO with Intune — method selection, settings and deployment considerations.
- Microsoft Learn: How Authentication Strengths work — supported combinations and registration considerations.
- Microsoft Learn: Windows Hello for Business overview — the Windows credential and security model.
Last checked: 9 August 2026. The Message Center archive is useful for publicly referencing MC1450134, but administrators should treat the notice in their own Microsoft 365 tenant and current Microsoft Learn documentation as authoritative.
Voluntary support
Found this useful? Support Trends4You
Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they've helped you or your organisation, you can support the time and hosting that keeps them freely available.
Support is optional, handled securely by Stripe and does not provide additional access.