MFA Mandates Map: Laws and Standards Requiring MFA

Multi-factor authentication has moved from a recommended control to a written legal or contractual obligation in finance, payments, US federal systems, defence supply chains and every NIS2 sector, but each rule draws the boundary in a different place. One rule says "any individual accessing any information system", another says "all non-console access into the cardholder data environment", another says "where appropriate". This map sets out the main MFA mandates side by side: who is covered, which access must use MFA, which exceptions are allowed, and the current status of each rule. It then shows how to scope one MFA programme that satisfies the strictest rule you are subject to, how to treat service accounts and AI agents, and how to evidence compliance. It is for identity architects, CISOs, GRC teams and auditors. Status as of 11 November 2026.

Sources: rule wording comes from the official texts we could read (eCFR, EUR-Lex, Federal Register, the OMB memorandum, NCSC and the PCI DSS v4.0.1 standard), with the NYDFS rule read through Cornell LII and the HIPAA timing from the federal regulatory agenda and trade press. Confirm against the official text before relying on it.

Key takeaways

The broadest mandates cover every person. 23 NYCRR 500.12 and the FTC Safeguards Rule, 16 CFR 314.4(c)(5), both require MFA for any individual accessing any information system, with a written alternative only where a CISO or Qualified Individual approves reasonably equivalent or more secure controls.
Sector rules scope by environment instead. PCI DSS v4.0.1 requires MFA for all non-console access into the cardholder data environment (8.4.2) and all remote access that could reach it (8.4.3), and has done so as a mandatory requirement since 31 March 2025.
EU rules set principles, not configurations. NIS2 Article 21(2)(j) asks for multi-factor or continuous authentication "where appropriate", and the DORA ICT risk standard asks for strong authentication for remote, privileged and critical-function access, which leaves the scoping to your risk assessment.
Phishing resistance is becoming the bar. US federal policy (OMB M-22-09) requires phishing-resistant MFA for staff, contractors and partners, and PCI DSS exempts accounts that use only phishing-resistant factors from 8.4.2; SMS codes satisfy the letter of most other rules but not their intent.
Machine accounts are carved out, not forgotten. PCI DSS excludes application and system accounts performing automated functions and NYDFS excludes non-interactive service accounts, so those identities need compensating controls that an auditor can see. See the Accounts Excluded From MFA guide.

Regulations and frameworks at a glance

