Phishing-resistant MFA on every privileged account

What the control is

Every account with privilege — and the definition of privilege has to be wider than the IT org’s instinct — authenticates with a phishing-resistant factor. That means a hardware security key (YubiKey, Feitian, Google Titan, Apple Secure Enclave) or a platform authenticator backed by WebAuthn (Windows Hello, Touch ID, Android biometric). Not SMS one-time codes. Not authenticator-app codes that the user can be talked into reading aloud. Not push notifications that a tired admin will eventually accept.

“Privileged” in the way regulators use the word is wider than “IT admin.” NCSC, NIST and CIS all extend privilege to any account that can read a population of customer or employee records, change identity-system configuration, deploy code, or move money. In practice that pulls in HR-system admins, CRM admins, payroll administrators, financial-controller accounts, cloud-tenant root, code-repo owners, and anyone whose support role lets them export data on a customer’s behalf. The Salesforce contact-centre operator at the centre of the Qantas breach was a privileged account by this definition, even though the airline’s IT org would not have called them one.

Why it matters

The single most common entry technique in the catalogue is credential theft followed by a single-factor or weak-factor logon. Phishing-resistant MFA breaks the chain at that step regardless of how the credential was stolen. It doesn’t matter whether the password came from an infostealer log on a personal laptop, a successful spear-phishing landing page, a vishing call to a helpdesk, an MFA-fatigue prompt, or an OAuth-token theft. The hardware-bound private key never leaves the authenticator, can’t be phished, can’t be relayed through an attacker-in-the-middle proxy, and can’t be socially engineered out of a tired user.

The catalogue makes the case unusually concrete. Wynn Resorts (employee credential into PeopleSoft, 800,000 records). Pitney Bowes (phishing-stolen email account into Salesforce, 8.2 million records dumped). Carnival’s Mariner Society programme (single phishing-compromised user, 7.5 million emails). The MGM and Caesars ransomware events of September 2023 (vishing of helpdesks for password resets). The 2024 Snowflake-customer wave (infostealer credentials harvested from contractor home machines, then walked into customer Snowflake tenants without MFA). Uber’s 2022 breach (Lapsus$ pushed an MFA prompt repeatedly until the contractor accepted it). LastPass (a DevOps engineer’s home device, then onward into the vault backup). Each of those chains has one step in common where a phishing-resistant factor would have stopped the attacker cold.

Where the regulators sit

NCSC’s published position is that passkeys and hardware keys should be the default, not an option, with SMS as an explicitly deprecated fallback. NIST SP 800-63B classifies MFA into Authenticator Assurance Levels and reserves AAL3 — the level required for federal high-value access — for cryptographic hardware authenticators or software authenticators that cannot be cloned. CISA published a 2022 fact sheet titled “Implementing Phishing-Resistant MFA” in plain language for federal agencies and has repeated the recommendation in every joint cybersecurity advisory since. CIS Controls v8 makes phishing-resistant MFA an explicit requirement under Control 6 for any account that can administer systems or access sensitive data. The Australian Essential Eight gives phishing-resistant MFA its own maturity-level escalation: SMS at level 1, app codes at level 2, hardware keys or platform authenticators at level 3.

There is no serious disagreement across the major frameworks. The argument has been won.

Where it usually breaks

Three places. First, scope creep on what counts as “privileged” — IT defines it narrowly, the attacker defines it broadly, and the gap between those two definitions is where most breaches start. The fix is to push the privilege definition up to the data-classification scheme: any account that can bulk-read a customer-data object is privileged, period. Second, helpdesk recovery flows. Hardware-key MFA is only as strong as the process that re-issues a key when an admin loses theirs. The MGM and Caesars events both pivoted on vishing the helpdesk during recovery, not on the front-door logon. The fix is a hardware-attested recovery path — government-ID verification, in-person hand-off, or a known supervisor’s countersignature — not a phone call. Third, contractor populations. Internal full-time staff get hardware keys; contractors at outsourced support providers often don’t, because the hardware-key budget lives with the contracting firm. Wynn, Qantas, Coinbase 2024 and the broader Salesforce contact-centre cluster all pivot on this gap. The fix is a contractual requirement that contractor populations with privileged access are issued and enforced on the same authentication standard as employees, paid for by the customer if necessary. £40 a key is cheaper than every breach in this list.

What good looks like

Every cloud-tenant root account uses a hardware key with a paper-based recovery code stored in a sealed envelope in a physical safe. Every Active Directory domain-admin account uses a hardware key bound to a privileged-access workstation. Every HR-system, CRM and finance-system administrator uses a hardware key, with a recovery flow that requires in-person re-attestation. Every bulk-export query on customer-record systems is gated behind a separate re-authentication step using the same factor. The cost is the hardware. The lift is the policy work to define “privileged” wide enough to catch the contact-centre operator, the contractor sysadmin, and the data engineer who wrote a Salesforce query that returns 5.7 million rows.

The regulators agree. The catalogue is the receipts.