What should organisations do first when BEC and phishing remain the top entry points?

The first step is to make account takeover harder before tuning detection. Enforce MFA everywhere, disable legacy protocols such as IMAP and POP3, and apply conditional access for risky logins. For high-value apps, add phish-resistant MFA and app-level prompts so stolen credentials alone are less useful to an attacker.

Why this should be the first move

When BEC and phishing are still the dominant entry paths, the immediate priority is to make stolen credentials less usable. That means tightening the authentication and session boundary before spending time on more refined detection tuning. If an attacker can log in with legacy protocols, weak MFA coverage, or permissive conditional access, they often do not need to be especially sophisticated to succeed.

The practical goal is to reduce the value of initial access. Enforcing MFA everywhere, blocking protocols that bypass modern authentication, and requiring stronger checks for risky sign-ins all shrink the number of paths that lead from a phish to a mailbox, SaaS console, or admin workflow.

Account takeover is also where BEC starts to scale. Once an attacker can reuse a valid session or authenticate to an inbox, they can monitor conversations, redirect payments, reset passwords, and stage further fraud. That is why hardening the first login step is usually higher leverage than trying to detect every malicious message after delivery.

This is especially true when mail systems, cloud consoles, and finance workflows still accept older authentication methods or broad token reuse. Controls that raise the cost of reuse, such as phish-resistant MFA on sensitive apps, reduce the chance that one successful lure becomes a business-wide compromise.

For examples of how credential abuse turns into real compromise, see TruffleNet BEC Attack, Stolen AWS Credentials and MailChimp Breach.

Controls that change the outcome fastest

Enforce MFA across all reachable user and admin entry points, then close the protocols and sign-in paths that let attackers bypass it. Legacy IMAP and POP3 are common examples because they can preserve password-based access even after stronger interactive login controls are introduced.

Apply conditional access to risky logins so the control decision is based on context, not just on whether a password matched. That lets organisations force additional friction when a sign-in comes from unfamiliar locations, devices, impossible travel, or other suspicious conditions.

For high-value applications, use phish-resistant MFA and app-level prompts. This matters because generic MFA can still be socially engineered or replayed in some scenarios, while stronger authenticators make credential theft alone much less profitable.

Phishing often succeeds by exploiting the gap between initial authentication and downstream trust. The best first-line controls reduce that gap by making a stolen password, token, or session less likely to translate into durable access.

For deeper guidance on the control pattern itself, consult NIST SP 800-63 Digital Identity Guidelines, NIST SP 800-207 Zero Trust Architecture, and NIST Cybersecurity Framework 2.0.

A useful supporting statistic is that NHI Mgmt Group’s Ultimate Guide to NHIs reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is a reminder that password-centric abuse is often amplified by weak secret handling elsewhere in the environment.

Risk and Threat Considerations

When BEC and phishing are the main entry points, the risk is not only message compromise, but account compromise that survives the initial lure. Once an attacker gains valid access, they can operate inside normal business workflows, which makes fraud, mailbox rules abuse, token theft, and follow-on impersonation materially harder to spot.

Failure mechanism: Legacy protocols, weak MFA coverage, or permissive access policies let a stolen password, token, or session become a working login, even when the original phishing message was crude.

Impact: The attacker can bypass detection-oriented controls and move from inbox access to payment diversion, internal impersonation, or wider cloud and SaaS compromise.

Standards & Framework Alignment

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

NIST SP 800-63, NIST Zero Trust (SP 800-207), NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL — Authenticator Assurance Levels	Defines stronger authenticator requirements for phishing-resistant login assurance.
Recommendation — Require phishing-resistant authenticators for high-value access paths.
NIST Zero Trust (SP 800-207)	5.2 — Policy Decision Point	Uses contextual access decisions to gate risky logins and reduce trust in default access.
Recommendation — Apply contextual policy decisions to challenge risky sign-ins.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	Covers authentication and access controls that reduce account takeover risk.
Recommendation — Strengthen authentication controls and disable bypassable access paths.
CIS Controls v8	6 — Access Control Management	Supports removing unnecessary access paths and tightening account authentication.
Recommendation — Remove legacy access methods and enforce least-privilege authentication.

Practitioner Guidance

What to prioritise: Start with the highest-value accounts and the authentication paths most likely to be abused, especially email, finance, help desk, and admin roles. If those paths still allow password-only or legacy access, the organisation has not yet addressed the main failure mode.

Decision rule: If a login method can be used without phishing-resistant MFA, treat it as a candidate for removal or restriction before you invest in deeper alert tuning. Detection improves response, but it does not stop an attacker who can repeatedly authenticate.

What to verify: Confirm that risky-login policies actually trigger on the identities and apps that matter, that legacy protocols are disabled where possible, and that high-value applications require the strongest available authentication path.

Practitioner takeaway: The right first step is to narrow the attacker’s usable authentication surface, because that directly reduces both the probability and the blast radius of BEC.