Team: Huntress Managed ISPM
Product: ISPM
Environment: Huntress.IO management portal
Summary: This article outlines an issue that occurs when Microsoft Entra ID is configured to require two authentication methods for Self-Service Password Reset (SSPR), but security policies (like those enforced by Huntress) have disabled weaker methods, leaving users with only one valid option. Because modern secure methods like FIDO2 or passkeys may not always satisfy SSPR’s specific requirements, a policy deadlock is created that prevents users from resetting their own passwords. To maintain a high security posture without reintroducing weak factors such as SMS, it is recommended to disable SSPR entirely and use Secure Recovery Methods for identity recovery.
Incompatible SSPR Configuration
Overview
This issue occurs when Self-Service Password Reset (SSPR) requirements conflict with enforced authentication methods in Microsoft Entra ID.
SSPR requires users to register at least two valid authentication methods. If your security policy restricts users to fewer or unsupported methods, the configuration becomes invalid and cannot be applied.
What Huntress Detected
Huntress enforced secure authentication methods only (e.g. Authenticator, FIDO2, passkeys), while:
- SSPR is configured to require 2 methods, and
- The allowed methods do not satisfy SSPR requirements
This results in a policy deadlock:
- Secure methods are enforced
- SSPR requirements cannot be met
The Error will present itself as a banner instructing users to contact their admin, requiring them to register an authentication method to continue, but none have been enabled for this account. The None part is what causes confusion: you may have an authentication method set up, but SSPR requires 2.
Why This Happens (Root Cause)
1. SSPR Requires Two Methods
SSPR can be configured to require a minimum number of methods. If users don’t have enough registered, the SSPR will fail.
2. Not All Methods Are Equal
Some authentication methods:
- Work for sign-in/MFA
- Do NOT fully satisfy SSPR requirements
Additionally:
- Some methods are restricted to authentication only (e.g. FIDO2, Windows Hello)
- Phone-based methods are considered weak and are disabled by Huntress to adhere to best practice.
- SSPR only shows methods enabled in policy
3. Microsoft Design Limitation
SSPR and Authentication Methods policies are now unified; you cannot cleanly allow a method for SSPR but block it for MFA/sign-in. There is no current workaround for this.
Common Scenario (Secure Tenants)
You have:
- SMS / Voice disabled (correct for security)
- Authenticator / Passkeys enforced
- SSPR still requires 2 methods
This results in users only having 1 valid SSPR method, which causes the configuration to fail.
Huntress Recommendation
This issue represents a design limitation in Microsoft Entra ID, not simply a misconfiguration.
If you are enforcing secure authentication methods only using ISPM, there is no perfect alignment with SSPR’s default expectations at this time.
Our recommended approach is to Disable SSPR and Use Secure Recovery Methods
Implement secure recovery via:
- Temporary Access Pass (TAP)
- Helpdesk-assisted reset with strong identity verification
Why this is recommended:
- Maintains a phishing-resistant authentication model
- Avoids reintroducing weak factors purely to satisfy SSPR
- Aligns with modern Zero Trust principles
How to Disable SSPR
- Browse to Entra (https://entra.microsoft.com)
- Select Entra ID > Password Reset
- Ensure Self service password reset enabled is configured to ‘None’
- Ensure you save your charges