What PCI DSS 8.5 MFA system configuration requires
Many organizations already run multi-factor authentication, yet their MFA system may not meet Requirement 8.5 of PCI DSS v4.0.1. Requirement 8.5.1 is the only sub-requirement under 8.5, and it is about how the MFA system is built and configured, not whether MFA is switched on. It asks for four properties: the system must resist replay attacks, it must not be bypassed (including by administrators) unless management documents and authorizes the bypass for a limited time, it must use at least two different types of factors, and every factor must succeed before access is granted. The risk these address is account takeover. A stolen password combined with a captured one-time code that can be replayed, or an admin console that skips the second factor, gives an attacker the same access a legitimate user has. Requirement 8.5.1 was a best practice until 31 March 2025 and is now tested in assessments, so a configuration that passed informally may now be a finding.
The most common gaps sit in the login flow rather than in the factor itself. A flow that checks the password, then reports whether the second factor is needed, or that tells the user which factor passed, can help an attacker work through the steps one at a time. PCI SSC FAQ 1584 notes that an MFA implementation may show that one factor succeeded before the next is presented, and recommends giving no feedback until all factors are entered, or checking a session-unique factor first. Legacy directories are the other frequent problem. An LDAP or Active Directory tree that authenticates password-only clients, or an older application that still accepts a direct password login, can sit beside an MFA portal and quietly offer a path around it. Administrative consoles and break-glass accounts often carry undocumented bypasses.
Before the assessment, confirm three things with your team: an inventory of every login path into the CDE that passes through the MFA system, a documented and time-limited process for any bypass with named management approval, and test evidence showing that each path requires two different factor types in sequence. Ask your identity vendor or implementation partner to show these behaviors in a lab, and record the results. Your QSA will test this configuration directly, so the evidence should show what the system does rather than what the design document says it does. For the broader context of the MFA requirements, see PCI SSC's PCI DSS standard page.
Which MFA systems and access paths fall under 8.5.1
Requirement 8.5.1 applies to every MFA system that gates access into the cardholder data environment, not only the login screen users see. The cards below cover the components that usually sit in that authentication path and the scoping questions that decide who configures and evidences each one.
Central identity provider
The identity provider stores users, verifies passwords and decides which second factors a user must present. If it authenticates anyone who can reach the CDE, its MFA logic falls under 8.5.1 even when the CDE itself is elsewhere. Check whether the IdP is dedicated to the payment environment or shared with corporate users, because shared tenants widen the set of settings an assessor must review. Confirm which realm, tenant or policy set governs CDE logins.
Single sign-on and identity brokers
An SSO broker sits between users and many applications, so a factor accepted there may apply to every application behind it. Brokers that federate to an external provider inherit that provider's authentication behavior. Map which applications trust the broker, and record whether each one trusts the broker's MFA decision or repeats its own check. Brokered logins to CDE applications belong in the 8.5.1 review.
Third-party and cloud MFA services
When a cloud IdP or a hosted MFA service issues or verifies the second factor, that service is in the authentication path even though your team does not operate it. Ask the vendor who configures replay protection, bypass rules and factor order, and whether those settings can be exported as evidence. Contracts and shared-responsibility documents should state who changes each setting. Where the entity cannot see the settings, assessors will expect other evidence.
VPN and remote access gateways
Remote access gateways that reach the CDE or a jump host into it are MFA systems under 8.5.1 when they authenticate the user. Gateways often have their own local accounts, fallback modes or RADIUS handoffs that skip the intended factor sequence. Test each access profile, including emergency or legacy profiles, and confirm that a session cannot open with only one factor accepted.
Administrative consoles and jump hosts
Administrative consoles for cloud accounts, hypervisors, databases and key management usually grant the most access to the CDE, so they carry the highest risk if MFA can be skipped. Check whether break-glass accounts, console-only logins or API paths bypass the MFA system entirely. Any bypass must be documented, authorized by management and time-limited to meet the 8.5.1 bypass condition.
Factor enrollment and recovery paths
Enrollment, reset and recovery flows can defeat MFA even when login is configured correctly. A help desk that resets a factor by phone, or a recovery code that never expires, creates an alternate route into the CDE. Include these workflows in the scope inventory, define who may approve a change, and log each one. Confirm with the platform owner which recovery options exist and whether they can be disabled for CDE accounts.
How a QSA tests 8.5.1 MFA configuration
This table shows what a Qualified Security Assessor typically does for each property of Requirement 8.5.1, the evidence requested and the findings that most often cause trouble. Read it as a preparation checklist: each row is a test the assessor may run against your login flows, so confirm each behavior before the assessment starts.
| Property tested | Assessor test approach | Evidence requested or common finding |
|---|---|---|
| Login flow configuration | Review the authentication flow settings and stage order to confirm each factor is checked before access is granted | Flow exports and configuration screenshots. Finding: a stage grants access before a second factor is checked |
| Replay resistance | Capture a valid one-time code or token during a login and attempt to reuse it in a later session | Replay test results. Finding: a TOTP or token accepted more than once within its validity window |
| Bypass including administrators | Attempt to skip MFA with administrator and service-level accounts, and check for hidden bypass switches | Admin login test records. Finding: an admin or debug flag that disables the second factor |
| Time-limited bypass approvals | Ask for any documented bypass and confirm management authorization and an expiry date | Signed approvals with start and end dates. Finding: a bypass switch with no expiry or no named approver |
| Two distinct factor types | Confirm the factors come from different categories, such as something known, held or inherent | Enrollment records per user. Finding: two factors of the same type, such as two email codes |
| Factor feedback | Observe whether the system reveals that one factor succeeded before all factors are entered | Screen recordings of login. Finding: the page advances after the first factor, signaling partial success |
| Failed factor handling | Submit a wrong first factor and check whether the system still prompts for the next one | Test logs of failed attempts. Finding: the system confirms which factor failed, leaking state to an attacker |
| Configuration change control | Check who can change MFA settings and whether changes are logged and reviewed | Change tickets and audit logs. Finding: MFA policy edits with no review or approval trail |
How to configure an MFA system to meet 8.5.1
This sequence turns an MFA deployment into one that can be defended against requirement 8.5.1: every entry point is known, every factor is validated before access is granted, bypasses are controlled, and the resulting configuration is documented well enough for an assessor to test.
Inventory every MFA entry point into the CDE
Start by listing every path that reaches the cardholder data environment and checking which of them pass through an MFA system. Include administrator consoles, SSH and jump hosts, VPN and remote access, application logins, API gateways, and any service that issues tokens or sessions. Your identity team and the owners of each application should confirm the list against network and data-flow diagrams. The output is a register of entry points, each marked with its authentication path, its owner, and whether the MFA system or a separate local login controls it. Gaps found here are fixed before any configuration work starts, because an unlisted path is one an assessor will find.
Select factor types from at least two categories
For each entry point, choose factors from at least two different types, such as something the user knows, something the user has, or something the user is. Confirm that the chosen factors are truly different types, since two hardware tokens or two passwords do not satisfy the requirement. Where a platform supports it, prefer phishing-resistant options such as WebAuthn or FIDO2 passkeys, and document the recovery path, including who may issue recovery codes and how they are protected. The output is a factor matrix that lists each entry point, the factor types it uses, the enrollment method, and the recovery method, reviewed and signed off by the system owner.
Configure stages so all factors succeed before access
Build the authentication flow so that access is granted only after every required factor has been validated, in one flow that ends in a single decision. Use the validation stage of your chosen platform to check enrolled second factors, and confirm that a session token is not issued after the first factor alone. Under PCI SSC FAQ 1584, the flow may reveal that one factor succeeded, but the SSC recommends giving no feedback until all factors are entered or checking a session-unique factor first, so set feedback messages to match that guidance. The output is an exported flow definition for each entry point and a test log showing that a valid first factor with an invalid second factor produces no session.
Disable or gate administrator bypass
Review every setting, service account, or policy that lets an administrator skip MFA, including emergency bypass users, local break-glass accounts, and exception groups. Requirement 8.5.1 allows a bypass only when management documents and authorizes it for a limited time, so remove any standing bypass and replace it with a time-limited exception that has a named approver, a stated reason, an expiry, and a log entry. Confirm that the identity platform enforces the expiry rather than relying on someone to remove the exception. The output is a bypass register with approvals and expiry dates, plus configuration evidence that no permanent bypass remains.
Test replay resistance and bypass paths
Verify that the MFA system resists replay attacks by attempting to reuse a previously accepted one-time code, a captured token, or a stale authentication response, and confirm that each attempt is rejected. Then test each bypass path listed in the inventory to confirm that none grants access without the required factors, and that the time-limited exceptions expire as documented. Testing should be carried out by someone independent of the configuration team, and the findings should be recorded with reproduction steps. The output is a test report with each replay and bypass attempt, the expected result, the observed result, and the remediation and retest record for any failure.
Document the configuration baseline and change control
Record the approved configuration as a baseline that states the platform and version, each flow and stage, the factor types in use, the feedback behavior, the bypass policy, and the owner of each entry point. Store the baseline with the policies and evidence the organization keeps for requirement 8, and place every later change under change control with a review that repeats the replay and bypass tests. Confirm with your assessor which artifacts they expect, since the form of evidence depends on the assessment type. The output is a versioned baseline document and a change log that together let an assessor trace the configuration from the entry point inventory to the test results.
Self-hosted open-source options for the factor flow
authentik is a self-hosted identity provider whose authenticator validation stage checks enrolled second factors during login. Within the MFA flow, it is the component that decides whether every required factor has succeeded before a session is granted, which is the behavior Requirement 8.5.1 asks for. The validation stage supports the factor types listed in the researched facts, so it can cover most user populations without a separate product for each method.
- Factor types: TOTP authenticator apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes.
- Role: a central point where second factors are checked during login, suited to placing in front of CDE applications.
- Licensing: authentik is released under the MIT license, so confirm with your own counsel what that means for your support model and any modifications.
- Factor mix: confirm that your configured stages require at least two different factor types for every path, including recovery and enrollment flows.
- Replay and feedback: confirm in your configuration whether the flow reveals which factor passed before the next is requested, and whether session-unique factors are checked first.
Before relying on this tab's configuration, test each login path against your own Requirement 8.5 design and record the results as evidence.",
FreeIPA is an identity management system that works as a directory with OTP support. Its role in the MFA flow is to hold the user records and the HOTP and TOTP token registrations, so the factor check happens where the identities live. For organizations with an existing RADIUS server, FreeIPA can proxy OTP checks to that server during migration, which can keep an older authentication path running while tokens are moved over.
- Factor types: HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys.
- Role: a directory that stores credentials and validates OTP values, rather than a broker for external identity providers.
- Migration: OTP proxying to an existing RADIUS server can support a staged move, but the proxy path needs its own review under Requirement 8.5.1.
- Licensing: FreeIPA is released under GPL-3.0-or-later, so confirm distribution and modification obligations with your legal team.
- Feedback behavior: confirm whether your login interface reports the result of each factor separately, since FreeIPA's OTP checks are only one part of the overall flow.
A directory with OTP support still needs a front end that enforces the full factor sequence, so confirm the integration point with every application that authenticates against it.
Keycloak provides single sign-on, so users authenticate once with Keycloak rather than separately with each application. In the MFA flow, it is the central place where the authentication sequence is defined and enforced for applications that use OpenID Connect, OAuth 2.0 or SAML 2.0. Keycloak can also broker logins to existing OpenID Connect or SAML 2.0 identity providers, which helps when a corporate identity provider already holds the user population.
- Protocols: OpenID Connect, OAuth 2.0 and SAML 2.0 for applications that delegate authentication.
- Role: a central broker for applications, with the ability to route logins to upstream identity providers.
- Licensing: Keycloak is released under Apache-2.0, a permissive license. Confirm attribution and patent terms with your legal team.
- Brokering: when logins are brokered to an upstream provider, confirm which system performs the second factor and whether Keycloak still enforces the two-type requirement.
- Session behavior: confirm in your realm configuration how factor results are shown to the user and how sessions are replayed or refreshed.
Where applications bypass Keycloak, those paths sit outside the central control, so inventory them before scoping.
Zitadel acts as a central identity broker so that users can sign in through external identity providers such as Google, Microsoft Entra ID or Okta. Applications trust Zitadel, not each provider separately. In the MFA flow, this means the factor requirements for a CDE application can be set in one place, even when the underlying factors are issued by a provider outside your environment. The brokering model also makes it easier to review which upstream provider performs which factor.
- Upstream protocols: OpenID Connect, SAML 2.0 and LDAP for external identity providers.
- Role: a central broker in front of many providers and applications, so MFA policy is applied once.
- Licensing: Zitadel is released under AGPL-3.0-only. Confirm network-use obligations with your legal team, especially if you modify the code.
- Upstream factors: a provider's MFA only satisfies Requirement 8.5 if your design proves that all required factors are verified before access, so document each upstream flow.
- Replay and feedback: confirm how redirects and error messages reveal which factor succeeded, and test replay of captured responses.
Treat each upstream provider as a dependency that requires its own evidence, and include it in your responsibility matrix.
Evidence that passes an 8.5.1 review
An assessor testing 8.5.1 wants to see that the MFA system behaves as designed today and that the proof is recent. The cards below cover the artifacts that show resistance to replay, bypass control, factor types and factor verification, and the routines that keep them current between assessments.
Authentication flow configuration exports
Export the authentication flow definitions from every identity platform that gates CDE access, such as the stage order, binding conditions and the validation stage that checks second factors. Store the exports with a timestamp and the change ticket that produced them. Check that the export shows the second factor is required, not optional, for each in-scope application and that no fallback flow skips it. For authentik, this means the flow bindings and the authenticator validation stage configuration. Confirm the export matches what is running, not what was planned.
Replay and bypass test records
Keep dated records of tests that try to reuse a captured one-time code or assertion, and tests that attempt to reach the CDE without completing the second factor. Record the account used, the method, the expected result and the observed result. Include administrator accounts, since 8.5.1 covers bypass by administrators too. Rerun the tests after any change to the identity platform, the factor types or the flow logic, and keep the failed runs with their remediation.
Signed and time-limited bypass approvals
If any bypass path exists, such as a break-glass procedure for an outage, the approval must come from management, be documented and be limited in time. Keep each approval with the named approver, the scope, the start and end time, and the reason. Pair it with the log showing when the bypass was used and when it was closed. Assessors look for the approvals that exist, and for evidence that no bypass ran outside them. A bypass with no approval record is a finding even if it was used for a valid reason.
Factor enrollment records
Maintain a register of which factor types each user or group has enrolled, such as TOTP apps, WebAuthn or FIDO2 passkeys, hardware tokens or other methods supported by the platform. The register supports the 8.5.1 requirement for at least two different types of factors, so check that the sampled accounts show two distinct types, not two instances of one type. Include enrollment dates and the verification step used during enrollment. Remove enrollments when a user leaves or changes role.
Factor sequencing and feedback settings
Document how the login screens present factors and what feedback they give. PCI SSC FAQ 1584 notes that an implementation may show one factor succeeded before the next is presented, and recommends giving no feedback until all factors are entered or checking a session-unique factor first. Keep screenshots or configuration records showing the chosen behavior and the reason for it. Assessors use this to confirm that all factors must succeed before access is granted.
Change logs and periodic review records
Keep the change history for the identity platform, including who changed the flows, factor policies and bypass settings, when, and under which approved change request. Add the periodic review records that compare the live configuration with the documented design. Between assessments, schedule reviews of the exports and test results, and log each review with its outcome. This is what keeps the evidence current, because an assessor sees a continuous trail rather than a snapshot prepared for the audit.
What meeting 8.5.1 costs in money and effort
This table separates one-time setup work from recurring upkeep for an MFA system configured to meet Requirement 8.5.1, and names who is paid for each part. Read it as a checklist for asking providers and assessors what is included in a quote. No figures are shown because none were supplied; ask for the scope behind every line.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Configuring the MFA flow to block replay and bypass | Internal platform team or implementation partner | One-time | Number of login entry points, such as console, portal, API and remote access paths |
| Testing factor sequencing and failure responses | Internal QA, implementation partner or security tester | One-time, repeated after changes | Number of factor types enrolled and whether feedback is given before all factors are entered |
| Documenting the bypass approval process | Internal security and management, with partner drafting support | One-time, then reviewed | Number of management roles that can authorize a time-limited bypass |
| Handling time-limited bypass approvals | Internal identity or security staff | Recurring | Frequency of exceptions, and whether approval and expiry are logged automatically |
| Maintaining evidence of factor types and configuration | Internal compliance lead, supported by the identity platform logs | Recurring | Number of systems in the CDE and how often configuration changes |
| Retesting after upgrades or new integrations | Internal engineers or implementation partner | Recurring | Release cadence of the identity platform and each connected application |
| Assessor sampling of MFA records | QSA or internal assessor, paid by the assessed entity | Recurring, annual | Number of entry points and the sample the assessor selects |
| Open-source identity platform licensing | No license fee for MIT, Apache-2.0 or GPL-licensed platforms, though support contracts may apply | Recurring if support is bought | Choice between self-supported operation and a paid support or retainer agreement |
Where MFA configurations usually fail 8.5.1
Requirement 8.5.1 is tested by behavior, not by whether MFA is switched on. The gaps below are the ones assessors most often find in MFA systems that look correct in a demo but leak under test. Each card pairs the gap with the configuration change or evidence that closes it.
Password error after the first factor
Many login flows check the password, then show a message such as "wrong password" before the second factor is requested. That tells an attacker that the first factor succeeded, which 8.5.1 is meant to prevent. PCI SSC FAQ 1584 recommends showing no feedback until every factor has been entered, or checking a session-unique factor first. Test the flow with a valid password and an invalid code, and confirm that the responses look the same at every stage.
Administrators with silent bypass
A common gap is an administrator account, service console or break-glass path that skips the second factor without anyone approving it. 8.5.1 allows a bypass only when management documents and authorizes it for a limited time. Inventory every bypass route, including directory overrides, local accounts and emergency logins, then confirm each one has a written approval and an expiry that the system enforces.
Codes reused across sessions
One-time codes sent by SMS or email can be replayed if the system accepts the same value twice or keeps it valid after a successful login. Replay resistance means each code is consumed on first use and expires quickly. Ask the platform owner to show how a used code is rejected on a second attempt, and check whether recovery codes are also single use.
Two factors of the same type
Two factors that both come from the same place, such as a password and a security question or two codes from one app on one phone, do not meet the requirement for two different types. Map each enrolled factor to its type, such as something the user knows, has or is, and block enrollment combinations that share a type. Review this mapping whenever a new authenticator is added.
Undocumented bypass switches
Configuration flags that disable MFA for a group, an application or a whole realm often sit in files or admin consoles with no change record. Export the active authentication flows and policies from each identity provider, compare them with the approved baseline, and alert on any change. Keep the export in the evidence set so an assessor can see the configuration as it was during the review period.
No test evidence
A configuration that was never tested cannot be shown to work. Keep dated test records for each gap above: a failed login with a valid password, a replayed code, an attempt to use a bypass without approval and a login with two factors of the same type. Repeat the tests after upgrades and changes. Confirm with the assessor which test format and retention period they expect before the assessment starts.
Who configures, who tests, and who validates 8.5.1
Your organization owns requirement 8.5.1. That means the MFA system is part of your cardholder data environment (CDE) access design, its settings are approved by people accountable for the CDE, and its exceptions are decided by management, not by the engineers who happen to hold administrative rights. Nothing in the standard moves this ownership to a vendor or consultant, and an assessor will ask your staff to explain how the configuration works and who can change it.
- Policy and risk decisions: Management decides which factor types are acceptable, who may request a time-limited bypass, and how long a bypass may last. These decisions should be written down and approved before configuration begins.
- Operating the system: Your administrators keep the identity provider running, manage enrollment and revocation of factors, and respond when a user loses a token.
- Change control: Changes to factor policy, stage order or bypass settings go through your normal change process with a named approver and a record.
- Bypass governance: Each documented bypass needs an authorizer, a reason, a start and end time, and a closing record.
- Assessor access: Your team arranges screenshots, configuration exports and sample records for the QSA and answers their questions.
Confirm internally who signs off on factor policy and who is accountable for each bypass before anyone else touches the configuration.
An implementation partner such as DeployOpen can plan, install, configure and document the self-hosted identity stack that enforces 8.5.1, and can prepare the evidence your team and the QSA will review. The partner works inside your infrastructure and under a written, fixed scope. The partner does not decide your risk acceptance, does not sign off on the control as compliant, and does not issue any report.
- Configuration build: Authenticator validation settings, factor enrollment flows and session handling are set according to your approved policy, for example in authentik, FreeIPA or Keycloak, depending on what your environment already uses.
- Replay and bypass controls: The partner configures how the system handles one-time codes and bypass paths, then tests them and records the results.
- Evidence preparation: Configuration exports, test logs and a short design note describing each factor path are prepared for your team to review.
- Documentation handover: Runbooks explain how to enroll factors, revoke them and review bypass records after the engagement ends.
- Scope boundaries: The written scope states which systems, identity sources and administrative paths are covered, so there is no ambiguity about who handled what.
Check that the statement of work names the deliverables and that the partner's role is limited to preparation, configuration and evidence, with the compliance decision left to you and the QSA.
The Qualified Security Assessor (QSA) is the independent party that tests 8.5.1 during a PCI DSS assessment and records the result in the Report on Compliance (ROC). Where the assessment is a self-assessment instead, the organization completes the applicable questionnaire and its Attestation of Compliance (AOC) itself. In either case, the validation is a formal statement made by the assessor or the organization, not a certificate, and PCI SSC does not recognize certificates as validation.
- Independence: The QSA must be independent of the work it assesses. A firm that designed or configured the MFA system generally cannot also validate it, so your choice of implementation partner affects who can assess the same environment. Confirm this with the QSA before engagement.
- Testing method: The QSA examines the configuration, observes login behavior, checks replay resistance and reviews bypass records against the requirement.
- Sampling and evidence: The QSA selects administrators, remote users and bypass events to test, so your records must be complete and retrievable.
- Findings and remediation: Gaps are reported to you, and you decide how to remediate or document an approved alternative.
- Issuance: Only the QSA issues the ROC and its AOC, and the payment brands decide which entities must validate and how.
Ask the QSA early which evidence they expect for bypass approvals and factor replay tests so these can be prepared before fieldwork begins.
Questions about 8.5 MFA system configuration
Can an implementation partner configure MFA to meet requirement 8.5?
Yes, a partner can configure the MFA system, but the organization still owns the control and its compliance result. The partner works on the identity platform: setting up the authentication flows, enrolling factor types, blocking bypass paths and producing configuration exports and test records. The organization decides which factors are acceptable, who may approve a time-limited bypass and how that approval is documented. Only the QSA issues the Report on Compliance or Attestation of Compliance. Ask any partner to show how its written scope maps each part of 8.5.1 to a deliverable before work starts.
What drives the effort of an MFA configuration project?
Effort depends mainly on how many systems sit behind the MFA system and how many of them already use a central identity source. The main drivers are:
- The number of applications, admin consoles and remote access paths that must enforce MFA
- Whether the current login flow reveals one factor's result before the next factor is entered
- How many factor types must be supported, such as authenticator apps, hardware keys, or codes
- Whether bypass or break-glass accounts exist and need documented, time-limited approval
- The volume of testing evidence needed to show that replay and bypass attempts fail
Ask for a written scope that lists each system and each factor type, since these items set the work.
What does our internal team need to provide for an MFA project?
The internal team must supply decisions and access that only the organization can provide. Expect to name owners for the identity platform and for each protected application, approve the list of acceptable factor types, and define the management approval process for any bypass. The team must also grant access to test accounts, provide change windows for production login flows and review the configuration before it goes live. Engineers should be ready to confirm which login paths reach the cardholder data environment, because 8.5.1 applies to those paths. Assign a single point of contact so approvals do not stall the work.
Are open-source identity platforms accepted by QSAs for requirement 8.5?
The standard does not name products, so a QSA assesses whether the configuration meets 8.5.1, regardless of license. Open-source platforms such as authentik, FreeIPA, Keycloak and Zitadel offer MFA features that can be configured to resist replay, require at least two factor types and block bypass. Whether a specific setup passes depends on the configuration and the evidence, not the brand. Confirm early with your QSA which product version, configuration exports and test records they will want to see, and confirm each platform's current capabilities against its own documentation before you rely on them.
How do we confirm that factors are verified before access is granted?
Test the login flow from the user's perspective and record each step. The flow should not grant access until every factor has succeeded. A key detail is feedback: PCI SSC FAQ 1584 notes that an MFA implementation may indicate that one factor succeeded before the next is presented, and recommends giving no feedback until all factors are entered or checking a session-unique factor first. Test with wrong and correct values in each position, attempt to reuse a captured code, and confirm that a failed later factor leaves no session behind. Keep the test scripts and results as evidence.
How should we prepare for the QSA test of MFA system configuration?
Prepare evidence that a QSA can check without guessing. Assemble the written MFA policy and the documented bypass approval process, a current list of every system protected by MFA, configuration exports from the identity platform, and records of replay, bypass and factor-order tests. Show a sample of time-limited bypass approvals, including their expiry. Run the tests again close to the assessment so results reflect the current build. Brief the internal owners on how the flow works, since the QSA will often ask staff to walk through it. Any change after testing should trigger a new test record.
Does configuring MFA alone satisfy PCI DSS requirement 8.5?
No, configuring the MFA system is necessary but does not on its own cover 8.5.1 in full. The requirement also depends on how the organization governs exceptions. Bypass must be documented and authorized by management for a limited time, so the process around the system matters as much as the settings. Requirement 8.5.1 became required in assessments after 31 March 2025, having been a best practice before that date. Plan the configuration and the governance together so the evidence supports both.
How DeployOpen prepares 8.5.1 evidence
DeployOpen's role in 8.5.1 is to prepare the MFA systems and the evidence about them, while the organization owns the control and an independent QSA decides whether it is met. Engagements start with a written, fixed scope that names every MFA entry point in the cardholder data environment: administrator console and non-console access, remote access from outside the network, and any application or identity provider that brokers logins into the CDE. The scope also lists each factor type enrolled for each population, the platform that validates factors, and the systems that rely on its decisions. Agreeing that inventory before work begins is the step that most affects how much evidence the assessor later asks for.
Implementation covers the self-hosted platforms in the client's own cloud accounts, data centers or air-gapped networks. For example, an illustrative deployment might use authentik's authenticator validation stage for TOTP, WebAuthn and passkey checks, or Keycloak as a single sign-on layer in front of CDE applications. DeployOpen configures the validation order so that all factors must succeed before a session is granted, records the settings used for the no-bypass rule and the documented, time-limited exception process, and runs replay and bypass tests against each entry point, including attempts to reuse a captured one-time code and attempts to skip a factor through alternate flows. Results, configuration exports and change records are kept as dated artifacts. Confirm with the vendor how each platform handles factor feedback before deciding how much detail the login page shows.
DeployOpen does not issue Reports on Compliance, Attestations of Compliance or any other assessment output. Those come from the QSA or from the entity's own completed SAQ, and the organization submits them under the payment brands' rules. Ask any partner, including DeployOpen, to state in writing which evidence it produces, which parts remain the organization's responsibility, and which decisions belong to the assessor. Before the assessment, confirm with your QSA which test procedures they will run for 8.5.1, which logs and configuration exports they expect, and how they want the management authorization for exceptions documented. The implementation partner's written scope should match that list.
