A common mistake is relying only on message filtering and ignoring behavioural signals after delivery. Sophisticated spear phishing can arrive through spoofed domains, thread hijacking, or convincing pretexts that look routine. Teams should watch for unusual requests, abnormal payment changes, unexpected credential prompts, and access patterns that do not match normal user behaviour. Detection works best when people, email controls, and monitoring are aligned.
Why Teams Miss Spear Phishing in Live Email and Identity Systems
Spear phishing is often treated as an email-filtering problem, but that misses the part attackers actually exploit: trust relationships. Once a message lands, the real risk shifts to identity, session handling, and downstream actions such as mailbox access, token theft, MFA fatigue, or fraudulent payment changes. Guidance from the NIST Cybersecurity Framework 2.0 is useful here because detection has to support response across multiple control layers, not just the inbox.
That is why NHI Management Group keeps emphasising the operational side of compromise. In its Ultimate Guide to NHIs, one of the clearest signals is that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. For email-driven intrusion paths, that matters because spear phishing often aims to steal the account or the delegated access behind it, not just trick someone into clicking once.
Teams get this wrong when they assume a clean message verdict means a clean environment. In practice, many security teams encounter the compromise only after an attacker has already used valid identity paths to blend into normal business activity.
How Detection Works Across Email, Identity, and Behaviour
Effective spear phishing detection is a chain, not a single alert. Email telemetry should identify suspicious sender reputation, domain lookalikes, thread hijacking, and anomalous links or attachments. Identity telemetry then checks whether the message was followed by unusual authentication events, MFA prompts, OAuth consent abuse, inbox rule creation, or impossible travel. Finally, behavioural monitoring looks for requests that do not match the user’s normal role, such as a finance user suddenly changing supplier banking details or an admin account initiating unusual mailbox searches.
The practical model is to correlate the message with what happened next. If a user received a plausible request and then authenticated from a new device, granted mailbox delegation, or forwarded sensitive mail externally, the security story is no longer just “phishing delivered.” It is “phishing translated into identity abuse.” The NIST SP 800-53 Rev. 5 Security and Privacy Controls gives teams a control vocabulary for logging, access enforcement, and incident handling, while the 52 NHI Breaches Analysis is a useful reminder that identity misuse is often the real impact path after initial compromise.
- Alert on mailbox rule changes, token grants, and forwarding that appear shortly after a suspicious message.
- Compare payment, vendor, and credential-change requests against established user and workflow patterns.
- Correlate email events with identity events so a benign-looking message is not treated as low risk in isolation.
- Watch for unusual access from the same account across email, SaaS, and identity provider logs.
These controls tend to break down in environments with fragmented logging, weak identity telemetry, or outsourced mailbox administration because the attack’s post-delivery behaviour cannot be correlated quickly enough.
Where the Standard Playbook Breaks Down
Tighter detection often increases alert volume and investigation cost, requiring organisations to balance coverage against analyst fatigue. That tradeoff is especially sharp when phishing attempts are highly targeted, because standard reputation-based scoring can miss one-off domains and carefully timed thread hijacks. Current guidance suggests prioritising context over volume, but there is no universal standard for exactly how much behavioural scoring should outweigh message-level filtering.
Edge cases matter. Executive impersonation campaigns may succeed without malware, relying only on convincing language and timing. OAuth consent phishing can bypass classic email attachment rules entirely. Shared mailboxes, delegated access, and service accounts also complicate attribution, because the suspicious action may not be tied to the person who clicked the message. This is where the NHI perspective is valuable: identity paths are often longer-lived than the phishing lure itself, so detection must watch for durable access changes, not just the initial lure. The Top 10 NHI Issues is relevant because excessive privilege and weak rotation make post-phish abuse easier to sustain.
Best practice is evolving toward continuous correlation across email, identity, and session telemetry rather than a single “phish detected” verdict. In practice, teams usually discover the gap after a user account has already been used to move laterally, issue fraudulent requests, or expose downstream secrets.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-1 | Continuous monitoring supports correlation of email, identity, and behaviour signals. |
| NIST SP 800-63 | Phishing often targets authenticators, sessions, and recovery flows. | |
| NIST AI RMF | Risk governance applies when detection depends on dynamic, context-based judgment. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Compromised service accounts and tokens often extend phishing impact. |
| CSA MAESTRO | Agentic workflows and delegated access broaden phishing blast radius. |
Track suspicious email plus identity events together and escalate when patterns diverge from normal use.
Related resources from NHI Mgmt Group
- What do teams get wrong about monitoring privileged sessions in OT environments?
- What do security teams get wrong about workload identity in cloud and CI/CD environments?
- What do security teams get wrong about identity visibility in modern environments?
- What do identity teams get wrong about phishing in verification journeys?
