Enable and troubleshoot self-service password reset
Self-service password reset closes the exact gap the previous unit leaves open: a Relecloud user who simply forgets a password they were allowed to set. You enable SSPR for the engineering group, Group1, and require two methods to complete a reset. A week later, the help-desk queue hasn't shrunk—it's grown. Before you touch a single setting again, you need to know whether the problem is a scoping gap, a policy mismatch, or something else entirely.
Predict whether SSPR follows the rule you already know
Your first instinct is to check group membership, because that's usually where scoping problems hide. Group2, a subset of Relecloud's contractors, is nested inside Group1—and you already know how nested groups behave for Conditional Access policies and license assignment: both apply only to direct members, so a user who belongs to Group1 only through Group2 gets skipped entirely.
Guiding question: Based on how Conditional Access and license assignment treat nested groups, predict what happens when you enable SSPR for Group1. Can Group2's members—who are members of Group1 only through nesting—complete a self-service password reset? Check your prediction against the next section before you read further.
See why SSPR treats nested groups as the exception
Your prediction based on Conditional Access and licensing is reasonable, and it's wrong here. Microsoft's own guidance draws a hard line around this: "Only one Microsoft Entra group can currently be enabled for SSPR using the Microsoft Entra admin center. As part of a wider deployment of SSPR, nested groups are supported." Enabling SSPR for Group1 does extend to Group2's members, because they're indirect members of Group1 through nesting.
That's the opposite of what Conditional Access and license assignment taught you to expect, and it's worth holding onto as a deliberate exception rather than a bug. SSPR's single-group scoping model is more permissive by design, precisely because Microsoft expects a wider rollout over time—nesting additional groups under the one enabled group is a supported way to extend access without re-enabling SSPR against a different group each time. So the ticket spike isn't a nested-group gap. Group2's members can reach the reset flow. Something else is stopping them from finishing it.
Reconcile the registered count with the required count
The next place to look is the gap between two numbers that sound similar but aren't the same setting. Number of methods required to reset is the count a user has to satisfy during an actual reset. A separate setting, methods required to register, is the count a user has to satisfy the first time they enroll. Microsoft's documentation is specific about which one determines registration status: "A user is considered registered for SSPR when they registered at least the Number of methods required to reset a password that you set in the Microsoft Entra admin center."
Here's where Relecloud's rollout likely went sideways. Group1's users originally registered when the required-to-reset count was set to one method, so most of them added a single phone number and stopped there. When you raised the requirement to two methods, nothing forced those users to go back and register a second one—the policy change doesn't retroactively re-enroll anyone. Instead, it quietly moves the goalposts, and any user who registered only one method now falls short of the new threshold. They technically remain "registered" under the old count, but they can't complete a reset until they add another method, and most of them have no idea that's what's blocking them. This is exactly why the documented best practice sets methods required to register at least one higher than methods required to reset: it guarantees every user always has a spare method banked before you ever raise the reset requirement, so tightening the policy later doesn't strand anyone who already enrolled.
Recognize when a lockout blocks a valid method
A second, unrelated cause produces the same symptom—a user who's fully registered and correctly scoped, but still can't finish a reset. Repeated failed verification attempts trigger a temporary lockout, and the thresholds differ by method. For a phone call, an authenticator app notification, a text message, or security questions, a user gets five attempts within one hour before a 24-hour lockout takes effect. Email verification is more forgiving in volume but tighter in time: ten attempts within ten minutes before the same 24-hour lockout applies.
| Verification method | Attempts allowed | Window | Lockout |
|---|---|---|---|
| Phone call, app notification, text message, security questions | 5 | 1 hour | 24 hours |
| 10 | 10 minutes | 24 hours |
A user mid-lockout can't complete SSPR, even if every other method on their account is valid and correctly registered. If a Relecloud contractor mistypes a security code five times while distracted, the account locks for a full day regardless of how well-scoped the group membership is or how many methods they've registered. From the help desk's point of view, that ticket looks identical to a registration-count mismatch or a scoping problem—the user reports "SSPR isn't working for me" either way. Diagnosing which of the three it is means checking registration state, group membership, and lockout status, in that order, before assuming the policy itself is broken.
Diagnose the real cause behind the ticket spike
Put together, Relecloud's ticket spike almost never traces back to the nested-group exception you just ruled out. It traces back to users who registered under a looser count and got caught by a tightened policy, or to users temporarily locked out after a handful of failed attempts. The one scoping error that does produce a distinct, recognizable signal is different from both: a user outside Group1 entirely—not nested, just excluded—sees the error UserNotMemberOfScopedAccessGroup when they try to start a reset. That error resolves cleanly, by adding the user to the enabled group either directly or through a nested group. It's the mismatched-count and lockout cases that masquerade as scoping problems and cost the help desk the most time to untangle.
| Cause | Signal | Fix |
|---|---|---|
| Registered-count mismatch | User enrolled under a lower required-to-reset count, then the requirement was raised | Have the user register another method; set methods-to-register higher than methods-to-reset |
| Verification lockout | Fully registered and scoped, but locked after repeated failed attempts | Wait out the 24-hour lockout |
| Out-of-scope user | Error UserNotMemberOfScopedAccessGroup at reset start |
Add the user to the enabled group (directly or nested) |
Learn more about how SSPR registration and reset counts work, enabling SSPR for a group, including nested groups, and SSPR lockout thresholds.
SSPR now handles the case where a Relecloud user forgets a password they were allowed to set in the first place. But a forgotten password isn't the only signal worth watching at sign-in—some sign-ins look suspicious before a password ever enters the picture. Can Relecloud trust that every client app attempting to sign in is even capable of proving it deserves that extra scrutiny? That question is where Conditional Access picks up next.