8.4 MFA for CDE access: PCI DSS requirements and evidence

What PCI DSS 8.4 multi-factor authentication for CDE access requires

Requirement 8.4 asks whether every route into the cardholder data environment (CDE) requires more than a password. It requires multi-factor authentication (MFA) for three access paths: non-console administrative access into the CDE, all access into the CDE, and all remote network access from outside the entity's network that could reach the CDE. Since 31 March 2025, the all-access requirement in 8.4.2 is no longer a best practice. An assessor or customer asking how users prove identity into card data will expect an answer for each of those paths, not a general statement that MFA is in place. The risk is simple: a stolen, phished or guessed password should not be enough to reach stored or transmitted account data.

The three sub-requirements break down as follows. 8.4.1 covers administrators who reach system components in the CDE over a network rather than through a direct physical connection (see PCI SSC FAQ 1577 for how console access is defined). 8.4.2 covers every user account that logs into the CDE, with one exception: application and system accounts performing automated functions. 8.4.3 covers remote network access from outside your network, including vendors and other third parties. Phishing-resistant authentication does not replace these requirements on its own. PCI SSC FAQ 1596 states that it does not satisfy 8.4.1 or 8.4.3 alone, so confirm your approach with your assessor before relying on passkeys or hardware keys for administrative or remote paths.

The case that usually makes 8.4 hard is the remote administrator. A person connecting from home through a VPN and then opening a session into the CDE must pass MFA twice, once for the remote network access and once for the CDE access, as the SAQ D notes describe. An illustrative design is a single identity provider issuing a second factor at VPN login and a separate factor at the jump host, with each step logged. Decide early whether one factor event can satisfy both checks, document that decision, and test it with real administrator accounts, including vendor accounts, before an assessment begins.

Which access paths, accounts and third parties fall under 8.4

Requirement 8.4 applies to the access paths into the cardholder data environment (CDE), not to every login in the organization. The cards below separate the three sub-requirements and the exceptions that change the work, starting from the CDE boundary your Requirement 1 and Requirement 12 scoping work already defines.

Administrative non-console access (8.4.1)

Requirement 8.4.1 covers administrators who reach CDE system components through a network connection rather than a direct console. Jump hosts, bastion servers, database admin tools, hypervisor consoles and Kubernetes API access are typical paths. Check each admin role against each access path, because an admin who also works in the CDE through a helpdesk tool can fall under more than one rule. Confirm whether every administrative path requires MFA, not only the main bastion.

All user access into the CDE

Requirement 8.4.2 applies to all access into the CDE, including standard users, support staff, developers with read access and service desk accounts that can view cardholder data. Jump hosts and shared support tools are easy to miss because they sit outside the payment application but still lead into the CDE. Application and system accounts that perform automated functions are excluded, so list interactive human accounts separately from service accounts before you scope the work.

Remote access from outside the network

Requirement 8.4.3 covers remote network access from outside your network that could reach or affect the CDE. Employees working from home, contractors, and vendors connecting through VPN, remote desktop or a vendor portal all fall within it. Third-party support accounts are often the weakest link, so inventory every remote path, including vendor-managed links that your team does not operate directly.

Console access definition

PCI SSC FAQ 1577 defines console access as a direct physical cable connection to a system component that does not rely on a network connection. Access from a physically attached keyboard or serial cable at the device falls outside 8.4.1 for that session. Any remote management interface, out-of-band controller or KVM over IP session relies on a network connection and therefore counts as non-console access. Confirm each management path against this definition with your assessor before you rely on it.

Two MFA events for remote users

A person who connects remotely to the corporate network and then moves into the CDE must authenticate with MFA for each type of access. An employee who signs into the VPN with MFA and then logs into a payment database must complete a second MFA challenge for the database path. Map these chained sessions in your data-flow diagrams, and check that the identity provider and CDE jump hosts enforce the second challenge rather than trusting the VPN session.

Scope follows the CDE boundary

The accounts and paths covered by 8.4 come from the CDE boundary, which your Requirement 1 network controls and Requirement 12 scope validation define. If a system is removed from scope through segmentation or tokenization, its access paths may also leave scope, but only if the segmentation is tested. Revisit the access inventory whenever the network diagram, cloud account structure or third-party connections change.

How the three access paths combine into one MFA design

