What PCI DSS 8.3 strong authentication requires and why it matters
If an assessor or payment brand is asking you to prove that user logins into the cardholder data environment (CDE) are strong enough, Requirement 8.3 is the part of PCI DSS v4.0.1 that sets the bar. It defines the minimum strength of authentication factors and the password controls that protect them, including how many factors each user needs, how factors are protected, when accounts lock, how passwords are built and reused, and how often they change. Requirement 8.3 is a technical requirement, so the answer an assessor wants is a configured system, not a policy statement. The risk it addresses is simple to state: attackers guess weak passwords, reuse passwords stolen elsewhere, or intercept and read credentials as they cross a network or sit in a database. The controls are hard to get right for ordinary reasons. Legacy directories often carry old password rules, administrators share logins that nobody can tie to a person, and password settings live separately in the directory, the VPN, the jump host, the database and each application, so a rule that looks correct in one place is wrong in another. Several of these settings are also easy to misreport because the same user may reach the CDE through more than one path.
Some of the 8.3 wording is newer than many teams expect. The v4.0.1 rules that matter most here, including the 12-character password minimum and the 90-day change rule for passwords used as the only factor, became mandatory on 31 March 2025 after being future-dated best practices in v4.0. If your last assessment was built on the older seven-character password rule from v3.2.1, your evidence and configuration both need to be checked against the current wording. Confirm the exact requirement text and its applicability with your QSA or the payment brand, because the interpretation for your environment decides what you configure. The controls under 8.3 belong to your organization. The payment brands and assessor decide what is in scope and what counts as evidence, and a partner can prepare systems, settings and documentation, but the entity must own the policy decisions, the configuration and the proof that it runs as described. Before any assessment, list every path into the CDE, record which authentication factors and password rules apply on each one, and confirm with your assessor how they will sample those settings.
Which accounts, systems and teams 8.3 applies to
Requirement 8.3 applies wherever a user or service can reach the cardholder data environment, which reaches further than the payment application itself. The cards below separate the scoping decisions that determine how much of your identity estate must meet the strength rules, starting with the one that changes the work most.
Whether MFA covers all in-scope access
This is the decision that changes the work most. FAQ 1590 says the 90-day password change rule in 8.3.9 does not apply where multi-factor authentication is used for all in-scope access. If MFA covers every path into the cardholder data environment, password rotation is no longer the control you run on a calendar. If any path relies on a password alone, that path keeps the rotation obligation. Map every in-scope access path, including administrator consoles and vendor access, before deciding which rule governs each one.
User accounts with CDE access
Every person with a user ID that can reach the cardholder data environment falls under 8.3, including staff, contractors, support engineers and privileged administrators. Build the list from the systems that grant access, not from the HR roster, because accounts often exist in jump hosts, databases and monitoring tools that were never added to the payment inventory. Confirm for each account which factors it uses and whether those factors meet the length, lockout and history rules.
Identity stores feeding those accounts
Directories, identity providers and Kerberos realms often hold the password or factor that authenticates a CDE user, even when the payment system never sees it. A FreeIPA realm providing single sign-on to Linux hosts, for example, carries the authentication for every system that trusts it. Treat each store that issues or verifies credentials for in-scope access as part of the 8.3 boundary, and document how it enforces lockout, history and factor storage.
Applications that authenticate users
Each in-scope application either verifies passwords itself or delegates sign-in to an identity provider. Applications that keep their own user tables must meet the lockout after no more than 10 invalid attempts and the 12-character rule, while applications that delegate sign-in inherit those controls only if the provider enforces them. Inventory both, because a delegated application with a local fallback login still has its own authentication path to test.
Third-party and SaaS identity platforms
A hosted identity service, a SaaS payment tool or a managed support portal can bring its own user accounts into scope when it sits in the payment flow or can reach the CDE. Your assessor will ask whether those accounts are yours to control or the provider's to control, and what evidence the provider supplies. Obtain written responsibility splits and confirm that the provider's factor storage, lockout and history settings meet 8.3 before relying on them.
Service provider customer accounts
If your organization is a service provider, the customer accounts you host for other entities may fall under 8.3.10.1, which applies the 90-day or dynamic analysis rule to those customer accounts. This requirement became effective on 31 March 2025 and superseded 8.3.10. Confirm with your assessor whether your customer portal, API keys or administrative consoles for customers fall in scope, and document how each customer account is governed.
How an assessor tests 8.3 and which evidence passes
This table compares each testable element of Requirement 8.3 against the test approach an assessor typically uses, the evidence requested and a common finding. Read each row as a checklist to run before the assessor arrives, since most findings come from configuration that differs between the documented policy and the live system.
| Testable element | Test approach and evidence requested | Common finding |
|---|---|---|
| Factor count per user (8.3.1) | Review the identity provider and directory configuration, then sample user accounts with access to the CDE and confirm at least one factor is enrolled and enforced. Evidence: configuration exports and a sampled account list with factor records. | Accounts with a password stored but no enforced factor policy, or service accounts treated as exempt without documented justification. |
| Factor protection in transit and storage (8.3.2) | Review transport settings for every login path and inspect how passwords and tokens are stored. Under FAQ 1253, strong cryptographic hashing of passwords meets this element. Evidence: TLS configuration, hashing algorithm settings, and a sample of stored credential records showing they are not readable. | Passwords stored with weak or reversible methods, or login endpoints that accept credentials over unencrypted channels in legacy or internal paths. |
| Lockout after invalid attempts (8.3.4) | Observe a controlled failed-login test on a non-production or designated test account and confirm the lock occurs at or before the tenth invalid attempt. Confirm the lock duration of at least 30 minutes or identity verification before release. Evidence: lockout policy export and a timestamped test log. | Lockout set above 10 attempts, lockout applied only in the application and not in the directory, or no documented unlock procedure. |
| Password length and character mix (8.3.6) | Review the password policy in each system that accepts passwords, confirm the 12-character minimum, and check that numbers and letters are both required. Where a system cannot support 12 characters, review the documented technical reason and the eight-character setting. Evidence: policy configuration and a test attempt with a short password. | Legacy systems still at a seven-character minimum from v3.2.1, or a policy that is enforced at creation but not on password change. |
| Password history (8.3.7) | Test by changing a password repeatedly and attempting to reuse one of the last four. Sample the history store where the system keeps it. Evidence: history setting and a test record showing rejected reuse. | History kept for fewer than four passwords, or history not applied to administrator-initiated resets. |
| Change interval or dynamic analysis (8.3.9) | Confirm whether passwords are the only factor for any in-scope access. If they are, review the 90-day change setting and sample accounts for expiry dates. If MFA covers all in-scope access, confirm that position against FAQ 1590. Evidence: password age report and MFA coverage report. | Password-only accounts with no expiry setting, or a claim of dynamic analysis with no documented rules or monitoring output behind it. |
How to implement 8.3 in the authentication stack, step by step
This sequence takes a team from an inventory of every login path into the cardholder data environment to a dated record that shows each Requirement 8.3 control is configured, tested and evidenced. Each step names the output it produces so the assessor can trace the control from policy to setting to test result.
Inventory every authentication point into the CDE
List every place a user or system authenticates to reach the cardholder data environment: operating system logins, VPN and remote access gateways, administrative consoles, databases, cloud management planes, applications and any identity provider they depend on. Assign each entry an owner and note whether the account is a person, a service or a customer. The output is an authentication inventory that ties each entry to a system in the CDE scope diagram, so no login path is left for the assessor to find on their own. Confirm the list with the team that owns each system, not only the identity team.
Decide the factor model per user population
For each population in the inventory, record which authentication factors it uses: a password alone, a password with a second factor, a certificate, or a managed secret. Requirement 8.3 needs at least one factor per user, so this step confirms that no account has zero factors. Where passwords are the only factor, mark the account for the 90-day change rule under Requirement 8.3.9 unless it is covered by MFA for all in-scope access. The output is a factor matrix that shows the population, the factors, and whether the 90-day rule applies.
Configure lockout and password rules in each identity source
Apply the Requirement 8.3 rules in every identity source the inventory names, not only in the primary directory. Set the lockout after no more than 10 invalid attempts, with the lockout lasting at least 30 minutes or until identity is confirmed. Set the minimum password length to 12 characters (eight only where a system cannot support 12) with both numbers and letters, and block reuse of the last four passwords. Where a system cannot enforce a rule natively, record the gap for review. The output is a configuration baseline per identity source, with each setting written down and its exact value noted.
Confirm hashing and transport protection with each vendor
Requirement 8.3.2 requires every authentication factor to be unreadable during transmission and storage. For each system in the matrix, ask the vendor or the system owner how passwords are stored and whether the login channel uses strong cryptography. Where passwords are hashed with strong cryptography, PCI SSC FAQ 1253 confirms this meets the requirement, so ask for the algorithm and configuration. Check the vendor's documentation rather than relying on verbal assurance. The output is a written vendor confirmation or configuration excerpt for each system, filed with the baseline.
Set the password change rule or MFA scope
For accounts that rely on passwords alone, set the 90-day change rule under Requirement 8.3.9 or document the dynamic analysis of account security posture that replaces it. For customer accounts on a service provider platform, apply the parallel rule in Requirement 8.3.10.1. Where MFA covers all in-scope access, record that scope and retain the MFA configuration as the reason the change rule does not apply, referring to PCI SSC FAQ 1590. The output is a signed-off rule decision for each population, linked to the factor matrix from step two.
Capture configuration exports and test results
Export the live configuration from each identity source and test each Requirement 8.3 setting against it. Run a controlled lockout test with a test account, attempt a password that is too short, attempt a reused password, and confirm that the system rejects each one. Save the exports, the test scripts or screenshots, the dates, and the name of the person who ran each test. Store the set in the evidence repository with the baseline and vendor confirmations. The output is a dated test record that an assessor can re-perform, and it should be refreshed whenever an identity source changes.
Evidence that keeps 8.3 current between assessments
Requirement 8.3 is tested as a point-in-time sample, but the settings behind it drift with every upgrade, directory change and new user population. The cards below are the artifacts an assessor will ask for, each with a refresh cadence and a named owner so the evidence still matches the live configuration when the QSA arrives.
Identity provider lockout and password settings
Export the effective policy from the identity provider or directory, including the lockout threshold, the lockout duration or unlock condition, the minimum password length, and the password history depth. Confirm the export shows the values enforced at login, not only the values written in a policy document. Compare each export against the 10-attempt lockout, 12-character length and four-password history requirements in 8.3.4, 8.3.6 and 8.3.7. Refresh the export after every configuration change and at least quarterly, and have the security lead sign off that the exported values match the change ticket.
Hashing and transport configuration
Record how authentication factors are protected in storage and in transit: the hashing algorithm and parameters for stored passwords, the TLS versions and cipher suites on login endpoints, and any encryption used for token or secret stores. Under 8.3.2, every authentication factor must be unreadable in storage and transmission, and PCI SSC FAQ 1253 confirms that strong cryptographic hashing meets this. Ask each vendor in writing to confirm the configuration for the version you run, and file that confirmation with the export. Refresh after every upgrade and sign off by the platform engineering lead.
Authentication factor inventory by population
Maintain a list of every in-scope user population, such as administrators, customer support staff, service provider personnel and customer accounts, and the authentication factors each one uses. Note where a population relies on a password alone, because that changes which 90-day rule applies under 8.3.9 or 8.3.10.1. Reconcile the inventory against directory group membership so new populations do not appear without a factor assigned. Refresh the inventory monthly and at each access review, with sign-off from the identity owner.
Lockout and password history test records
Keep dated records of test runs that attempt repeated failed logins against a test account until lockout occurs, then confirm the lockout holds for the required period. Add a second test that attempts to reuse one of the last four passwords and confirms rejection. Store the test script, the inputs, the output and the tester name. Rerun these tests after each identity provider upgrade and on a fixed schedule, and have the security team sign off the results before the records go into the evidence folder.
Decision record for 8.3.9 or 8.3.10.1
Document which path applies to each population: MFA for all in-scope access, which PCI SSC FAQ 1590 says removes the 90-day change rule, or dynamic analysis of account security posture for password-only populations. Name the 8.3.10.1 customer account population separately if you are a service provider. The record should state the decision, the reasoning, the systems it covers and the review date. Revisit the decision whenever a population changes its factors. Risk owner and compliance lead should both sign it, and the record should be dated.
Change records after upgrades
Link each upgrade, patch or migration of the identity provider, directory or login application to a change record that lists the authentication settings reviewed afterward. Vendor releases can change defaults for lockout, password rules or token lifetimes, so a short checklist of the 8.3 settings should be completed for every change. Keep the signed checklist beside the change ticket. Refresh it on each release cycle and have the change approver sign off that the post-change checks were completed.
What meeting 8.3 costs in money and effort
This table breaks the cost of meeting Requirement 8.3 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration is published for this work and every figure depends on your environment and agreed scope.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Identity platform licenses or subscriptions | Setup is one-time; licenses or subscriptions recur | Number of users, number of applications integrated, commercial add-on features | Compare commercial subscriptions with self-hosted open-source identity providers such as authentik or FreeIPA, then price the operating effort that replaces the license fee |
| Engineering time to configure and test each identity source | One-time, with periodic retesting after changes | Number of identity sources, legacy directories, and applications that authenticate outside the central provider | Consolidate sources where feasible, and ask the implementation partner to scope each source as a separate deliverable |
| Password policy and lockout configuration | One-time configuration, recurring review | Number of password-only systems and customer-facing accounts that need the 90-day rule or dynamic analysis | Move password-only access to MFA where possible, since the 90-day change rule does not apply where MFA covers all in-scope access (PCI SSC FAQ 1590) |
| Factor hardware or MFA tokens where needed | Hardware is one-time; replacement and inventory recur | Number of users requiring physical tokens, lost-device replacement rate | Confirm which factor types your MFA design supports before buying hardware, and reuse software-based factors where the design allows |
| Credential storage and secrets management | Setup one-time; operation and rotation recur | Number of service accounts, databases and pipelines holding static secrets | Use dynamic short-lived credentials where the platform supports them, such as OpenBao, to reduce manual rotation work |
| Evidence upkeep | Recurring | Number of systems producing authentication logs, frequency of access reviews, changes to policy | Automate policy exports and configuration snapshots, and store them in a single evidence location tied to each sample |
| External testing or configuration review | Recurring, typically tied to the testing cycle | Scope of the identity estate, number of internet-facing login pages, depth of testing requested | Define the scope in writing before work starts, and test the identity flows that touch the CDE first |
| Assessor sampling time | Recurring, once per assessment | Number of systems in scope, number of sampled accounts, quality of prepared evidence | Prepare sample-ready evidence for each factor type and password rule, so the assessor does not need repeated follow-up requests |
Which self-hosted open-source tools can support 8.3 evidence
No open-source tool satisfies Requirement 8.3 by itself. The requirement is met by the configuration of the systems that authenticate users, and an assessor will test that configuration and the records it produces. Identity providers, secrets managers and pipeline scanners can generate much of that configuration and evidence, which is why they are worth evaluating early. The organization still owns the control, and the QSA decides whether the evidence is sufficient. authentik (MIT) is the most direct fit for the authentication-strength work. It acts as an identity provider that applications delegate sign-in to, using OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers. Applications that rely on authentik do not hold their own password stores, so the factor count, password policy, lockout and multi-factor settings can be reviewed in one place. Confirm in the version you deploy whether lockout thresholds, password history depth and the hashing algorithm meet the values in 8.3.4, 8.3.6, 8.3.7 and 8.3.2, and keep the configuration exports as dated evidence. Applications that cannot delegate sign-in will need their own configuration review. FreeIPA (GPL-3.0-or-later) covers single sign-on for Linux and UNIX hosts through an MIT Kerberos KDC, which is useful where administrators log in to systems that hold cardholder data. The GPL-3.0-or-later license matters if you modify the code and distribute it, so have counsel confirm your obligations before embedding it in a product. OpenBao (MPL-2.0) stores secrets encrypted in one place and issues dynamic, short-lived credentials with leases that revoke automatically on expiry. This supports the handling of non-person and service credentials, and the lease history is useful evidence. The MPL-2.0 is file-level copyleft, so confirm how any modifications are shared. GitLab Community Edition (MIT) pipeline secret detection writes a gl-secret-detection-report.json artifact on each job, giving a record that committed credentials were checked. Treat the report as one input to the review of hard-coded passwords, not as proof that none exist.
Who owns 8.3: your team, an implementation partner and the assessor
Your organization owns Requirement 8.3 in full. It sets the authentication policy, decides which factors each user population uses, and takes the position on Requirement 8.3.9 or 8.3.10.1, which governs password changes when a password is the only factor. Those decisions must be documented and approved by someone accountable for the cardholder data environment. Outside help can draft material, but the decisions and the sign-off stay with you.
- Policy and factor decisions: Choose which factors apply to staff, service provider customers and remote users, and record why.
- The 8.3.9 or 8.3.10.1 position: State whether passwords are ever the only factor and, if so, whether you use the 90-day change rule or dynamic analysis of account security posture.
- Ownership of exceptions: Approve any deviation and keep the rationale current.
- Operational follow-through: Review lockout events, handle account unlocks and confirm that configuration changes go through your change process.
- Final sign-off: Accept the evidence pack before it goes to the assessor.
Confirm with your assessor which evidence format they expect for your position on 8.3.9 or 8.3.10.1 before you finalize the policy.
An implementation partner such as DeployOpen can configure the systems that enforce Requirement 8.3 and prepare the evidence that shows they work. Typical work covers identity providers, directory services and secrets management in your own infrastructure. The partner builds and documents the configuration, then tests it against your stated rules. Its output is material for your team and the assessor to review, not a finding about compliance.
- Identity configuration: Set up providers such as authentik so applications delegate sign-in, and enforce password and factor settings centrally.
- Lockout and history testing: Run controlled tests of the lockout threshold, lockout duration and reuse of the last four passwords, and record the results.
- Configuration exports and evidence packs: Export settings, produce dated test records and map each artifact to the requirement it supports.
- Remediation support: Fix gaps found in testing and document the change.
- Independence limit: The partner must not perform the PCI DSS assessment, must not sign the Attestation of Compliance and must not present its own tests as the assessor's validation.
Ask for the written scope, the list of evidence the partner will deliver and confirmation that the partner has no role in the assessment itself.
A Qualified Security Assessor (QSA) or other assessor performs the independent assessment. The assessor selects samples, tests whether the configured controls behave as documented, reviews the evidence and records its findings. A QSA completes the Report on Compliance (ROC). A self-assessment questionnaire (SAQ) is validated against the official PCI SSC templates with an Attestation of Compliance (AOC). Only the assessor issues the report or attestation, and a certificate from any other party is not recognized as validation.
- Sampling and testing: Choose accounts and systems to test, including lockout behavior, password history and factor storage.
- Evidence review: Compare exports, logs and test records with the stated policy and the configuration in place.
- Reporting: Document the ROC or validate the SAQ, and sign the AOC where the template calls for it.
- Independence: The assessor should not design or configure the controls it later tests. Consulting and assessment are kept separate for this reason.
- Compensating controls or customized approach: Where you use either, the assessor judges whether the alternative meets the stated objective.
Confirm that the assessor is listed as eligible for your assessment type and ask how it will treat evidence prepared by a partner.
Where 8.3 usually fails and how to close each gap
Most 8.3 findings do not come from missing policy. They come from one system enforcing a rule that another system ignores, or from settings that were correct at one point and drifted afterward. The cards below cover the gaps assessors meet most often, with the fix and the evidence that shows it holds across every in-scope system.
Legacy directories that cannot enforce policy
Older directories and applications may cap passwords below 12 characters or cannot block reuse of the last four passwords. Check each in-scope authentication source against the 8.3.6 and 8.3.7 settings, not only the primary directory. Where a system cannot enforce the rule, the fix is to route sign-in through a modern identity provider such as authentik, which delegates sign-in to applications over OpenID Connect, SAML or LDAP, or to document a customized approach with a stated objective and a risk analysis. Evidence is the exported password policy from each system plus the identity provider configuration showing it is the sole sign-in path.
Lockout configured in one system only
A lockout after no more than 10 invalid attempts, held for at least 30 minutes or until identity is confirmed, is often set on the VPN or directory while cloud consoles, admin portals and databases keep their defaults. Inventory every login path into the CDE and record the lockout values for each. Centralizing sign-in through one identity provider, or through FreeIPA for Linux and UNIX hosts, removes the mismatch. Evidence is a per-system table of lockout thresholds and durations, with a sample of lockout events from logs.
Shared administrator logins
A shared administrator account lets several people sign in with one password, so the per-user factor, the lockout and the password history apply to no one in particular. Replace shared logins with named accounts that each enforce the required factors, and keep any break-glass account sealed and monitored. Secrets for service access can be held in OpenBao, which issues short-lived credentials and revokes them on lease expiry. Evidence is the account inventory showing no shared interactive logins, plus credential issuance and revocation records.
Password rules without an MFA scope decision
Teams often apply 90-day password changes everywhere, or drop them everywhere, without deciding whether MFA covers all in-scope access. Under 8.3.9 the 90-day rule applies only where a password is the sole factor, and FAQ 1590 confirms it does not apply where MFA covers all in-scope access. Record the decision per population: which accounts use MFA, which rely on passwords alone, and how dynamic analysis is used where it replaces the change rule. Evidence is a signed scope decision tied to the MFA enrollment report and the password change configuration.
Factors not shown to be protected
Assessors need proof that every authentication factor is unreadable in storage and in transmission, not an assumption that the login page uses TLS. Confirm that passwords are hashed with strong cryptography, that no credentials appear in configuration files or pipeline logs, and that tokens are protected in transit. Pipeline secret detection in GitLab Community Edition writes findings to a JSON artifact, which gives repeatable evidence for code. Evidence is the hashing configuration, a TLS scan of each login endpoint, and secret detection reports from the pipeline.
Evidence that describes last year
Settings exported once for an assessment go stale as systems change, accounts are added and identity providers are upgraded. Assessors test the state at the time of the assessment and the operation of controls across the period, so a single screenshot is weak support. Schedule automated exports of password policies, lockout settings and MFA enrollment, store them with timestamps, and review drift against a baseline. Evidence is a dated configuration history, change tickets for each authentication change, and a recurring review record signed by the control owner.
What buyers ask about 8.3 cost, effort and outside help
How much effort does requirement 8.3 take with one identity provider compared with several?
A single identity provider that every in-scope application signs in through usually means one configuration baseline to set, test and evidence. Several identity sources multiply the work: each one needs its own password policy, lockout settings, factor storage checks and change records, and each application's sign-in path must be traced back to the right source. Effort also rises with the number of legacy applications that handle their own passwords, because those applications may need to be moved onto central sign-in or configured individually. Ask any partner to list every identity source and every application that authenticates users before quoting, since that inventory drives most of the estimate. Confirm the scope of each source with your assessor before work starts.
Does the 90-day password change rule still apply if MFA covers all in-scope access?
Under the PCI SSC's FAQ 1590, the 90-day change requirement in 8.3.9 does not apply where multi-factor authentication is used for all in-scope access. The rule is aimed at passwords that are the only authentication factor, or at the single factor in a system that lacks MFA. Because the answer depends on how access is actually configured, document each access path, confirm that every path into the cardholder data environment uses MFA, and keep that evidence for the assessor. Re-check the FAQ and the current version of the standard before each assessment, since version-specific guidance can change.
Can self-hosted open-source software meet requirement 8.3 without license spend?
Open-source software can cover several parts of 8.3 without a license fee, but the standard does not require any specific product and the license is only one cost. Tools such as authentik, which acts as an identity provider through OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, can centralize sign-in. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. OpenBao can store secrets encrypted and issue short-lived credentials. Still budget for the work that does not disappear: design, hosting, hardening, testing, monitoring, upgrades and the evidence that proves each setting. Confirm each product's capabilities against your configuration before you rely on it.
What does a PCI DSS 8.3 project need from our internal team?
Your team owns the controls, so it must make decisions and provide access. Expect to name an owner for identity and authentication, confirm which systems hold or process cardholder data, approve password and lockout settings, and sign off on any exceptions. Your engineers will need to explain how each application authenticates users, provide administrative access to the identity platform, and give the change approvers time to review configuration changes. Someone in the business must also own the ongoing tasks, such as reviewing failed-login reports and recording any changes to factor settings. Ask any provider to list these internal tasks in writing so you can plan staffing before the work starts.
Can a partner prepare 8.3 evidence while an independent assessor tests it?
Yes, that split is the usual arrangement. A partner can configure the systems, document settings, collect logs and assemble the evidence that shows each part of 8.3 is in place. Only an independent QSA, or your own assessor where the program permits it, tests the controls and records the result in the Report on Compliance or Self-Assessment Questionnaire. The partner cannot issue the assessment or the Attestation of Compliance, and a certificate is not accepted as validation. Keep the roles separate in the contract, and ask the assessor early which evidence they expect, since their testing approach may affect how you prepare it.
What changed on 31 March 2025 for requirements 8.3.6 and 8.3.10.1?
On 31 March 2025, the 12-character password minimum in 8.3.6 became mandatory for passwords used as authentication factors, replacing the seven-character minimum from v3.2.1. Where a system cannot support 12 characters, eight is the fallback. The same date brought 8.3.10.1 into effect for service provider customer accounts, which applies the 90-day change or dynamic analysis rule and superseded 8.3.10. Check your current password policy and any customer-facing account settings against these rules, and confirm version-specific details with the current PCI DSS v4.0.1 text and the PCI SSC FAQs, since the standard's guidance is updated over time.
What should we ask for in a written quote for 8.3 work?
Ask for a written scope that lists every identity source, each in-scope application and the systems that handle cardholder data. The quote should separate one-time work, such as design, configuration, hardening and evidence preparation, from recurring work, such as upgrades, monitoring and support. Request the deliverables, the evidence each one produces, the assumptions behind the timeline, and which tasks belong to your team. Confirm what the provider will not do, including any testing or attestation that only an independent assessor can perform. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen prepares 8.3 systems and evidence
DeployOpen works on Requirement 8.3 by setting up the self-hosted identity, secrets and password controls that the requirement tests, then documenting the configuration so your assessor can check it. The organization owns its controls and its assessment, and DeployOpen prepares the systems and evidence for an independent QSA to review.
How we scope
- Confirm which identity providers, directories and secrets stores authenticate users with access to the cardholder data environment.
- Record which accounts use passwords as the only factor, since that decides whether the 90-day change rule applies.
- Agree the scope, deliverables and timeline in writing before any configuration work begins, as all engagements are fixed-scope.
How we build
- Configure the self-hosted identity provider so applications delegate sign-in to it through supported protocols such as OpenID Connect and SAML.
- Set password length, character mix, lockout after no more than 10 invalid attempts, and reuse limits of four in line with 8.3.4, 8.3.6 and 8.3.7.
- Confirm that authentication factors are hashed with strong cryptography and unreadable in storage, the approach described in PCI SSC FAQ 1253.
How we hand over
- Deliver configuration exports, screenshots and test records showing each setting, so an assessor can trace each control to its evidence.
- Document the password policy, lockout behavior and any dynamic account analysis in a format your team can maintain.
- Provide a handover session for administrators who will run and change these settings after the engagement closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement ends.
- Retest authentication settings after platform upgrades or directory changes so evidence stays current for each assessment cycle.
- Ask your QSA which evidence formats they accept before the build begins, since the report on compliance is their decision alone.
