PCI DSS v4.0.1 for Linux servers: what the requirements mean on a real machine
Standard: Payment Card Industry Data Security Standard, v4.0.1 (published June 11, 2024) Owner: PCI Security Standards Council Applies to: anyone who stores, processes or transmits payment card data, or can affect the security of the systems that do
PCI DSS is a contractual standard from the card brands, not a law by itself (a few US states reference it in their own laws). It is validated by a Qualified Security Assessor (QSA) or by a self-assessment questionnaire (SAQ), depending on your size and how you take cards. This sheet shows what the technical requirements mean for a Linux server. It is not legal or audit advice: your QSA or acquirer decides what applies to you, and PCI DSS is a whole-organisation programme (policies, people, networks, vendors), not just server settings.
Timeline (checked 2026-09-29): v4.0.1 is a limited revision of v4.0 with no requirements added or deleted. v4.0 was retired on 31 December 2024. The requirements that were "future-dated" in v4.0 became mandatory on 31 March 2025, so v4.0.1 is now the only active version and all of them must be met.
Requirement numbers below follow v4.0.1. The Council's PDF sits behind its document library (a licence click-through) and could not be fetched automatically, so the numbers and values here were cross-checked against several published summaries. Read the official text for your assessment.
Step zero: scope
Only systems in or connected to the cardholder data environment (CDE) are in scope. The cheapest, safest way to stay compliant is a SMALL scope: use a payment provider's hosted page or tokenisation so card numbers never touch your servers, keep in-scope systems on their own network segment, and document it. Everything else in this sheet then applies to a few machines, not all of them. Scope must be confirmed and documented (Requirement 12.5.2, at least every 12 months).
The requirements that hit a Linux server, and what to do
Req What it says (short) On Linux
1.x Network security controls restrict traffic to what is needed Default-deny host firewall (ufw / firewalld) plus network ACLs and security groups; document allowed ports.
2.2.1 Configuration standards, based on industry-accepted hardening A CIS Benchmark (or STIG) is the usual standard. Write down which one and which profile.
2.2.2 Vendor default accounts are managed Remove or disable default accounts, change default passwords, no shared logins.
2.2.4 Only necessary services, protocols, daemons and functions on ss -tulpn and systemctl list-unit-files --state=enabled: remove or disable everything not needed.
2.2.5 Insecure services are justified and secured No telnet/ftp/rsh. If something insecure must stay, document why and how it is protected.
2.2.6 System security parameters set to prevent misuse sysctl hardening, file permissions, SSH settings.
2.2.7 All non-console administrative access uses strong cryptography SSH (keys, no telnet), TLS for web consoles.
3.5.1 Stored PAN is rendered unreadable LUKS covers the disk, but is NOT enough alone if users can read the data while the system runs: use application/database-level protection or tokenisation.
4.2.1 Strong cryptography for card data over open networks TLS 1.2 or newer, valid certificates, no old ciphers.
5.2.x Malware protection on systems commonly affected by malware Linux servers are often treated as lower risk, but 5.2.3 requires a DOCUMENTED, periodically re-evaluated list of systems "not at risk". Many organisations simply deploy an endpoint agent or ClamAV plus scheduled scans.
6.3.1 Vulnerabilities are identified and risk-ranked Subscribe to your distribution's security advisories.
6.3.3 Patches for critical vulnerabilities installed within one month of release; others within a timeframe based on risk unattended-upgrades or dnf-automatic, plus a kernel reboot process. Keep the patch records.
7.2.x Least privilege; access reviewed (7.2.4: at least every six months) Groups and sudoers by role; a review ticket every six months for user accounts.
8.2.1 Every user has a unique ID No shared accounts, ever.
8.2.8 Session idle for more than 15 minutes must re-authenticate SSH: ClientAliveInterval 300 / ClientAliveCountMax 2. Shell: TMOUT=900 (read-only in /etc/profile.d/). Screen lock on consoles.
8.3.4 Lock the account after not more than 10 failed attempts, for at least 30 minutes (or until identity is confirmed) pam_faillock: deny = 5-10, unlock_time = 1800 or more.
8.3.6 Passwords of at least 12 characters (8 only if the system cannot support 12), plus complexity pwquality: minlen = 12 or more. Better: SSH keys and MFA.
8.4.2 MFA for all access into the CDE MFA on SSH and consoles that reach the CDE (for example an OTP/PAM module, an identity provider, or hardware tokens). Keys alone do not count as MFA unless they are combined with a second factor.
8.4.3 MFA for remote access into the network from outside VPN with MFA.
8.6.x System and application accounts are managed No interactive logins for service accounts, no hard-coded passwords, credentials in a vault.
10.2.1 Audit logs on all system components (10.2.1.1 to 10.2.1.7: user access to cardholder data, admin actions, access to the logs, failed access, changes to identity and authentication, start/stop of the logs, creation/deletion of system objects) auditd rules for /etc/passwd, shadow, sudoers, sshd config, module loading, time changes and admin commands; keep journald persistent.
10.3.x Logs are protected from change and access Central log server, restricted permissions, remote copy.
10.4.1.1 Automated mechanisms review audit logs A SIEM, log server alerts, or a tool such as Wazuh / Graylog / Elastic. "Someone reads them" is not enough.
10.5.1 Retain audit log history for at least 12 months, with the most recent three months immediately available for analysis Retention on the log server: three months online, the rest in cheaper storage.
10.6.x Time synchronisation chrony or systemd-timesyncd against trusted servers; monitor drift.
11.3.x Regular vulnerability scans (internal and external) Quarterly internal scans and quarterly external scans by an Approved Scanning Vendor; rescan after fixing.
11.5.2 Change-detection mechanism (file integrity monitoring) alerts on unauthorised changes to critical files, comparing at least weekly AIDE, Wazuh FIM or an agent. Schedule the check weekly or more often.
12.3.1 Targeted risk analysis where a requirement lets you choose the frequency Write it down, for example how often you review "not at risk for malware" systems.
Quick checks on a server
sudo ss -tulpn # 2.2.4: what is listening
systemctl list-unit-files --state=enabled --type=service # 2.2.4: what starts at boot
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|clientalive|maxauthtries|allowgroups' # 2.2.6, 2.2.7, 8.2.8
sudo grep -E 'deny|unlock_time' /etc/security/faillock.conf # 8.3.4
sudo grep -E 'minlen' /etc/security/pwquality.conf # 8.3.6
echo $TMOUT # 8.2.8: idle timeout for shells
sudo auditctl -l # 10.2: audit rules that are live
timedatectl status ; chronyc tracking # 10.6: time in sync
sudo aide --check # 11.5.2 (Ubuntu: sudo aide.wrapper --check)
sudo dnf updateinfo list security or apt list --upgradable # 6.3.3: pending patches
Set an idle timeout for shells (read-only so users cannot unset it), in /etc/profile.d/tmout.sh:
readonly TMOUT=900
export TMOUT
Scanning and automation
Red Hat family: scap-security-guide ships a pci-dss profile. Check which PCI DSS version it targets before relying on it:
oscap info --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
sudo oscap xccdf eval --profile pci-dss --results pci-results.xml --report pci-report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml
Ubuntu: use a CIS profile (usg audit cis_level1_server) as your documented configuration standard for 2.2.1. See the OpenSCAP, USG and Lynis sheet for commands and warnings.
A green scan supports the technical requirements. It does not cover policies, network diagrams, training, vendor management or the SAQ or Report on Compliance itself.
Evidence an assessor will ask for
- Your configuration standard (for example "CIS Ubuntu 24.04 Level 1 Server v2.0.0") and scan reports against it.
- A network diagram and data-flow diagram with the CDE marked.
- Lists of accounts, sudoers, and the last access review.
- Patch records and vulnerability scan reports (internal, external, rescans).
- Sample logs showing the required events, plus proof of retention (12 months, 3 immediately available).
- Screenshots or command output for settings (sshd -T, faillock.conf, pwquality.conf, TMOUT).
- Change tickets for hardening changes.
Save the command output with a date instead of screenshots when you can: it is easier to repeat next year.
Common problems
"Are Linux servers exempt from anti-malware?": not automatically. 5.2.3 lets you exclude systems that are not at risk, but only with a documented list, an evaluation of evolving threats, and a periodic re-check.
"We use SSH keys, so is that MFA?": a key alone is one factor (something you have). Assessors usually want a second factor for CDE access. Ask your QSA how they treat key plus passphrase, and use a real second factor to be safe.
"Our logs are only kept 30 days": 10.5.1 needs at least 12 months, with three months immediately available. Set retention on the central log server.
"We patch monthly, is that enough?": critical patches must be installed within one month of release. Plan for faster than that. Also plan the reboot: a kernel patch does nothing until the reboot.
"Everything is in scope because it is all on one flat network": segment the CDE. It shrinks both the risk and the audit.
"We passed the scan but failed the assessment": scans do not cover policies, reviews, evidence or people. Requirement 12 is a large part of the standard.
"A rule in the CIS profile conflicts with an app": tailor it out and record the exception with the risk decision.
Tips
Avoid touching card numbers: hosted payment pages and tokenisation remove most of the pain.
Give the CDE its own accounts, its own admin path (jump host with MFA) and its own logging.
Automate evidence (a scheduled job that saves sshd -T, account lists and scan reports into a dated folder).
Track the requirement numbers next to each control in your runbook: it saves hours when the assessor arrives.
The standard was already updated once. Check the PCI SSC document library each year for changes, FAQs and guidance.
"Compliant" is a moment in time. "Secure" is what you do on the other 364 days.