Why do phishing and social engineering still create so much breach risk?

Why phishing keeps working even when people know the basics

Phishing remains effective because it exploits normal business behaviour, not just technical weakness. Most organisations still rely on humans to recognise urgency, verify legitimacy, and decide when to trust an email, text, call, or login prompt. Attackers win when they can make a request feel routine, plausible, or time-sensitive enough to override caution.

The real problem is that modern phishing is usually not a generic “click this link” message. It often uses brand impersonation, account notifications, invoice themes, meeting invites, or helpdesk-style conversations that look operationally normal. That makes the attack socially credible before it ever becomes technically visible, which is why The 52 NHI breaches Report is useful reading on how stolen credentials and abuse of trusted access paths can turn a single deceived user into broader compromise.

Credential theft is only one outcome. A successful pretext can also push a user to approve MFA, share a one-time code, install remote access software, or hand over access through a support channel. Once the attacker has a trusted session or authenticated foothold, security tools may see the action as legitimate unless there are strong verification and anomaly controls in place.

How social engineering bypasses technical controls

Phishing and social engineering are dangerous because they target the point where control ownership shifts from the security stack to the user. If the victim discloses a password, authorises a login, or grants access in response to a convincing pretext, the attacker may inherit a real identity with real permissions. That is why breaches often start as conversation, not code.

The most damaging campaigns usually combine several moves: impersonation, urgency, authority, and follow-through. A fake password reset, a “shared document” prompt, or a helpdesk callback can each seem harmless in isolation. In practice, the attacker is trying to create one authenticated action that unlocks downstream access, and that can be enough to defeat perimeter filtering, email gateways, or basic MFA if the user is the final approval point.

This is also why phishing can scale so well. Attackers do not need perfect technical exploitation when they can abuse trust relationships already accepted by the business, including vendor support, collaboration tools, cloud sign-in flows, and shared workflows. Cases like MGM Resorts Breach 2023, Scattered Spider show how social engineering against identity workflows can be more effective than trying to break encryption or exploit a software flaw directly.

For identity-related guidance, NIST SP 800-63 Digital Identity Guidelines is a strong reference point because phishing-resistant authenticators and stronger verification materially reduce the value of stolen credentials and replayed login attempts.

What actually reduces breach risk in practice

Awareness training helps, but it is not enough on its own. The practical goal is to make one mistaken user action less likely to become a full compromise. That means adding verification steps for sensitive requests, tightening helpdesk procedures, limiting what a single account can do, and using stronger authentication methods that are harder to intercept or socially engineer.

Practitioners should treat high-risk actions differently from ordinary mail hygiene. Resetting MFA, changing bank details, approving third-party access, or granting remote support should require an out-of-band check or a second control path. The best programs also test for “human bypass” failure modes, not just phishing link clicks, because attackers increasingly target approvals, tokens, and session access rather than passwords alone.

It is also worth measuring what happens after a user reports or clicks. If response is slow, if helpdesk identity proofing is weak, or if privileged actions are not logged clearly enough to spot unusual patterns, the organisation may already be behind the attacker. The most useful controls are the ones that shorten attacker dwell time and reduce the blast radius of a single deceived user.

Risk and Threat Considerations

Phishing creates breach risk because it can convert trust into authenticated access. The attacker does not need to defeat every defensive layer if one convincing interaction causes a user to reveal a secret, approve a login, or hand over a session.

Failure mechanism: A successful pretext bypasses technical controls by exploiting human verification gaps, weak helpdesk checks, MFA fatigue, or overly permissive approval paths. Once the attacker holds a valid session or credential, they can move laterally or access sensitive systems as an apparently legitimate user.

Impact: The organisation can lose confidentiality, integrity, and control over downstream systems very quickly, especially when the stolen access belongs to a privileged user, a support function, or an account with broad application reach.

Practitioner Guidance

What to verify: Do not trust “user awareness” as a control unless you can show how the organisation handles the next step after a user is deceived. Verify that sensitive requests require separate confirmation, that helpdesk identity proofing is strong, and that privileged actions cannot be completed from a single email thread or call.

What to prioritise: Focus first on the workflows attackers most often abuse, password resets, MFA enrolment, approvals, and support interactions. Those are the points where a social-engineering campaign becomes a breach, so they deserve more scrutiny than generic phishing education alone.

Practitioner takeaway: The question is not whether users will occasionally be fooled, it is whether one fooled user can still turn that mistake into broad access, and that is the control problem to design against.

Related resources from NHI Mgmt Group

• Why do vendor breaches create so much social engineering risk?
• Why do compromised SaaS integrations create outsized phishing and social engineering risk?
• Why do weak passwords and poor password practices still create so much breach risk in enterprise environments?
• Why do weak app integrations and social engineering create such high breach risk in mobile environments?