Microsoft Entra self-service password reset (SSPR) is changing so that it only accepts authentication methods a user has explicitly registered, which means phone numbers and email addresses that were only copied into the directory (the mobilePhone, businessPhone and otherMails attributes) will stop working for reset unless the user registered them. Microsoft’s documentation source currently lists 5 October 2026 for that enforcement and 9 November 2026 for a registration campaign, but it also says the campaign runs ahead of enforcement, so the two dates may be swapped and you should confirm them in your tenant’s Message Center. Keycloak has the same underlying risk in its default “forgot password” flow, which sends the reset link to whatever is in the user’s email attribute, so the rule worth copying is to recover accounts only through channels the user has proved they control.
This post covers what Entra is changing and why, then maps the same discipline onto Keycloak, an open-source identity server that teams run themselves or consume as identity management as a service. If you run both, for example during a migration or with Entra for staff and Keycloak for customers, the Keycloak sections are where you can close the equivalent gap.
Key takeaways
- Entra SSPR will reject directory-sourced contact details that were never registered as authentication methods (Microsoft Learn, “Prepopulate user authentication contact information for SSPR”, 2026).
- Microsoft’s published dates have changed several times and currently contradict each other, so check your tenant’s Message Center.
- In Keycloak 26.8, the default reset flow sends the link to the
What is Microsoft changing in Entra SSPR?
In 2026, Microsoft added an “Important” note to its Learn article on prepopulating SSPR contact information. As of 3 October 2026, the source of that article says that “SSPR will only accept explicitly registered authentication methods”, and that directory-sourced properties such as mobilePhone, businessPhone and otherMails that were never registered will no longer work for SSPR verification. Until now, organizations could synchronize those attributes from on-premises Active Directory through Microsoft Entra Connect, and SSPR would use them even if the user had never confirmed them. The body of the same article still describes that older behaviour, so the page is currently inconsistent with its own note.
The note also describes a registration campaign. If your SSPR settings require users to register during sign-in and an enabled user does not have enough methods to complete SSPR, Entra will prompt that user to register methods ahead of enforcement.
The dates are less settled than the policy. When the note was added on 1 June 2026, it set the registration campaign for 6 July and enforcement for 7 September. On 24 June the campaign moved to 6 August. On 4 August enforcement moved to 5 October and the campaign to 9 November, which puts the campaign after the enforcement it is meant to precede. That ordering looks like an error in one of the dates, and we read the documentation source on GitHub rather than the rendered Learn page, so treat both dates as provisional and rely on your tenant’s Message Center for the ones that apply to you.
Why are registered recovery methods more secure?
A directory attribute is data that someone typed or synchronized, while a registered method is one the user has proved they control. A reset channel works like a credential, because whoever controls the phone or mailbox it points to can take over the account. If that channel comes from an HR system or an old Active Directory field, it may be out of date, belong to a phone the user no longer has, or have been edited by someone with write access to the directory rather than by the user.
Recovery is also a common target for social engineering, since convincing a help desk to change a recovery phone or reset MFA can be easier than defeating the sign-in itself. That is why our guide to MFA fatigue and help-desk vishing focuses on who is allowed to change recovery methods, and not only on which methods exist.
How does Keycloak handle password reset by default?
Keycloak’s “forgot password” link runs a built-in authentication flow called “reset credentials”. In the Keycloak 26.8.0 source, that flow has four steps in this order: choose the user by username or email, send a reset email, set a new password, and a conditional step for users who already have an OTP authenticator. The reset link itself is an action token, a signed, single-use JWT that expires after a configurable lifespan.
The step that matters here is “Send Reset Email”. It sends the link to the user’s email attribute, and nothing in the reset path checks whether that address was ever verified. If the attribute is empty, Keycloak shows the same “email sent” message without sending anything, so it does not reveal which accounts exist. After the user sets a new password, the “Force login after reset” option on that step decides whether they are signed straight in when they complete the reset in the same browser session. Its default, only-federated, signs local users straight in and makes users from LDAP or another federated store log in again.
The conditional OTP step does not check the user’s existing second factor. With its default configuration it only adds the CONFIGURE_TOTP required action, so the user is asked to set up an authenticator app again, and the old one stays in place unless the step is configured to remove it. In a default realm, control of the mailbox in the email attribute is therefore enough to set a new password, which is the Keycloak version of Entra’s directory-sourced contact problem.
How do you require verified recovery methods in Keycloak?
Keycloak 26.8 has no single setting that stops a reset email going to an unverified address, but you can get close to Entra’s registered-methods rule by combining built-in settings with a modified flow. Here is the order we would work through.
- Turn on email verification, and verify existing users. Under Realm settings, then Login, enable “Verify email”. This adds the
VERIFY_EMAILrequired action at a user’s next login, so it does not help users who never log in or who were imported before you turned it on. For those, send an “execute actions” email withVERIFY_EMAIL(see the example below), and decide whether unverified accounts should be able to reset at all. - Control who can change the email attribute. In the declarative user profile (Realm settings, then User profile), decide whether users may edit
emailthemselves. The “Update Email” feature is available by default in Keycloak 26.8, but its required action is disabled until you enable “Update Email” under Authentication, then Required actions. Once it is on, a user-initiated change goes through that action, and with “Verify email” enabled the new address has to be confirmed before it takes effect. - Check where emails come from. LDAP and Active Directory user federation and external identity providers each have a “Trust Email” option that marks imported addresses as verified. Leave it off unless you trust that source’s email data as much as a user-completed verification, because that is what it asserts.
- Check a second factor before the password is reset. Duplicate the “reset credentials” flow, add a conditional subflow containing “Condition – user configured” and the “OTP Form”, and move that subflow above “Reset Password”, because the password is changed as soon as the “Reset Password” step completes. Then bind the copy as the realm’s reset credentials flow. At that point Keycloak has identified the user but not authenticated them, which is what the OTP Form needs. Users without OTP skip the subflow and still reset by email alone, so test with users who have and do not have OTP before you switch.
- Force a fresh login after reset. Set “Force login after reset” to
trueon the “Send Reset Email” step of your copied flow, so a reset never produces a signed-in session on its own.
The admin CLI covers the realm setting and the bulk verification step. The second command sends one user an email asking them to verify their address and set up an authenticator app:
kcadm.sh update realms/myrealm -s verifyEmail=true
kcadm.sh update users/<user-id>/execute-actions-email -r myrealm
-b '["VERIFY_EMAIL","CONFIGURE_TOTP"]'For any of the email steps to work, the realm needs a working SMTP configuration, which our Keycloak email configuration guide covers.
Which Keycloak required actions map to Entra’s registration?
Required actions are steps Keycloak makes a user complete at their next login, and they are how you get users to register methods before you depend on them. The ones that matter for recovery in Keycloak 26.8 are VERIFY_EMAIL, UPDATE_EMAIL, CONFIGURE_TOTP for an authenticator app, CONFIGURE_RECOVERY_AUTHN_CODES for one-time recovery codes, and the WebAuthn registration actions for security keys and passkeys. The recovery codes and passkeys features are both enabled by default in 26.8, and each still needs its required action or flow configured in the realm.
An administrator can set required actions on one user in the admin console, or send the “execute actions” email shown above. You can also make an action a default for new users under Authentication, then Required actions, and users can manage their own credentials in the account console afterwards. If you are moving users towards phishing-resistant sign-in at the same time, our Keycloak passkeys guide and our post on moving from Entra SMS MFA to passkeys cover the registration side, and our multi-factor authentication feature page summarises the options.
How do you audit recovery method changes in Keycloak?
Keycloak records recovery activity as user events, so you can see who reset what and when. The relevant event types in 26.8 include SEND_RESET_PASSWORD, RESET_PASSWORD, UPDATE_PASSWORD, UPDATE_EMAIL, VERIFY_EMAIL, UPDATE_CREDENTIAL and REMOVE_CREDENTIAL. Turn on user events under Realm settings, then Events, and make sure those types are saved. Turn on admin events as well, because a change an administrator makes to a user’s email or credentials appears there rather than as a user event.
The patterns worth alerting on are an email change followed soon after by a password reset, a credential removed and re-added without a matching help-desk ticket, and repeated reset emails for one account. Our guide to Keycloak auditing and event logging explains how to ship those events to a SIEM, and our audit logs feature page covers the audit trail Skycloak exposes.
What should you do if you run Entra and Keycloak together?
If both systems hold the same people, recovery has to be equally strict on each side, because an attacker will use whichever is weaker. For workforce users who sign in to Keycloak through Entra, recovery usually belongs to Entra, so disable “Forgot password” in those Keycloak realms or point those users to Entra’s reset page. For customers or partners who sign in to Keycloak directly, apply the steps above. During a migration, do not import Entra contact attributes into Keycloak as verified unless the user registered them in Entra, which is the same distinction Microsoft is now drawing.
For background on how the two products line up, our guide to learning Entra ID through a Keycloak lens maps the concepts.
FAQ
What is SSPR in Microsoft Entra ID?
SSPR is Microsoft Entra self-service password reset, which lets users reset their own password or unlock their account without the help desk after proving their identity with one or more authentication methods. Under the change Microsoft documented in 2026, those methods must be explicitly registered, so unverified directory phone numbers and emails will no longer count.
When does Entra SSPR stop accepting directory phone numbers and emails?
Microsoft’s documentation source lists 5 October 2026 for enforcement and 9 November 2026 for a registration campaign, while also saying the campaign comes first, so one of those dates is likely wrong. The dates have been revised twice since June 2026. Check your tenant’s Message Center for the schedule that applies to you.
Does Keycloak have self-service password reset?
Yes. Enable “Forgot password” under Realm settings, then Login, and Keycloak shows a link that runs the “reset credentials” flow. By default it emails a single-use link to the user’s email attribute without checking that the address was verified, so turn on “Verify email”, verify existing users, and consider adding a second-factor check to the flow.
Can Keycloak require MFA during password reset?
Yes, with a custom flow. Duplicate the built-in “reset credentials” flow, add a conditional subflow with “Condition – user configured” and the “OTP Form”, place it above “Reset Password”, and bind the copy as the realm’s reset flow. Set “Force login after reset” to true as well. Users without OTP still reset by email alone.
How do I make users register a recovery method in Keycloak?
Use required actions. Set VERIFY_EMAIL, CONFIGURE_TOTP, CONFIGURE_RECOVERY_AUTHN_CODES or a WebAuthn registration action on the user, or make one a default for new users under Authentication, then Required actions. The user completes it at their next login, and you can send an “execute actions” email to existing users.
Sources
- Microsoft, Microsoft Learn, “Prepopulate user authentication contact information for Microsoft Entra self-service password reset (SSPR)” (documentation source in the entra-docs repository), retrieved 2026-10-03, https://github.com/MicrosoftDocs/entra-docs/blob/main/docs/identity/authentication/howto-sspr-authenticationdata.md (published version: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-sspr-authenticationdata)
- Microsoft, entra-docs commit history for that article, showing the date changes in commits d5c68c0 (1 June 2026), 59e2cda (24 June 2026) and 63ce419 (4 August 2026), retrieved 2026-10-03, https://github.com/MicrosoftDocs/entra-docs/commits/main/docs/identity/authentication/howto-sspr-authenticationdata.md
- Keycloak,
DefaultAuthenticationFlows.javaat tag 26.8.0 (reset credentials flow), retrieved 2026-10-03, https://github.com/keycloak/keycloak/blob/26.8.0/server-spi-private/src/main/java/org/keycloak/models/utils/DefaultAuthenticationFlows.java - Keycloak,
ResetCredentialEmail.javaandResetOTP.javaat tag 26.8.0 (reset email, “Force login after reset”, OTP reset step), retrieved 2026-10-03, https://github.com/keycloak/keycloak/tree/26.8.0/services/src/main/java/org/keycloak/authentication/authenticators/resetcred - Keycloak,
Profile.javaat tag 26.8.0 (recovery codes, Update Email and passkeys features enabled by default), retrieved 2026-10-03, https://github.com/keycloak/keycloak/blob/26.8.0/common/src/main/java/org/keycloak/common/Profile.java - Keycloak,
DefaultRequiredActions.javaat tag 26.8.0 (Update Email required action disabled by default), retrieved 2026-10-03, https://github.com/keycloak/keycloak/blob/26.8.0/server-spi-private/src/main/java/org/keycloak/models/utils/DefaultRequiredActions.java