MFA for admin access: the baseline that is no longer optional

The carve-out that survived for two decades was that internal users on the corporate network did not need a second factor. The corporate network was the perimeter; the perimeter was the trust boundary; once inside, an authenticated session was enough. That model is gone. Every major framework now in force has removed the internal-users exemption, and most have removed the administrative-access exemption too. Multi-factor authentication is required on every login path, for every user, including federated identity providers, service accounts, and recovery flows. The companion article on framework convergence walks through the calendar of when each framework moved. This piece is the architectural detail underneath.

The shift is the easy part of the story. The harder part is that "MFA" as commonly implemented in 2026 still includes factors that the same regulators now consider weak. Time-based one-time passwords delivered to an authenticator app. SMS codes. Push notifications without number-matching. Each is bypassable at scale, and each has been bypassed at scale in the named breaches of the last three years. The framework expectation has moved past "do you have MFA" to "do you have phishing-resistant MFA", and the cryptographic distinction between those two phrases is what determines whether a platform passes the 2026 audit posture.

This article walks through the cryptographic difference, the framework-by-framework specificity of what is now required, the real-world failure modes that map to predictable architectural gaps, and the four weak spots that most platforms still leave open.

The cryptographic distinction that decides everything

"Phishing-resistant" has a formal definition in NIST SP 800-63B-4, the August 2025 final publication of the federal authenticator guidelines. Section 4.1.5 sets out four cumulative requirements. First, verifier-impersonation resistance: the authenticator cryptographically binds its response to the verifier's origin, so an adversary-in-the-middle proxy cannot relay the response. Second, replay resistance: each authentication uses a fresh nonce or challenge. Third, a non-exportable authentication secret: the private key cannot leave its hardware boundary. Fourth, explicit user intent: the user must perform an action that signals consent for this authentication, not be auto-approved.

The cleanest way to see what this means is to compare TOTP, push, and FIDO2/WebAuthn against the four tests.

A time-based one-time password is a six-digit number derived from HMAC-SHA1(shared_secret, time_window). It is not bound to who is asking. A user who lands on accouts-google.com, a typosquatted phishing page, and enters their TOTP, has handed the attacker a code the attacker can replay to the real accounts.google.com within the thirty-second validity window. TOTP fails the verifier-impersonation resistance test. It is MFA, but it is not phishing-resistant MFA.

A push notification with tap-to-approve is even weaker if number-matching is not enforced. The push message carries no proof that this approval is for this login attempt. An attacker who has the username and password can spam push prompts until the user taps yes, which is exactly what happened in the Uber 2022 breach. Push with number-matching narrows the window because the user has to enter a number shown on the login screen into their authenticator app, but the user is still the one binding "the number on screen" to "the number on phone", and an attacker can race a login with the legitimate user's expected login. Microsoft enabled number-matching by default in February 2023 and no longer offers push without it; the underlying point is that push approval alone is not cryptographically bound to the verifier.

FIDO2 with WebAuthn passes all four tests. Registration generates a fresh key pair on the authenticator (hardware-bound for security keys; bound to the secure element on iOS or Android for platform authenticators). The private key never leaves the secure element. At authentication time, the relying party sends a challenge plus its rpId (its origin). The browser provides the authenticator with the actual origin the user is on, and the authenticator signs a transcript that includes the challenge and that actual origin. The relying party verifies the signature with the public key it stored at registration. The user has to touch the security key (explicit intent). The signature is over the origin the browser observed, which means the signature an attacker harvests at accouts-google.com will not verify at accounts.google.com because the origin in the signed transcript is wrong. This is verifier-impersonation resistance in cryptographic form, not policy form.

The same property holds for PIV smart cards under the FIPS 201 specification: a TLS client-authentication or Kerberos PKINIT exchange signs the challenge with the private key stored in the card's tamper-resistant secure element, where the certificate identifies the origin. CISA's October 2022 phishing-resistant MFA factsheet is direct on this point: "the only widely available phishing-resistant authentication is FIDO/WebAuthn authentication and Public Key Infrastructure (PKI)-based authentication". Every other factor fails one of the four 800-63B-4 tests.

