PCI Password Requirements and MFA Rules

The password rules, setting by setting

Requirement 8 reads like the settings page of a login screen, because that is what it is. Most of it is a number you can type into a box: a length, a count of wrong tries, a number of minutes, a number of days. The core password rule is 8.3.6: passwords need “A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters)” and must contain both numbers and letters. It does not apply to POS terminal accounts that can reach one card number at a time.

The last column is the exception every shop owner should know. Most of these lines carry the same note in the standard: they are not meant for user accounts on point-of-sale terminals that see only one card number at a time for a single sale. A cashier's sign-in on the card terminal is not what Requirement 8 is aiming at. The back-office login that sees the day's sales, the payment portal, and your website's admin are.

One line changes how often you rotate. Under 8.3.9, where a password is the only factor, it is changed “at least once every 90 days,” or the account's security posture is analyzed dynamically. Put MFA on the account and the 90-day rule stops applying to it: the requirement “does not apply to in-scope system components where MFA is used.”

What v4.0 changed, and what has applied since 31 March 2025

The new requirements that PCI DSS v4.0 introduced as best practices became mandatory on 31 March 2025. For logins that meant longer passwords and MFA for far more people. The standard's own grace note shows the old floor: “Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.”

Source: PCI SSC, Prioritized Approach Tool, 8.3.6 note, 8.4.1 and 8.4.2, read on 2026-10-22

The same note sits on 8.6.1, 8.6.2 and 8.6.3, which govern system and application accounts that a person can also log into: interactive use only by exception, no passwords hard-coded in scripts or config files, and changes at a frequency set by your own targeted risk analysis. They reach you only if some software in your setup has a login of that kind.

Version 4.0.1, the wording revision of June 2024, added one carve-out to MFA. The Council lists it as an applicability note that MFA for all non-administrative access into the CDE “does not apply to user accounts that are only authenticated with phishing-resistant authentication factors.”

Source: PCI SSC blog, Just Published: PCI DSS v4.0.1, read on 2026-10-22

Shared logins at the till

The first rule of Requirement 8 is that every person is a separate person. 8.2.1 says all users are assigned a unique ID before they get access to system components or cardholder data. A shared “till” or “manager” account is the thing it forbids, with one narrow way back in.

Read the last line again: every action traced to one person. A login the whole Saturday shift shares cannot meet it, so in practice the exception is for an emergency, not for the rota. The card terminal is the exception the standard writes in itself. Both 8.2.1 and 8.2.2 are “not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.”

The vendor line has its own rule. Under 8.2.7, accounts that third parties use for remote access are “Enabled only during the time period needed and disabled when not in use,” and their use is monitored. If your POS reseller can dial in at any hour on a standing account, that is the gap.

Vendor and default passwords

Every terminal, router and POS install arrives with an account somebody else knows the password to. The Council's glossary puts it plainly: “Default accounts and passwords are published and well known, and therefore easily guessed.” That is why the rule sits in Requirement 2, secure configuration, and points back to the password length in Requirement 8.

“If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. If the vendor default account(s) will not be used, the account is removed or disabled.”

Req. 2.2.2, PCI DSS v4.0.1

The new password has to meet 8.3.6, so at least 12 characters with letters and numbers, not the vendor's word with a digit added. The same thinking covers the passwords you hand out: under 8.3.5 a first-time or reset password is unique to the user and must be changed straight after first use, so the welcome password you give every new starter is a default of your own making. On Wi-Fi connected to your card systems or carrying card data, 2.3.1 adds the wireless defaults, access point passwords and encryption keys included; the firewall and router guide covers that side.

MFA for remote access and for access into the CDE

Multi-factor authentication checks at least two of: something you have, something you know, something you are. Where it is required is the part people get wrong. MFA is required for all non-console access into the cardholder data environment (8.4.2, which includes admins under 8.4.1), and for all remote network access from outside your network that could reach or affect it (8.4.3).

“Non-console” is any login over a network rather than at the machine's own screen and keyboard, and the glossary is explicit that it “includes access from within local/internal networks as well as access from external or remote networks.” The office PC logging in to the till server across the shop counts. So does a web login: the MFA rules cover “web-based access to an application or function,” and cloud and hosted systems as well as the ones in the back room.

Each leg has its own escape hatch. Into the CDE, MFA can sit at the network or at each system; it “does not have to be applied at both levels.” For remote access, a connection that lands on a part of your network properly segmented from the CDE does not need it, though the Council still recommends MFA for all remote access. And the remote rule names who it covers: “vendors, suppliers, service providers, and customers” as well as your staff. The POS reseller who logs in to fix the till is on that list.

“Applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access.”

Req. 8.4.2, PCI DSS v4.0.1

Two passwords are two of the same type, so they are not MFA. And the v4.0.1 carve-out for phishing-resistant factors is narrower than it sounds: the glossary says factors that rely on passwords or one-time passwords “are not considered phishing resistant, nor are SMS or magic links.” A text-message code does not earn the exception.

Which SAQs carry Requirement 8

Not every questionnaire asks about passwords. Our checklist carries Requirement 8 lines for SAQ A, SAQ A-EP, SAQ C-VT, SAQ C, SAQ D. It has none for SAQ B, SAQ B-IP, SAQ P2PE, SAQ SPoC. The table reads straight from the checklist's data; open your SAQ's checklist from its column head.

“Yes” means our checklist shows the line for that SAQ; it is our reading of each SAQ's eligibility text and each requirement's scope. SAQ D carries all requirements, so the rest of Requirement 8 is on it too. Your SAQ form has the final list.

Source: PCI SSC, SAQ Instructions and Guidelines v4.0.1 r1, p. 10, read on 2026-10-22

Check your own password policy

Answer for the systems that touch card data, not for every login you own. Each question is a setting you can read off a settings screen or ask your provider about, so the check never needs a password. It shows the questions our checklist carries for your SAQ, marks each answer against the requirement's wording, and copies or prints as a record for your files.

“Does not apply” follows the standard's own exceptions: the card terminal that sees one card at a time, accounts already behind MFA, phishing-resistant sign-in, and remote access that cannot reach card systems. “Find out” means ask whoever set the system up; a guess is not an answer you can sign.

Quick reference