PCI DSS Requirement 5 Guide: Anti-Malware, Removable Media and Anti-Phishing Controls

Requirement 5 decides whether malicious code that reaches a payment environment is stopped, contained and recorded, and since 31 March 2025 it also expects automated defences against the phishing that so often delivers it. This guide covers PCI DSS v4.0.1 Requirement 5, "Protect All Systems and Networks from Malicious Software", section by section: where anti-malware must run and how to document systems not at risk (5.2), keeping it current, scanning, removable media, logging and tamper protection (5.3), and anti-phishing mechanisms (5.4.1). It is written for endpoint and server security engineers, SOC leads and PCI programme owners preparing evidence for a Qualified Security Assessor (QSA) or a self-assessment. Requirement text is paraphrased from the standard as reproduced by Microsoft Learn and other secondary sources; check every point against the current standard in the PCI SSC Document Library.

Source note: requirement wording is paraphrased from PCI DSS v4.0.1 as reproduced by secondary sources (the ComplianceAsCode PCI DSS v4 control file and Microsoft Learn) and from PCI SSC publications, because the standard itself is a PDF in the PCI SSC Document Library. Confirm against the official text before relying on it.

Key takeaways

• Anti-malware is the default everywhere: 5.2.1 requires a solution on all system components except those a periodic evaluation under 5.2.3 concludes are not at risk from malware, so the exemption must be earned and re-checked.
• "Not at risk" is a documented, recurring decision: 5.2.3 needs a list of such components, an evaluation of evolving threats to them and confirmation they still need no protection, at a frequency set by a targeted risk analysis (5.2.3.1).
• Behavioural detection is an accepted option: 5.3.2 is met by periodic plus real-time scans, or by continuous behavioural analysis of systems or processes, which is how most EDR tools operate.
• Users cannot switch it off: 5.3.5 forbids users disabling or altering anti-malware unless management authorises it case by case, in writing, for a limited time.
• Phishing protection must be automated: 5.4.1 requires processes and automated mechanisms to detect and protect personnel against phishing, so awareness training alone does not meet it.

How Requirement 5 is structured

Requirement 5 has four sections. Several sub-requirements were new in v4.0 and became mandatory on 31 March 2025, when the PCI SSC says the 51 future-dated requirements of v4.x took effect; v4.0.1 (June 2024) added or deleted no requirements, according to the PCI SSC. The wider standard is summarised in the PCI DSS 4.0 Guide.

5.2: deployment, capability and systems not at risk

5.2.1 coverage: the starting point is the in-scope inventory under 12.5.1. Compare it with the anti-malware console's device list every month at least; the difference is your coverage gap. Include virtual desktops, jump hosts, payment application servers, file servers that receive uploads and cloud workloads.

5.2.2 capability: the solution must detect all known types of malware and remove, block or contain them. Detection-only modes (audit or passive) meet the first half but not the second, so check that remediation actions are switched on in policy, not just available in the product.

Allowlisting as an alternative: a PCI SSC FAQ says application allowlisting can be acceptable only if the implementation meets every Requirement 5 sub-requirement, including detecting, removing and protecting against malware, and notes that many allowlisting products cannot do the detection and removal parts on their own. Allowlisting is therefore usually a strong complement, not a replacement. See the Application Allowlisting Guide.

5.2.3 systems not at risk: as reproduced on Microsoft Learn, the periodic evaluation includes a documented list of all components not at risk for malware, identification and evaluation of evolving malware threats for those components, and confirmation whether they continue not to require protection. Common candidates are some network appliances, mainframes and hardened Linux or Unix systems with no user-facing services. The question to ask each time is whether malware now targets that platform, for example ransomware families built for hypervisors or Linux servers.

5.2.3.1 requires the evaluation frequency to be defined in a targeted risk analysis performed according to all elements of 12.3.1. See the PCI DSS Customised Approach and Targeted Risk Analysis Guide.

5.3: keeping anti-malware active, maintained and monitored