Treat 8.4 as three separate access paths that must each be covered, then map them onto one identity design. A remote administrator reaching the CDE crosses two boundaries: the entity's network edge and the CDE itself. The SAQ D notes state that this person must authenticate with MFA twice, once for each type of access. Plan for two verification events in the login flow, not one, and confirm that your identity platform can enforce a second factor at the CDE jump point even when the user has already passed MFA at the VPN or remote access gateway. Test this with a real administrator account before you rely on it in an assessment.

The decision that trips most teams is whether phishing-resistant authentication can replace MFA. Phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3, according to PCI SSC FAQ 1596, so a hardware key used as the only factor for administrative console-free access or for remote network access still needs a second, distinct factor. The exception in the 8.4.2 note is narrower: PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys qualify for accounts that use only phishing-resistant authentication. Ask your QSA which of your accounts fall under that exception, and record the reasoning, because the exception applies per account type and not to the whole environment.

Map each access path to an owner, a factor set and an evidence source before you configure anything. For example, an illustrative design might use an identity broker for remote administrators with a passkey plus a TOTP fallback, while standard CDE users receive MFA at the application layer with an authenticator app. Confirm whether your chosen platform can enforce a factor at each boundary, keep factor enrollment records and log each verification. Service and automation accounts are excluded from 8.4.2, but they still need a documented decision, so mark them explicitly rather than leaving them unassigned.

How an assessor tests 8.4 and what evidence they request

This table compares the three 8.4 sub-requirements by how an assessor scopes them, what they sample, the evidence they ask for and where organizations most often fall short. Read each row as a checklist for your own evidence folder before the assessor arrives. The main takeaway is that 8.4.1 and 8.4.3 are judged on access paths, while 8.4.2 is judged on every account that reaches the CDE.

Sub-requirement	How the assessor tests it	Evidence requested	Common findings
8.4.1 Admin non-console access	Maps every administrative path into CDE system components, then separates console access from network access and checks MFA on each network path	Access path diagram, list of admin accounts with CDE rights, MFA configuration for bastions, jump hosts and admin consoles, sample login logs	Admin VPN or bastion accepts a password alone; MFA covers the portal but not direct SSH or database tools
8.4.1 Console access scope	Confirms which access is direct physical cable connection (console) and which relies on a network, using the console definition in PCI SSC FAQ 1577	Documented definition of console access used by the entity, physical access records for on-site connections	Out-of-band management interfaces are treated as network access but are not listed in the scope
8.4.2 All CDE access	Samples user, admin and service accounts with CDE access and checks MFA at each login step; confirms the automated-function exception is limited to application and system accounts	Identity provider configuration showing MFA is enforced, list of CDE accounts with factor type, documented exception list for automated accounts	Application accounts used by people for interactive logins are not excluded; MFA is enforced for web apps but not for database or file shares
8.4.2 Phishing-resistant exception	Checks that accounts relying only on phishing-resistant authentication fall under the note added in v4.0.1, and that the authenticator meets the criteria in PCI SSC FAQ 1595	Authenticator inventory, FIDO2 or passkey enrollment records, confirmation of synced passkey type	Accounts marked as exempt use TOTP or SMS, which do not qualify; exemption is not documented per account
8.4.3 Remote network access	Traces every remote path from outside the entity network that could reach the CDE, including vendor and third-party connections, and checks MFA on each path	VPN and remote gateway configuration, vendor access list, MFA logs for remote sessions, contracts or access approvals for third parties	Vendor support tunnels use shared credentials or site-to-site links with no MFA; remote access is documented only for employees
Two-step remote access into the CDE	Confirms that a remote user who then connects into the CDE authenticates with MFA at both steps, as described in the SAQ D notes	Sample session records showing two authentication events, network segmentation documentation	MFA applied once at VPN login, with a cached session allowing CDE access without a second challenge
Evidence over time	Checks that MFA settings were in force across the assessment period, not only on the day of testing	Configuration change records, MFA enforcement history, access review results, exception approvals with expiry dates	Settings changed after the sample date with no change record, or exceptions never reviewed

How to implement MFA on CDE access in sequence

This sequence takes an organization from an unclear set of access paths to documented, tested multi-factor authentication for every route into the cardholder data environment (CDE). Each step produces a artifact an assessor can check against Requirement 8.4 and its three sub-requirements.

