How should organisations handle phone-based requests for password resets and access changes?

Why This Matters for Security Teams

Phone-based requests sit in a dangerous middle ground: they feel operationally urgent, yet they are easy to impersonate, social-engineer, or relay through compromised voice channels. That makes them a frequent entry point for password resets, MFA rebinds, and privilege escalation attempts. Current guidance from OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev 5 Security and Privacy Controls both point toward verification, logging, and least privilege rather than trust in the request channel itself.

This is especially important where password resets or access changes affect privileged accounts, service accounts, or support staff with administrative reach. NHIMG research shows that 97% of NHIs carry excessive privileges and only 20% have formal offboarding and revocation processes, which underscores how quickly weak approval paths can become durable access paths. The same governance problem appears in human workflows when voice requests bypass durable checks and leave no reliable audit trail. In practice, many security teams encounter misuse only after a reset or access change has already been granted, rather than through intentional verification design.

How It Works in Practice

The safest operating model is to treat voice as a request trigger, not as proof of identity or authority. The person answering the call should follow a script that confirms the caller through an independent channel already on file, such as a ticketing callback, signed workflow approval, or a verified device-bound method. For higher-risk actions, the approval path should be two-step and time bound, with separate verification and execution roles where possible.

Strong handling usually combines:

• Identity proofing against pre-enrolled attributes, not information volunteered during the call.
• Out-of-band confirmation for resets, MFA changes, and access grants.
• Step-up approval for privileged access or shared admin credentials.
• Audit logs that record who requested, who verified, who approved, and what was changed.
• Queue-based workflows that let urgency be assessed without letting urgency authorise action.

For NHI-adjacent processes, the same principle applies to service accounts and API keys. The Ultimate Guide to NHIs and Ultimate Guide to NHIs — Key Challenges and Risks show why over-privilege, weak revocation, and poor visibility create lasting exposure after a single bad decision. That is why password reset and access-change procedures should mirror privileged access governance, not informal help-desk convenience. These controls tend to break down in outsourced support environments where scripts are inconsistent and callback verification is not technically enforced.

Common Variations and Edge Cases

Tighter verification often increases call handling time and user friction, requiring organisations to balance service speed against the risk of account takeover. Best practice is evolving for remote work, executive support, and after-hours escalation, because not every environment has the same callback confidence or ticketing maturity. Where there is no universal standard for a specific scenario, the safer rule is to require stronger verification, not weaker process shortcuts.

Some edge cases deserve special handling. For lost phones, urgent travel, or incidents involving a potentially compromised email account, voice verification alone is especially unreliable because the caller may already have one compromised channel. For contractors and third parties, the approval chain should be tighter still, because delegated support can blur responsibility and weaken accountability. For privileged users, separate approval from execution whenever possible, and avoid letting the same person both verify identity and perform the reset.

Organisations that manage both human and non-human access should also keep their control logic consistent. A caller asking for a reset to a vault, token, or admin console is effectively touching identity infrastructure, so the same governance discipline that protects NHI credentials should apply. For a practical control baseline, compare this workflow against the NIST control catalog and the OWASP guidance on identity abuse paths. Phone requests fail most often when support teams optimise for speed without a hard independent verification step.

Related resources from NHI Mgmt Group

• What breaks when organisations keep password-based remote access in place?
• How should security teams handle governance when access changes at cloud speed?
• Why do stolen tokens often survive password resets and MFA changes?
• How should organisations handle privileged access when workloads and AI systems are part of the model?