Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› What should teams do first when a phishing…
Threats, Abuse & Incident Response

What should teams do first when a phishing email is clicked?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated November 9, 2026 Domain: Threats, Abuse & Incident Response

Isolate the affected device or session, disable the clicked link or attachment if possible, and reset the affected account with MFA reauthentication. Then review mailbox rules, token grants, and sign-in logs to confirm whether credentials, session cookies, or OAuth consent were exposed and revoke anything suspicious immediately.

Stop the bleed before you investigate

The first priority after a click is containment, not curiosity. Treat the endpoint, browser session, and mailbox as potentially compromised until you break the attacker’s path to the account and to any open sessions or delegated access. If the link or attachment is still reachable, disable or remove it so no one else can follow the same path.

Isolation matters because many phishing outcomes depend on more than a password. A valid session, a refresh token, or an OAuth grant can keep working after a password change, so the safe order is to interrupt live access first, then force a fresh, controlled sign-in path.

When the event involves a message rather than a device, a mailbox purge or tenant-side removal can be part of containment, but only after you preserve what you need for review. The useful question is whether the actor can still act, not whether the original email still exists.

What exposure to check immediately

After containment, teams should verify whether the click exposed credentials, session cookies, OAuth consent, or any mailbox automation that could forward, hide, or delete messages. That means reviewing sign-in activity, token grants, inbox rules, forwarding settings, and recent consent prompts for anything that the user did not intentionally create.

Pay special attention to changes that survive a password reset. New inbox rules, authorized app consents, or persistent sessions can keep the compromise alive even when the obvious secret has been changed, which is why the investigation has to include account state, not just the password itself.

If the phishing page asked for MFA, assume the attacker may have captured more than a single credential challenge. In practice, that can include replayable session material, consented API access, or a second-stage lure that reaches a different identity boundary than the one the user noticed first.

Why the first hour matters more than the first theory

The first hour is about shrinking blast radius, preserving evidence, and deciding whether the incident is only a click or already an account compromise. A fast reset without session revocation can leave active access in place; a slow investigation without containment can let the same actor keep reading mail, issuing new consents, or pivoting to other systems.

That is why phishing response has to be executed as an access-control problem, not just an email problem. The right sequence is to stop current access, remove any attacker persistence, and then determine whether there is any sign of lateral use of the account or mailbox.

For a practical playbook on that sequence, use the Phishing Incident Response Playbook as a containment-and-scoping reference, and the Phishing Guide for the attack patterns that most often determine what was clicked.

Risk and Threat Considerations

The main risk is that a single click can convert into durable access if the attacker obtains a live session, token grant, or mailbox rule rather than only a password. Once that happens, the compromise can persist silently even after the user believes the issue is fixed.

Failure mechanism: The attacker abuses whatever trust material the click exposed, then uses it to maintain access, bypass password-only recovery, or hide follow-on activity in the mailbox and sign-in trail.

Impact: Teams may face mailbox exfiltration, internal phishing from a trusted account, consent abuse, or wider account takeover across connected services.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, OWASP ASVS and CIS Controls v8 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5IA-5 — Authenticator ManagementPhishing clicks often expose or invalidate credentials and sessions.
IA-6 — Authenticator FeedbackClicked phishing often relies on deceptive credential collection flows.
AU-6 — Audit Review, Analysis, and ReportingSign-in logs and mailbox activity must be reviewed after a click.
Recommendation — Reset exposed credentials and revoke any active authenticator material promptly. Use clear authentication feedback to help users spot suspicious sign-in prompts. Review authentication and mailbox audit records for signs of abuse.
OWASP ASVSV6 — AuthenticationThe response depends on reauthentication after possible credential exposure.
V7 — Session ManagementSession cookies and active sessions may remain valid after a phishing click.
V10 — OAuth and OIDCOAuth consent grants can be abused during phishing incidents.
Recommendation — Require reauthentication after suspected credential or session compromise. Invalidate existing sessions and require fresh session establishment. Review and revoke suspicious OAuth consents and app grants.
MITRE ATT&CKT1566 — PhishingThe question is about response after a phishing click, an ATT&CK technique.
Recommendation — Map the incident to phishing technique handling and containment steps.
CIS Controls v8CIS-5 — Account ManagementClicked phishing can create unauthorized account access and persistence.
CIS-8 — Audit Log ManagementMailbox rules, token grants and sign-in logs are essential evidence.
Recommendation — Remove unauthorized access and review account changes immediately. Collect and review logs that show authentication and mailbox changes.

Practitioner Guidance

What to prioritise: Containment first, investigation second. If you can only do one thing immediately, revoke the attacker’s current access path, then reset the account and require MFA reauthentication before anyone treats the user as safe again.

What to verify: Check whether the mailbox has new forwarding rules, suspicious OAuth consents, unfamiliar device sessions, or recent token grants that survive the password reset. Those are the common indicators that the click created persistence, not just exposure.

Decision rule: If the user clicked and entered anything, assume the account boundary may already be crossed and escalate to session revocation plus consent review. If nothing was entered and the click was blocked, containment may be narrower, but the sign-in and mailbox checks still need to happen.

Practitioner takeaway: The first response is not “did the user enter a password”, it is “what access still works right now”, because live sessions and delegated grants are often the real compromise path.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org