PCI DSS Password Compliance Checker

The PCI DSS password compliance checker compares the rules your systems really enforce with PCI DSS v4.0.1 Requirement 8, then shows which settings pass, which fail, and how far each one is from the standard. Enter your length, history, lockout, rotation and multi-factor settings, and you get a pass or fail for every control plus an overall score, so you can close PCI DSS compliance gaps and tighten your security posture before a QSA or customer finds them first.

How the PCI DSS Password Compliance Checker Works

Passwords protect the accounts that can reach cardholder data, and the Payment Card Industry Data Security Standard turns that security idea into measurable password controls. A written security policy rarely tells the whole story, because the settings that count are the ones configured in each directory, application and device. The checker therefore asks for the values you have actually set, not the values your handbook promises, and grades each against the matching sub-requirement. A quick pass through the free password regex tester catches issues before they become real problems.

Password policy settings you enter

The form mirrors the numeric and yes/no policy settings that Requirement 8 tests. Each field maps to one control, so a failed field points straight at the sub-requirement behind it:

• Minimum length in characters, plus whether the password must mix letters and numbers.
• Password history, meaning how many earlier passwords are blocked from reuse.
• Failed attempts allowed before an account lockout, and how long the lockout lasts.
• Change frequency in days, for accounts where the password is the only authentication factor.
• Whether temporary passwords must be changed at first use.
• Whether multi-factor authentication protects access into the cardholder data environment.

What the pass or fail result tells you

Each control returns a pass or a fail, and the score is the share of checked controls that pass. A pass means your setting meets the written minimum; it does not prove the security control is enforced everywhere, and compliance without enforcement is only paperwork. Think of the output as a fast compliance check of security intent and configuration, one that points your remediation effort at the right control before anyone books an assessment.

PCI DSS Password Requirements in Requirement 8

Requirement 8 is titled identification and authentication, the security backbone of the standard, and it holds nearly every one of the PCI DSS password requirements. Under PCI DSS v4.0.1 the wording applies to passwords and passphrases alike, so a long passphrase is judged by the same rules as a short password. Every user gets a unique ID (Requirement 8.2.1), which is what makes user authentication and accountability possible in the first place. The sections below walk through the controls the checker grades.

Minimum length and password complexity

Requirement 8.3.6 sets the baseline for password complexity: a minimum length of 12 characters, containing both numeric and alphabetic characters. Where a system cannot support 12 characters, the standard allows eight, but treat that as an exception you must be able to justify, not a comfortable default. Length does most of the security work in password strength, because every extra character multiplies the work a brute force attack needs. Passwords this short also fall quickly to credential stuffing, which tries leaked pairs against your login pages.

Password history and reuse

Requirement 8.3.7 stops a person submitting a new password that matches any of their last four passwords or passphrases. This password history rule closes the loophole of cycling between two favourites. Your setting must be four or more to pass, and it has to apply to local accounts and federated sign-ins as well as the main directory.

Account lockout and failed attempts

Requirement 8.3.4 limits failed attempts by locking the account after no more than 10 invalid tries. The lockout must then last at least 30 minutes, or until an administrator confirms the user's identity. A threshold of 15 or a 15-minute lockout both fail the security test, which is why the checker grades attempts and duration as two separate controls.

Change frequency and the 90 days rule

Many people still believe every password must change every 90 days. In PCI DSS v4.0.1, Requirement 8.3.9 applies only where a password or passphrase is the only factor for user access. In that case you either run a password change at least every 90 days or use dynamic analysis of account security posture to make a real-time access decision. Accounts protected by multi-factor authentication are treated differently, so the checker asks which case you are in before it grades your change frequency.

Reset, first use and temporary passwords

Requirement 8.3.5 says a password set or reset for first-time use must be unique to the user and changed immediately after first use. A temporary password sent by the help desk is the usual weak point, because the recovery route is part of the control: a strong login can be undone by a weak reset. Requirement 2.2.2 adds that vendor default accounts and default passwords must be changed or the account removed before a system goes live.

Storage, hashing and strong cryptography

Requirement 8.3.2 is the control a checker form cannot see, so it is worth stating plainly: every credential must be unreadable in transit and in storage, using strong cryptography: TLS protects the login while it travels, and encryption or salted hashing protects the stored verifier, which keeps the security of the whole login chain intact. In practice that means passwords are salted and hashing uses a slow, purpose-built algorithm rather than a fast general-purpose one, and no application writes a password to a log, a ticket or a configuration file. A policy can score 100% on length and still fail an assessment if a legacy application keeps passwords in clear text. Ask each application owner how verifiers are stored, and record the answer next to the policy settings you entered.

PCI Password Requirements for Multi-Factor Authentication and Special Accounts