Inventory every path into the CDE
Map each way a person or system reaches the CDE: consoles and jump hosts for administrators, application logins, database and command-line access, VPN and remote desktop from outside the network, and third-party vendor connections. Include access from cloud consoles and from management networks. The organization owns this inventory, and the network and data-flow diagrams should match it. Done means every path has a named owner, an access type (console, non-console administrative, general user or remote), and a list of the accounts that use it.
Classify accounts and choose the identity source
Sort the accounts from the inventory into human users, administrators, vendors and automated application or system accounts, because Requirement 8.4 treats them differently. Decide where identities will live, such as an existing directory or a self-hosted identity provider, and whether applications will sign in through a single sign-on layer. Confirm that the identity source can enforce second factors for every path in scope. Output: an identity source decision record and an account classification table signed off by the control owner.
Select MFA factors that meet the requirement
Choose the factor types for each population, such as authenticator apps, WebAuthn or FIDO2 security keys, or hardware tokens. Confirm that at least two different factor types are available for MFA, as required by 8.5, and that phishing-resistant options are considered for administrators. Check the current PCI SSC FAQs before relying on any passkey or phishing-resistant method for 8.4.1 or 8.4.3, because the FAQs treat those sub-requirements differently. Output: a factor matrix that lists each population, its permitted factors and the FAQ reference used.
Enroll factors and define recovery processes
Enroll each user's second factors under a controlled process that verifies identity before a factor is bound to an account. Define how lost devices are replaced, how recovery codes are issued, stored and used, and who may approve a reset. Recovery paths are a common bypass, so they must meet the same standard as the primary login. Output: an enrollment procedure, a recovery procedure, and enrollment records that show who enrolled which factors and when.
Enforce MFA at the gateway and each CDE entry point
Configure the identity provider, VPN, bastion host, jump server, console and application login so that a second factor is required before access is granted at every entry point identified in step one. Remote access from outside the entity's network needs MFA before it reaches the CDE, and someone who connects remotely and then enters the CDE needs MFA for each type of access. Exclude automated accounts from interactive MFA only where step six documents the justification. Output: configuration exports and change records for each entry point.
Separate or exempt automated accounts with justification
Application and system accounts that perform automated functions do not fall under the MFA requirement for all access into the CDE, but they must be governed under Requirement 8.6. Identify any interactive login used by a service account and treat it as a human access path that needs MFA or a documented exception. Record the business reason, the compensating restrictions, such as source address limits and credential vaulting, and the approver. Output: an exemption register that an assessor can trace back to the account inventory.
Test each path and retain the results
Test every entry point from the inventory with a valid password and no second factor, then with an invalid second factor, then with a valid factor, and record whether access is granted only in the last case. Repeat the tests for remote access from outside the network and for administrators using non-console access. Keep the test scripts, timestamps, screenshots or logs, and the names of the testers. Any failed path returns to the configuration step, and the retest is recorded. Output: a signed test report that the organization can give to its assessor, with the assessor independently selecting samples for validation.

Choosing an open-source identity layer for CDE MFA

authentik is an identity provider whose authenticator validation stage checks the second factors a user has enrolled during login. For Requirement 8.4 work, the useful part is that one flow can enforce MFA across applications and remote access portals, with factor types that include TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. The project is released under the MIT license, so the software itself carries no license fee.

Factor coverage: Map which factor types you will allow for CDE access. SMS and email codes are weaker than app-based or hardware-backed factors, and you should confirm with your assessor how they are treated for 8.4.2 and 8.4.3.
Recovery codes: Static recovery codes are listed as a supported factor, so document how they are issued, stored and retired.
Phishing-resistant options: WebAuthn and FIDO2 passkeys are the factor types to review against the phishing-resistant note in v4.0.1 and the related FAQs.
Enforcement point: Confirm that the validation stage sits in every path that reaches the CDE, including vendor and third-party access.
Operations: Logins, enrollments and resets generate records that feed Requirement 10, so confirm where these events are stored.

Confirm the factor set, the enforcement points and the license terms against your CDE design and your QSA's expectations before you commit.

Evidence that passes 8.4 and how to keep it current

An assessor testing 8.4 wants proof that MFA is configured on every path into the CDE, that enrolled factors are real, and that any exception is approved and reviewed. The cards below cover the records that show this, and each one needs a routine refresh so the evidence still reflects production when the assessment starts.

MFA configuration exports by access path