What the major frameworks now require

The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.

NIST SP 800-63B-4 (United States, August 2025). The final publication moved several things from "deprecated" to "restricted at every Authenticator Assurance Level". SMS and PSTN-based out-of-band authenticators are now restricted at AAL1, AAL2, and AAL3; use requires a risk assessment, user notification, and a migration plan, and the credential service provider must offer a non-restricted alternative. Email is explicitly not an out-of-band channel. AAL2 must offer at least one phishing-resistant option even if it is not the default. AAL3 requires a hardware-bound authenticator with verifier-impersonation resistance and a non-exportable private key; syncable passkeys (whose private key can be copied between devices via end-to-end encrypted sync) qualify for AAL2 but not AAL3.

NIST SP 800-53 Rev 5 (United States federal). The IA-2 family is the canonical control set: IA-2(1) MFA for privileged accounts (Low/Moderate/High in FedRAMP baselines), IA-2(2) MFA for non-privileged accounts (Moderate/High), IA-2(5) prohibits undifferentiated shared accounts, IA-2(6) requires the second factor to be on a separate device or cryptographically isolated channel, IA-2(8) replay-resistant authentication, IA-2(12) acceptance of PIV credentials for federal employees and contractors. FedRAMP's Phishing-Resistant MFA Memo of April 2024 instructs 3PAOs to assess phishing resistance against the 800-63B-4 §4.1.5 definition, treating the cumulative test as the bar.

OMB M-22-09 (United States federal, January 2022). Action 3 required all federal civilian agencies to mandate phishing-resistant MFA for staff, contractors, and partners by the end of fiscal year 2024 (30 September 2024). Action 4 required agencies to offer phishing-resistant MFA as an option for public-facing systems. Footnote 11 names PIV and WebAuthn as the qualifying mechanisms. The memo states directly that MFA via SMS, voice, and one-time password is not sufficient for the federal zero-trust target. CISA's May 2024 Secure-by-Design Pledge, signed by 200-plus vendors including Microsoft, Google, AWS, IBM, Cisco, and Okta, committed signatories to measurably increase MFA use across their products within one year of signing, with explicit emphasis on default-on MFA.

PCI DSS 4.0.1 (international, payments). Requirement 8 carries the bulk of the MFA detail. 8.4.1 requires MFA for all non-console administrative access to the cardholder data environment (carried from 3.2.1). 8.4.2, mandatory since 31 March 2025, requires MFA for all access into the cardholder data environment, not just administrative; developers, support engineers, third parties, and query users are in scope by default. 8.4.3 requires MFA for all remote network access originating outside the entity's network that could reach the cardholder data environment. 8.5.1, also mandatory since 31 March 2025, sets four cumulative system-configuration requirements: replay-resistant, no bypass by any user including administrators except by explicit time-limited documented exception, at least two different factor types, and success of all factors required before access. The (b) and (d) clauses together explicitly forbid fallback flows that admit a user when the second factor is unavailable. Requirement 8.6 addresses interactive use of system, application, and service accounts: must be managed, must not have hardcoded credentials in scripts or configuration files, and must have password rotation based on a documented risk analysis.

ISO 27001:2022 (international). Annex A.5.17 covers authentication information lifecycle; A.8.2 restricts privileged access rights with MFA explicitly recommended in ISO 27002:2022 paragraph 8.2; A.8.5 Secure Authentication makes the MFA recommendation explicit in the control text itself, with the implementation guidance in ISO 27002:2022 paragraph 8.5 calling for cryptographic, smart-card, token, or biometric authentication for high-risk systems and instructing implementers not to reveal which factor failed during a failed login. The 2013-to-2022 transition window closed on 31 October 2025, leaving only 27001:2022 with its explicit MFA expectations.

