PCI DSS 4.0 Vulnerability Management: What Is Now Mandatory

The Payment Card Industry Data Security Standard (PCI DSS) evolved to address the growing complexity of cybersecurity threats. PCI DSS 4.0 became effective on March 31, 2024, and its future-dated requirements became mandatory on March 31, 2025. Those requirements are now in force: the vulnerability management obligations described below are being assessed today, not at some point in the future.

This post was originally published in March 2025, ahead of the mandatory date. It was rewritten in September 2026 to reflect the standard as it now applies.

For businesses that process credit card transactions, compliance with PCI DSS 4.0 is not just a contractual obligation - it is a critical step toward safeguarding sensitive data and maintaining customer trust. Below are the key requirements, with a focus on vulnerability management and open source vulnerability patching.

Understanding PCI DSS 4.0 vulnerability management requirements

PCI DSS 4.0 places a stronger emphasis on continuous vulnerability management, requiring organizations to adopt a more rigorous and proactive approach. The key requirements include:

Requirement 6.3: Develop internal and external software applications securely

This requirement focuses on identifying and addressing vulnerabilities in custom and third-party software, operating systems, and databases. It includes three critical sub-requirements:

Requirement 6.3.1: Organizations must identify and manage new security vulnerabilities using industry-recognized sources and rank them by risk based on best practices and potential impact.

Requirement 6.3.2: An inventory of bespoke and custom software, as well as third-party software components incorporated into custom software, must be maintained.

Requirement 6.3.3: Critical or high-severity patches and updates must be installed within one month of release.

Requirement 11.3.1: Regular identification, prioritization, and resolution of vulnerabilities

This requirement mandates that organizations:

• Conduct vulnerability scans every three months to identify potential weaknesses in systems, applications, and network devices.
• Prioritize and remediate vulnerabilities based on their risk level, with a focus on high-risk and critical vulnerabilities.

Requirement 11.3.1.1: Organizations must perform targeted risk analyses to assess and prioritize non-critical vulnerabilities.

Requirement 11.3.1.3: Organizations must conduct internal vulnerability scans after any significant change to their network environment or system components.

What it means to "manage vulnerabilities" under PCI DSS 4.0

For PCI DSS compliance, managing vulnerabilities means more than identifying them - it requires timely and effective remediation. Key actions include:

• Regular scanning: conduct vulnerability scans at least quarterly.
• Timely remediation: resolve critical and high-severity vulnerabilities within one month of release.
• Post-change scanning: perform additional scans after significant infrastructure changes and remediate what they surface.
• Comprehensive coverage: address all vulnerabilities, not only those classified as high-risk or critical.

The one-month clock in Requirement 6.3.3 is the requirement that most often breaks against open source dependencies, because it assumes a patch exists and can be applied. Frequently neither is true.

Challenges in open source vulnerability patching

Many organizations struggle to manage vulnerabilities in open source dependencies due to:

• Vulnerability overload: the sheer volume of findings across multiple business units can overwhelm security teams.
• Lack of technical expertise: development teams often lack the resources or incentives to address open source vulnerabilities.
• Complex upgrade paths: open source dependencies frequently lack clear upgrade paths, leaving vulnerabilities unresolved.
• Legacy systems and end-of-life software: older codebases and unsupported software are particularly difficult to patch, increasing operational risk.

According to data from Snyk, 38% of organizations address only 50% or fewer reported vulnerabilities, while 10% remediate fewer than 25%.

Limitations of current tools

Software Composition Analysis (SCA) and prioritization tools are designed to identify and rank vulnerabilities and suggest upgrades, but they often fall short of comprehensive coverage. Common limitations include:

• Excessive noise: SCA tools generate numerous false positives, making it difficult to prioritize real risk.
• Incomplete remediation guidance: these tools often lack actionable insight into the risk and complexity of upgrading a dependency.
• Manual processes: remediation remains time-consuming and impractical, especially for legacy systems and EOL software.

Staying compliant now that the requirements are in force

With the March 31, 2025 date behind us, the question is no longer whether your program will be ready but whether it holds up under assessment. Organizations that align their vulnerability management to PCI DSS 4.0's requirements can:

• Meet regulatory standards
• Reduce operational risk
• Improve overall security posture
• Avoid the penalties and higher fees associated with non-compliance

The gap that most often shows up in assessment is a known critical or high-severity CVE in an open source dependency, sitting past the one-month window, because no safe upgrade path exists.

Embracing the future of payment security

PCI DSS 4.0 represents a significant shift in how organizations manage vulnerabilities, particularly in the context of open source software. With requirements for regular scanning, timely remediation, and post-change assessment now mandatory, businesses need proactive and comprehensive vulnerability management rather than a best-effort process.

How Seal Security helps with PCI DSS 4.0 compliance

At Seal Security, we help organizations overcome the challenges of open source vulnerability patching and meet PCI DSS 4.0 requirements without disrupting development workflows or relying solely on upgrades.

Our solution provides standalone security patches that are fully compatible with the versions of open source packages you are already running. That makes fixes for vulnerabilities in both application dependencies and Linux operating systems seamless and predictable, and it means the one-month remediation clock in Requirement 6.3.3 can be met even where no upstream upgrade path exists.

By enabling continuous remediation without the overhead of full dependency upgrades, Seal Security helps your organization maintain compliance, reduce risk, and protect sensitive payment data.

For more information contact us at: info@seal.security