MFA Enforcement Gaps

A software vendor confirmed in their security assessment that multi-factor authentication was required for all user access. The confirmation was accurate for their human user population accessing the application through the web interface. It did not describe their service account population, which used API key authentication with no second factor. It did not describe their legacy integration endpoints, which supported basic authentication for backward compatibility with older partner integrations. It did not describe their database access, which used certificate-based authentication for some accounts and password-only authentication for others , certificate authentication having been implemented for new accounts but not retrofitted to existing ones. And it did not describe their remote administration access through an older VPN system that predated modern MFA support. The human user population had strong MFA. The non-human identities, legacy paths, and infrastructure access points had varying and often weaker authentication , the paths that attackers prefer precisely because human-facing MFA enforcement creates pressure toward the less-protected alternatives.

What are MFA Enforcement Gaps, Really?

MFA enforcement gaps are the authentication paths in an environment where the second factor is not required , paths through which identities can authenticate using only a single factor (typically a password, API key, or certificate) without the additional verification that MFA provides. Every gap represents an identity and an access path for which credential theft is sufficient for unauthorized access , no MFA to defeat, no second factor to obtain, no phishing-resistant authentication to circumvent.

The exception accumulation problem is the structural root of MFA enforcement gaps. MFA policies are typically defined with a broad requirement , 'all users must use MFA' , and then eroded through exceptions: service accounts cannot use MFA because they authenticate non-interactively; legacy applications do not support modern authentication; certain administrative paths were built before the MFA requirement existed. Each exception is individually justifiable. The aggregate of exceptions represents an authentication posture that is significantly weaker than the stated policy , and the exceptions are precisely the paths that attackers have learned to target as organizations have improved their human-user MFA coverage.

The phishing-resistant MFA distinction is a further complexity layer. Not all MFA provides equivalent protection. SMS-based MFA can be defeated through SIM swapping and real-time phishing proxies. Push notification MFA can be defeated through MFA fatigue attacks , bombarding users with push notifications until one is accidentally or deliberately accepted. TOTP-based MFA can be intercepted in real-time phishing attacks. Phishing-resistant MFA , FIDO2/WebAuthn hardware security keys and passkeys , cannot be defeated through these techniques because the second factor is cryptographically bound to the legitimate site. An MFA enforcement confirmation does not specify which type of MFA is used, and different types provide radically different levels of protection.

• Service account MFA exemptions , non-human identities authenticating without a second factor
• Legacy endpoint basic authentication , older API and application endpoints supporting password-only authentication for backward compatibility
• Infrastructure access MFA gaps , database administration, server management, and network infrastructure with weaker authentication than application access
• MFA bypass through alternative authentication paths , paths that authenticate without the standard MFA-enforced workflow
• Weak MFA type , SMS or push notification MFA that can be defeated through SIM swapping, MFA fatigue, or real-time phishing

Why this matters

MFA enforcement gaps matter for TPRM because vendors who process customer data represent attractive targets precisely because their systems hold data from multiple customers simultaneously. Defeating their authentication controls , particularly on administrative paths with broad access , provides access to all customers' data at once. An attacker who defeats a vendor's service account authentication because service accounts lack MFA is not accessing one customer's data; they are potentially accessing the full customer dataset that the service account can query.

The real-time phishing proxy attack on TOTP and push MFA has made MFA gap assessment more nuanced since 2022. Services like Evilginx and similar transparent proxy tools enable attackers to intercept TOTP codes and session cookies in real time, defeating time-based OTP and push notification MFA methods. For vendors processing highly sensitive data, the relevant MFA assessment question is not just whether MFA is enforced but whether the MFA type is phishing-resistant , specifically, whether FIDO2 or equivalent hardware key MFA is used for the highest-privilege accounts.

For TPRM practitioners, MFA assessment requires asking not just whether MFA is enforced for all users but what authentication method is used for service accounts, legacy endpoints, administrative infrastructure, and the highest-privilege human accounts , and whether the MFA type used for those accounts is phishing-resistant.

Where most teams get this wrong

The most consistent failure is accepting 'MFA required for all users' as a comprehensive MFA posture statement. The statement confirms human user MFA enforcement. It says nothing about service accounts, legacy paths, infrastructure access, or MFA type. A vendor with strong human-user TOTP MFA and API key authentication for service accounts has MFA for all users and no MFA for the non-human identities that process most of the data.

• Accepting 'MFA for all users' as comprehensive MFA posture
• Service account authentication not assessed , non-human identity authentication gaps
• Legacy endpoint authentication not evaluated , basic auth and older authentication paths
• MFA type not assessed , phishing-resistant vs phishable MFA methods
• Infrastructure access MFA gaps not examined

