TL;DR: Phishing has shifted from obvious scam emails to AI-assisted impersonation across email, chat, phone, QR codes, and video, according to ThreatLocker, with IBM’s 2026 Cost of a Data Breach Report citing phishing as the most common initial attack vector in studied breaches at 15% and an average cost of $4.9 million. The control problem is no longer spotting fake messages, but limiting what stolen trust can do once a user clicks, approves, or replies.
At a glance
What this is: This is an analysis of how phishing has evolved into a cross-channel identity attack that increasingly relies on believable business context, AI-generated content, and trust in normal workflows.
Why it matters: It matters because IAM and NHI teams cannot treat phishing as only an email problem when the same stolen trust can drive credential capture, MFA abuse, session theft, and downstream access to cloud and internal systems.
By the numbers:
- IBM’s 2026 Cost of a Data Breach Report found phishing accounted for 15% of attacks in studied breaches.
- IBM’s 2026 Cost of a Data Breach Report put the average breach cost linked to phishing at $4.9 million.
Context
Phishing is no longer just a problem of obvious bad grammar and suspicious links. The control gap is that modern attacks now exploit normal communication channels, normal urgency, and normal trust assumptions, which makes user judgement alone an unreliable security boundary.
For identity and access programmes, the article is really about how attackers convert social trust into authentication events, support desk actions, and active sessions. That creates a direct intersection with IAM, MFA, remote access controls, and NHI governance where stolen credentials or trusted sessions become the real objective.
Key questions
Q: What breaks when help desk processes rely on MFA alone against social engineering attacks?
A: MFA alone breaks when attackers can socially engineer support staff, reuse stolen credentials, or trigger push fatigue to obtain a valid session. Once an account is taken over, the attacker can move through SSO-connected apps, register new federation paths, and operate as the user. Teams need phishing-resistant help desk verification, stronger identity proofing, and controls that detect unusual authentication paths.
Q: Why do phishing attacks still lead to major breaches when email filters are in place?
A: Email filters reduce exposure, but they do not stop a convincing lure that reaches a human and captures credentials or MFA approvals. The breach happens when the attacker turns that interaction into authenticated access. That is why email security must be paired with identity controls, session monitoring, and least privilege.
Q: What are the signs that phishing reporting is failing as a control?
A: The clearest signs are high report volume with little reduction in compromise risk, no visibility into who was targeted, and the same users repeatedly generating alerts without follow-up action. If reporting is not changing prioritisation or intervention, it is functioning as an inbox process, not a security control.
Q: How can organisations reduce the impact of a successful phishing click?
A: Use layered controls that limit what a stolen credential can do. MFA, conditional access, device trust, DNS filtering, and secure email protection should work together so one click does not become persistent access. The goal is to contain the event at authentication and session level, before it becomes an identity breach.
Technical breakdown
Spear phishing and business email compromise
Spear phishing uses specific context about a person, project, supplier, or payment flow to make a message look routine. Business email compromise goes further by taking over a legitimate account or impersonating a trusted sender so the attacker can alter banking details, approvals, or other business processes without obvious malware. The technical advantage is that the message itself becomes the delivery vehicle and the trust relationship is the exploit. Defenders should assume that message authenticity, not just content filtering, is the central problem because the attack may look like normal work until the recipient acts.
Practical implication: tighten approval flows and secondary verification on financial and access-sensitive requests, not just inbox filtering.
MFA fatigue, token theft, and help desk impersonation
Modern phishing often targets authentication rather than the inbox. MFA fatigue attacks overwhelm users with prompts until one is approved, while adversary-in-the-middle kits can intercept live tokens or sessions during login. The article also highlights help desk impersonation and push bombing, where the attacker uses support processes to reset access or bypass recovery controls. This matters because many identity systems still assume the user is making a deliberate, informed choice at authentication time, when in practice the attacker may be steering that choice through pressure, repetition, or social engineering.
Practical implication: harden MFA recovery and support workflows with stronger verification than the login flow itself.
Phishing beyond email channels
Phishing now moves through SMS, QR codes, fake search results, cloned websites, and even video calls. The mechanism is simple: the attacker places a believable prompt in the channel the target already uses for work or personal tasks, then captures credentials, payment details, or approval actions before the target has time to inspect the source carefully. AI-generated voice and video make that channel expansion more dangerous because the impersonation can now mimic familiar people rather than just familiar brands. The security model breaks when organisations assume one communication channel is inherently safer than another.
Practical implication: extend anti-phishing controls and user verification across all user-facing channels, not only email.
Threat narrative
Attacker objective: The attacker’s objective is to obtain trusted access that can be used for financial fraud, account compromise, or broader system intrusion without deploying obvious malware.
- Entry begins with a convincing phishing message, fake QR code, cloned site, or impersonation call that places the attacker inside a trusted communication flow.
- Credential_harvested or session-approved access follows when the victim enters credentials, accepts MFA prompts, or hands over a token during the interaction.
- Escalation occurs through account takeover, help desk abuse, or use of the captured session to reach email, collaboration, cloud, or internal systems.
- Impact is achieved through unauthorized payments, data access, or further lateral movement while the activity still resembles ordinary user behaviour.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Phishing is now an identity attack, not just a messaging problem. The article shows that the real target is trust in who is asking, not just what is being sent. That shifts the governance question from email hygiene to how identity is verified across support, collaboration, and payment workflows. Practitioners should treat phishing as a control failure in trust validation, not only user awareness.
Cross-channel phishing creates a trust boundary problem that classic email controls cannot solve. SMS, QR codes, search, voice, and video all now serve the same social engineering goal, which means the attack surface has expanded beyond the inbox. The specific named concept here is trust-channel sprawl, where every new communication surface becomes another place to impersonate authority. Teams need channel-specific controls, not a single anti-phishing narrative.
MFA is no longer a sufficient control unless recovery and approval paths are equally hardened. Fatigue attacks, token interception, and help desk impersonation exploit the assumptions around human confirmation and support verification. This is where IAM and identity verification converge with phishing resilience: if recovery steps are weaker than login, the attacker will route around the login. Practitioners should govern the whole authentication journey, not just the primary factor.
Zero Trust only helps when it blocks value after compromise, not before compromise. The article’s practical lesson is that phishing will still get through sometimes, so the decisive control becomes blast-radius reduction after a user click or token theft. For IAM and NHI programmes, that means limiting what a stolen identity can reach, what a trusted session can execute, and which devices can be trusted for sensitive actions. The security model must assume trust has already been abused.
AI has reduced the attacker’s cost of believability more than it has changed the underlying playbook. The old phishing patterns still work, but AI now makes them scalable, personalised, and harder to inspect quickly. That matters for governance because it turns phishing into a volume and realism problem at the same time. Practitioners should focus on preventing a single mistaken trust decision from becoming a broad access event.
From our research library:
- The IBM/Ponemon 2025 Cost of a Data Breach Report found that phishing-initiated breaches cost an average of $4.8M each.
What this signals
Trust-channel sprawl: phishing now spans inboxes, texts, QR codes, search, and video, so security teams need verification patterns that work consistently across all user-facing channels. The practical shift is from blocking messages to governing trust decisions wherever they happen.
Identity programmes should treat phishing resilience as a lifecycle problem, not a training problem. If recovery, approval, and device trust are weaker than primary authentication, attackers will keep using social engineering to route around the strongest control in the stack.
For practitioners
- Harden support and recovery workflows Require stronger verification for MFA resets, push approvals, and account recovery than the standard login path. Separate help desk identity proofing from user-facing authentication so an attacker cannot simply impersonate a legitimate employee.
- Apply deny-by-default to endpoints and devices Block untrusted software and restrict device access so a successful phish does not automatically translate into usable execution or privileged connectivity. Focus on reducing what can run and what can connect after initial compromise.
- Extend phishing controls beyond email Treat SMS, QR codes, search, collaboration tools, and video calls as part of the phishing control surface. Train users to verify context through an out-of-band channel when a request involves credentials, money, or access changes.
- Limit the blast radius of stolen sessions Use conditional access, least privilege, and device-aware policy so an active session cannot reach every internal system once the user has been tricked into approving access.
Key takeaways
- Phishing remains effective because it now exploits trusted workflows, not just obvious malicious emails.
- AI makes impersonation faster and more believable across multiple channels, which increases the chance that users will act before verifying.
- The most useful controls limit what a stolen trust event can reach, so one click, call, or approval does not become a full compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Phishing here is about abusing access decisions after trust is established. |
| Recommendation — Limit the reach of stolen sessions and approved access with least-privilege authorization. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article focuses on credential theft, MFA fatigue, and authentication abuse. |
| Recommendation — Strengthen authenticator lifecycle controls so stolen or abused credentials lose value quickly. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern centres on stealing credentials and using them to move through trusted systems. |
| Recommendation — Map phishing detections to credential access and lateral movement indicators in your monitoring stack. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Phishing is used here to capture credentials, tokens, and session material that function as secrets. |
| Recommendation — Treat exposed credentials and tokens as secrets leakage events and revoke them immediately. | ||
Key terms
- Business email compromise: A form of social engineering where an attacker impersonates a trusted person or domain to manipulate payment, change banking details, or extract sensitive information. It often succeeds without malware because the attacker targets process trust and human judgement instead of technical controls.
- MFA Fatigue Attack: An MFA fatigue attack is a social engineering technique that bombards a user with repeated authentication prompts until they approve one out of annoyance, confusion, or urgency. The attacker usually starts with stolen credentials, then uses the approval flow itself to obtain access.
- Vishing: Voice phishing is a social engineering technique that uses phone calls or voice channels to persuade a target to reveal information or approve access. It succeeds by exploiting trust, urgency, and procedural shortcuts, often bypassing technical controls that would have stopped a direct login attack.
- Zero Trust Access Management: Zero Trust access management is the practice of making every access decision explicit, contextual, and continuously reassessed. It replaces blanket trust in a network zone with identity, device, and risk-based policy that can change during a session. In mature programmes, it governs both human and non-human actors.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management. It helps security practitioners connect identity controls to the broader access risks that phishing can trigger.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org