What breaks when phishing detections are built only around traditional email and network signals?

Why This Matters for Security Teams

Phishing detection that relies only on email headers and network telemetry assumes the attack must look like a classic message-delivery problem. That assumption fails as soon as adversaries move through collaboration apps, identity provider abuse, QR codes, browser sessions, or legitimate cloud infrastructure that never trips a mail gateway. Current guidance from NIST Cybersecurity Framework 2.0 pushes teams toward broader detection and response outcomes, because the control objective is not “catch all bad email” but “recognise malicious intent across the full attack path.”

This matters because modern phishing is often less about spoofed infrastructure and more about abusing trust after the first contact. Identity is now the primary control plane, so if detections stop at the inbox or perimeter, security teams miss the moment when a user authenticates into a fake app, approves a malicious consent grant, or hands over a session token. That is why NHI governance now overlaps with phishing defence, especially when attackers target tokens, API keys, and other secrets rather than just passwords. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames how identity sprawl expands the places attackers can hide.

In practice, many security teams discover the gap only after a user has already authenticated to the wrong service, rather than through intentional detection design.

How It Works in Practice

Modern phishing detection needs to correlate signals from delivery, identity, endpoint, browser, and SaaS layers. A single email verdict is too narrow. Instead, defenders should look for the chain: initial lure, suspicious authentication flow, unusual consent grant, anomalous token use, and post-click actions such as mailbox rules, OAuth abuse, or lateral movement into cloud services. The operational model is closer to NIST SP 800-207 Zero Trust Architecture than to legacy gateway filtering, because trust must be re-evaluated at each request.

A practical program usually includes:

• Identity provider telemetry for impossible travel, MFA fatigue patterns, consent grant anomalies, and token replay.
• Browser and endpoint signals for suspicious redirect chains, credential harvesting pages, and session hijack behaviour.
• Cloud and SaaS audit logs for mailbox rule creation, inbox forwarding, privileged app registration, and API abuse.
• Detection content that links phishing events to downstream actions instead of treating the click as the finish line.

NHIMG’s Top 10 NHI Issues is relevant because many phishing campaigns now pivot from human credentials to non-human tokens once the initial account is compromised. That is where NIST SP 800-53 Rev. 5 Security and Privacy Controls becomes useful for mapping logging, least privilege, and incident response requirements across multiple telemetry sources.

These controls tend to break down in organisations that cannot centralise identity and SaaS logs, because the attack chain is fragmented across systems that do not share a common event model.

Common Variations and Edge Cases

Tighter phishing detection often increases operational overhead, requiring organisations to balance broader visibility against alert volume and engineering effort. That tradeoff becomes sharper when users authenticate through mobile apps, third-party identity brokers, or external collaboration tools, because the signal is real but the context is messy. There is no universal standard for this yet, but current guidance suggests prioritising detections that validate the full identity journey rather than just message content.

Two edge cases matter most. First, phishing may arrive through legitimate platforms that pass email security checks, such as shared document links, calendar invites, or helpdesk impersonation. Second, an attack can succeed without a click in the traditional sense if the user approves an OAuth grant or reuses an exposed session. NHIMG’s CoPhish OAuth Token Theft via Copilot Studio illustrates how identity-based abuse can bypass email-centric assumptions entirely, while the DeepSeek breach shows why secret exposure and downstream misuse must be part of the detection model.

For practitioners, the key distinction is simple: if a control only sees the lure, it will miss the compromise path. If it sees identity, token use, and post-auth behaviour, it can still catch the attack even when no malicious email is present.

Related resources from NHI Mgmt Group

• What breaks when DLP is still built around endpoints and email gateways?
• What breaks when detections are built around vendor coverage instead of attacker behaviour?
• What breaks when AI governance is built only around approved tools?
• What breaks when GRC architecture is built around periodic reviews only?