Rule	Who it binds	Access that must use MFA	Allowed exceptions	Status (11 November 2026)
New York 23 NYCRR 500.12	DFS-licensed covered entities	Any individual accessing any information system of the covered entity	CISO-approved, reasonably equivalent or more secure controls, reviewed at least annually; entities with a 500.19(a) limited exemption still need MFA for remote access, remote access to third-party applications holding nonpublic information, and all privileged accounts other than non-interactive service accounts	In force; universal MFA required from 1 November 2025
US FTC Safeguards Rule, 16 CFR 314.4(c)(5)	Non-bank financial institutions under FTC jurisdiction (lenders, dealers, tax preparers and others)	Any individual accessing any information system	Qualified Individual approves in writing reasonably equivalent or more secure access controls	In force
PCI DSS v4.0.1, Requirements 8.4.1 to 8.4.3 and 8.5.1	Entities that store, process or transmit cardholder data, and their service providers (by contract with acquirers and brands)	All non-console administrative access to the CDE (8.4.1); all non-console access to the CDE (8.4.2); all remote access from outside the network that could access or impact the CDE (8.4.3)	8.4.2 does not apply to automated application or system accounts, single-card point-of-sale accounts, or accounts using only phishing-resistant factors	8.4.2 mandatory since 31 March 2025; v3.2.1 retired 31 March 2024
US HIPAA Security Rule	Covered entities and business associates	Current rule: no explicit MFA; the January 2025 proposal would require MFA under the authentication standard, proposed 45 CFR 164.312(f)	Proposal discusses limited exceptions	Proposed only (NPRM 6 January 2025, 90 FR 898); final action reported moved to July 2027
OMB M-22-09 (federal zero trust strategy)	US federal civilian agencies	Phishing-resistant MFA for agency staff, contractors and partners; public-facing systems must offer a phishing-resistant option	None stated for workforce; public users choose	In force; zero trust goals were due by end of FY2024
NIST SP 800-171 (03.05.03 in Rev 3) via DFARS and CMMC	US defence contractors and subcontractors handling CUI	MFA for access to system accounts (privileged and non-privileged)	Assessed against the control text and organisation-defined parameters	In force through contract clauses; CMMC assessments being phased in
EU NIS2 Directive, Article 21(2)(j)	Essential and important entities in the 18 NIS2 sectors	"the use of multi-factor authentication or continuous authentication solutions ... where appropriate"	Risk-based "where appropriate"; national law and implementing acts add detail	Applies through national transposition
EU DORA, Delegated Regulation (EU) 2024/1774, Article 21(f)	EU financial entities in DORA scope	Strong authentication methods for remote access, privileged access and access to ICT assets supporting critical or important functions or that are publicly accessible	Risk-based, "in accordance with leading practices and techniques"	Applies since 17 January 2025
EU PSD2 RTS on SCA, Delegated Regulation (EU) 2018/389	Payment service providers (banks, e-money and payment institutions)	Strong customer authentication for payers accessing accounts online and initiating electronic payments, with dynamic linking for remote payments	Exemptions in Articles 10 to 18 (low-value, contactless, trusted beneficiaries, recurring, transaction risk analysis)	In force since 14 September 2019
UK Cyber Essentials (requirements v3.2)	Organisations seeking Cyber Essentials certification	Authentication to cloud services must always use MFA; administrative accounts and accounts reachable from the internet should use MFA; MFA where available for users	None for cloud services	Certification scheme; v3.2 dated April 2025

The table is a map, not the rule text. Read the primary source for anything you will attest to, and check your sector supervisor's guidance, because several regulators publish expectations that go further than the rule.

Scope: who and what is covered

The rules fall into four scoping models. Knowing which model applies tells you how much of the estate is in scope.

Scoping model	Rules	What is in scope	Typical gap auditors find
Universal: every person, every system	NYDFS 500.12, FTC Safeguards Rule	All human access, internal and remote, to any information system, including on-premises applications and internal admin consoles	Legacy applications that cannot do MFA and have no documented equivalent control
Environment-bound	PCI DSS 8.4, CMMC / 800-171	Access into a defined boundary (the CDE, the CUI enclave) and remote access that could reach it	Jump hosts and management planes that sit outside the boundary but can reach it
Risk-based	NIS2 Article 21, DORA RTS Article 21(f), Cyber Essentials for users	Access the entity's risk assessment identifies, with remote and privileged access as the floor	No written rationale for where MFA is not "appropriate"
Customer-facing	PSD2 SCA, M-22-09 public users	Customers and citizens, not staff	Exemption logic (transaction risk analysis) not monitored against fraud rate limits

Third parties count. NYDFS covers any individual, which includes vendors and contractors using the covered entity's systems, and its limited-exemption floor names remote access to third-party applications that hold nonpublic information. M-22-09 names contractors and partners explicitly. A remote support vendor with a shared password is a direct finding under these rules.

Key obligations

What counts as MFA

Two different factor types: PCI DSS 8.5.1 requires at least two different types of factor, success of all factors before access is granted, resistance to replay, and no bypass by any user, including administrators, unless documented and authorised by management as a time-limited exception. Two passwords are not MFA.
Independence of factors: the PSD2 RTS (Article 9) requires that a breach of one element does not compromise the others, and where a multi-purpose device such as a phone carries a factor, separate secure execution environments and tamper checks. This is the strictest written test of independence in the table.
Phishing resistance: M-22-09 requires agencies to stop supporting methods that do not resist phishing, such as SMS, voice, one-time codes and push notifications, for routine staff access. PCI DSS rewards it by exempting phishing-resistant-only accounts from 8.4.2. See the Phishing-Resistant MFA Guide.
Lockout and session rules: the PSD2 RTS limits consecutive failed attempts to five before a block and times out online sessions after five minutes of inactivity. Most other rules leave this to the entity.