Export the MFA policy for each path into the CDE: administrator non-console access under 8.4.1, all CDE access under 8.4.2, and remote access from outside the network under 8.4.3. Label each export with the path it covers, the system or identity provider it came from, and the date. Include the configuration of the stage that enforces the second factor, not only the login screen. Re-export after every change to identity flows, VPN or bastion settings, and on a fixed review cycle your assessor will accept.

Enrollment and factor-type records

Keep a current register of which users have enrolled which second factors, such as TOTP apps, hardware tokens, passkeys or push methods, and when each was enrolled or revoked. Assessors use this to confirm that every account reaching the CDE has at least one verified factor and that factors are of types the entity can defend. Reconcile the register against the directory each month so departed staff and retired devices do not stay active.

Exception register for automated and phishing-resistant accounts

Record every account excluded from MFA under 8.4.2 because it runs automated functions, and every account relying only on phishing-resistant authentication under the v4.0.1 note. Each entry needs a named owner, the business reason, the authentication method, and a documented approval. Confirm the phishing-resistant exemption against the PCI SSC FAQs before relying on it, since 8.4.1 and 8.4.3 still need MFA. Review entries at the same cadence as access reviews.

Remote access logs showing both MFA events

For remote users who reach the CDE, the logs must show two separate MFA events: one for the network connection and one for entry into the CDE. Pull sample sessions from the VPN or gateway and from the CDE jump host and match them by user and time. A log that shows only one prompt is a finding. Keep log retention and time synchronization consistent so the pairs can be matched during sampling.

Vendor and third-party access records

Third parties and vendors connecting from outside the entity's network fall under 8.4.3. Keep a list of each vendor account, its connection method, the MFA factor it uses, the named internal sponsor, and the dates access was granted and reviewed. Ask vendors to confirm in writing that their MFA is enforced on their side as well. Disable accounts promptly when a contract ends, and keep the disable record as evidence.

Periodic review evidence

Assessors want proof that the MFA controls were checked after they were set up. Keep dated review records showing who tested each access path, which test accounts were used, the results, and the changes made. Schedule test logins for admin, standard and vendor paths, and include a check that the exception register matches the live configuration. Tie reviews to change tickets so that any change to MFA settings has a matching verification.

What meeting 8.4 costs in money and effort

This table compares the cost components of meeting Requirement 8.4, showing who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, because no price is stated here and the figures depend on your environment and scope. The main takeaway is that self-hosted open-source platforms remove license spend, but integration, enrollment support and evidence upkeep still carry real effort.

Cost component	Who is paid or who carries the effort	One-time or recurring, and what drives it
Identity platform licenses or self-hosted operation	Software vendor for commercial licenses, or your team and any implementation partner for self-hosted deployments	Commercial licenses recur. Self-hosted authentik, FreeIPA, Keycloak and Zitadel carry no license fee, but hosting and operations recur. Ask what the quote assumes about hosting and upgrades.
Hardware tokens (FIDO2 or OTP keys)	Your procurement team, with spares and replacements handled internally	One-time for the initial issue, then recurring for lost, damaged and new-joiner tokens. Driven by user count and the share of users on hardware versus software factors.
Engineering time for gateway and CDE integration	Your platform engineers, or an implementation partner under a written scope	Largely one-time. Driven by the number of access paths into the CDE, including console-adjacent admin tools, jump hosts, VPN and remote vendor access. Fewer paths lower the effort.
Factor enrollment and user support	Your help desk and identity administrators	Onboarding is one-time per user, while resets and lockouts recur. Self-service enrollment and documented recovery steps reduce ongoing load.
Evidence upkeep	Your compliance and security operations staff	Recurring. Driven by how often configuration changes, how many access logs must be retained and reviewed, and whether MFA evidence is generated automatically or assembled by hand.
External testing or review	Independent testers or reviewers, selected and paid by you	Recurring at the frequency you set. Driven by the depth of testing of MFA bypass, replay and remote access paths. Ask the provider to state the test scope in writing.
Assessor sampling time	Your team supports the QSA, and the QSA's time is billed by the assessor	Recurring with each validation cycle. Driven by the number of samples requested and how quickly you can produce configuration and access records. Ask the assessor for its sampling approach before work starts.

Who does what: your team, a partner and the QSA