SOC 2 (United States, AICPA). The 2022 revised points of focus for CC6.1 added explicit reference to multi-factor authentication for remote and privileged access, and CC6.1 points of focus now also call out service account and machine-to-machine authentication. CC6.6 boundary protection translates in practice to MFA on any externally reachable administrative interface. Auditor expectations in 2024 through 2026 have hardened on two specific points: shared administrative accounts are flagged as a control deficiency unless individual accountability is demonstrated, and MFA at the federation identity provider is no longer sufficient evidence on its own. Auditors now test the configuration of the relying party to confirm it would actually reject a login that did not assert an MFA claim, because relying parties that fail to check the amr and acr claims from the IdP admit weak-factor sessions to protected resources.

NIS2 directive (European Union). Article 21(2)(j) explicitly mandates "the use of multi-factor authentication or continuous authentication solutions" as a minimum cybersecurity measure. The Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 details the technical requirements in Annex point 6.7 Authentication: MFA or equivalent strong authentication for privileged accounts, accounts performing administration on network and information systems, remote access, access to sensitive data, and access to administrative interfaces. The "continuous authentication" language is one of NIS2's distinct contributions and refers to ongoing post-login verification through behavioural analytics, device-binding trust signals, and session anomaly detection. ENISA's Technical Implementation Guidance points to phishing-resistant MFA as the default for high-risk roles, citing FIDO2/WebAuthn and PKI-based authentication as the qualifying technologies.

HIPAA Security Rule (United States healthcare). The December 2024 NPRM, published in the Federal Register on 6 January 2025, proposes the most significant rewrite since 2003. The "addressable" versus "required" distinction is eliminated; proposed section 164.312(d) explicitly requires multi-factor authentication for access to ePHI and for any action that affects security configuration, privileged access, or backup and recovery functions. The proposed rule references NIST SP 800-63B for technical guidance on authenticator strength. The compliance window is 180 days after the final rule publishes; comments closed in March 2025, with the final rule anticipated in 2026.

FINMA (Switzerland). Circular 2023/1 on operational risks and resilience, in force since 1 January 2024, expects authentication methods commensurate with risk, with strong authentication for privileged users and remote access. Annex 3 extends the expectation to cloud service providers used by Swiss banks, who must demonstrate MFA enforcement equivalent to the bank's own. FINMA Guidance 05/2025, effective 1 January 2026, names phishing-resistant MFA as the expectation for system administrators and any access path that could reach customer data or core banking systems. The Q1 2025 risk monitor flagged MFA on operator and developer accounts at outsourced cloud platform providers as a recurring gap.

ADHICS V2 (United Arab Emirates). The Abu Dhabi Department of Health standard mandates MFA for all PHI access, not just administrative, regardless of internal or external origin. Phishing-resistant authentication is named as the preferred approach for clinical operator accounts and administrators. AC 3.7 requires session timeouts and re-authentication for sensitive operations. Shared accounts are prohibited; every PHI access requires unique identity plus a second factor, including from inside the trusted network.

SAMA (Saudi Arabia). The Cyber Security Framework Domain 3.3.5 requires MFA enforcement based on policies whose granularity considers user, group, organisational unit, session, device, location, and time. Domain 3.3.5.4 mandates enhanced MFA with hardware tokens for privileged accounts and separation of privileged from non-privileged credentials. Domain 3.3.5.6 requires MFA for any third-party external administrative access. The "user, group, OU, session, device, location, time" granularity language is among the most explicit per-context MFA expectations in any framework, anticipating risk-based authentication and step-up patterns by design.

Eleven framework references, six jurisdictions. The shape of the requirement is consistent: MFA on every privileged and remote access path, phishing-resistant for high-risk roles, with the carve-outs that used to admit weaker factors written out of the frameworks.

The failure modes that map to architectural gaps

The breaches that defined the period from 2022 to 2025 each map to a specific architectural failure, and the failures recur with enough frequency that they should be read as patterns rather than incidents.

The Uber breach of September 2022 was a push-fatigue case. The attacker bought a contractor's credentials, hit the MFA prompt repeatedly for over an hour, and messaged the contractor on WhatsApp impersonating Uber IT support. The contractor approved. The attacker pivoted to internal Slack, the privileged-access vault, AWS, Google Workspace, and HackerOne. The architectural lesson is that push approval without number-matching trains users to tap yes reflexively, and the attacker only needs one tap.

