They keep working because many IAM controls still depend on a person making the right decision under pressure. If the attacker can influence help-desk staff, approvers, or end users, the technical control may remain intact while the access path is bypassed.
Why This Matters for Security Teams
social engineering keeps bypassing modern IAM because many controls still assume a legitimate person will make the right decision at the right time. Attackers do not need to break cryptography if they can pressure a help desk, trick an approver, or persuade a user to approve MFA fatigue prompts. That means the access system can look healthy while the human decision point is compromised. NHI Management Group research shows the gap is not theoretical: in The 2024 Non-Human Identity Security Report, 88.5% of organisations said their non-human IAM practices lag behind or merely match their human IAM efforts.
This matters because identity programs often optimise for policy coverage, not adversary persuasion. A phishing-resistant login does little if an attacker resets the account through a weak recovery flow, abuses delegated approval, or engineers an exception. Guidance from NIST SP 800-63 Digital Identity Guidelines is clear that assurance depends on the whole lifecycle, not just the login ceremony. In practice, many security teams encounter compromise only after a support workflow, approval path, or recovery process has already been used as the access bypass.
How It Works in Practice
The attack works by moving outside the technical boundary of authentication and into the operational boundary of trust. If an attacker can impersonate an employee, claim urgency, or exploit a recovery exception, the strongest IAM stack can be sidestepped without a single password crack. That is why social engineering remains effective even in environments with MFA, SSO, and conditional access.
Effective defence requires treating identity operations as an attack surface. Security teams should harden the pathways attackers actually target:
- Help-desk reset flows should require strong verification, step-up checks, and clear anti-impersonation scripts.
- Approver workflows should separate duties so one compromised reviewer cannot silently grant access.
- Recovery channels should be monitored, time-limited, and resistant to urgency-based pressure.
- Privileged access should be issued through just-in-time processes rather than standing entitlements.
- High-risk events should trigger out-of-band validation and real-time policy evaluation.
For non-human and agentic systems, the same lesson applies even more strongly. Attackers increasingly target secrets, tokens, and workload identities because those objects can be reused at machine speed. NHIMG’s 2024 Non-Human Identity Security Report found 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, which creates a social-engineering-friendly path straight to workload compromise. External guidance from CISA cyber threat advisories and the MITRE ATLAS adversarial AI threat matrix both reinforce that identity abuse often begins with trust exploitation, not exploit code. These controls tend to break down when organisations allow recovery exceptions, informal approvals, or shared support privileges because the attacker only needs one human to override the system.
Common Variations and Edge Cases
Tighter identity controls often increase friction for legitimate users, so organisations must balance resistance to social engineering against service desk latency and user experience. That tradeoff is real, especially in large enterprises where resets, exceptions, and delegated approvals are part of daily operations.
Best practice is evolving, but current guidance suggests the highest-risk environments need stronger verification than standard MFA alone. This is especially true when:
- support staff can bypass normal controls during incidents or travel emergencies;
- executives or contractors receive exceptions that are not centrally reviewed;
- hybrid or multi-cloud operations rely on shared secrets and informal handoffs;
- AI agents can request access, chain tools, or trigger workflows faster than humans can review them.
For that reason, identity programs should align human recovery controls with workload identity governance. The same organisation that hardens user resets should also eliminate long-lived secrets, use short-lived credentials, and verify workload identity at runtime. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both show that credential sprawl and access inconsistency are recurring failure points. Social engineering keeps working when organisations protect the login more carefully than they protect the people and processes around it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Defines identity assurance across enrollment, authentication, and recovery. | |
| NIST CSF 2.0 | PR.AA-1 | Identity proofing and auth assurance are weakened by impersonation and help-desk abuse. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Social engineering often leads to secret exposure and unsafe credential handling. |
Review identity proofing and recovery workflows for impersonation resistance and step-up validation.
Related resources from NHI Mgmt Group
- Why do traditional visitor controls fail against modern social engineering?
- How should security teams defend against modern email attacks that bypass legacy filters?
- Why do phishing-resistant MFA controls still fail against social engineering?
- Why do phishing and social engineering still succeed against mature IAM programmes?