Documented alternatives

NYDFS and the FTC both allow a written alternative instead of MFA. The bar is "reasonably equivalent or more secure", approved in writing by the CISO (NYDFS, with at least annual review) or the Qualified Individual (FTC). Treat every approval as a dated register entry with an owner, a compensating control and an expiry. See the MFA Exception Register Template.

Timeline and current status

14 September 2019: PSD2 strong customer authentication standards apply in the EU.
26 January 2022: OMB issues M-22-09, with phishing-resistant MFA for federal staff, contractors and partners and a one-year deadline to offer a phishing-resistant option to public users.
31 March 2024: PCI DSS v3.2.1 retires; v4.x becomes the only active version.
6 January 2025: HHS publishes the proposed HIPAA Security Rule update with an MFA requirement; comments closed 7 March 2025.
17 January 2025: DORA and its ICT risk management standard (2024/1774) apply.
31 March 2025: the 51 future-dated PCI DSS v4.x requirements, including 8.4.2, become mandatory.
1 November 2025: NYDFS universal MFA under amended 500.12 applies.
Pending: the HIPAA final rule. The federal regulatory agenda listed final action for May 2026, and trade press reported in 2026 that OMB's site moved it to July 2027. Until a final rule is published, MFA is not an explicit HIPAA requirement, although OCR treats authentication weaknesses as risk analysis findings.

Enforcement and penalties

NYDFS: enforcement under the Financial Services Law, with an annual written certification of compliance to the superintendent; MFA gaps should be expected to surface in examinations and in incident reports to DFS.
FTC Safeguards Rule: enforced under the FTC Act through orders that typically impose long-term security programme and assessment obligations.
PCI DSS: no statutory penalty; consequences flow through acquirer and card brand contracts, including non-compliance fees and higher liability after a breach.
EU NIS2 and DORA: national competent authorities enforce. NIS2 sets maximum fines of at least EUR 10 million or 2% of worldwide turnover for essential entities and EUR 7 million or 1.4% for important entities.
CMMC and DFARS: failure blocks contract award at the required level and can expose contractors to False Claims Act liability for inaccurate self-attestation.

The real cost is usually the breach, not the fine. The Change Healthcare breach began with a remote access portal that had no MFA, and the Snowflake breach turned infostealer credentials into data theft across customer accounts that had not enforced MFA.

What it means for AI agents and non-human identities

MFA mandates are written for people. An API key, a workload identity or an AI agent cannot present a second factor, and the rules say so: PCI DSS 8.4.2 excludes application and system accounts performing automated functions, and NYDFS excludes service accounts that do not allow interactive login from its limited-exemption floor. That carve-out is narrow and conditional.

Interactive means in scope: a service account that a person can log in to interactively is a human access path and needs MFA or a documented equivalent. Disable interactive logon on service accounts so the exclusion is true.
Equivalent controls for machines: the substitute for MFA is strong credential binding: workload identity federation instead of static keys, certificate or mTLS authentication, short-lived tokens, IP or network restrictions and vaulting with rotation. PCI DSS 8.6.1 to 8.6.3 cover system and application accounts directly.
Agents acting for a user: when an AI agent acts on behalf of a person, the person's MFA at delegation time and the scope of the token the agent receives are what an auditor will examine. Long-lived refresh tokens issued once after MFA defeat the purpose of the mandate.
Exclusion lists drift: conditional access exclusions created for automation are the most common way human accounts end up without MFA. See Accounts Excluded From MFA.

Compliance steps

Choosing the design target

Single sector, one rule: scope to that rule, but design to its strictest neighbour you may face next. Multiple regimes: design to universal MFA for all human access (the NYDFS and FTC model) with phishing-resistant factors for privileged and remote access, and the narrower rules are met as a by-product. Small firms using the NYDFS limited exemption or the FTC rule should still start with email, remote access and admin accounts, because those are the paths attackers use first. Large estates should expect a long tail of legacy applications that need either an identity-aware proxy in front or a documented equivalent control.