The Cisco breach of May 2022 was an OTP phishing case via reverse proxy. The attacker phished a Cisco employee's Google credentials that had been saved in Chrome and synced from a personal account, then social-engineered the employee through voice and SMS to accept MFA push notifications. The attacker gained VPN access. The architectural lesson is that TOTP and push delivered through a reverse-proxy phishing kit (EvilProxy, Evilginx, Modlishka, sold as a service for around $400 a month on cybercrime forums) lets the attacker harvest both factors in real time and replay them.

The Reddit breach of February 2023 was a spear-phishing case. An attacker presented a landing page mimicking Reddit's intranet gateway. The employee entered credentials and OTP. The attacker accessed internal documents and source code. Phishing-resistant MFA would have prevented it because the WebAuthn assertion would not have validated against the phishing origin.

The MGM Resorts and Caesars Entertainment compromises of September 2023 were help-desk social engineering cases. Scattered Spider impersonated employees whose details were lifted from LinkedIn, called the service desk, and asked for a password reset and an MFA reset. The help desk performed the resets without out-of-band identity proofing. Caesars paid approximately $15 million; MGM disclosed approximately $100 million of operational impact in Q3 2023 across room operations, slot machines, hotel keys, and online booking. The architectural lesson is that the MFA recovery flow is the new attack surface. PCI DSS 4.0.1 Requirement 8.5.1(b) ("MFA cannot be bypassed by any users including administrative users") is the framework response.

The Microsoft Midnight Blizzard intrusion of November 2023, disclosed January 2024, was a legacy-account case. APT29 compromised a non-production tenant test account that did not have MFA enabled via password spray, then abused an OAuth application with elevated privileges to traverse into corporate Exchange Online. The architectural lesson is that "we have MFA enforced organisation-wide" is meaningless if exception accounts persist; forgotten test, legacy, and service accounts without MFA are the most common entry vector.

The Change Healthcare breach of February 2024 was a no-MFA-at-all case. BlackCat used stolen Citrix credentials on a remote-access portal without MFA. UnitedHealth's CEO testified before the US Senate Finance Committee that the compromised credentials were for a Citrix portal that did not have multi-factor authentication. Approximately 190 million Americans were affected; total cost reported at approximately $2.45 billion across 2024 disclosures. The architectural lesson is that a single remote-access portal without MFA can compromise an entire industry's payment infrastructure.

The Snowflake-customer compromises of May and June 2024 were default-off-tenant cases. The UNC5537 attacker group used credentials harvested by infostealers from 2020 through 2024 to log into approximately 165 Snowflake customer tenants. Snowflake did not enforce MFA by default on customer accounts at that time. Victims included Ticketmaster (560 million records), AT&T (110 million records of call and text metadata), Santander, Advance Auto Parts, Neiman Marcus, and LendingTree. Snowflake moved to MFA by default for new accounts in July 2024 and announced mandatory MFA for human users by November 2025. The architectural lesson is that platform-default-off MFA migrates the configuration risk to the customer, and many customers do not configure it.

Each pattern has a corresponding architectural fix. Push fatigue: enforce number-matching or migrate to FIDO2. OTP phishing: migrate to phishing-resistant factors. Help-desk social engineering: out-of-band verification on recovery, with the highest-risk roles requiring in-person verification or a second hardware key registered at enrolment. Legacy accounts: tenant-wide MFA enforcement that covers test and service accounts without exception. No-MFA-at-all on remote portals: deny the access path until MFA is configured. Default-off platforms: change the default.

The four weak spots most platforms still leave open

Beyond the breach patterns, four architectural weak spots persist in 2026 even at platforms that have implemented MFA for interactive human logins.

