Context: Microsoft published a Microsoft Entra ID security update about three tenant changes: Custom controls moving to External MFA, Conditional Access being enforced more consistently during credential registration, and SSPR requiring explicitly registered authentication methods.
What Microsoft is changing
Microsoft is tightening a few old edges in Entra ID. The common theme is simple enough: identity controls should be explicit, policy-backed, and visible to administrators. Redirect-style MFA integrations, registration flows that bypass part of the policy path, and password reset methods copied from directory attributes all create awkward security gaps.
The three changes have different timelines, so I would not treat this as one generic identity task. Put dates next to the work, assign owners, and test the user journeys before the deadlines arrive.
Timeline
These dates are the part I would put straight into a change calendar. The July changes can hit onboarding and device provisioning. The September SSPR change can hit users when they already have a password problem, which is exactly when you don't want the helpdesk to discover missing registration data.
| Date | Change | Risk if ignored |
|---|---|---|
| Now | Inventory Custom controls, Conditional Access policies for Register security information, and SSPR method registration status. | You won't know which users or policies will break later. |
| 6 July 2026 | Conditional Access enforcement starts for more credential registration flows. Microsoft also starts the SSPR registration campaign. | Windows Hello for Business, macOS Platform Single Sign-on, and security info registration can block users if policy is too tight. |
| 7 September 2026 | SSPR accepts only authentication methods the user has explicitly registered. | Users relying on directory-sourced phone or email attributes may not be able to reset passwords. |
| 30 September 2026 | Custom controls deprecation starts. | Old third-party MFA integrations remain on a retiring path. |
| May 2027 | Custom controls reach end of life. | Policies depending on Custom controls need a supported replacement before this point. |
Custom controls to External MFA
Custom controls are the older way to send a user out to a third-party service during Conditional Access. They worked, but they were always a bit bolted-on. External MFA is the supported direction because it fits better into the Entra authentication flow and Conditional Access evaluation.
The technical work starts with finding every Conditional Access policy that has a Custom control grant. Then you need to map the third-party provider, affected users, excluded break-glass accounts, and the exact sign-in flows where the control is required. Don't just replace the control and hope. Run a pilot policy first, because redirect behavior and native External MFA behavior are not the same user journey.
| Area | Custom controls | External MFA |
|---|---|---|
| Policy integration | Legacy integration with redirect-style behavior. | Built for modern Conditional Access enforcement. |
| User flow | User leaves Microsoft flow for the external provider. | Provider result is integrated into the Entra sign-in flow. |
| Support path | Retiring. Deprecation starts 30 September 2026. | Recommended path for third-party MFA providers. |
| Operational check | List policies and affected groups before migration. | Pilot with a scoped group and monitor sign-in results. |
Credential registration policy
The second change is about Conditional Access evaluation during credential registration. Microsoft says policies targeting the Register security information user action will apply more consistently to Windows Hello for Business provisioning and macOS Platform Single Sign-on registration from 6 July 2026.
This can be good security and still break onboarding if the policy design is too strict. A common example is requiring a compliant device before the user has completed the very setup flow that makes the device compliant. Another one is requiring MFA for registration when the user has no usable registered method yet. Report-only mode is your friend here, but only if you test real onboarding paths and not only normal browser sign-ins.
# Microsoft Graph PowerShell: list Conditional Access policies
# Review policies that target the "Register security information" user action.
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy -All |
Select-Object DisplayName, State, Conditions, GrantControls |
Format-ListFor testing, I would use separate pilot accounts for at least these flows: first-run Windows Hello for Business provisioning, macOS Platform Single Sign-on registration, security info registration from the browser, and password reset registration. Capture the exact prompt or block reason. That gives the endpoint team and helpdesk something useful instead of "Conditional Access broke onboarding".
SSPR registered methods
The SSPR change is the one I expect many tenants to underestimate. Phone numbers and alternate email addresses can sit on user objects for years. They may have been imported from HR, synced from on-premises directories, typed by an admin, or left stale after a role or country change. Microsoft is moving SSPR toward methods the user explicitly registered and verified.
From 7 September 2026, SSPR will no longer accept unregistered directory-sourced phone numbers and email addresses. Microsoft starts a registration campaign on 6 July 2026, but I would still validate coverage yourself. The campaign prompts users, but it doesn't fix every service desk process or stale identity lifecycle issue.
| Area | Check | Owner |
|---|---|---|
| Authentication method coverage | Which users have no registered method that can satisfy SSPR? | Identity team |
| Directory-sourced contact data | Which users rely only on phone or email fields that were not registered by the user? | Identity team and HR data owner |
| Registration campaign | Is the campaign enabled, scoped correctly, and communicated before July 2026? | Identity team and communications |
| Helpdesk scripts | Does support know how to recover a user who cannot complete SSPR? | Service desk |
| Break-glass and privileged users | Are admin accounts registered with strong methods without weakening emergency access? | Security operations |
Audit and reporting
This update is mostly policy and registration work, so the audit angle is different from incident hunting. I would build a small workbook around four questions: which policies still depend on Custom controls, which policies target Register security information, which users lack registered SSPR-capable methods, and which registration failures start appearing after 6 July 2026.
For Conditional Access, sign-in logs are the useful place to watch policy results. For registration state, use the authentication methods reporting views and Graph reports. For support volume, tag helpdesk tickets with a simple category like "security info registration" or "SSPR method missing" so you can see whether the rollout is creating real user friction.
SigninLogs
| where TimeGenerated > ago(14d)
| where ConditionalAccessStatus in ("failure", "reportOnlyFailure")
| mv-expand ConditionalAccessPolicies
| extend PolicyName = tostring(ConditionalAccessPolicies.displayName)
| extend PolicyResult = tostring(ConditionalAccessPolicies.result)
| where PolicyName has_any ("Register", "Security information", "Credential")
| summarize Count=count(), Users=dcount(UserPrincipalName)
by PolicyName, PolicyResult, bin(TimeGenerated, 1d)
| order by TimeGenerated descImplementation checklist
So, practically, I would split the work into three tracks and run them like a small identity change program.
- Custom controls: export affected Conditional Access policies, identify the external provider, design the External MFA replacement, pilot it with a narrow group, and document rollback.
- Credential registration: test Windows Hello for Business, macOS Platform Single Sign-on, and browser security info registration against report-only policies before 6 July 2026.
- SSPR: report users without registered authentication methods, enable or validate the campaign, update onboarding, and prepare the helpdesk for the September enforcement date.
The awkward part is ownership. Custom controls may belong to the identity team, the MFA vendor owner, and app teams. Windows Hello for Business and macOS Platform Single Sign-on involve endpoint management. SSPR involves identity, HR data quality, communications, and helpdesk. If nobody owns the cross-team test plan, the July date will find the gap for you.
Important: Don't remove emergency access account protections while fixing SSPR registration. Emergency access accounts should be monitored and tested, but they should not be forced into a normal user recovery flow that can lock you out during an outage.
What I would report
I would keep the status report short and date-based:
- By 6 July 2026, we need report-only validation for credential registration policies and SSPR campaign readiness.
- By 7 September 2026, users must have explicitly registered SSPR-capable authentication methods.
- By 30 September 2026, Custom controls must have migration owners and tested External MFA replacement plans.
- Before May 2027, no production Conditional Access policy should depend on Custom controls.
That gives leadership something concrete to approve: testing time, communications, helpdesk preparation, and any vendor work needed for External MFA.