Your organization owns requirement 8.4. The standard places responsibility for the controls on the entity being assessed, so no partner or assessor can accept that ownership on your behalf. Your team decides which accounts reach the cardholder data environment (CDE), which second factors are acceptable, who may approve an exception, and how MFA is run from one day to the next.

Access policy: Define which administrators, users, vendors and remote connections must use MFA under 8.4.1, 8.4.2 and 8.4.3, and document the policy that sets those rules.
Approvals and exceptions: Record who approves each factor type, each remote access path and each time-limited exception to MFA, including the reason and the end date.
Phishing-resistant decisions: Decide whether any account will rely only on phishing-resistant authentication, and confirm with your QSA how that choice maps to the notes in the standard.
Daily operation: Handle enrollment, lost token replacement, offboarding of vendor accounts and review of failed logins.
Ownership of evidence: Keep the records assessors ask for, such as enrollment logs, configuration exports and access review results.

Before engaging anyone, confirm that a named owner exists for each of these items, since assessors look for the people behind the decisions as well as the technology.

Where 8.4 fails at assessment and how to close each gap

Assessors who test Requirement 8.4 tend to find the same handful of weaknesses: MFA applied to some access paths but not all, exceptions that nobody documented, and second factors that are weaker or more widely shared than the design assumed. Each card below names one gap, explains why it fails 8.4 and gives the action that closes it before the assessor arrives.

Remote administrators pass MFA once

An administrator who connects through the corporate VPN, then opens a session into the CDE, can clear MFA at the VPN and assume the CDE login is covered. The SAQ D notes treat these as two types of access, so each needs its own MFA challenge. Check the jump host or bastion logs for an administrator session that shows only one second factor event, and configure the CDE login to require a fresh factor.

Vendor VPN accounts outside MFA

Third-party support staff often reach the network through VPN accounts that were created before the MFA rollout or sit in a separate directory. Requirement 8.4.3 covers remote network access from outside the entity's network by third parties and vendors, so these accounts are in scope even when the vendor is trusted. Inventory every remote access account that can reach a CDE segment, confirm each one enforces a second factor, and remove accounts that have no current contract.

Undocumented service account exceptions

Teams often exempt automated accounts from MFA without writing down why. Requirement 8.4.2 does not apply to application or system accounts that perform automated functions, but that carve-out only holds when the account really is non-interactive. Keep a register of each exempt account with its purpose, the systems it touches and proof that no person logs in with it, and review the register on a schedule. Interactive logins from these accounts should trigger a finding.

SMS or email as sole factor

SMS codes and email codes are accepted second factors in many identity platforms, but they are a single factor type that can be intercepted or redirected. If a CDE login relies only on them, the assessor will ask whether the setup meets the MFA design expectations, including how a second factor is verified before access is granted. Review which factors are enrolled for CDE users, retire SMS or email as the only option where possible, and document the reason for any remaining use.

Shared recovery codes among staff

Static recovery codes give a way back into an account when a device is lost. When several staff members share one set, the second factor no longer identifies a single person, which undermines the unique-user intent of 8.4 and the identification rules in Requirement 8.2. Issue recovery codes per user, store them under the user's control, log each use and rotate codes after use or on a defined schedule.

MFA on the portal, not direct entry

A common pattern is an MFA-protected web portal sitting in front of the CDE while database consoles, SSH paths or management APIs remain reachable by a route that skips the portal. Requirement 8.4.1 applies to non-console administrative access into the CDE, so every administrative entry point needs the same control. Map each path into the CDE, including direct SSH, database clients and API endpoints, and test each one to confirm it prompts for MFA.

Questions buyers ask about PCI DSS 8.4

How much effort does requirement 8.4 take for a small team?

For a small team, most of the effort goes into enrolling every person and system path that reaches the cardholder data environment, not into the MFA product itself. Expect work in three places: inventorying who and what reaches the CDE (administrators, all users, and remote access from outside your network, including vendors), choosing a second factor each group can actually use, and collecting evidence that the control works. The effort is largely one-time setup followed by recurring enrollment for new staff and periodic review. The total depends on how many access paths you have and whether your identity provider already exists. Ask any provider to break its quote into inventory, configuration, testing and evidence work.

Does 8.4.2 apply to automated application or system accounts?