• 5.3.1 automatic updates: signatures and engines update automatically. Alert on endpoints whose definitions are older than your threshold, because a failed update is silent otherwise.
• 5.3.2 scanning model: periodic scans plus active or real-time scans, or continuous behavioural analysis of systems or processes. If you rely on periodic scans, 5.3.2.1 requires their frequency to come from a targeted risk analysis.
• 5.3.3 removable media: the solution automatically scans removable electronic media when it is inserted, connected or logically mounted, or performs continuous behavioural analysis when that happens. Many organisations go further and block removable storage on CDE systems entirely, which removes most of the evidence burden. See the Removable Media and USB Control Guide.
• 5.3.4 audit logs: anti-malware logs are enabled and retained according to 10.5.1. Forward detections, policy changes, agent stops and update failures to the central log platform. See the PCI DSS Requirement 10 Guide.
• 5.3.5 tamper protection: users cannot disable or alter anti-malware unless specifically documented and authorised by management case by case for a limited period. Use the product's tamper protection, remove local administrator rights from users, and protect the management console as a privileged system.

Disabling security tools is a standard attacker step, tracked by MITRE ATT&CK as T1685 Disable or Modify Tools, often achieved with vulnerable drivers. Failure of anti-malware is one of the critical security control failures that 10.7.2 requires to be detected, alerted and addressed promptly. See the Bring Your Own Vulnerable Driver and EDR Killers Guide and the EDR Tuning and Exclusions Management Guide.

Where identity fits

The anti-malware management console holds a powerful non-human identity: it pushes code and policy to every endpoint, and its API keys and service accounts can disable protection estate-wide. Treat the console and its integration credentials (SIEM connectors, SOAR playbooks, MDM links) as privileged, with MFA for administrators, scoped API tokens and rotation. Exclusions are also an access decision: each one should have an owner and an expiry, because a broad path exclusion is the easiest place for malware to hide. See the EDR Platform Configuration Guide.

5.4.1: anti-phishing mechanisms

5.4.1 requires processes and automated mechanisms to be in place to detect and protect personnel against phishing attacks. It became effective on 31 March 2025 with the other future-dated requirements. Awareness training is covered separately under 12.6.3.1, so training on its own does not meet 5.4.1. A PCI SSC community meeting presentation on 5.4 best practice recommends combining anti-spoofing controls: SPF, DKIM and DMARC.

SPF, DKIM and DMARC protect others from mail that spoofs your domain; inbound filtering and link protection protect your own staff. Assessors increasingly expect both. Microsoft's mapping for Entra ID points to phishing-resistant credentials and Conditional Access authentication strength as the identity part of 5.4.1, and notes that broader phishing mitigation needs workload controls such as mail anti-phishing protection. DMARC was originally published as RFC 7489 (Informational, March 2015); the RFC Editor now lists it as obsoleted by RFCs 9989 to 9991. See the DMARC, SPF and DKIM Guide and the DMARCbis Changes Guide.

Social engineering against credentials remains a common first step in major incidents: the Uber breach combined a contractor's stolen password with MFA fatigue prompts, which is why phishing-resistant authentication belongs in the 5.4.1 evidence pack alongside email controls.

Decision guidance

• Traditional antivirus or EDR: signature-based antivirus with scheduled scans meets 5.3.2 with a targeted risk analysis for scan frequency; EDR with continuous behavioural analysis meets it without one and also supports 10.7.2 heartbeat monitoring. Most entities with a SOC choose EDR. See the EDR Guide.
• Exempting systems or protecting them: exempting a platform under 5.2.3 saves licences but creates a recurring evaluation and a risk of being wrong. Where a supported agent exists and performance is acceptable, deploying it is often cheaper than defending the exemption.
• Scan removable media or block it: blocking storage-class USB devices on CDE systems is simpler to evidence than scan-on-mount, but needs an exception path for legitimate uses such as firmware updates.
• Small merchants: a managed endpoint protection service plus the email provider's built-in anti-phishing and a DMARC record usually covers 5.2 to 5.4 for a small estate. Large entities need coverage reconciliation, central logging and policy-as-code.