The PCI password requirements do not stop at passwords themselves. Requirement 8.4 adds a second security layer, and Requirement 8.6 deals with accounts that are not ordinary people.

Multi-factor authentication for the cardholder data environment

Multi-factor authentication must protect all access into the cardholder data environment (Requirement 8.4.2), and it must cover remote access that starts outside your network (8.4.3). That includes non-console administrative access and privileged access through jump hosts or cloud consoles. The authentication factors must come from different categories: something you know, something you have and something you are. Two passwords are not MFA, and a second factor adds security only when it is independent of the first. A phishing-resistant authenticator is a strong implementation choice, and a passwordless design can satisfy the standard when every factor is still enforced.

Service account and shared account rules

A service account is not a person, so the human rules fit it badly. Requirement 8.6 limits interactive login for service accounts, keeps their secrets out of scripts, and requires their passwords to be changed on a schedule set by a targeted risk analysis. Shared and generic IDs are allowed only as exceptions. Break-glass emergency accounts follow the same logic: store the secret in a vault, log every use and rotate it afterward.

Password Compliance Formula and Scoring

The score is deliberately simple, so you can reproduce it on paper. Each control scores one point when your setting meets or beats the minimum, and the total is divided by the controls checked:

$$\text{Score} = \frac{\text{controls passed}}{\text{controls checked}} \times 100$$

For a numeric floor such as length, the control passes when \(\text{your value} \geq \text{required value}\). For a ceiling such as failed attempts or rotation in days, it passes when \(\text{your value} \leq \text{required value}\). To compare unlike units on one scale, the chart below divides a floor by its requirement and a ceiling's requirement by your value, so 100% always means "meets the minimum":

$$\text{Strictness} = \frac{\text{your value}}{\text{required}} \quad\text{(floors)} \qquad \frac{\text{required}}{\text{your value}} \quad\text{(ceilings)}$$

Worked Example: A PCI DSS Compliance Assessment for a Small Merchant

Consider a regional online shop whose administrators sign in through Active Directory. Its password policy is a typical legacy one: 10-character minimum, letters plus numbers, three remembered passwords, a lockout after 15 failed attempts for 15 minutes, a 180-day change cycle for accounts without a second factor, first-use changes for temporary passwords, and MFA on administrator access to the payment systems. Running these values through the checker gives eight controls:

Three of eight controls pass, so \(3 \div 8 \times 100 = \mathbf{37.5\%}\). The biggest gaps are the lockout duration and the change cycle, which sit at only 50% of the standard. Raising the minimum length to 12 and the history to four takes two controls from fail to pass, while the lockout settings and the change cycle need configuration changes in the identity platform.

Testing a Payment Startup's Password Policy Against PCI Password Requirements

The IT lead at a 40-person subscription-billing startup has four weeks before a customer's vendor review. They open the directory's effective policy export and copy the values in: an 11-character minimum, letters plus numbers, 5 remembered passwords, lockout after 6 failed attempts for 20 minutes, a 120-day change cycle on accounts with no second factor, MFA on administrator access to the billing cluster, and a help-desk script that issues the same starter password to every new hire without forcing a change.

The checker returns 4 of 8 controls passing, a score of \(4 \div 8 \times 100 = 50\%\). Composition, history, the 6-attempt threshold and MFA pass. Length misses Requirement 8.3.6 by one character (strictness 11 ÷ 12 = 92%), the 20-minute lockout falls short of the 30 minutes in Requirement 8.3.4 (67%), the 120-day cycle exceeds the 90 days in Requirement 8.3.9 (75%), and the shared starter password breaks the first-use rule in Requirement 8.3.5.

The lead sees at once that three of the four failures are single-value edits. The directory gets a 12-character minimum and a 30-minute lockout the same afternoon, and the help-desk script now generates a unique temporary password that expires on first sign-in. On the re-run, the score reads 7 of 8, or 87.5%. Only the 120-day cycle remains, and the lead has two choices: shorten it to 90 days, or move the password-only accounts to MFA so Requirement 8.3.9 stops applying to them. Because the helpdesk dislikes extra resets, they pick MFA, schedule the rollout for the next two weeks, and attach both exports and both checker results to the vendor questionnaire as dated evidence.

Who Needs a PCI DSS Password Check and When

Organizations that store, process or transmit payment card data fall under the standard, whatever their size or transaction volume, and every one of them carries the same compliance duty for the accounts that touch that data. That covers the small web shop using a hosted payment page, the hotel chain with card terminals in every branch, and the software company that runs a payment platform for others. The scope of Requirement 8 differs between them, but the question the checker answers is the same: do the password rules for the people and systems in scope meet the written minimum?

Merchants and service providers

