Why do phishing and social engineering still succeed against mature IAM programmes?

Why This Matters for Security Teams

Phishing and social engineering still work because mature IAM programmes often optimise for authentication success, not for trustworthy intent. A valid session, a correctly entered one-time code, or a pushed approval can still be captured under false authority. That gap matters more in environments that rely on MFA fatigue, help desk resets, or delegated approvals than in environments that rely on passwords alone. The issue is not that IAM is broken; it is that human trust remains the weakest policy input.

NIST’s NIST SP 800-63 Digital Identity Guidelines makes clear that identity proofing, authentication, and verifier binding are separate problems, yet many programmes still collapse them operationally. NHIMG’s The State of Secrets in AppSec shows how confidence in controls can outpace actual resilience, especially when access decisions depend on people recognizing deception in real time. In practice, many security teams encounter compromise only after a user has already legitimized the attacker through an approved prompt, reset flow, or support interaction.

How It Works in Practice

Successful phishing usually exploits the moment where trust is converted into privilege. Attackers do not need to defeat the entire IAM stack if they can convince a user to surrender a code, approve an unexpected prompt, or follow a link that initiates a session with the wrong party in the loop. Once that happens, downstream controls often see a legitimate identity and a valid token, not a deception event.

That is why mature programmes increasingly pair strong authentication with phishing-resistant methods, session risk scoring, and tighter recovery workflows. The practical goal is to reduce the number of situations where a user can unilaterally validate a malicious request. Useful countermeasures include:

• Phishing-resistant MFA, especially where session binding and origin checking are supported.
• Help desk verification steps that do not rely on easily replayed personal data.
• Step-up authentication for sensitive actions such as device enrollment, recovery, and privilege elevation.
• Continuous session monitoring so anomalous token use can be challenged after login.
• Out-of-band confirmation for high-risk changes, ideally through a separate trusted channel.

NHIMG research such as the DeepSeek breach illustrates a broader pattern: once attackers obtain a valid trust path, they move quickly and exploit what appears to be normal administrative behaviour. That same dynamic appears in identity attacks where the credential is not stolen first, but socially obtained. These controls tend to break down in high-friction environments where support teams are pressured to restore access quickly because urgency repeatedly overrides verification.

Common Variations and Edge Cases

Tighter identity controls often increase user friction and help desk workload, requiring organisations to balance fraud resistance against recovery speed and business continuity. Best practice is evolving here, and there is no universal standard for the exact mix of controls that will stop every phishing path.

Some environments are more exposed than others. Executive impersonation, vendor onboarding, and urgent payroll or payment changes often bypass normal caution because they exploit time pressure and authority bias. Shared inboxes, contractor access, and outsourced support create another weak point because the verifier may not know the user well enough to notice inconsistency. Where attackers target account recovery, the issue is frequently not MFA weakness but weak proofing around reset and re-enrollment.

NHIMG’s Azure Key Vault privilege escalation exposure reinforces an important point: once an attacker wins a trust decision, the blast radius depends on what that identity can reach next. That is why mature IAM programmes should treat phishing resistance, recovery design, and privilege boundaries as one system rather than separate projects. The hard cases are environments with legacy authentication, broad delegated admin rights, and rapid support escalation, because those conditions let social engineering bypass policy even when the login screen looks strong.

Related resources from NHI Mgmt Group

• Why do phishing-resistant MFA controls still fail against social engineering?
• Why do MFA fatigue attacks still work in mature IAM programmes?
• Why do segregation of duties conflicts still happen in mature IAM programmes?
• Why do shared chatbot pages create a phishing problem for IAM and browser security?