Short answer: PCI DSS, NIS2, the FTC Safeguards Rule, NYDFS, Cyber Essentials and the Essential Eight explicitly require MFA (each in its own scope). SOC 2, ISO 27001, GDPR and HIPAA don't name MFA as a fixed rule, but auditors expect strong authentication and individual accountability. For shared accounts that means being able to show who used each login and that leavers lost access promptly.
"Do we need 2FA for compliance?" is one of the most-searched security questions, and one of the most often answered wrong. Some frameworks name multi-factor authentication outright. Others never mention it but expect it anyway. Several popular summaries mix the two up.
Here's what each framework actually says, with links to the source text, and what auditors look for when several people share one login.
This is a practical summary, not legal advice. Your auditor or counsel has the final word.
The quick answer
| Framework | Does it require MFA? | Where it says so | Applies to |
|---|---|---|---|
| PCI DSS v4.0.1 | Required | Req. 8.4.1–8.4.3, 8.5.1 | All access into the cardholder data environment, plus remote access |
| NIS2 (EU) | Required, where appropriate | Art. 21(2)(j) | Essential and important entities in the EU |
| FTC Safeguards Rule (US) | Required | 16 CFR 314.4(c)(5) | Non-bank financial institutions |
| NYDFS Part 500 (US) | Required | 23 NYCRR 500.12 | NY-regulated financial services |
| Cyber Essentials (UK) | Required for cloud services | Requirements v3.3, user access control | Certified organisations |
| Essential Eight (Australia) | Required at each maturity level | Multi-factor authentication strategy | Government and organisations that adopt it |
| HIPAA Security Rule (US) | Not named yet. Authentication required; MFA proposed, not final | 45 CFR 164.312(d) | Covered entities and business associates |
| SOC 2 | Not named. Expected in practice | CC6.1 (logical access) | Service organisations being audited |
| ISO/IEC 27001:2022 | Not named. "Secure authentication" | Annex A 8.5 | Certified organisations |
| GDPR | Not named. "Appropriate" security | Art. 32 | Anyone processing EU personal data |
Frameworks that explicitly require MFA
PCI DSS v4.0.1
The card industry standard is the most specific. MFA is required for all non-console admin access into the cardholder data environment (8.4.1), for all non-console access into it, not only admins (8.4.2), and for all remote network access from outside your network that could reach it, including vendors (8.4.3). Requirement 8.5.1 sets out how MFA must work: it must resist replay attacks, it can't be bypassed, and it needs at least two different types of factor. The newer requirements (8.4.2 and 8.5.1) became mandatory on March 31, 2025.
PCI DSS also speaks directly to shared accounts. Requirement 8.2.2 allows group, shared or generic accounts only when necessary, on an exception basis. Use must be limited to the time needed, the business reason documented, management approval given, each user's identity confirmed before access is granted, and every action traceable to an individual. The PCI Council's own FAQ says this covers all shared credentials, and names password vaults as an acceptable way to manage them.
NIS2 (EU)
NIS2 lists "the use of multi-factor authentication or continuous authentication solutions" among the minimum cybersecurity risk-management measures (Article 21(2)(j)), "where appropriate". EU member states had to transpose it by October 17, 2024. It covers medium and large organisations in sectors like energy, transport, health, digital infrastructure, managed services and many manufacturers. For digital-infrastructure and digital-service providers, including cloud providers and managed service providers, Implementing Regulation (EU) 2024/2690 adds detail. It requires MFA where the classification of the assets calls for it, requires unique identities, and allows shared identities only when needed for business or operational reasons, with explicit approval and documentation. If you're an MSP serving EU clients, it likely reaches you through them.
FTC Safeguards Rule (US)
Non-bank financial institutions (including mortgage brokers, tax preparers, auto dealers and many fintechs) must "implement multi-factor authentication for any individual accessing any information system" (16 CFR 314.4(c)(5)). The only alternative is an equivalent control approved in writing by the person responsible for the security program. This has been in force since June 9, 2023.
NYDFS Part 500 (US)
New York's cybersecurity regulation for financial services moved to universal MFA: from November 1, 2025, MFA is required for every individual accessing any of the covered entity's information systems (23 NYCRR 500.12).
Cyber Essentials (UK)
The UK government-backed scheme has required MFA on cloud services since 2022. The current requirements (v3.3, "Danzell", for assessments from April 27, 2026) say authentication to cloud services must always use MFA, cloud services can't be left out of scope, and each user needs their own credentials, with separate admin accounts.
The Essential Eight (Australia)
The Australian Signals Directorate's Essential Eight includes multi-factor authentication as one of its eight mitigation strategies, with stricter expectations at each maturity level. Phishing-resistant MFA is expected from Maturity Level Two. The model was last updated in November 2023, and ASD is consulting on its successor.
Frameworks that expect MFA without naming it
HIPAA Security Rule (US)
The current rule requires "person or entity authentication": procedures to verify that whoever is seeking access to electronic health information is who they claim to be (45 CFR 164.312(d)). It doesn't say how, and MFA is the usual way to meet it. The rule also requires a unique user identification for every user (164.312(a)(2)(i)), which matters if your team shares a login to a system holding patient data.
In January 2025, HHS proposed updating the Security Rule to make MFA an explicit requirement, with narrow exceptions. As of October 2026 there's no final rule. The federal regulatory agenda now projects final action for July 2027. So "HIPAA requires MFA" is premature, but the direction is clear.
SOC 2
SOC 2 reports are built on the AICPA Trust Services Criteria, which describe outcomes, not specific controls. CC6.1 covers logical access security, and its points of focus include authenticating users before granting access. MFA isn't written in, but most auditors expect it on production systems, admin consoles and anything holding customer data. Their real question is whether access is restricted and tied to individuals.
ISO/IEC 27001:2022
Annex A control 8.5, "Secure authentication", requires authentication appropriate to the sensitivity of the information. The supporting guidance in ISO/IEC 27002 points to methods like MFA for critical systems. Control 5.16, "Identity management", treats shared identities as something to allow only when needed, with approval and documentation. Control 5.17, "Authentication information", covers how secrets like passwords and 2FA keys are handed out and protected. Every certificate has had to be on the 2022 version since October 31, 2025.
GDPR
Article 32 requires "appropriate technical and organisational measures" for the risk. It doesn't mention authentication or MFA at all. What's "appropriate" depends on the risk, so for systems holding sensitive personal data, MFA is the kind of measure you'd expect to justify leaving out, not adding.
Platforms are making MFA mandatory too
Even without a framework, many of the platforms your team uses now require MFA:
- Microsoft Azure: MFA has been mandatory for the Azure portal and admin centres since October 2024, and for Azure CLI, PowerShell and management APIs since October 2025 (postponable to July 2026). It includes break-glass accounts.
- Google Cloud: 2-step verification is required for the Cloud console, rolled out from May 2025, reaching Cloud Identity accounts without SSO from October 20, 2026.
- AWS: MFA is required for root users of every account type, completed in June 2025.
- GitHub: 2FA has been required for anyone contributing code on github.com since 2023.
- Salesforce: MFA has been a contractual requirement since February 2022.
- Amazon Seller Central requires two-step verification, and Amazon recommends an authenticator app for accounts with several users.
Cyber insurers commonly ask about MFA for all users before they quote, too.
What auditors look for on shared accounts
Shared accounts don't fail an audit by default. Unexplained shared accounts do. Whichever framework you're under, expect these questions:
- Why is this account shared? Have a short reason for each one, such as a root account, a client-owned login, or a single-seat vendor portal. Use separate users wherever the platform supports them.
- Who can use it? A current list of people with access, and who approved it.
- Who used it, and when? Evidence tying each use to a person. A shared phone or a QR code copied onto several phones can't give you this.
- How is the second factor protected? Where the secret key is stored, and whether people can copy it.
- What happens when someone leaves? How quickly access is removed, with a record. See our offboarding checklist.
- Is admin access stronger? The people who control access should have the strongest sign-in themselves.
How Fox Auth helps with the evidence
Fox Auth doesn't make you compliant on its own. No tool does. But it covers the shared-account questions above:
| Auditor question | What Fox Auth gives you |
|---|---|
| Who can use this account? | Each person signs in to Fox Auth individually. Codes are shared with the team or kept Only me, and roles (owner, admin, member) control who can manage them. |
| Who used it, and when? | Every reveal, copy and autofill is logged with the person, the time and the app they used, along with changes to codes, members, roles and settings. Retention runs from 7 days on Starter to 1 year on Scale. |
| How is the second factor protected? | Secret keys are encrypted (AES-256-GCM) on the server, with the encryption key held separately from the database. Teammates only ever receive the current code, and reveals are limited to 10 per person per minute. |
| What happens when someone leaves? | Remove them in Members and they lose every shared code at once. They never had the keys, so there's nothing to rotate. The removal is logged. |
| Is admin access stronger? | Owners and admins sign in with their own second factor by default. Exporting secrets or deleting the team always requires it. |
If you're also deciding whether shared 2FA is acceptable at all, read is sharing 2FA safe?, and see how teams set up shared 2FA.
Sources
Checked October 13, 2026.
- PCI SSC, FAQ: does requirement 8.2.2 allow users to share authentication credentials?
- PCI SSC, Future-dated requirements of PCI DSS v4.x
- 45 CFR 164.312, HIPAA technical safeguards
- Federal Register, HIPAA Security Rule proposed update (January 6, 2025)
- Holland & Knight, HIPAA Security Rule amendments now projected for July 2027
- AICPA, 2017 Trust Services Criteria (with revised points of focus, 2022)
- EUR-Lex, NIS2 Directive (EU) 2022/2555
- EUR-Lex, Implementing Regulation (EU) 2024/2690
- EUR-Lex, GDPR (Article 32)
- 16 CFR 314.4, FTC Safeguards Rule
- NYDFS, Multi-factor authentication guidance
- NCSC, Cyber Essentials: requirements for IT infrastructure v3.3
- Australian Signals Directorate, Essential Eight maturity model changes
- Microsoft, Mandatory MFA for Azure
- Google Cloud, MFA requirement
- AWS, MFA for root users across all account types
- GitHub, 2FA requirement for contributors
- Marsh McLennan Agency, Cyber security controls insurers ask about
Frequently asked questions
Is MFA required for SOC 2?
SOC 2 doesn't name specific controls, so MFA isn't a written requirement. In practice auditors expect strong authentication for access to production systems and sensitive data, and MFA is the usual way to show it.
Does HIPAA require 2FA?
Not in so many words, today. The Security Rule requires you to verify that a person seeking access to health data is who they claim to be (45 CFR 164.312(d)), and to give each user a unique identity, but it doesn't name MFA. HHS proposed making MFA mandatory in January 2025. As of October 2026 that rule isn't final, and final action is projected for July 2027.
Can you share 2FA and stay compliant?
Usually yes, if you can show individual accountability. Frameworks like PCI DSS allow shared accounts only by exception, with each use traceable to a person. A shared vault that logs every reveal per person, and lets you remove access at once, is how you show that.
Is SMS 2FA good enough for compliance?
Most frameworks accept it as a factor, but guidance increasingly favours authenticator apps, passkeys and security keys. Some regulators and platforms discourage SMS for high-risk access. An authenticator app is the safer default.
Is this legal advice?
No. It's a practical summary to help you ask the right questions. Your auditor, assessor or legal counsel has the final word for your situation.
