Forum Discussion
Challenges with New MFA and SSPR Policies: Need Guidance
I am currently transitioning our Self-Service Password Reset (SSPR) and Multi-Factor Authentication (MFA) to the new Authentication Methods policy, moving away from legacy policies. However, the lack of clarity on which methods are compatible with both scenarios is quite frustrating, and I wonder if I might be missing something.
Our goal is to exclusively use the Authenticator app and security keys for both MFA and SSPR, eliminating all other methods. Additionally, we want to maintain the requirement of two methods (Authenticator app and security key) for password changes. We are in the process of distributing security keys to all staff.
The issue I’m encountering is that while Microsoft promotes this new portal as a unified solution for both MFA and SSPR, not all methods are supported across both. Specifically, the security key does not currently work for SSPR. If I am unable to use the security key for SSPR and must resort to a less secure second method, I would at least like to disable that less secure method for MFA. However, it seems there is no way to configure this in the policy.
Am I on the right track here? I am aware that Authentication Strengths can be configured—perhaps this is where I should focus?
Any advice or discussion would be greatly appreciated.
3 Replies
- AlterEgoCopper Contributor
Kidd_Ip I am currently transitioning our SSPR process from a Helpdesk Call Knowledge-based process (with its major flaw of a weak knowledge based factor) to Entra SSPR.
Like brentmattson I am wondering why state of the art secure authentication methods are not allowed for SSPR according to https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods
Since the usage of Text/SMS and voice calls is highly discouraged (you even mention this in the documentation), the documentation leaves us with only 3 options:
MS Authenticator Push and OATH TOTP (Software or Hardware) which might be sufficient for Standard Accounts, but we want to offer Administrator accounts SSPR.
You also mention email and security questions, but email is not usable when you locked yourself out and security questions are highly discouraged as well.
It would be ideal if you would allow a 2nd Passkey/FIDO2 Hardware Token as a means of recovery.
E.g. Administrators should have 2 Hardware Tokens: the 1st as a primary AuthN factor and the 2nd purely for recovery.
This is currently not possible because Entra ID does not allow Passkeys for SSPR.
Do you have planned updates to SSPR AuthN methods on your roadmap?
With the state being, we can't allow SSPR but instead look at https://learn.microsoft.com/en-us/entra/verified-id/helpdesk-with-verified-id
The Verified ID would also serve greatly as a SSPR Recovery AuthN Method.
You are correct that not all authentication methods are supported across both MFA and SSPR. Specifically, security keys (FIDO2) are currently not supported for SSPR:
How to migrate to the Authentication methods policy - Microsoft Entra ID | Microsoft Learn
Manage authentication methods - Microsoft Entra ID | Microsoft Learn
Enable Microsoft Entra self-service password reset - Microsoft Entra ID | Microsoft Learn
- brentmattsonBrass ContributorDo you know if that is by design or if the FIDO2 keys will eventually support SSPR?