MFA, 2FA, and Why Your Auditor Keeps Asking About It
What multi-factor authentication actually means, which methods hold up against real attacks, and what your auditor specifically looks for when they check.
The security questionnaire arrived on a Tuesday — twelve pages, enterprise procurement boilerplate. Somewhere around question thirty-seven: "Do you enforce MFA for all administrative and privileged access? Please describe your implementation." The founder who forwarded it to me had been running Okta with MFA for the engineering team for about a year. The rest of the company was still on password-only email login. The honest answer to that question was "yes, partially," which in enterprise procurement translates roughly to "no."
MFA has become one of the most-checked controls in any compliance audit or vendor security review. If you're unclear on what it actually means, which implementations hold up, and what an auditor specifically wants to see, here's the full picture.
2FA vs MFA: the actual difference
These terms get used interchangeably in product marketing, which doesn't help. The distinction matters.
Authentication factors fall into three categories:
- Something you know: a password, a PIN, a security question answer
- Something you have: a phone, a hardware key, a smart card
- Something you are: a fingerprint, a face scan, another biometric
Two-factor authentication (2FA) means any combination of exactly two distinct factor types. Multi-factor authentication (MFA) means two or more. Every 2FA setup is technically MFA, but not everything marketed as "two-step" verification uses genuinely distinct factor types — some flows stack two knowledge factors (a password plus a security question), which doesn't meet the bar that compliance frameworks set.
When your auditor or a security questionnaire asks about MFA, they mean factors from at least two different categories. A password plus an authenticator app code qualifies. A password plus a second password does not.
Not all MFA is equally strong
This is where teams run into trouble. Enabling any form of MFA is meaningfully better than passwords alone. But within MFA, there's a wide spectrum of actual attack resistance.
Authenticator apps — Google Authenticator, Microsoft Authenticator, Authy, 1Password — generate TOTP codes, which are time-based six-digit numbers that rotate every 30 seconds. This is the standard "scan a QR code" setup, and it's reasonably strong for most threat models. The weak point is phishing: a convincing fake login page can collect your password and your TOTP code in real time, then replay them to the real service before the code expires. That's not a theoretical attack. It's how most enterprise account compromises actually happen today.
SMS one-time codes are the weakest widely-deployed form. They have the same phishing problem as TOTP, plus additional exposure: SIM-swapping, where an attacker convinces a mobile carrier to transfer your phone number to a SIM card they control, bypasses the factor entirely. NIST's SP 800-63B Digital Identity Guidelines designated SMS as a "restricted" authenticator, noting specific vulnerabilities not present in other authenticator types. It's not prohibited outright, but NIST's guidance is clear that if your threat model includes targeted attacks, SMS shouldn't be your answer.
Hardware security keys using FIDO2/WebAuthn — YubiKey, Google Titan Key — are the current standard for high-value accounts. The key generates a cryptographic signature that's bound to the specific website you're authenticating to. A phishing page can't receive a valid response from your key, because the key checks the origin domain before signing. Platform authenticators — Windows Hello, Face ID, Touch ID operating via the device's secure enclave — use the same FIDO2 protocol and offer comparable protection without requiring a separate physical device.
What frameworks actually require
Different frameworks have different specificity here, and conflating them causes confusion.
SOC 2 doesn't prescribe specific technical controls — it sets criteria, and your controls need to satisfy them. The access control criteria that anchor MFA requirements cover restricting logical access from external systems and ensuring that authentication mechanisms protect against unauthorized access. In practice, every auditor I've encountered treats MFA for administrative access as a baseline expectation. Missing MFA for remote access or cloud console access will appear as a gap in any reasonable audit. The SOC 2 readiness checklist covers the access control requirements in sequence if you want to work through them systematically.
PCI DSS 4.0 is far more explicit. Released in March 2022 and the only active version since March 2024 when version 3.2.1 was retired, Requirement 8.4 mandates MFA for all non-console administrative access into the cardholder data environment and for all remote network access from outside the CDE. The standard also specifies implementation characteristics — MFA systems must be configured so that they actually prevent replay attacks, which rules out certain weaker setups. If you're in PCI scope, saying "we have MFA" isn't enough; you need MFA configured to the technical requirements the standard describes.
HIPAA takes a different approach. The Security Rule doesn't explicitly mandate MFA — the required implementation specifications at 45 CFR § 164.312(a) cover unique user identification and other controls, but stop short of specifying authentication factor counts. The practical reality is murkier: HHS Office for Civil Rights enforcement actions following breaches have repeatedly cited absent or inadequate MFA as a contributing factor, and recent Resolution Agreements have included MFA deployment as a corrective action. "HIPAA doesn't technically require MFA" is technically accurate and genuinely risky reasoning if you handle protected health information at any scale.
NIST CSF 2.0 places MFA under the Protect function, within the Identity Management, Authentication, and Access Control category. If you're working from the NIST framework, strong authentication is one of the first controls that appears when you start mapping your practices against the profile outcomes.
What your auditor will specifically look for
Knowing that MFA is required is the easy part. Understanding what evidence auditors actually want is where teams usually find their real gaps.
For a SOC 2 audit, expect the auditor to:
- Pull a population of user accounts from your identity provider (Okta, Entra ID, Google Workspace, whatever you use)
- Sample a subset and check whether MFA was enrolled and enforced — not just available but required by policy, so users can't bypass it on login
- Verify coverage across administrative access to cloud environments, production systems, and code repositories
- Ask for configuration evidence showing MFA is enforced at the policy level, not simply offered as an option
The enforced-versus-optional gap catches more teams than anything else. If Okta has MFA available but not required by policy, every user without it is one phishing email away from a full account compromise, and the auditor will note it. Required means the policy blocks login without completing MFA — no legacy app passwords that route around it, no bypass for named individuals, no mobile enrollment exceptions that never got cleaned up.
Coverage is the other gap. MFA on your Okta tenant means nothing for AWS root accounts, GitHub organization access, or any other system running separate credential sets. The practical task is mapping every authentication path that reaches a sensitive or production system and confirming each one enforces MFA.
Coverage first, then upgrade
For most organizations, the highest-return move isn't upgrading from TOTP to hardware keys — it's closing gaps in coverage. A company that enforces authenticator-app MFA for every user on every system is in a significantly better position than one with hardware keys for five engineers and password-only login for everyone else.
Get the coverage right first: every user account, every administrative path, every cloud console, every code repository, every third-party tool with access to sensitive data. Then look at where phishing-resistant methods make sense for your highest-risk accounts. Production infrastructure administrators, finance roles with payment system access, and executives are reasonable starting points for hardware key or platform authenticator requirements.
Least privilege and MFA solve adjacent problems and reinforce each other. Tight access scoping limits what an attacker can reach with a compromised account. Strong authentication limits how easily they compromise the account. Neither is a substitute for the other, and auditors check both.
When the next questionnaire asks how you enforce MFA, "password plus required TOTP, enforced via policy in Okta, with FIDO2 hardware keys required for all administrative access" is a complete and credible answer. Get the configuration there, document it, and MFA stops being the question that makes your security review stall.