A practitioner’s guide to Requirement 8 of PCI DSS v4.0.1 (and the parts of Requirement 2 that go with it). Reviewed by the Oreaxe editorial team, June 2026. This is editorial guidance for small and mid-sized merchants — not a substitute for a formal assessment by a Qualified Security Assessor (QSA).
PCI DSS 4.0.1 authentication is where many card-data assessments are won or lost. Most cardholder-data breaches don’t start with an exotic zero-day. They start with a credential — a default account nobody renamed, a service password hard-coded in a config file, a VPN login that was valid five years ago and never rotated. That is why the PCI Security Standards Council rewrote authentication so heavily in version 4.0, and why Requirement 8 is one of the areas assessors scrutinize hardest. Weak credentials remain the entry point behind a large share of the threats small businesses face.
This guide walks through the authentication and credential controls the way an assessor reads them — not as a list of password rules, but as defenses against the most common path attackers take into a network. Wherever a requirement maps to a real-world failure, we say so, and we flag what it means specifically for a smaller merchant.
PCI DSS 4.0.1 authentication: what changed — and what didn’t
There is persistent confusion here, so it is worth settling up front. PCI DSS v4.0 was the major rewrite. v4.0.1 is a limited revision — it corrects formatting, resolves typos, and adds clarifications and guidance. It does not add or remove any requirements. If you built your program around v4.0, you are not facing a fresh set of obligations; you are working from a cleaner version of the same standard.
Two clarifications in v4.0.1 matter for this topic specifically, and we cover both below: the treatment of phishing-resistant authentication, and the scope of multi-factor authentication for non-administrative access.
The other thing that trips people up is timing. v4.0 introduced a set of future-dated requirements — controls that were best practice until a hard deadline, after which they became mandatory. That deadline has passed. The future-dated authentication controls described here, including the stronger password and MFA rules, are now in force. “We’ll get to it before the deadline” is no longer an available answer.
Requirement 8: the credential controls, one by one
Requirement 8 governs identification and authentication — how users and system accounts prove who they are. Here is how the major sub-requirements read in practice.
Password length and composition (8.3.6)
The headline change everyone remembers: minimum password length moved from 7 characters to 12 characters, with both numeric and alphabetic characters required. Where a system genuinely cannot support 12, the floor is 8 — but that is a fallback for technical limitation, not a default you choose for convenience. An assessor will expect you to justify any 8-character configuration, not just assert it.
What gets flagged in the field: legacy systems and embedded appliances that silently cap password length below the requirement. For an SMB, the usual culprits are concrete: a budget point-of-sale terminal, an older NAS holding backups, or a router admin panel that won’t accept more than eight characters. Inventory those before the assessment, because the fix is sometimes a setting and sometimes a firmware or vendor change you can’t make overnight.
Password change frequency and the modern alternative (8.3.9)
Here the standard quietly modernized. The old reflex — force a password change every 90 days for everyone — is no longer the only path, and in many cases is no longer required at all.
If passwords are the only authentication factor, you must either rotate them every 90 days or dynamically analyze the account’s security posture in real time and respond to signs of compromise. The second option reflects where the industry has moved: continuous, risk-based evaluation rather than blunt periodic resets that push users toward predictable patterns (Password1, Password2, and so on).
The practical takeaway: if an account is protected by MFA, the rigid 90-day reset generally falls away. That is a feature, not a loophole — it rewards organizations that have implemented stronger authentication. For a small team, turning on MFA for the handful of accounts that reach the payment environment is usually less painful than policing quarterly password resets across the whole company.
Password reuse, lockout, and inactive accounts (8.3.4, 8.3.7, 8.2.6)
These are the controls that quietly catch the most findings because they are easy to overlook in configuration:
- Reuse: the previous four passwords cannot be reused. A user cannot cycle back to an old favorite.
- Lockout: accounts must lock after no more than six consecutive failed attempts, and stay locked for at least 30 minutes or until an administrator resets them. This is a direct brute-force defense — six guesses is not enough for an attacker to win, so they move on.
- Inactive accounts: accounts inactive for more than 90 days must be disabled. Dormant accounts are a favored foothold precisely because nobody is watching them.
The classic SMB version of this finding: the login for a seasonal hire or a contractor who finished months ago, still active “just in case.” That is the account an attacker wants. Disable accounts at offboarding, not at audit time.
Multi-factor authentication: the biggest shift (8.4.2, 8.5.1)
This is the change with the largest operational footprint. Under PCI DSS 3.2.1, MFA was required only for administrative access to the CDE and for remote access into the network. Under v4.0, MFA is required for all access into the cardholder data environment — administrator and non-administrator alike. (As v4.0.1 clarifies, this does not apply where a phishing-resistant factor alone is used for non-administrative access.)
A concrete SMB picture: a small online store where the owner and two staff log into the payment dashboard. Previously only the owner’s admin login might have needed MFA; now every one of those logins does. For many organizations this is the requirement that demands real engineering work, not a policy update.
Requirement 8.5.1 then governs how MFA must be implemented. An assessor checks that:
- the factors are independent (compromising one does not grant the other);
- the system is resistant to replay attacks;
- access is not granted until all factors are presented.
In other words, bolting a weak second factor onto a login is not enough — the implementation itself is assessed. Where v4.0.1 clarifies the picture: a phishing-resistant factor (FIDO-based methods are the common example) can substitute for MFA for non-administrative access into the CDE. It is referenced as a preferred approach, not mandated — but it points clearly at the direction of travel. Pairing strong authentication with well-chosen endpoint protection tools closes a large part of the credential-theft gap.
System and service accounts: where real breaches live (8.6.1–8.6.3)
If you read only one section of this guide, read this one, because it addresses the failure pattern behind a striking number of real incidents.
Requirement 8.6 covers application and system accounts — the non-human credentials that scripts, services, and integrations use. The sub-requirements address the things that go catastrophically wrong:
- Hard-coded credentials in scripts, configuration files, and source code must not be left exposed. This is the silent killer: a password sitting in plaintext in a config file that gets copied, committed to a repository, or extracted from a compromised appliance.
- Passwords for application and system accounts must be protected against misuse and changed periodically (or on a defined trigger), with their use managed and monitored.
The SMB version isn’t hypothetical: the API key pasted into a WooCommerce or Shopify config, the database password in a website’s wp-config, or the stored login for a booking or accounting integration. These rarely get rotated and often outlive the person who set them up. This is also the exact territory of large-scale credential-harvesting campaigns against perimeter appliances — the kind tracked in ongoing threat advisories. When attackers extract configuration files from internet-facing devices and crack the stored credentials, they are exploiting precisely the gap these requirements exist to close.
The assessor’s quick checklist
Strip away the prose and this is what an assessor is actually verifying. Walk this list before they do:
- MFA on every path into the CDE — admin and non-admin — with independent, replay-resistant factors, and no access granted until all factors are presented.
- Passwords at least 12 characters (numeric + alphabetic); any 8-character exception backed by a documented technical justification.
- Lockout after ≤6 failed attempts for ≥30 minutes; no reuse of the last four passwords; inactive accounts disabled at 90 days.
- Password-only accounts either rotated every 90 days or covered by continuous risk-based analysis.
- A complete inventory of accounts with CDE access — human and service/system accounts.
- No hard-coded credentials in scripts, config, or source; service-account passwords protected, rotated, and monitored.
- Evidence for each control: policy/configuration screenshots, MFA enrollment records, and logs showing failed logins and lockout events.
For smaller merchants, the gap between compliance-on-paper and compliance-in-practice is where most findings originate. Close it before the assessor finds it for you.
Key documents and resources
Work from the primary sources rather than second-hand summaries:
- The PCI SSC Document Library — the full PCI DSS v4.0.1 standard and the Summary of Changes from v4.0.
- The Prioritized Approach for PCI DSS v4.0.1 tool, which sequences the controls by risk — useful when you can’t do everything at once.
- The right Self-Assessment Questionnaire (SAQ) for how you take payments (for example SAQ A for fully outsourced e-commerce, SAQ A-EP, or SAQ D).
Have ready the artifacts in the checklist above — a current account inventory, password and MFA configuration, and the logs that prove the controls are running, not just written down. Authentication is not a one-time project; review it, test it, and collect evidence on at least a quarterly cycle.
Securing more than payments?
Browse our independently reviewed security tools for SMBs, or keep reading our small-business security guides.
Muhammad Saqlain is the founder of Oreaxe and a digital transformation and cybersecurity consultant. He helps small and mid-sized businesses modernise their operations and meet real security and compliance requirements — PCI DSS, ISO 27001, and SOC 2 — without the jargon or the fear-selling.
Mubbashir Ali has spent 17+ years in the engine room of enterprise IT — running multi-cloud infrastructure, hardening Linux fleets, and hunting vulnerabilities with OpenVAS and Nessus. A Certified Ethical Hacker (CEH v12) and AWS Solutions Architect, he leads IT operations by day and brings the hands-on technical depth — the actual scanning, hardening, and incident response — to Oreaxe's security coverage.