In This Article
The self-service password reset that keeps your staff productive and your help desk from drowning is about to change in a way most banks, credit unions, and mortgage companies have not noticed yet. On September 7, 2026, Microsoft Entra ID stops accepting directory-sourced phone numbers and email addresses for password-reset verification. Only authentication methods a user has explicitly registered will work. If your institution has relied on phone numbers and email addresses synced from on-premises Active Directory to give employees a reset path, the employees who never registered a method lose the ability to reset their own password, and every one of those resets becomes a help-desk call.
This is a quiet change with a loud operational tail. Self-service password reset is a productivity control before it is a security control. When it works, an employee who forgets a password on a Monday morning is back to work in two minutes without opening a ticket. When it breaks, that same employee calls the help desk, waits, and the help desk absorbs a wave of identity-verification requests during the exact window an attacker most wants a rushed agent on the phone. Microsoft is tightening the reset path for a good reason, and the institutions that prepare before the deadline keep the productivity benefit while closing a real security gap. The ones that do not prepare inherit both a lockout problem and a social-engineering opening.
This article explains exactly what changes, which configuration pattern leaves an institution exposed, the three dates that belong on your calendar, and the specific steps to take before September 7 so the change is a non-event for your users. The mechanics are Microsoft Entra ID identity governance, and the details are where this either goes smoothly or turns into a help-desk crisis.
What Changes on September 7, 2026
Microsoft Entra self-service password reset, usually shortened to SSPR, lets an employee reset or unlock their own account without calling IT. To do that, Entra ID has to verify the person is who they claim to be, and it does that by contacting an authentication method on file: a text message or call to a phone, a code to an email, or a prompt in the Microsoft Authenticator app. The change coming on September 7, 2026, is about which of those methods Entra ID will accept for that verification.
Today, an institution can populate a user's phone number or email address in two very different ways. A user can register a method themselves, which records it as an explicit authentication method tied to that user. Or the institution can synchronize contact details that already live in on-premises Active Directory, so that Entra ID has a phone number or email for the user without the user ever registering anything. That second path is convenient. It also produces a verification method the user never confirmed and may not even know is being used.
Starting September 7, 2026, Microsoft Entra SSPR will accept only explicitly registered authentication methods. Directory-sourced properties, specifically the fields Microsoft names as mobilePhone, businessPhone, and otherMails, that were never registered will no longer work for SSPR verification. A user whose only reset path was a synced phone number, and who never registered a method, will not be able to complete a self-service reset after that date.
A synced phone number is a convenience the user never confirmed. After September 7, Entra ID treats reset the way it should have all along: only a method the user actually registered counts.
Microsoft frames this as part of its Secure Future Initiative, and the security logic is sound. A phone number copied out of a directory field is a weaker proof of identity than a method the user deliberately set up, because nobody verified the user controls it. For a bank, credit union, or mortgage company, that is exactly the kind of unverified fallback an examiner does not want sitting in the password-reset path. The change removes it. The work is making sure every employee has a real registered method before the fallback disappears.
Which Institutions Are Most Exposed
The institutions most exposed to this change are the ones that did the sensible thing years ago and synchronized user contact information from on-premises Active Directory into Entra ID. If you run Microsoft Entra Connect and let it map telephoneNumber to Office phone and mobile to Mobile phone, some of your users almost certainly have a phone number that Entra ID can use for reset today but that the user never registered. Those users are the ones who lose self-service reset on September 7 unless they register a method first.
The uncomfortable part is that this exposure is invisible from the outside. A synced phone number and a registered phone number look similar in day-to-day use. The difference only surfaces at the moment of a reset after enforcement begins, which is the worst possible time to discover it. Identity gaps like this one tend to stay hidden until a deadline or an attacker finds them, the same way a Conditional Access scoping gap let a June 2026 password spray slip past multi-factor authentication. The table below shows the two states side by side, so you can see which of your users is quietly depending on a method that is about to stop counting.
Directory-Sourced, Retired on Sept 7
- Phone or email synced from on-premises Active Directory via Entra Connect
- Populated in the
mobilePhone,businessPhone, orotherMailsfields - Never explicitly registered by the user
- Works for SSPR verification today
- Stops working for SSPR verification on September 7, 2026
Explicitly Registered, Still Valid
- A method the user set up through the registration experience
- Microsoft Authenticator, a passkey or FIDO2 security key, a registered phone, or email
- Confirmed by the user, tied to their identity
- Works for SSPR verification today
- Continues to work after September 7, 2026
Why This Hits Financial Institutions Harder
Banks, credit unions, and mortgage companies tend to run hybrid identity, with on-premises Active Directory synchronized to Microsoft Entra ID, precisely because they have core systems and branch infrastructure that predate the cloud. That hybrid pattern is the one most likely to be leaning on directory-sourced contact details for password reset. Combine that with a lean internal IT team and a workforce spread across branches, and you have the conditions for a large batch of users who have never registered a method and will all hit the wall at once. A lockout wave is a productivity problem. The pressure it puts on a help desk to verify identities quickly is a security problem. This is the kind of quiet identity migration ABT already runs across its 750-plus financial-institution footprint, which is why the details below are worth getting right before the deadline rather than after.
The Rollout Timeline You Need on the Calendar
Microsoft is not flipping a single switch on one day. There is a sequence, and two of the dates matter for planning even though only the last one is the hard enforcement point. Read the timeline as a runway: the earlier dates are your chance to get users registered before the fallback disappears.
Per Microsoft Learn, Conditional Access policies that target the "Register security information" action now also apply during Windows Hello for Business and macOS Platform Single Sign-on credential registration, flows that previously did not evaluate registration-targeting Conditional Access. This is a different change from the SSPR one, but it touches the same registration surface, so review policies scoped to security-info registration and test them in report-only mode.
Microsoft's SSPR documentation states that starting on this date, if your settings require users to register during sign-in and enabled users do not have enough methods to complete SSPR, a registration campaign prompts affected users to register methods ahead of enforcement. This is your built-in nudge to close the gap, and it runs for roughly a month before the cutoff.
Microsoft Entra SSPR accepts only explicitly registered authentication methods. Directory-sourced mobilePhone, businessPhone, and otherMails values that were never registered stop working for verification. Any user without a registered method can no longer self-serve a reset.
One earlier date provides useful context. Since September 30, 2025, authentication methods can no longer be managed in the legacy multi-factor authentication and SSPR policies, and Microsoft directs organizations to the centralized Authentication methods policy instead. If your institution has not completed that migration, do it as part of this work, because the Authentication methods policy is where registration and method controls now live.
Do Not Confuse the Two Dates
The August 6, 2026 date is the SSPR registration campaign. The July 6, 2026 date is a separate Conditional Access change affecting Windows Hello for Business and macOS Platform Single Sign-on registration. Some secondary summaries have merged the two into a single July date. They are distinct changes with distinct dates, and Microsoft's own documentation lists the SSPR registration campaign as beginning August 6, 2026. Plan against the vendor dates, not the aggregated blog summaries.
What to Do Before the Cutoff
You do not need a large project to get ahead of this. The work is a registration-coverage push, and it maps to a short set of concrete actions inside Microsoft Entra ID. Done in the weeks before September 7, it turns a potential lockout wave into a quiet migration your users barely notice. Each step below is something an internal team can start now, and something an examiner may reasonably ask you to evidence.
A regional credit union synced branch employees' phone numbers from Active Directory years ago and never ran a registration push, because self-service reset simply worked. On the morning of September 8, 2026, a teller who has never opened the Authenticator app forgets her password and tries to reset it. The synced number no longer counts, so the reset fails.
She calls the help desk, along with dozens of colleagues in the same position. The queue backs up, agents are under pressure to move fast, and identity verification gets looser as the day wears on. That is precisely the environment in which a caller impersonating an employee talks an overwhelmed agent into resetting a password that is not theirs.
The scenario is avoidable, and the avoidance is entirely in the preparation window. An institution that runs the registration report in July, drives coverage through the August campaign, and hardens its help-desk process before the cutoff experiences September 7 as a date on a slide rather than a crisis at the front desk. Help-desk social engineering has become one of the more common ways attackers take over accounts at financial institutions, from talking an agent into a reset to the abuse of the self-service reset flow itself, and a lockout wave is an engineered opportunity for exactly that tactic. Preparing removes the opportunity.
Key Takeaway
The change itself is small. The exposure is entirely about how many of your users have never registered a method and are quietly relying on a synced phone number or email. Find those users with the registration report, get them onto a registered strong method through the August campaign, and September 7 becomes a non-event. Skip the preparation and it becomes a lockout wave with a social-engineering tail.
How M365 Guardian Handles the Migration
This is exactly the kind of Microsoft 365 identity change that M365 Guardian exists to absorb. ABT is a Tier 1 Microsoft Cloud Solution Provider that manages the Microsoft 365 and Entra ID tenants of more than 750 banks, credit unions, and mortgage companies. Where a customer runs workloads in Azure, ABT hosts and runs those Azure environments. The registration coverage and the Authentication methods policy that decide whether September 7 is smooth or painful live inside the Microsoft 365 tenant ABT manages on the customer's behalf.
A small internal IT team rarely has the time to pull a registration report, chase down every unregistered user across every branch, run a communication campaign, and harden the help-desk reset process, all while keeping the day-to-day running. That coordination is the work M365 Guardian takes off their plate, so the institution's technology staff can stay focused on serving members and closing loans while the identity migration happens correctly and on schedule.
For this specific change, the Guardian operating model does four things inside the managed tenant:
- Registration coverage, driven to zero gaps. ABT runs the Microsoft Entra ID authentication methods registration report, identifies every user relying on a directory-sourced method, and drives them onto a registered strong method before the September 7 cutoff, so no employee is stranded.
- The registration campaign, run on schedule. ABT configures and manages the August 6 registration campaign with the right scope and user communication, so the prompts land as an expected step rather than a suspicious surprise.
- Authentication methods policy, migrated and maintained. ABT completes and maintains the move to the centralized Microsoft Entra ID Authentication methods policy, steering registration toward Microsoft Authenticator and phishing-resistant methods rather than SMS.
- Help-desk reset hardened, and sign-in activity watched. ABT helps define and enforce how identity is verified during an assisted reset, and Guardian MxDR watches the Microsoft Entra ID sign-in and reset activity around the cutoff, so the predictable spike does not become an account-takeover opening.
Everything this change requires is already in the Microsoft 365 and Microsoft Entra ID platform most financial institutions hold. The Microsoft Entra admin center provides the authentication methods registration report that finds unregistered users. The Microsoft Entra ID Authentication methods policy is where registration and the registration campaign are configured, and it is where you steer users toward Microsoft Authenticator, passkeys, and FIDO2 security keys. Microsoft Entra Conditional Access secures the registration experience itself. Microsoft Purview supplies the audit trail an examiner will ask for, and Microsoft Defender surfaces the suspicious sign-in and reset activity worth watching around the cutoff. The capability is present. The work is running it correctly for a regulated institution and keeping it that way.
What separates ABT from a national reseller is vertical depth. The largest Tier 1 CSPs move Microsoft licenses at scale but carry no financial-services specialization, and the regional IT shops that understand banking rarely hold Tier 1 CSP status or manage identity at this depth. ABT does both, for financial institutions specifically, which is why a registration deadline that catches a credit union off guard is one ABT is already managing across its 750-plus institution footprint. For institutions weighing whether their reset path is ready, ABT's analysis of why identity is the new perimeter in Microsoft 365 shows how quietly identity controls fail when a configuration detail is one notch off.
Self-service password reset is a productivity control that fails silently. Nobody notices the gap until an employee cannot reset a password, which is why the registration report matters more than the deadline.
The takeaway for a bank, credit union, or mortgage CISO is direct. Some of your users are relying on a password-reset method that stops working on September 7, 2026, and you cannot see who without running the report. M365 Guardian turns that report into a completed migration and a hardened reset process, so the change strengthens your identity posture instead of stranding your staff. The same discipline applies to the adjacent identity work, from closing reset-flow abuse to moving toward phishing-resistant multi-factor authentication, all of which lives in the same managed tenant.
Are your users ready for the September 7 reset cutoff?
ABT runs your Microsoft Entra ID registration report, finds every user still relying on a directory-sourced reset method, drives them onto a registered strong method before the deadline, and hardens your help-desk reset process. Book an identity and authentication readiness review through M365 Guardian.
Frequently Asked Questions
Starting September 7, 2026, Microsoft Entra self-service password reset will accept only explicitly registered authentication methods. Directory-sourced properties that Microsoft names as mobilePhone, businessPhone, and otherMails, meaning phone numbers and email addresses that were synced into Entra ID but never registered by the user, will no longer work for reset verification. A user whose only reset path was one of those synced values, and who never registered a method, will not be able to complete a self-service reset after that date until they register one.
Yes, for any user who never registered that number as an authentication method. If Microsoft Entra Connect syncs a phone number into the mobilePhone or businessPhone field and the user relies on it for reset without ever registering it, that path stops verifying resets on September 7, 2026. The fix is to get those users to register a method, ideally the Microsoft Authenticator app, a passkey, or a FIDO2 security key, before the cutoff. Running the authentication methods registration report in the Microsoft Entra admin center tells you exactly which users are affected.
A directory-sourced method is a phone number or email address that arrives in Entra ID by synchronization from on-premises Active Directory, without the user confirming it. A registered method is one the user deliberately set up through the registration experience, which ties it to their identity and confirms they control it. Microsoft is moving reset verification to registered methods only because a confirmed method is a stronger proof of identity than a value copied from a directory field the user never verified.
Microsoft's SSPR documentation states that starting August 6, 2026, if your settings require users to register during sign-in and enabled users do not have enough methods to complete SSPR, a registration campaign will prompt those users to register methods ahead of enforcement. In practice it is a built-in nudge that runs for about a month before the September 7 cutoff. Enable it and communicate it to staff so the prompt looks like an expected step rather than a suspicious one. Note that this August date is the SSPR campaign specifically, and it is distinct from a separate July 6, 2026 Conditional Access change that some summaries have merged with it.
Per Microsoft Learn, starting July 6, 2026, Conditional Access policies that target the "Register security information" action also apply during Windows Hello for Business and macOS Platform Single Sign-on credential registration. Those registration flows previously did not evaluate registration-targeting Conditional Access. After the change, a user registering one of those credentials must also satisfy the policy's grant controls, such as an authentication strength or a trusted location. Review any policy scoped to security-info registration and test it in report-only mode before enforcement. This is a separate change from the SSPR registered-methods requirement, though both touch the registration surface.
ABT manages your Microsoft 365 and Microsoft Entra ID tenant as a Tier 1 Microsoft Cloud Solution Provider. Microsoft hosts the underlying infrastructure; ABT manages the tenant, including the authentication methods registration and the Authentication methods policy that determine whether the September 7 change is smooth for your users. Where a customer runs workloads in Azure, ABT hosts and runs those Azure environments. Through M365 Guardian, ABT drives registration coverage to completion before the cutoff and hardens the help-desk reset process, so the change strengthens your identity posture rather than stranding your staff.
