Who should approve sensitive identity changes after a social engineering attempt?

Why This Matters for Security Teams

After a social engineering attempt, the risk is not just an exposed credential. The bigger problem is an attacker convincing support, help desk, or an overworked manager to make an identity change that creates a new foothold. Sensitive changes such as password resets, MFA re-enrollment, recovery factor replacement, API key reissue, or role elevation should not rest with a single approver. NIST’s NIST SP 800-63 Digital Identity Guidelines reinforce that identity proofing and authenticator recovery need stronger controls than routine access requests.

NHIMG research shows how often identity control failures are already tied to damage: Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities, and only 20% of organisations have formal offboarding and revocation processes for API keys. That same pattern applies to human identity workflows when social engineering succeeds through a weak approval path. A single reviewer can be manipulated, impersonated, or simply make a bad exception in the moment. In practice, many security teams discover the failure only after the account takeover has already propagated into downstream systems.

How It Works in Practice

The safest model is dual approval from separate functions, with at least one approver outside the immediate support chain. For example, a help desk agent can validate the request mechanics, while a security or identity team member validates risk, evidence, and policy fit. For higher-risk changes, best practice is evolving toward step-up verification, case-based review, and explicit denial of any change that cannot be tied to a documented incident or recovery workflow.

Identity teams should treat the change itself as a controlled event, not an administrative convenience. That means:

• Requiring two independent reviewers for sensitive changes.
• Logging the request, justification, approvers, timestamps, and evidence used.
• Using short-lived recovery actions instead of permanent bypasses.
• Revoking sessions, tokens, and related credentials after the change.
• Separating recovery approval from the person who received the social engineering call or email.

This is especially important for accounts with privileged access, service ownership, or delegated admin rights. The 52 NHI Breaches Analysis shows that identity-related incidents commonly spread when one weak action is enough to unlock broader access. For analogous control design, the NIST identity model and the operational discipline behind NHI governance point in the same direction: require proof, preserve evidence, and make the approval path resistant to coercion. Controls tend to break down in high-volume help desk environments because speed pressure overrides second-review discipline.

Common Variations and Edge Cases

Tighter approval controls often increase recovery time, requiring organisations to balance user friction against account-takeover resistance. That tradeoff is acceptable for high-impact identities, but not every change needs the same level of scrutiny. Current guidance suggests tiering approvals by risk: low-risk profile edits may use standard workflows, while MFA resets, email changes, privileged role grants, and recovery-factor replacement should require stronger review.

There is no universal standard for this yet, but several edge cases are clear. If the original verifier may have been socially engineered, that verifier should not be the sole approver. If the request involves a privileged administrator, the approval should come from a separate control plane such as IAM security, PAM operations, or a designated incident response path. If the person is unavailable, a documented break-glass procedure should exist, but it should still require post-event review and alerting. The goal is not to freeze the business; it is to ensure that a manipulated workflow cannot silently rewrite trust. That matters even more when identity changes are tied to service accounts or delegated automation, because a single mistaken approval can create persistent access long after the initial attack.

Related resources from NHI Mgmt Group

• What breaks when deprovisioning is delayed after role changes?
• How should organisations govern access when identity state changes daily?
• How can identity teams keep pace with access changes in modern environments?
• When does a machine identity become a compliance problem?