Merchants that validate with a self-assessment answer yes or no to password questions in the questionnaire, so a clear record of the settings behind each answer makes that attestation easier to defend. Service providers carry more obligations, including stricter rules for the credentials used to manage customer environments, and face a fuller assessment. If you host other businesses' payment data, run the checker for your own staff and for the administrative accounts you hold on behalf of customers.

Step-by-step: using the checker well

1. List the account populations: workforce users, administrators, service accounts and emergency accounts.
2. Pull the effective settings for each population from the platform that enforces them, not from the policy document.
3. Enter the values, noting whether the password is the only factor.
4. Review each failed control and its strictness figure, then write down the owner and a date for the fix.
5. Re-run after the change and file both results as evidence.

This routine takes minutes per population once the settings are at hand, and it turns the checker from a one-off curiosity into the first step of an audit-ready process. The people who benefit most are the ones who own the directory, because they can change a setting the same afternoon the checker flags it.

Reading Your PCI DSS Compliance Score

A single percentage hides a lot, so read the checker's result in three layers. The overall figure is the share of Requirement 8 controls your settings pass. The failures name the exact sub-requirement behind each miss. The strictness value shows how far each setting sits from the PCI DSS minimum, which decides how hard the change will be.

Score bands and what they mean

• 100%: every checked control meets its minimum. Move on to evidence, because the checker only vouches for the values you typed in.
• 75% to 99%: a few settings are off. These are usually quick directory changes such as history or lockout duration.
• 50% to 74%: the policy predates the current standard. Expect to change several controls and retest sample accounts.
• Below 50%: treat the policy as a rewrite. Start with the controls that protect administrator access to the cardholder data environment.

Why a pass is not a guarantee

The checker grades the values you supply, so it can be only as honest as the input, and honest input is the foundation of real compliance. Two accounts on the same server can follow different rules if one is local and one comes from the directory, and a system that cannot technically support a setting may quietly fall back to a weaker default. Run the checker once per platform or per account population when the settings differ, rather than once for the whole company, and treat any difference between the results as a finding in its own right.

Common Password Policy Gaps a Compliance Check Finds

The same gaps turn up again and again when merchants run a first compliance assessment. Knowing them in advance saves a round of rework.

• Legacy length. Older directories default to seven or eight characters, so the 12-character floor fails untouched.
• Lockout set for convenience. Help desks lengthen the threshold to cut unlock calls, which breaks the 10-attempt ceiling.
• Local accounts. Databases, network appliances and hypervisors keep their own local users, often with weaker security settings than the directory.
• Shared logins. One administrator ID used by several people removes accountability and fails the unique ID control.
• Stale defaults. A vendor account retained with its factory credential survives from installation day.

Customer Accounts, Legacy Systems and Compensating Controls

Not every population follows the workforce rules. Requirement 8 separates employees and administrators from customer accounts, which are the logins your shoppers use on your own site. Where the standard distinguishes the two groups, do not silently impose internal workforce rules on customers, and do not relax the workforce rules because customers are exempt from some of them. The checker's questions are written for staff and administrator accounts, so use it for those populations and document the customer-facing design separately.

When a system cannot meet the setting

Some older payment terminals, appliances and mainframe-era applications cannot store 12 characters or enforce a history. The standard does not pretend this never happens. If the limit is genuine, you document why the control cannot be met, describe the risk, and put compensating controls in place that achieve the same intent, for example stronger network segmentation, tighter monitoring of that system, and a longer secret held in a vault. A compensating control is not a shortcut: it has to be at least as effective as the requirement it replaces, and your assessor has to agree. Record every such exception in the same place as your policy so it surfaces during the next review instead of during an incident.

Passphrases and password managers

PCI DSS defines the outcome, not the tool. A long passphrase generated and stored by a password manager is often the best way to meet the length and uniqueness controls without burdening people, and it reduces the temptation to reuse a favourite across systems. The standard still judges the result: the passphrase must meet the minimum length and composition, the manager must be protected by multi-factor authentication, and administrators must not store shared infrastructure secrets in an unmanaged personal vault. Run the checker with the values the manager enforces and keep those same values in your evidence pack.

Evidence a Qualified Security Assessor Expects for PCI DSS Compliance

A passing score is useful, but PCI DSS compliance is proved with evidence, and becoming PCI compliant means showing it, not just claiming it. A qualified security assessor (QSA) tests whether the policy on paper matches the system in production, and for each control wants proof of the setting, the population it covers and the enforcement.

Effective policy and sample accounts

Export the effective policy from each platform, not just the group policy you intended to apply. Then pick sample accounts that could expose a weaker route: a local administrator, a service account, a recently reset user. Try a weak password, a reused password, a locked-out login and a reset through the help desk. Each test shows whether the written policy settings are really enforced.

