Contents
The March 2025 deadline has passed, and PCI DSS phishing requirements under Requirement 5.4.1 are now fully enforceable, not aspirational guidance buried in an appendix. Security teams that built their compliance posture around annual awareness training are finding out the hard way that QSAs no longer accept that as sufficient. Auditors now expect automated technical mechanisms, documented configurations, and evidence packages proving controls run continuously throughout the year.
This article maps each anti-phishing obligation to a specific control, explains precisely what evidence QSAs collect, and ends with a practical checklist you can use to close gaps before your next assessment. But first, you need to understand what the requirements actually say, and why the technical bar is higher than most teams realize.
This guide reflects common QSA practice and assessor guidance for PCI DSS v4.0.1. The authoritative obligations are defined in the standard itself, and some thresholds cited here (simulation cadence, pass-rate and click-rate targets) are widely used benchmarks rather than fixed numbers in the text. Confirm specifics with your assessor.
What PCI DSS v4.0 Actually Changed for Phishing Prevention
PCI DSS Phishing Requirements: Requirement 5.4.1 and the End of Training-Only Compliance
Requirement 5.4.1 mandates that organizations implement processes and automated mechanisms to detect and protect personnel against phishing attacks. Per the PCI SSC's official v4.0 documentation, security awareness training alone does not satisfy this requirement. That distinction forces a shift from behavioral nudges to technical controls that operate regardless of whether an employee makes the right decision on a suspicious email.
The intent is to close the gap between awareness and actual detection coverage. A well-trained employee who clicks a convincing lookalike domain still represents a breach risk. Automated controls, specifically DMARC, SPF, and DKIM, address the threat at the infrastructure layer before it ever reaches that employee's inbox. The PCI SSC phishing resource guide elaborates on this distinction and is worth reviewing alongside the standard itself.
The March 2025 Mandatory Deadline and What It Means for Audits Now
Requirement 5.4.1 was listed as a best practice in the initial PCI DSS v4.0 release but became fully mandatory in March 2025, per the PCI SSC's published v4.0 transition timeline. Any organization undergoing a QSA assessment now is evaluated against it as a hard control. Annual training no longer qualifies as a compensating control, QSAs are unambiguous on this point.
For teams preparing their 2026 assessment, the implementation window has closed. You are not being evaluated on your roadmap. You are being evaluated on what is running right now, and whether you can prove it.
Scope Extends Beyond the Cardholder Data Environment
Anti-phishing controls under 5.4.1 apply across the entire organization, not just within the CDE perimeter. This includes suppliers and financial partners who communicate with the organization, which has direct implications for email domain configuration. Many teams scope their controls too narrowly, protecting the primary payment domain while leaving secondary business domains unprotected, and fail this check as a result. Every domain that sends email or could be spoofed must be in scope.
PCI DSS Phishing Requirements: Email Authentication Controls
Building a DMARC Policy Progression Auditors Can Verify
DMARC enforcement follows a policy ladder: p=none (visibility phase), p=quarantine, and p=reject. According to PCI DSS assessor guidance and widely accepted implementation standards, QSAs expect your organization to be at p=quarantine or p=reject, with aggregate DMARC reports showing greater than 95% pass rates before enforcement moves to the reject level. A policy stuck at p=none signals to auditors that you are monitoring without acting, which does not satisfy the active protection requirement.
The rua= (aggregate) reporting address must be configured and actively monitored, this is a specific auditor checkpoint. Forensic reporting via ruf= is also commonly expected, though its implementation can be constrained by privacy and operational considerations; clarify its status with your QSA if applicable. Either way, DMARC records that are not being consumed and acted on are considered decorative rather than functional controls. For practical implementation guidance tailored to PCI DSS v4.0, see implementing DMARC to meet PCI DSS v4.0 requirements.
SPF and DKIM Configuration Requirements Assessors Review
SPF records must include all authorized sending services, and the DNS lookup count must stay under 10, a technical limit defined in RFC 7208 that QSAs treat as a configuration hygiene check. Assessors look specifically for misconfigurations where payment confirmation domains, invoicing systems, or support email platforms are omitted from the SPF record. A spoofing exposure on a support subdomain creates the same risk as one on the primary domain.
DKIM signing must cover all outbound mail streams, with public keys published in DNS for each sending service. A common gap: a third-party marketing or billing platform sends email on the organization's behalf without DKIM signing, leaving that stream unsigned and vulnerable to spoofing even when the primary domain appears fully protected. Assessors check for exactly this scenario. For vendor and platform comparisons to help you pick the right email authentication tooling, review the best email authentication platforms for PCI DSS v4.0 compliance roundup.
Why All Business Domains Must Be Covered, Not Just the Payment Domain
Anti-phishing controls for the CDE do not stop at the payment processing domain. QSAs check whether lookalike or subdomain abuse is possible because secondary domains were left without DMARC, SPF, and DKIM coverage. This is one of the most common gaps found during assessments, and it is entirely preventable. Every business domain that sends email, or that an attacker could convincingly spoof, must be in scope for email authentication configuration.
Phishing-Resistant MFA and the Scope of Requirement 8.4.2
When Phishing-Resistant Authentication Satisfies 8.4.2
Requirement 8.4.2 mandates MFA for all non-console access to the CDE, but includes one carefully scoped exception: if a user authenticates solely with a phishing-resistant factor such as a FIDO2 passkey, the additional MFA factor is not required for that specific requirement. The PCI SSC FAQ (see FAQ 1595) documents this exception and its boundaries. The rationale is technically sound, FIDO2 passkeys are cryptographically bound to the legitimate originating site and do not function on fraudulent lookalike pages, making credential theft via phishing structurally impossible.
This exception applies only to non-administrative users accessing the CDE under Requirement 8.4.2. It does not extend to any other requirement. Assessors probe the boundaries of how organizations have applied it, and overreach is a common finding. For auditor-focused analysis of phishing-resistant authentication in the context of PCI, see phishing-resistant authentication for PCI DSS compliance. For practical considerations and adoption patterns around passkeys, read passkeys and PCI DSS 4.0.
Where Full MFA Remains Non-Negotiable: Requirements 8.4.1 and 8.4.3
The phishing-resistant single-factor exception does not apply to administrative access (Req 8.4.1) or remote access (Req 8.4.3). Both require MFA regardless of the authentication method used. Auditors specifically test this distinction because organizations frequently assume the FIDO2 exception is broader than it is, and misconfigured access controls are a consistent finding across assessments.
If your administrative accounts are protected only by FIDO2 passkeys without an additional factor, you have a compliance gap. The requirement is unambiguous, and no amount of documentation around the phishing-resistant nature of the method compensates for the missing factor at the 8.4.1 and 8.4.3 level.
The Double Authentication Rule for Remote-to-CDE Access
When a user connects via remote access from outside the network and then accesses the CDE from inside the network, MFA must be applied twice: once for the remote session and once for CDE access. QSAs look for technical enforcement of this control. Evidence must show the system requires both authentications independently, not that the initial remote session MFA is treated as satisfying the CDE access requirement as well. Policy documents describing the requirement are not substitutes for proof of technical enforcement.
Training, Simulations, and Incident Response Documentation Under Requirement 12.6
Simulation Cadence, Failure Metrics, and What Auditors Measure
Phishing simulations should run on an ongoing basis rather than as a single annual exercise; many mature programs test monthly or quarterly. QSAs look for documented simulation records that include campaign content, dates, participation rates, click rates, and follow-up training completions for those who clicked. Industry benchmarks and assessor guidance commonly reference click rates below 5% and reporting rates above 80% as targets, with trend data demonstrating measurable improvement over time. A single annual exercise does not satisfy Requirement 12.6's intent; assessors identify this gap immediately when reviewing program records.
Simulation records must be retained and presented as a cohesive dataset. Scattered screenshots from different tools do not constitute a reviewable program. QSAs also check whether scenarios increase in sophistication over time, a program that runs the same obvious test each month does not demonstrate adaptive risk management.
Role-Specific Training Content and Incident Response Procedures
Training content must be tailored to employee roles. Billing teams should face invoice fraud scenarios; finance teams should face executive impersonation scenarios. Generic awareness modules shared across all roles do not satisfy the specificity QSAs now expect under the security awareness program requirements. The training catalog itself becomes an evidence artifact, demonstrating that the program addresses the actual threat landscape facing each team.
Incident response plans must document the full workflow after a confirmed phishing attack: account re-provisioning steps, workstation isolation procedures, and credential reset timelines. QSAs look for both the plan and evidence it has been tested. An untested plan is treated as an incomplete control, one that reflects intent, not execution.
PCI DSS Phishing Requirements, Audit-Ready Evidence
The Documentation and Evidence Checklist QSAs Work Through
During a PCI DSS phishing assessment, QSAs collect a specific set of artifacts. Expect requests for screenshots of DMARC, SPF, and DKIM configurations; email gateway logs showing blocked spoofed senders; phishing simulation reports with full metrics; incident response plan documentation; and MFA enforcement evidence for each requirement tier. The Report on Compliance documents how each anti-phishing control was tested and what evidence was reviewed. Organizations that assemble this manually during the audit window routinely miss gaps that translate into costly remediation cycles. For examples of audit-ready packaging and evidence formats, see PhishEye's Reports & briefs.
The clearest differentiator between teams that pass cleanly and teams that scramble is operational continuity. Evidence must reflect controls that run 365 days a year, not controls configured last month in preparation for the assessment.
Brand-Targeted Threat Detection as an Audit Trail Requirement
PCI DSS phishing compliance also encompasses monitoring for brand-targeted threats: lookalike domains, fraudulent ad campaigns, and fake social profiles targeting cardholders. While not explicitly enumerated as a standalone line item in the standard, auditors in regulated environments increasingly expect evidence that an organization detects these threats proactively and documents its response. This extends beyond email authentication to the external threat surface that customers face even when internal controls are solid.
Phishing & scam detection, takedowns addresses this directly within a compliance workflow. The platform automates detection of phishing infrastructure targeting your brand, tracks takedown status across web, social, and ad channels, and helps build an evidence trail that supports audit documentation. When a QSA asks for proof of proactive external monitoring, a timestamped detection and enforcement log gives you a concrete, reviewable answer.
Keeping Evidence Current Between Assessments
Evidence collected only during an audit window is a red flag for experienced QSAs. Controls must demonstrably run continuously, and assessors are trained to identify compliance theater. Automated platforms that log detections, enforcement actions, and takedown timelines provide timestamped, ongoing records that demonstrate year-round compliance. The operational value and the compliance value converge: a system that works all the time serves both your security posture and your audit readiness simultaneously.
Your Pre-Audit Checklist: Closing the Gaps Before Your Next Assessment
- DMARC policy: Confirm all business domains have DMARC records at p=quarantine or p=reject, with rua= addresses actively monitored and aggregate pass rates above 95%. Clarify ruf= forensic reporting status with your QSA.
- SPF completeness: Verify all authorized sending services are included in SPF records, DNS lookup count is under 10, and payment, billing, and support domains are all covered.
- DKIM signing: Confirm all outbound mail streams, including third-party platforms, are DKIM-signed with public keys published in DNS.
- MFA tiering: Verify FIDO2 exceptions are applied only to 8.4.2 non-admin CDE access, and that 8.4.1 and 8.4.3 both require full MFA with documented technical enforcement.
- Double authentication: Confirm remote-to-CDE access requires two separate MFA events with technical controls enforcing both independently.
- Simulation records: Assemble monthly simulation reports with campaign content, dates, click rates below 5%, reporting rates above 80%, and follow-up training completions, organized as a continuous dataset.
- Incident response testing: Confirm the phishing incident response plan has been tested within the last 12 months, with documented results available for QSA review.
- External threat monitoring: Document proactive monitoring for lookalike domains, fake social accounts, and fraudulent ad campaigns, with takedown records and timestamped evidence packages ready for audit.
Treat Compliance as an Operational State, Not an Event
The PCI DSS phishing requirements under v4.0, Requirement 5.4.1, Requirement 8.4.2, and Requirement 12.6, form a control stack covering detection, authentication, training, and documentation. Every gap in that stack is a finding, and findings discovered during a QSA review cost far more to remediate than gaps closed proactively.
The organizations that pass clean treat evidence collection as a year-round operational workflow. Continuous monitoring and automated logging are not just operational best practices; they are precisely what QSAs interpret as evidence of genuine compliance rather than point-in-time preparation. If your team is still manually assembling phishing control evidence in the weeks before a review, that process itself signals a control weakness.
PhishEye's automated detection, takedown tracking, and evidence packaging support continuous audit readiness, so your team is not caught rebuilding documentation when a review window opens. When these compliance controls expand in scope with each revision cycle, having an automated evidence trail already in place means your team adapts from a position of preparation rather than urgency. The checklist above is your starting point; an operational platform is what keeps it current. For more on centralizing these workflows, see Why Teams Centralize Digital Risk Programs (2026) | PhishEye.
Frequently Asked Questions
Does annual phishing training still satisfy PCI DSS phishing requirements under v4.0?
No. Since March 2025, Requirement 5.4.1 requires automated technical mechanisms in addition to training. Annual awareness training alone is not accepted as a compensating control by QSAs.
Which domains must comply with DMARC, SPF, and DKIM under PCI DSS?
All business domains that send email or could be spoofed, not just the primary payment processing domain. Secondary domains, support subdomains, and billing platforms are all in scope.
Does a FIDO2 passkey eliminate the need for MFA across all PCI DSS requirements?
No. The phishing-resistant single-factor exception applies only to non-administrative CDE access under Requirement 8.4.2. Administrative access (8.4.1) and remote access (8.4.3) still require full MFA regardless of authentication method.