Notifications
Clear all
Topic starter
16/08/2026 5:00 pm
TL;DR: Third-party SSPR remains critical for on-premises Active Directory because native cloud-first recovery flows do not fully cover complex AD estates, multi-forest setups, or delegated administration needs, according to Securden. The governance issue is not password reset alone but whether identity recovery, verification, auditing, and policy control are consistent enough to reduce help desk load without widening the attack surface.
NHIMG editorial — based on content published by Securden: third-party self-service password reset for on-premises Active Directory
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams govern self-service password reset in on-premises AD?
A: They should treat SSPR as part of the identity control plane, not a separate convenience tool.
Q: Why do on-premises AD environments need different recovery controls than cloud identities?
A: Because the recovery path has to align with local directory policy, delegation, and logging, not just cloud authentication flows.
Q: Who should own password reset and account unlock governance in the enterprise?
A: Ownership should sit with IAM or identity security, with the service desk operating the workflow under policy rather than controlling the policy itself.
Practitioner guidance
- Map every reset path by identity source Document how password reset and account unlock work for on-premises AD, hybrid users, VPN users, and mobile users so you can see where assurance changes between channels.
- Require strong verification for recovery flows Use MFA or equivalent verification for every reset path and remove weak knowledge-based methods where they can be predicted or socially engineered.
- Tie SSPR to directory policy enforcement Confirm that resets write back to AD policy, respect password history and complexity rules, and do not create exceptions that bypass existing controls.
What's in the full article
Securden's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step comparison of on-premises AD, hybrid AD/Entra ID, and remote access reset flows
- Implementation detail on MFA, audit logging, and policy writeback for recovery workflows
- Deployment and licensing considerations for organisations replacing legacy password reset tooling
- Product-level discussion of how the unified platform approach affects administration and rollout
👉 Read Securden's analysis of third-party SSPR for on-premises Active Directory →
On-prem AD self-service password reset: what IAM teams miss?
Explore further
16/08/2026 5:01 pm
SSPR should be governed as a recovery trust boundary, not as a standalone utility. The article is really about how organisations decide whether users can re-enter the identity system after lockout, and that decision has security consequences. If verification strength, audit logs, and directory policy enforcement are weak, recovery becomes an alternate access path. Practitioners should evaluate SSPR as part of the identity control plane, not as a convenience add-on.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How can teams tell whether an SSPR process is actually reducing risk?
A: Look for fewer help desk tickets, but also verify that reset events are audited, recovery methods are strong, and resets do not bypass password policy or delegation boundaries. If the process is faster but less traceable, it has traded convenience for exposure.
👉 Read our full editorial: Third-party SSPR for on-prem AD exposes the IAM control gap