How to implement Requirement 5

1. Reconcile coverage: compare the in-scope inventory with the anti-malware console and list every component without an agent.
2. Decide exemptions: for each uncovered component, deploy an agent or document a 5.2.3 evaluation; write the 5.2.3.1 targeted risk analysis for evaluation frequency.
3. Pilot policy in audit mode: apply the target policy (real-time or behavioural protection, removable media control, tamper protection) to a pilot ring in detect-only mode, review false positives and performance, then switch to block. Keep the previous policy version so it can be restored quickly if a payment application breaks.
4. Roll out by ring: extend from pilot to non-critical then critical CDE systems, with change records.
5. Lock it down: enable tamper protection, remove local admin rights, and create a documented, time-limited exception process for 5.3.5.
6. Connect the logs: forward detections, health and policy-change events to the SIEM, retain them per 10.5.1, and alert on agent silence and update failures.
7. Deploy anti-phishing: publish SPF and DKIM for all sending services, start DMARC at p=none, read aggregate reports, then move to quarantine and reject; enable inbound filtering and link protection.
8. Collect evidence continuously: monthly coverage reports, exemption reviews, exception approvals and DMARC reports.

Detection and measurement

Framework mapping

In ISO/IEC 27001:2022 Annex A, Requirement 5 aligns most closely with control 8.7 Protection against malware. NIST SP 800-83 Rev. 1 remains NIST's guide to malware incident prevention and handling for desktops and laptops. See also the CIS Control 10 Malware Defenses Guide.

Common failure patterns

• Linux left out by habit: "Linux does not get malware" exemptions copied from old assessments, with no 5.2.3 threat evaluation behind them.
• Detect-only in production: a policy set to audit during rollout and never switched to block, failing 5.2.2.
• Broad exclusions: whole application directories or file types excluded to fix a performance problem, never reviewed.
• Silent agents: agents uninstalled during troubleshooting or broken by upgrades, with no alert on missing heartbeats.
• Training counted as 5.4.1: a phishing simulation programme presented as the anti-phishing mechanism with no automated email controls.
• DMARC stuck at p=none: a record published years ago for monitoring, with nobody reading the reports.

Practitioner checklist

• Reconcile anti-malware coverage against the 12.5.1 inventory every month (5.2.1).
• Confirm remediation actions are enabled, not just detection (5.2.2).
• Keep a 5.2.3 list of exempt components with threat evaluations, at a frequency set by targeted risk analysis.
• Alert on stale definitions and silent agents (5.3.1, 5.3.4).
• Scan or block removable media on CDE systems (5.3.3).
• Enable tamper protection and run a time-limited, approved exception process (5.3.5).
• Retain anti-malware logs per 10.5.1 in the central log platform.
• Run SPF, DKIM and DMARC at enforcement with inbound filtering and link protection (5.4.1).
• Protect the anti-malware console and its API credentials as privileged.

Standards and references

• PCI SSC: Document Library (PCI DSS v4.0.1)
• PCI SSC FAQ: Can application whitelisting be used to meet Requirement 5?
• PCI SSC: Now is the time to adopt the future-dated requirements of PCI DSS v4.x
• PCI SSC: Best practices for anti-phishing mechanisms, PCI DSS v4.0 Requirement 5.4
• Microsoft Learn: Microsoft Entra ID and PCI DSS Requirement 5
• NIST: SP 800-83 Rev. 1 Guide to Malware Incident Prevention and Handling
• IETF: RFC 7489 DMARC
• MITRE ATT&CK: T1566 Phishing

Related NHI Mgmt Group resources: PCI DSS 4.0 Guide, PCI DSS Readiness Checklist, PCI DSS Requirement 2 Guide, EDR Guide, Phishing Simulation Programme Guide. This guide summarises PCI DSS v4.0.1 Requirement 5 and is not legal or assessment advice.