What should organisations do when delegated administrators can reset privileged passwords?

Why delegated password reset power should be treated as privileged access

A delegated administrator who can reset a privileged password is not just performing support work. That capability can function as an indirect control path into every system and dataset the target account can reach, especially if password reset also enables membership changes, MFA reset, or ACL modification. The practical question is not who owns the ticket, but whether the delegated path can influence high-value access.

Reset authority becomes privileged the moment it can alter the security state of an account that protects sensitive systems, administrative consoles, or automation. If the delegated admin can also change group membership or permissions, the reset is part of a larger authorization chain and should be governed with the same care as direct login credentials.

The key distinction is between a narrow service action and an access-changing action. If the delegated role can only clear a user lockout with no effect on privilege, the risk is lower. If it can re-enable access, change the factor set, or restore an account into a more powerful state, it is already participating in privileged access control and should be handled accordingly.

What scope, review, and monitoring need to change

Organisations should include these delegated admins in PAM scope, certification cycles, and monitoring so the reset path is visible and reviewable, not hidden inside help desk or directory operations. That means treating the ability to reset privileged passwords as a monitored privilege, not a background administrative convenience. The delegated account itself becomes an object of access governance.

That governance should extend to the account being reset as well. Where a delegated admin can recover access to root accounts, cloud admins, break-glass accounts, or service accounts, the reset path should be subject to tighter approval, session visibility, and post-action review. Privileged Access Management Guide is the best starting point for aligning those controls with vaulting, just-in-time access, and session oversight.

Review should focus on effective power, not job title. A delegated administrator may appear ordinary on paper, yet still be able to steer privileged outcomes by resetting the right account at the right time. Privileged Session Management Guide shows why recording and brokering admin activity matters when support actions can change who controls a session or an entitlement.

If the delegation exists to reduce operational friction, organisations should still test whether the same function could be performed through a narrower workflow, time-bound approval, or break-glass process. Break-Glass and Emergency Access Account Guide is useful where the reset function is meant to exist only for exceptional recovery, not routine administration.

Where reset authority becomes an attack path

Attackers value delegated reset power because it can bypass the need to steal the password they actually want. If they compromise a help desk, a delegated admin, or a vendor workflow that can reset privileged access, they may inherit the target’s reach without triggering the usual password-theft signals. That is why reset authority is often a lateral-movement enabler rather than a simple support function.

The risk is highest when the reset path can also change groups, MFA, or access policies. In that case, the attacker is not only regaining a password, but reshaping the account’s effective privileges. BeyondTrust breach 2024 is a strong reminder that reset-capable support access can become a high-impact compromise path when an upstream credential or key is abused.

Reset abuse also tends to hide inside normal operations because the action itself looks legitimate. That makes post-event evidence essential: who requested the reset, what identity approved it, whether the target account was privileged, and whether any membership or ACL change followed. Account Recovery and Help Desk Security Guide is directly relevant where reset workflows are the primary control surface attackers try to manipulate.

For organisations with heavy directory dependence, the safe assumption is that reset authority equals potential takeover authority until proven otherwise. Active Directory and Entra ID Hardening Guide supports that view by tying delegation, privileged groups, and tiered administration together as one control problem rather than separate administrative chores.

Practitioner Guidance

What to verify: Check whether the delegated role can only reset a password, or whether it can also re-enroll MFA, alter group membership, modify ACLs, or recover break-glass access. The second set of capabilities turns a support function into an effective privilege-management control.

Decision rule: If the reset path can change the target account’s effective reach, place both the delegated administrator and the reset workflow under privileged access review, logging, and approval. If it cannot change reach and is tightly constrained, the governance burden is lower but still worth periodic review.

What good looks like: Reset actions for privileged accounts are time-stamped, attributable, session-visible where practical, and reconciled against an approved ticket or exception path. Teams can show who performed the action, why it was allowed, and what downstream access state changed.

Common mistake: Treating delegated reset capability as if it were only a service desk concern. In practice, it is often the fastest route to privilege escalation if the account being reset controls administration, cloud access, or automation.

Practitioner takeaway: Govern reset authority by the power it confers, not by the label on the role, because the ability to restore access is often the ability to hand control back to a privileged account.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?