No single PCI DSS v4.0 change generated more implementation work than the expansion of MFA requirements. Under v3.2.1, MFA was required only for remote access from outside the CDE. Under v4.0, MFA is required for every access into the CDE, from any location, for any user. This change fundamentally alters the authentication architecture for any organization with an on-premise or hybrid CDE.
Where MFA Is Required Under v4.0
| Access Context | v3.2.1 Requirement | v4.0 Requirement | Implementation Impact |
|---|---|---|---|
| Remote network access from outside CDE | MFA required | MFA required | No change — already required |
| Non-console admin access from internal network | MFA required | MFA required (same) | No change for admin access |
| All CDE system access (any user, any location) | Not required | MFA required (NEW) | Significant — all user logins to CDE systems must use MFA |
| Access to web-based management interfaces | MFA for remote access only | MFA for all access | Internal web console access now requires MFA |
| Access through jump/bastion server | MFA for initial jump server login | MFA for every hop (jump server + CDE system) | Multi-hop MFA may require PAM integration |
What Constitutes Valid MFA
Authentication Factor Categories
MFA requires authentication using at least two factors from different categories: something you know (password, PIN, passphrase), something you have (authentication token, smart card, hardware key, mobile authenticator app), something you are (biometric — fingerprint, facial recognition, retina scan). Authentication factors from the same category (two passwords, or a password and a PIN) do not constitute MFA.
Acceptable MFA Methods
| MFA Method | Factor Category | PCI DSS Acceptability | Phishing Resistance | |
|---|---|---|---|---|
| TOTP (Google Authenticator, Authy) | Something you have | Accepted | Moderate — can be phished via real-time relay | |
| Hardware token (RSA SecurID, OTP token) | Something you have | Accepted | Moderate — same as TOTP | |
| Push notification (Duo, Microsoft Authenticator) | Something you have | Accepted | Moderate — vulnerable to push bombing attacks | |
| FIDO2/WebAuthn (YubiKey, passkey) | Something you have | Accepted — most secure | High — cryptographically bound to origin domain | |
| Smart card / PIV card | Something you have | Accepted | High | |
| SMS OTP | Something you have (debated) | Accepted but not recommended | Low — vulnerable to SIM swap attacks | |
| Biometric (fingerprint, facial) | Something you are | Accepted as second factor | Moderate — depends on implementation quality | |
| KEY IDEA | PCI DSS v4.0 recommends phishing-resistant authentication mechanisms — particularly for privileged access to CDE systems. FIDO2/WebAuthn hardware keys (YubiKey, Google Titan) are considered the gold standard: they are cryptographically bound to the specific domain, preventing phishing attacks where a fake site collects credentials. For high-privilege CDE access, FIDO2 hardware tokens are increasingly the expected control. | |||
MFA Architecture for On-Premise CDEs
RADIUS-Based MFA
For organizations with on-premise infrastructure, RADIUS-based MFA integration is the most common architecture. The MFA solution (Duo, Microsoft NPS extension for Azure MFA, Google BeyondCorp) acts as a RADIUS server. Network devices (VPN concentrators, firewalls with management access) authenticate users via RADIUS, which invokes the MFA challenge. Linux servers using PAM can also be configured for RADIUS-based MFA.
Active Directory Integration
For Windows-dominated CDEs, Microsoft Entra ID (Azure AD) MFA provides deep integration with Windows authentication flows. AD-joined CDE servers can enforce MFA for all logins through Conditional Access policies (for Azure AD-joined systems) or through third-party MFA agents (Duo for Windows Logon, etc.) for on-premise-only environments.
MFA for Cloud CDEs
AWS — MFA for EC2 and RDS Access
In AWS CDEs, MFA should be enforced at multiple layers: AWS console access (IAM MFA), AWS CLI access (STS with MFA), EC2 instance login (Systems Manager Session Manager with MFA or SSH with certificate-based auth requiring MFA at certificate issuance), and RDS access through Systems Manager port forwarding.
Common MFA Gaps in PCI DSS Assessments
The most common MFA findings under v4.0:
- MFA enforced for VPN only — direct internal server access has no MFA (violates v4.0 requirement for all CDE access)
- MFA enforced at jump/bastion server but not for the final SSH hop from bastion to CDE server
- Service accounts excluded from MFA (service accounts must either have MFA or be managed through a PAM vault with just-in-time access)
- SMS OTP used as sole second factor — accepted but flagged as weak by QSAs
- MFA bypass paths exist (break-glass accounts, emergency access procedures not secured)
| IMPORTANT | The "MFA fatigue" attack (also called push bombing) — sending repeated MFA push notifications to a user until they accidentally or frustratedly approve one — has been used in several high-profile breaches. PCI DSS recommends phishing-resistant MFA (FIDO2) for privileged access and at minimum implements a number matching or context display in push notification approvals to make accidental approval less likely. |
| For Indonesian organizations with on-premise CDEs, deploying Duo Security's RADIUS integration is the most practical path to comprehensive MFA coverage — it handles PAM integration for Linux SSH, Windows Logon, and network device RADIUS simultaneously. For cloud-native organizations on AWS, AWS IAM Identity Center with MFA enforced via Conditional Access provides full coverage for both console and programmatic access. | |