The first is service accounts and non-human identities. CrowdStrike's 2024 Global Threat Report cited valid-account abuse in the majority of intrusions, and service accounts appear disproportionately because they are often exempt from MFA and rotation policies. PCI DSS 4.0.1 Requirement 8.6 addresses this for cardholder environments specifically: interactive use of system, application, and service accounts must be managed, must not have hardcoded credentials in scripts or configuration files, and must have password rotation based on risk analysis. The architectural answer is short-lived workload identities: AWS IAM Roles for Service Accounts on EKS, AWS IAM Roles Anywhere for on-premises workloads (X.509 certificate-based, no long-lived access keys), GCP Workload Identity Federation, Azure Managed Identities, or SPIFFE/SPIRE issuing short-lived SVIDs. The pattern eliminates the long-lived API key as a credential class.

The second is the recovery and bypass flow. PCI DSS 4.0.1 Requirement 8.5.1(b) is direct: MFA cannot be bypassed by any users including administrative users. Recovery flows that fall back to email magic links, security questions, or SMS-only recovery codes are non-compliant by construction unless paired with documented exception management. The architectural answer is to require a phishing-resistant factor on recovery (a second hardware key registered at enrolment, printed recovery codes stored physically) and to require out-of-band verification by video call with photo ID match or in-person verification for the highest-risk roles. Break-glass accounts need explicit documentation, credential splitting between security and executive holders, sealed tamper-evident storage in a safe, an audit alert on every use, and MFA via a hardware key stored with the credentials.

The third is session refresh. OAuth 2.0 refresh tokens are bearer tokens; if exfiltrated, they let an attacker hold a session indefinitely. The architectural answer is to revoke tokens on risk events and require re-authentication at intervals. Microsoft Entra Continuous Access Evaluation, AWS IAM Identity Center, and Okta Identity Threat Protection all implement this pattern, with token revocation within minutes of a risk event such as impossible travel, password change, or device compliance change.

The fourth is step-up authentication for sensitive operations. Re-authentication should be required for data export, key rotation, role assignment, billing change, account deletion, and privileged role activation, regardless of session age. Azure AD Privileged Identity Management activation, AWS IAM "MFA-protected API access" using the aws:MultiFactorAuthAge condition, and GitHub "sudo mode" for sensitive repository operations are the canonical patterns. The relying party reads the amr and acr claims from the IdP token and re-requires authentication if the asserted strength or recency is insufficient.

The architectural answer

Novantra treats MFA as a 2026-grade design intent rather than a feature retrofit, and the commitments below are the architectural answer behind it.

Novantra enforces MFA on every login path, including federated SSO with the relying party checking the amr and acr claims rather than admitting any authenticated session. Phishing-resistant factors (FIDO2/WebAuthn hardware keys, platform passkeys for AAL2, PIV in federal contexts) as the recommended path, with TOTP and SMS available only with explicit opt-in and audit warning. No bypass on second-factor failure; no fallback to weaker factors. Tenant-wide enforcement that covers test, legacy, service, and break-glass accounts without exception, with a tenant-wide report exportable on demand showing which accounts have MFA enabled, the factor type, and the last successful and failed challenge.

Service-to-service authentication on Novantra uses short-lived workload identities, never long-lived API keys. Recovery flows require a phishing-resistant factor or out-of-band verification, with the highest-risk roles requiring physical key holders or in-person verification, and break-glass accounts treated as named operational events with audit alerts on every use. Session refresh revokes tokens on risk events and requires re-authentication at policy intervals, with step-up MFA on every sensitive operation regardless of session age.

Every MFA challenge that fires and every one that does not lands in Novantra's continuous audit trail, with the authenticator type and the verifier-impersonation resistance status recorded per event, exportable to the customer's regulator without the vendor's cooperation. The companion articles on continuous evidence and tamper-proof audit trails cover the integrity layer that makes the MFA log trustworthy when an auditor reads it. For customers whose threat model requires it, Novantra's Sovereign deployment runs the entire identity and audit stack inside the customer's own infrastructure.

None of this is a feature. Each is an architectural commitment that becomes load-bearing the moment the regulated buyer's auditor walks past the perimeter and asks who logged in, with what factor, on what device, and what would have happened if the factor had been the wrong one. The frameworks have moved decisively. The carve-out is gone. The architecture has to follow.