The settingWhat we hold this to
CreativeTechs minimum
No account holding a privileged directory role is in the SSPR-enabled group. Administrators reset through the service desk.
Benchmark position
No published benchmark value in CIS, CISA or EIDSCA. Huntress rates it High · Foundational.
Where we differ, and why
A Huntress-only catch. Worth keeping on their judgement plus ours; note it has one authority behind it, not four.
Where the switch is
Entra admin centre → Protection → Password reset → Properties → Self service password reset enabled = Selected, and scope the group to exclude privileged accounts.
How to verify
Compare the SSPR-enabled group's members against /directoryRoles members. Expect no intersection.
- Why it matters
- SSPR on a privileged account turns a compromised recovery method into a path to Global Admin without ever knowing the password.
- How we check
- Huntress (High · Foundational). No framework equivalent found — a Huntress-only catch.
- Fix — M365
- Entra → Password reset → scope the SSPR-enabled group to non-privileged users only.
- Fix — Google
- Google blocks super-admin self-recovery by default; confirm it hasn't been re-enabled.
- User notices
- Admins call us for resets instead of self-serving. That is the intent.
- Expected pushback
- Minimal — small population, and the break-glass account covers the lockout fear.