Audit trail, logging and monitoring

Continuous monitoring matters here: lockouts, resets and administrator sign-ins should leave an audit trail that your logging and monitoring tools collect and review, with security alerts raised on repeated lockouts. Evidence of a failed-attempt alert is worth more than a screenshot of a threshold, because it proves the control is alive. Keep the documentation that ties each control to its owner, and give your security team a shared view of it, so an audit does not turn into a hunt for people and paperwork.

Password Compliance Checker Limits: Scan, Assessment and Validation

A tool that grades configuration values is a screening step, not certification. Some products run an outside-in compliance scan that reads TLS settings, security headers and encryption from the live site, which is useful website security hygiene, but a passive scan never sees how your internal passwords are configured. Vulnerability scanning and penetration testing find different problems again, such as exposed services and exploitable flaws. For formal validation, merchants still complete a self-assessment questionnaire or a full report on compliance, and the checker's results simply give those answers a firmer base. Where a system cannot meet a requirement for security or technical reasons, compensating controls or the customized approach may apply, both of which need documented risk analysis and assessor agreement.

Password Policy Compliance Beyond PCI: NIST, ISO 27001, SOC 2, HIPAA and GDPR

Most organizations, from small shops to large enterprises, answer to more than one framework, and a strong password design helps with all of them. NIST guidance favours length, screening for compromised passwords and fewer forced changes, while ISO 27001 and SOC 2 expect documented access rules and evidence that they are followed. HIPAA requires safeguards for health data access, and GDPR expects appropriate technical measures to protect personal data. A password manager and an identity provider with single sign-on make those goals easier, but they do not replace a stated PCI control unless the design satisfies it.

Fixing Compliance Gaps: A Remediation Plan

Once the checker flags compliance failures, work the list in order of risk, not in order of effort.

How often to run the checker

Compliance is not a one-time event, so run it whenever a setting changes, before each assessment cycle, and after any acquisition or platform migration that adds new login systems. A quarterly habit is a sensible minimum for an active environment: policies drift when a directory upgrade resets a default, when a help-desk exception becomes permanent, or when a new application ships with its own local administrator. Keep each run's inputs and results with a date, so you can show an assessor that you test continuously rather than once a year, and so you can see at a glance whether your score is improving or slipping.

Order of fixes

1. Raise length and history first, the quickest security gain; most directories change both with one setting.
2. Tighten lockout threshold and duration, and add an alert for repeated lockouts.
3. Decide for each password-only account between a 90-day cycle and the dynamic-analysis alternative, or add a second factor.
4. Inventory service accounts, assign owners and move their secrets into a vault with scheduled rotation.
5. Re-run the checker, collect evidence, and give your people security training on resets and shared logins.

Every failed control is a vulnerability that attackers can use to gain unauthorized access. A data breach involving a credit card number costs far more than a policy change, and basic cybersecurity hygiene is also the cheapest defence against every threat that targets payment systems. Treat the checker as a repeatable compliance and security habit: run it after each policy change, each new network segment, and each new administrator role, and keep the result with your access control records.

Frequently Asked Questions

Is this an official PCI DSS assessment tool?

No -- formal PCI DSS compliance is determined through a Report on Compliance or Self-Assessment Questionnaire conducted with a Qualified Security Assessor or your acquiring bank, not a browser checklist. This tool is a quick self-assessment against Requirement 8's password-specific practices, meant to surface obvious gaps before that formal process.

Why does PCI DSS offer two options for password rotation?

PCI DSS v4.0 introduced an alternative to fixed 90-day rotation: if an organization dynamically analyzes the security posture of an account in real time and denies access automatically upon detected compromise, it can forgo mandatory periodic rotation entirely. Most organizations without that kind of real-time monitoring in place should stick with the 90-day requirement.

Does PCI DSS require multi-factor authentication for everyone?

It requires MFA for all access into the cardholder data environment (CDE) -- both for remote access from outside the network and, as of PCI DSS v4.0, for all access into the CDE generally, not just administrative access. Check the current requirement text for your specific environment's scope.

What counts as 'compensating controls' for the 8-character minimum?

PCI DSS allows a shorter 8-character minimum only when documented compensating controls (additional monitoring, stronger lockout policies, MFA, etc.) offset the reduced length, and this must be formally assessed and approved as part of your compliance process -- it isn't a default fallback you can assume applies.

Where can I read the actual PCI DSS Requirement 8 text?

The PCI Security Standards Council publishes the full PCI DSS v4.0 standard, including Requirement 8's complete identification and authentication requirements, on its official website -- this checklist summarizes the password-specific items most relevant to a typical system.