Microsoft is closing a security gap in Self-Service Password Reset on 7 September 2026: phone numbers and email addresses that an admin added to the directory but users never personally confirmed will no longer be accepted as a recovery contact. Attackers have been actively exploiting this pattern. What changes, which users are at risk, and which steps must IT teams take now?
Forgetting a password is an everyday scenario. Microsoft Entra ID provides Self-Service Password Reset for exactly this purpose: users can reset their password without calling the help desk. Convenient, scalable, and enabled by default in most Microsoft 365 environments. But there is a security risk in how SSPR performs identity verification, and Microsoft is now actively closing that gap.
On 28 May 2026, Microsoft published Message Center notification MC1325414, part of the Secure Future Initiative: from 7 September 2026, SSPR will only accept explicitly registered recovery contacts. Phone numbers and email addresses that an administrator entered in Active Directory or Entra ID but that the user never personally confirmed will no longer be valid as proof of identity. For IT teams, this creates a concrete action window between now and the start of September.
Entra ID stores several contact fields for each user: mobilePhone, businessPhone, and otherMails. Administrators often populate these in bulk from HR systems or Active Directory synchronisation, without the user entering or verifying the values themselves. Until now, SSPR accepted these fields as valid proof of identity: send a one-time code to that number, user enters the code, reset complete.
A registered method works differently. The user visits the registration portal via My Security Info, confirms the contact by receiving and validating a code, and explicitly saves it as a recovery method. This actively proves that the user owns that contact.
The distinction seems subtle but is decisive from a security standpoint. A directory attribute proves nothing: it may have been entered by an administrator, imported from a legacy system, or be years out of date. A registered method proves that the user actively had access to that contact at a specific moment and deliberately linked it to their account.
SSPR abuse is not a theoretical risk. In 2025 and early 2026, security researchers documented multiple cases in which attackers compromised Azure environments through exactly this weakness. The attack technique typically runs in three steps.
First, the attacker collects information about the target: name, business email address, phone number. This is often effortless via LinkedIn, public company pages, or leaked databases. Then the attacker initiates an SSPR request for the target account. If the phone number in the directory matches a number the attacker controls, via SIM-swapping, number portability fraud, or control of a business telecom account, the attacker receives the verification code and resets the password entirely on their own.
The result is full access to the Microsoft 365 account, including email, SharePoint files, Teams chats, and in many cases connected external systems, without a single phishing email being involved. The help desk only becomes aware when the legitimate user reports that their account no longer works.
The change has two components. First, SSPR stops accepting contact data from directory attributes as valid proof of identity. Only recovery contacts that the user personally confirmed and saved via the registration portal will be accepted after the deadline. The fields mobilePhone, businessPhone, and otherMails no longer count, unless the user has personally validated them.
Second, Microsoft automatically starts a registration campaign on 6 July 2026 for affected users. Accounts that currently rely solely on directory attributes for SSPR will be prompted at every sign-in to register a recovery contact. This is a nudge, not a hard block: the user can postpone the prompt temporarily, but from 7 September, SSPR will not work for them without a registered method.
Microsoft states that approximately 86 per cent of SSPR requests already use registered methods. That sounds reassuring, but the remaining 14 per cent is, in an organisation of a hundred employees, already fourteen accounts that may hit a wall on the deadline. The accounts still dependent on directory attributes are often the most vulnerable: employees who rarely forget a password, users of shared function accounts, or accounts brought over from a migration that never had their security information set up.
The report is available in the Microsoft Entra admin centre under Security, then Authentication methods, then User registration details. You can see per user which methods are registered and whether SSPR meets the policy requirement. Export the list to CSV and filter for accounts without a registered method.
Pay particular attention to three user groups. First, new employees created recently who have not yet visited the registration portal. Second, employees in roles with limited PC use who never had a reason to set up their security information. Third, accounts created via hybrid synchronisation from on-premises Active Directory where directory attributes were carried over but never confirmed by the user.
First action: run the report now and export the list of users without a registered method. Prioritise accounts with elevated privileges such as administrators, finance staff, and directors, so the highest-risk accounts are covered first.
Second action: enable the registration campaign without waiting for the automatic start on 6 July. You will find the setting in the Entra admin centre under Authentication methods, Registration campaign tab. Set the maximum snooze period to seven days or fewer, so users cannot postpone the prompt indefinitely.
Third action: prepare the service desk for the scenario after 7 September. Users who pass the deadline without a registered method cannot reset their password independently. An administrator must then manually set a temporary password and guide the user through registration. If this affects dozens of users simultaneously, it creates a noticeable peak load on the help desk. Communicate to employees in advance about the need to register, so the volume stays manageable.
For environments that use Conditional Access, an additional option is available: a policy that requires registration in the security information portal for all accounts that have not yet registered a method, paired with a Named Location policy so that registration only takes place on trusted networks or managed devices. This closes the gap for accounts that keep ignoring the nudge.
The SSPR change does not stand alone. In June 2026, Microsoft also enforced a change in Conditional Access: policies targeting All resources are enforced from 15 June even when resource exclusions are present. This closes a configuration where specific applications fell outside policy scope via an exclusion while the policy formally targeted everything.
Both changes are part of the Secure Future Initiative, Microsoft's multi-year programme that systematically tightens identity security following the lessons of large-scale cloud identity attacks in 2023 and 2024. For IT teams, the broader picture is clear: Microsoft is raising the baseline, and organisations that have not reviewed their Entra configuration for some time risk having configurations that worked for years quietly stop working.
The SSPR deadline of 7 September gives nine weeks to get this in order. That is sufficient, but only if you start with the report now. Want help assessing your SSPR registration status, activating the registration campaign, or reviewing your Entra ID security configuration? Zarioh helps organisations with complete Microsoft 365 and Entra security. Contact us for a no-obligation conversation.
Zarioh Digital Solutions
IT specialists from Utrecht, the Netherlands. We help businesses with Microsoft 365, AI agents, hosting and telephony — and share what we learn in practice. Follow us on LinkedIn
Security
Security
Security