What good looks like

Mature MFA enforcement programs apply authentication controls proportionate to access risk across all identity types , human and non-human , and use phishing-resistant MFA for the highest-privilege accounts. Service accounts use secrets management rather than static credentials. Legacy endpoints are retired or migrated to modern authentication. Phishing-resistant MFA is required for administrative access.

• Phishing-resistant MFA for admin and privileged accounts , FIDO2/WebAuthn required for highest-privilege human access
• Secrets management for service account authentication , dynamic credentials rather than static API keys
• Legacy endpoint migration plan , basic auth endpoints identified with migration timeline
• Comprehensive authentication path inventory , all authentication paths documented with MFA status
• MFA bypass detection , monitoring for authentication through non-MFA paths by accounts that should use MFA

Tooling

Phishing-Resistant MFA , YubiKey, Google Titan Keys, Microsoft Entra FIDO2

FIDO2/WebAuthn hardware security keys provide phishing-resistant MFA , the second factor is cryptographically bound to the legitimate domain and cannot be captured through proxies or phishing sites. Microsoft Entra ID supports FIDO2 security keys as an authentication method. For TPRM practitioners, asking whether the vendor requires phishing-resistant MFA for privileged and administrative access provides the specific MFA type question that distinguishes phishable from phishing-resistant authentication.

Conditional Access and Authentication Policies , Microsoft Entra Conditional Access, Okta

Conditional access platforms provide the policy enforcement infrastructure for comprehensive MFA requirements , defining authentication requirements per user type, per application, per location, and per risk level. For TPRM practitioners, asking whether the vendor's conditional access policies specifically address service account authentication and legacy endpoint coverage provides specific MFA enforcement completeness questions.

Governance challenges

The governance challenge with MFA enforcement is the legacy debt problem. MFA has been added to most modern systems as a retrofit to authentication systems that predated it. Service accounts, database connections, and infrastructure management tools built before MFA was widely available have authentication designs that accommodate MFA poorly. Enforcing MFA across the entire authentication surface requires either modernizing legacy systems (expensive), accepting exceptions (risky), or implementing compensating controls for the paths that cannot use MFA (incomplete).

• Ask for complete authentication path inventory , all paths, not just human user web access
• Ask specifically about service account authentication
• Ask about legacy endpoint basic auth
• Ask about MFA type for administrative access , phishing-resistant vs phishable
• Ask about infrastructure access MFA , database, server, and network management

If you are a small team

Add three questions to your MFA assessment that go beyond the standard confirmation. First: what authentication method do your service accounts use , API keys, certificates, or secrets management? Second: do any of your application or API endpoints support basic authentication or other single-factor methods for backward compatibility? Third: what MFA method is required for your administrative accounts , and is it phishing-resistant? Those three questions surface the service account gap, the legacy endpoint gap, and the MFA type quality gap that standard MFA confirmation does not reach.

• Ask about service account authentication method
• Ask about legacy endpoint basic auth support
• Ask whether admin MFA is phishing-resistant
• Request the complete authentication path inventory

What to require

Ask directly:

"Beyond human user MFA, what authentication methods do your service accounts, API integrations, and legacy endpoints use , and are any of these paths accessible with a single authentication factor?"

"For your administrative and highest-privilege accounts, is phishing-resistant MFA (FIDO2/WebAuthn hardware keys or passkeys) required , or do those accounts use TOTP or push notification MFA that can be defeated through real-time phishing or MFA fatigue attacks?"

Expect as evidence

• Authentication path inventory , all paths with MFA status
• Service account authentication method documentation
• Legacy endpoint inventory with migration or compensating control plan
• Phishing-resistant MFA deployment for admin accounts

A vendor who confirms 'MFA is required for all users' should be asked to describe their service account authentication and whether any API endpoints support single-factor authentication. The policy covers users. The gaps are in the paths the policy does not mention. Ask about the paths.

How to evidence it

• MFA enforcement coverage assessment records , human and non-human identities
• Service account authentication method documentation
• Phishing-resistant MFA deployment evidence for admin accounts
• Legacy endpoint authentication assessment

Key Takeaway

MFA enforcement is only as strong as its weakest authentication path. Requiring MFA for all human users while leaving service accounts, legacy endpoints, and infrastructure access on single-factor authentication provides strong protection for the paths attackers have already adapted to avoid and weak protection for the paths they target. The MFA confirmation is accurate for what it covers. The gaps are in what it does not cover. Ask about the service accounts. Ask about the legacy endpoints. Ask about the admin accounts. Ask whether the MFA type is phishing-resistant. The policy says all users. The assessment should verify all paths.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations