PCI DSS v4.0.1 Requirement 8: a practical MFA and access-control guide
By the Zairen team · · 7 min read
Requirement 8 of PCI DSS v4.0.1 is the one most teams assume they've already passed because "we use MFA." Then the assessor asks which accounts are exempt, what counts as an admin, and how you'd prove any of it. That's where most programs quietly fall apart.
What Requirement 8 actually asks for
The requirement family covers identifying users (8.1), applying authentication factors (8.3), and MFA specifically (8.4). Under v4.0.1, MFA is required for all access into the cardholder data environment (CDE), not just remote or admin access, and it must be applied to all users with access to the CDE - with clear rules around exception accounts like service accounts and application accounts.
The gap between "we have MFA" and "we can prove it"
MFA enforced at the VPN or SSO layer is a start, but Requirement 8 asks whether the check actually covers every entry point. A single API key that bypasses the identity layer, a local service account with a standing password, or an admin path that skips the SSO policy is a hole in the requirement even if the marketing slide says MFA is everywhere. The evidence has to show enforcement, not intent.
What counts as "administrative access"
Under v4.0.1, administrative access means access to systems or applications that can control or change the configuration of the CDE: cloud consoles, CI/CD pipelines that deploy to production, database admin, and secrets management. If a tool can change the environment, it's an admin surface, and it needs MFA plus proper role-based access. Pinning this definition to your actual inventory is where static analysis earns its keep - it finds the admin entry points nobody documented.
Service accounts are the usual offender
Service accounts can't do interactive MFA, which is fine, but they still need to be accounted for: unique credentials, restricted to the specific function, and excluded from MFA only with documented justification and compensating controls. The classic failure is one shared service account with a rotating password sitting in a CI config file. Static analysis will flag exactly that: credentials in code, hardcoded secrets, and over-privileged roles.
What evidence looks like in an SAQ or ROC
For an SAQ, you need to demonstrate the MFA policy, the systems where it's enforced, and the exception list. For a ROC, an assessor will want to see the configuration of the identity provider, the access review logs, and proof that newly added accounts go through the same policy. None of this is a screenshot at a point in time - it's continuous evidence that the control is enforced as the code and configuration change.
This is the same problem class we cover on our PCI DSS page, where access controls are mapped to requirements and evidenced continuously instead of reconstructed for the audit. If you're mid-scope on Requirement 8 and want to see what that looks like on your own stack, book a demo and bring your identity provider configuration.