Inventory obligations: list every rule in the table that applies, with its scope model and exception mechanism. Record the strictest requirement per access type.
Inventory access paths: list every human entry point: IdP-federated apps, VPN and ZTNA, VDI and Citrix, SSH and RDP, cloud consoles, SaaS admin portals, break-glass accounts and vendor remote support tools.
Enforce centrally: enforce MFA at the identity provider and at network entry points, starting in report-only or audit mode, then a pilot group, then all users. Keep break-glass accounts excluded, monitored and sealed.
Raise factor strength: move administrators and remote access to phishing-resistant authenticators (FIDO2 passkeys, smart cards) first; retire SMS and voice where the rule or risk demands.
Handle the remainder: for systems that cannot do MFA, front them with a proxy or bastion that can, or record a dated equivalent-control approval.
Separate machines from people: disable interactive logon on service accounts, move automation to workload identities, and document why each excluded account is non-interactive.
Roll back safely: keep a tested rollback for each enforcement policy (revert to report-only), a staffed help desk with strong identity proofing for resets, and recovery codes stored securely. See the MFA backup codes and recovery codes guide.

Detection and measurement

Coverage: percentage of interactive human accounts with an MFA method registered and enforced, by population (staff, contractors, admins). Target 100% for in-scope rules.
Phishing-resistant share: percentage of privileged and remote sign-ins completed with phishing-resistant factors.
Single-factor sign-ins: count of successful interactive sign-ins with single-factor authentication, from IdP logs, per week. Each one needs an exception reference.
Open exceptions: number of equivalent-control approvals, and the share past their review date.
Excluded accounts: accounts excluded from MFA policies, and the share confirmed non-interactive.
Abuse signals: MFA push fatigue patterns (ATT&CK T1621), new method registrations after risky sign-ins, and password spraying (T1110.003) against accounts without MFA. See the MFA Fatigue and Bypass Guide.

Framework mapping

Framework	Reference	How it relates
NIST SP 800-53 Rev 5	IA-2(1), IA-2(2)	MFA to privileged and to non-privileged accounts
NIST SP 800-171 Rev 3	03.05.03	Multi-factor authentication for CUI systems
NIST CSF 2.0	PR.AA-03, GV.OC-03	Users, services and hardware are authenticated; legal requirements are understood and managed
CIS Controls v8.1	Safeguards 6.3, 6.4, 6.5	MFA for externally exposed applications, remote network access and administrative access
ISO/IEC 27001:2022	Annex A 8.5	Secure authentication
MITRE ATT&CK v20	T1078, T1621, T1111	Valid accounts; MFA request generation; MFA interception

Common failure patterns

MFA on the IdP, not on the side doors: legacy protocols, direct database logins and vendor portals that bypass the federated sign-in.
Exception by default: equivalent-control approvals with no expiry and no annual review, which NYDFS explicitly requires.
Interactive service accounts: accounts excluded as "service" that people still log in to.
Self-service recovery weaker than MFA: help desk resets on knowledge questions undo the control, and push prompts without number matching are weak too, as the MFA fatigue attack in the Uber breach showed.
Scope written once: new remote access tools or SaaS admin consoles added after the last assessment.

Practitioner checklist

List every MFA mandate that applies, with scope model, exception route and status date.
Map every human access path and record whether MFA is enforced at that path.
Enforce MFA for all remote, privileged and cloud console access first.
Move administrators and remote access to phishing-resistant factors.
Record every equivalent-control approval with owner, rationale, compensating control and review date.
Disable interactive logon on service accounts and document each MFA exclusion.
Monitor single-factor sign-ins and MFA policy exclusions weekly.
Test help desk and recovery flows against social engineering.
Re-check rule status (HIPAA, NIS2 national laws) at least twice a year.

Standards and references

Related NHI Mgmt Group resources: MFA Guide · Phishing-Resistant MFA Guide · Identity Security Regulatory Map · Authentication and MFA Policy Template · Cloud Provider Mandatory MFA. This guide summarises multi-factor authentication requirements in selected laws, regulations and standards and is not legal advice.

MFA Mandates Map: Which Laws and Standards Require MFA and for Whom