They succeed because many controls focus on message content while attackers target human trust and business context. A convincing supplier, executive, or support request can bypass suspicion and trigger legitimate action. Mature enterprises still fail when email governance is disconnected from identity verification and downstream approval controls.
Why This Matters for Security Teams
social engineering keeps working because attackers exploit decision-making, not just inbox hygiene. Mature enterprises often have strong email filtering, awareness training, and approval workflows, yet those controls still depend on people making fast trust judgments under pressure. That gap is especially dangerous when a request appears to come from a supplier, executive, or service desk and the downstream action is technically legitimate.
The problem is broader than phishing content. It spans identity proofing, verification steps, and authority escalation across channels. Guidance in NIST SP 800-63 Digital Identity Guidelines underscores that identity assurance must be matched to the transaction risk, not treated as a one-time login event. For organisations handling credentials and sensitive workflows, NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now shows how trust breaks down when access paths are not continuously verified.
In practice, many security teams encounter the real failure only after a payment, reset, or token handoff has already been approved by someone who thought the request was routine.
How It Works in Practice
Attackers succeed by matching business context, timing, and authority signals. They may impersonate a known vendor, copy the tone of an internal approver, or exploit a time-sensitive process such as invoice change, password reset, payroll update, or shared mailbox access. The goal is usually to trigger a legitimate human action that bypasses technical alarms because the request itself looks operationally normal.
What works best against this pattern is layered verification that is tied to identity and transaction context, not just message filtering. That means confirming who is requesting the action, whether the request fits the person’s role, and whether the channel used is appropriate for the sensitivity of the task. Standards such as NIST SP 800-63 Digital Identity Guidelines are useful because they reinforce assurance, proofing, and authentication strength as separate decisions.
- Use out-of-band verification for high-risk actions, especially payment, credential reset, and privileged access changes.
- Bind approval to identity, role, and transaction metadata, not to email appearance alone.
- Require step-up verification when a request deviates from normal business rhythm or source location.
- Log and correlate the request, approver, and downstream system action so a social engineering event cannot hide inside a normal workflow.
NHIMG research on the DeepSeek breach and the broader NHI security problem shows why trust collapses when identities, secrets, and approval paths are not governed as one chain. These controls tend to break down in organisations with decentralized approvals and shared service workflows because no single control owner can see the whole transaction path.
Common Variations and Edge Cases
Tighter verification often increases friction, so organisations have to balance fraud resistance against business speed. That tradeoff is real in finance, HR, customer support, and executive operations, where too many checks can create shadow processes or workarounds.
Best practice is evolving for AI-assisted and multi-channel social engineering. Current guidance suggests that traditional email-only defenses are no longer enough when attackers combine voicemail, collaboration tools, and even synthetic content to reinforce credibility. For that reason, mature enterprises increasingly separate content inspection from approval authority and treat every sensitive request as a transaction with its own proof requirements.
One useful benchmark comes from NHIMG’s research on secrets exposure: the average time to remediate a leaked secret is 27 days, even though 75% of organisations express strong confidence in their secrets management capabilities. That gap is a reminder that confidence and control quality are not the same thing. The same pattern applies to social engineering: organisations often believe training is working until a real-world prompt crosses into finance, identity, or privileged support.
There is no universal standard for this yet, but the most resilient programs combine identity verification, approval segregation, and rapid revocation paths so a mistaken trust decision cannot persist across systems.
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 | Identity assurance must match transaction risk, not just login strength. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege and access governance reduce blast radius after trust abuse. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Social engineering often becomes credential misuse once secrets are handed over. |
Use assurance levels and step-up checks for high-risk requests before approving sensitive actions.
Related resources from NHI Mgmt Group
- Why do phishing and social engineering still succeed against mature IAM programmes?
- Why do targeted phishing campaigns still work against mature organisations?
- Why do social engineering attacks still defeat mature IAM programmes?
- How should security teams respond to AI-assisted phishing and social engineering?
