Enforcing MFA for every user

Almost every company that reaches an audit has multi-factor authentication switched on somewhere. The identity provider prompts for it, the cloud console asks for a code, and the security policy says MFA is required. The control looks finished.

The audit question is narrower and harder. Is MFA enforced for every account that can reach an in-scope system, including the accounts that never pass through your identity provider? That is where the gaps live: a local admin login left on a SaaS tool, a cloud root account, a contractor added as a guest, a legacy protocol that skips the second factor entirely.

This article covers what the main frameworks require, where coverage usually breaks, how to choose factors, how to handle exceptions without hollowing out the control, and what evidence an auditor tests.

What the frameworks actually require #

The frameworks differ more than people expect. Some name MFA outright. Others ask for "secure" or "verified" authentication and leave the method to you.

PCI DSS is the most prescriptive. Requirement 8.4.2, MFA for all non-console access into the cardholder data environment, became mandatory on 31 March

2025. Requirement 8.5.1 adds conditions on the MFA system itself: it must not be open to replay attacks, it must use at least two different types of factor, all factors must succeed before access is granted, and no user (administrators included) may bypass it unless management has documented and authorized an exception for a limited period. If you handle card data, what changed in PCI DSS 4.0 covers the wider set of new requirements.

HIPAA's current text does not require MFA. HHS has proposed amendments to the Security Rule that would make it an explicit requirement, so confirm whether a final rule has been issued before you rely on the current wording. Either way, a risk analysis that leaves remote access to ePHI protected by a password alone is hard to defend.

SOC 2 and ISO 27001 leave the method to you. In practice, an auditor will ask how users authenticate to in-scope systems, and MFA is the answer they expect to hear for production, cloud consoles, and anything reachable from the internet. For federal work, NIST 800-53 control families explained puts IA-2 in context.

Where coverage breaks #

MFA rarely fails at the identity provider. It fails at the edges of it.

• Applications outside single sign-on. Any tool with its own username and password needs its own MFA setting, and that setting is often per user rather than enforced.

• Local fallback logins. Many SaaS tools keep a password login active after you configure SSO, usually for the account owner. That login does not inherit your identity provider's MFA policy.

• Cloud root and owner accounts. The account created at sign-up often sits outside federation entirely. It is also the most powerful account you have.

• Legacy protocols. Older mail and directory protocols, and app-specific passwords, can authenticate with a password alone even when interactive sign-in requires a second factor.

• Enrollment grace periods. A new user who can sign in for a week before enrolling a factor is a user without MFA for that week.

• Guests and contractors. External accounts in collaboration and code tools may follow their home organization's policy, not yours.

• Policy exclusion groups. Conditional access rules often carry an excluded group created for a migration and never emptied.

None of these shows up when you look at the identity provider's headline setting. All of them show up when an auditor compares the full list of users on a system with the list of users who are challenged for a second factor.

Choosing factors #

Not all second factors resist the same attacks. The question that matters most is whether the factor resists phishing, because a real-time phishing proxy can relay a one-time code as easily as a password.

In rough order of strength:

1. Phishing-resistant authenticators. Hardware security keys and platform authenticators built on the FIDO2 and WebAuthn standards, and smart cards. They bind the login to the real site, so a lookalike domain gets nothing usable. OMB memorandum M-22-09 requires phishing-resistant MFA for US federal agency staff, which is a useful reference point even outside government.

2. Push approval with number matching. Better than plain push, which invites "MFA fatigue", where an attacker sends prompts until someone taps approve.

3. Time-based one-time codes from an authenticator app. Reasonable, but phishable.

4. SMS and voice codes. NIST's digital identity guidelines (SP 800-63B) treat SMS as a restricted authenticator because of SIM swap and interception risk. Treat it as a fallback, not a standard.

You do not need every user on hardware keys on day one. A common sequence is phishing-resistant factors for administrators and production access first, then everyone else.

Handling exceptions without hollowing out the control #

Every real environment has accounts that cannot use interactive MFA. The goal is to make each one deliberate, visible, and temporary where possible.

Service accounts. Machine identities cannot answer a prompt. Do not pretend they are covered. Exclude them from the MFA policy by design, restrict them to the systems and network locations they need, and manage their credentials as secrets with an owner and a rotation schedule.

Break-glass accounts. You need at least one account that works when the identity provider is down. Give it a strong factor stored under dual control, alert on every use, and test that it works on a schedule. An emergency account nobody has tried since setup is not an emergency account.

Temporary exceptions. A user waiting for a replacement key, or a legacy system being retired. Record each one in an exception register with the account, the reason, the compensating control, the approver, and an expiry date. This mirrors what PCI DSS 8.5.1 expects for any bypass, and it is good practice under every other framework.

An exception register an auditor can read is far better than an exclusion group nobody can explain.

The evidence an auditor tests #

A screenshot of the policy page showing "MFA required" is the weakest version of this evidence. It proves a setting exists. It does not prove the setting applies to everyone.

A defensible package has four parts, each dated:

1. The enforcement configuration. An export of the identity provider's authentication policies, with any exclusions visible.

2. The user population with factor status. Every active account, from the system itself, showing whether a factor is enrolled and which type.

3. Systems outside the identity provider. For each in-scope application with its own login, the same population and status, or proof that local login is disabled.

4. The exception register. Every excluded account, with its approval and expiry.

Expect the auditor to reconcile parts two and four. Any active account without MFA should appear in the register. An account that appears in neither is a finding.

Watch for policies left in report-only or audit mode after testing. The configuration looks right on screen and enforces nothing.

Keeping it enforced #

MFA coverage decays. New tools are adopted, new admins are created, someone adds a colleague to the exclusion group to get past a login problem on a Friday. A point-in-time check before the audit will not catch drift during a Type II observation period.

The fix is a recurring check rather than an annual one. Alert when an active user has no enrolled factor, when a policy changes, when an exclusion group grows, and when a new application appears without SSO. Each alert has an owner and a ticket, which also gives you evidence that the control operated throughout the period.

How TrustLynce helps #

TrustLynce continuous monitoring runs control checks against the identity and cloud systems you connect through integrations, and routes each failure to its owner. The results come from the source systems and are dated, which is the evidence an auditor wants in place of a screenshot.