What should security teams do first when phishing keeps leading to account takeover?

Why This Matters for Security Teams

Phishing-driven account takeover is not just a user-awareness problem. It is an identity control problem that starts when an attacker reuses stolen credentials, bypasses weak second factors, or moves through sessions that remain trusted after the initial click. Security teams should prioritize the journeys that can cause the most damage, then harden authentication at those points so a single phished login does not become persistent access.

That shift matters because real-world takeover often follows a chain: password reuse, token replay, mailbox access, SaaS privilege escalation, and then lateral movement into other systems. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames authentication as one control among several, not the whole answer. In NHI security research, NHI Management Group found that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that attackers rarely stop at one account once they have valid access.

In practice, many security teams discover the real exposure only after a mailbox, VPN, or SaaS admin account has already been used to pivot into higher-value systems.

How It Works in Practice

The first move is to map the highest-risk login journeys, not every account equally. That usually means privileged users, finance, executives, help desk, and any application that can be used to reset passwords, approve transactions, or grant access elsewhere. Once those journeys are known, replace phishable factors with phishing-resistant authentication such as FIDO2/WebAuthn where possible, then pair that with adaptive step-up checks for unusual devices, locations, or behaviour.

This works best when authentication is treated as a runtime decision, not a one-time gate. A user who logs in from a normal device may get seamless access, while the same user from a new geolocation or impossible travel pattern gets challenged. For higher-risk actions, add step-up controls at the transaction layer as well, not just at sign-in. That reduces the chance that a stolen session can be used to alter MFA settings, create forwarding rules, or add new recovery methods.

• Start with accounts that can approve, reset, or delegate access.
• Use phishing-resistant MFA for those journeys first.
• Trigger step-up checks on anomalous sign-ins and risky actions.
• Review whether session duration, token reuse, and recovery flows are undermining the login control.

Training still has value, but it should reinforce controls that continue working after a user clicks. A good awareness program helps, yet it cannot be the primary defence when an attacker can replay credentials or steal a session token. For examples of how attackers exploit trusted identity paths, see NHIMG’s coverage of the Meta AI Instagram Account Takeover and the CoPhish OAuth Token Theft via Copilot Studio incidents. These controls tend to break down in legacy environments where older protocols, shared inboxes, or long-lived sessions prevent strong authentication from being enforced consistently.

Common Variations and Edge Cases

Tighter authentication often increases user friction and support overhead, so teams need to balance resilience against operational load. Best practice is evolving, but there is no universal standard for how quickly every step-up should fire or how much context is enough before a challenge is justified.

Some environments need special handling. Help desk workflows can become an ATO target if password reset and MFA reset paths are weaker than primary login. Service portals may need separate rules because contractors, partners, and customers have different risk profiles. High-availability operations also need fallback methods that do not reintroduce phishable factors just to keep access convenient. If the organisation uses legacy IMAP, POP, basic auth, or shared service accounts, the first fix may be to remove those paths entirely before authentication can be meaningfully improved.

Current guidance suggests that the fastest reduction in takeover risk comes from closing the most abusable paths first, then tightening recovery, session, and privilege workflows. In other words, the goal is not simply to make login harder. It is to make stolen credentials far less useful once they are obtained.

Related resources from NHI Mgmt Group

• How should security teams reduce account takeover risk from phishing sites?
• How do security teams know if internal phishing is spreading beyond the first account?
• How should security teams defend against AI-generated phishing, BEC, and account takeover in inboxes that look legitimate?
• How should security teams reduce phishing and account takeover risk after a third-party analytics breach exposes user profile data?