No. Requirement 8.4.2 covers all access into the CDE, but it does not apply to application or system accounts that perform automated functions. Those accounts still fall under requirement 8.6, which controls how they authenticate, including interactive login by exception and no hard-coded passwords in scripts or configuration files. Confirm the classification with your QSA early. An account that a person can log into interactively is not automated, even if it was created for a batch job, so the label alone does not settle the question.

Do passkeys satisfy requirement 8.4?

Passkeys can, but only under specific conditions. PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys qualify for 8.4.2. PCI SSC FAQ 1596 says phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3, so administrative non-console access and remote network access need MFA in the form the standard defines. Check the current FAQ wording with your assessor before you rely on a passkey design, and confirm how your chosen identity platform records each factor type.

Can a partner configure MFA for our CDE access?

Yes. An implementation partner can plan, configure and document MFA on your own infrastructure, including enrollment flows, factor policies and remote access gateways. DeployOpen works this way for self-hosted open-source identity platforms such as authentik, FreeIPA and Keycloak, deployed in your cloud accounts or data centers. The partner prepares the systems and evidence. Your organization owns the control and its operation, and only a QSA issues the Report on Compliance or the Attestation of Compliance. Ask the partner to state in writing which tasks it performs and which remain with your staff.

What do our engineers need to contribute?

Your engineers need to supply knowledge of your network paths, identity sources and CDE boundaries, plus time to test changes against production-like access. Typical contributions include:

Confirming which systems sit inside the CDE and how administrators reach them
Providing access to directories, VPN or remote access gateways, and jump hosts
Reviewing configuration changes and approving rollback plans
Running test logins for each user group and recording the results
Owning the ongoing process for enrolling new users and removing old factors

Without these inputs, any partner will have to guess at scope, which lengthens the work and raises the risk of gaps.

How long does a typical MFA rollout for 8.4 take?

It depends on scope. The number of user groups, the number of remote access paths, whether an identity provider already exists, and how many legacy systems must integrate all drive the timeline. A rollout that covers one administrative path with an existing directory is very different from one that spans multiple vendors and older applications. No standard duration applies. Ask for a timeline tied to a written scope, and check that it includes testing, user communication and evidence collection, not only configuration.

Can our QSA help design the MFA controls?

A QSA can explain what an assessor will test and what evidence will show that a control meets requirement 8.4. However, the QSA must remain independent, so it should not design or build the controls it will later assess. Design and implementation belong to your team or a separate implementation partner, while the QSA reviews the result. Agree these roles before work starts so the assessment does not depend on a conflict of interest.

How DeployOpen scopes and prepares 8.4 evidence

DeployOpen plans, implements, hardens and documents self-hosted identity and MFA platforms inside your own cloud accounts, data centers or private networks, under fixed-scope written agreements. Scoping comes first: the team maps every path into the cardholder data environment, including administrator consoles, application logins, service desks, jump hosts and VPN or remote access gateways used by employees, vendors and other third parties. Each path is then assigned to 8.4.1, 8.4.2 or 8.4.3, because the three sub-requirements cover different populations and an MFA control that covers one path does not cover the others. The written scope lists which systems, identity sources and accounts are in and out, and which application or system accounts are excluded from 8.4.2 because they perform automated functions only.

Preparation then turns that scope into configuration and evidence. Typical work includes enrolling the identity provider in front of CDE systems, setting the second factor types that each path accepts, configuring the authenticator validation stage or equivalent so that every login path is checked, and defining how physical console access is separated from network access under the console access definition in FAQ 1577. Where phishing-resistant authentication is used, the team records which accounts rely on it and confirms the position against FAQ 1595 and FAQ 1596, since phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3. Evidence packs usually include the scope statement, configuration exports, enrollment records, login flow diagrams and test results, all arranged for the assessor's walkthrough. Ask the implementation team to name every record it will produce and who keeps it after handover.

Responsibilities stay separate. Your organization owns the controls, the policy, the access decisions and the attestation. DeployOpen configures systems and prepares evidence. Only the independent Qualified Security Assessor issues the Report on Compliance or the Attestation of Compliance, and DeployOpen does not issue audit reports, attestations or certifications. Ongoing work such as user onboarding, factor changes, quarterly configuration checks and handling of new remote access paths can be covered by a retainer, which should be scoped in writing with the same clarity as the initial project. Before you sign, confirm with the assessor which evidence formats they accept and ask the implementation partner to walk through a sample login path end to end.

8.4 Multi-factor authentication for CDE access