Teams miss the point where a reported email becomes a real incident. Delivery tells you only that the lure arrived. The risk changes when someone interacts, enters credentials, or authorises access, because then the investigation has to expand into identity, session, and mailbox governance to understand the blast radius.
When a phish is delivered, what is still unknown?
Message delivery only proves exposure, not compromise. A phishing report is still a triage event until you know whether the recipient clicked, entered credentials, approved a prompt, opened a malicious attachment, or handed over a session. The investigation has to move from email hygiene into identity, access, and mailbox impact as soon as interaction is possible.
That shift matters because the same lure can end as a harmless delivery event or a full account compromise. The difference is not the inbox entry itself, but whether the message created a path into authentication, privileged access, or downstream persistence.
What changes once the recipient interacts?
The key inflection point is recipient action. If the user only received the message, the team is dealing with content, filtering, and awareness. If the user clicked, authenticated, approved access, or reused a password, the question becomes whether the attacker obtained a foothold that can be replayed, escalated, or used to impersonate the user elsewhere.
At that point, the investigation should widen to include credential exposure, session validity, mailbox rules, forwarding changes, and any tokens or OAuth grants created during the interaction. That is why a delivered phish can no longer be treated as a mail problem once the lure has crossed into authentication or authorisation.
For example, phishing that leads to token theft or consent abuse can bypass password resets unless the affected sessions and grants are explicitly reviewed. Cases such as CoPhish OAuth phishing via Copilot Studio show how a user interaction can convert a message into a credential and token problem, while Dropbox GitHub breach 2022 illustrates how phishing can lead to broader repository and secret exposure after the initial account access.
Why mailbox and identity scope are the real blast-radius questions
Once a phish becomes interactive, the next issue is scope. A compromised inbox can be used to search for reset links, pivot into internal trust relationships, and silently maintain access through forwarding rules or delegated mailbox access. That is why the right investigation is not just “was the email delivered?”, but “what did the actor gain after delivery?”
Mailbox governance matters because email is often the first authenticated workspace an attacker can turn into a control plane. If the account was accessed, teams should assume that message history, internal contacts, and any linked services may be exposed until proven otherwise. In parallel, identity governance must check whether the user’s session, MFA state, and any third-party app grants still represent active trust.
Delivery-only analysis also misses cases where the phish targets secrets rather than credentials. Attackers may use a fake login page, a consent screen, or a malicious attachment to reach other systems. The mailbox then becomes the pivot point, not the endpoint, and incident handling must follow the trust chain outward.
Risk and Threat Considerations
Stopping at delivery creates a false sense of containment. The main danger is that an email campaign may already have progressed into credential theft, session hijack, mailbox rule abuse, or unauthorised access to connected services before the report is even triaged.
Failure mechanism: The investigation ends before it checks for user interaction, so indicators of compromise such as sign-ins, token use, inbox rule changes, or consent grants are never validated.
Impact: Attackers can retain access after the message is removed, reuse stolen sessions or credentials, and spread laterally through mailbox trust, cloud apps, or downstream accounts.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Phishing often turns on stolen or replayed authenticators and session material. |
| AU-6 — Audit Review, Analysis, and Reporting | Phish investigations rely on correlating mailbox, sign-in, and consent activity. | |
| AC-2 — Account Management | A delivered phish becomes an access problem when accounts, grants, or delegates are abused. | |
| Recommendation — Review and rotate compromised authenticators and revoke related sessions immediately. Correlate sign-in, mailbox, and token events to confirm whether delivery became compromise. Review account status, delegated access, and unexpected privilege changes after user interaction. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Credential or consent phishing undermines identity assurance and should trigger stronger checks. |
| Recommendation — Use stronger verification when a reported phish may have compromised identity proofing confidence. | ||
Practitioner Guidance
What to verify: Treat “delivered” as the starting point, not the conclusion. Verify click activity, authentication events, mailbox rule changes, forwarding configuration, and any new app consents or token issuance tied to the recipient account.
Decision rule: If the message prompted any interaction that could authenticate the user or authorise access, escalate the case from email handling to identity and access response. If there was no interaction, keep the response focused on mail controls, user notification, and campaign suppression.
What good looks like: A mature workflow can answer, for each reported phish, whether the event stopped at delivery, crossed into authentication, or created a persistent access path. That distinction should drive whether the response ends with removal and blocking or continues into credential rotation, session review, and mailbox governance.
Practitioner takeaway: Delivery is only the exposure signal. The real incident begins when the message changes who can authenticate, what can be accessed, or what trust the attacker can reuse.
Related resources from NHI Mgmt Group
- What breaks when organisations still allow macro-enabled attachments in phishing delivery chains?
- What breaks when phishing filters rely on static message signatures?
- What breaks when phishing delivery uses trusted redirect chains instead of obvious malicious URLs?
- What breaks when identity governance stops at login events?