PCI DSS v4.0.1 Compliance: A Developer’s Guide to ASV Scans

Share on social media

Categories : Knowledge, Knowledge-home, News

PCI DSS v4.0.1 Compliance

A Developer’s Guide to ASV Scans,

beyondthe Green Checkmark

You patched the server. You updated the certs. You ran the scan. It failed anyway.
If you’ve ever stared at an ASV scan report wondering why your perfectly reasonable infrastructure just got flagged for 47 vulnerabilities — half of which feel like false positives — welcome to the club.
PCI DSS 4.0.1 didn’t just move the goalposts; it added new ones most developers didn’t see coming. This guide is for the people who actually have to fix things when scans go red. Not the compliance officers, not the auditors — the developers and engineers who get the ticket at 4 PM on a Friday because the quarterly scan window closes Monday.

What Even Is an ASV Scan?

An Approved Scanning Vendor (ASV) is a company authorized by the PCI Security Standards Council to perform external vulnerability scans on your internet-facing systems. Think of it as a standardized penetration-lite: the ASV probes your public-facing IPs, domains, and services looking for known vulnerabilities, misconfigurations, and policy violations.

The scan itself is non-intrusive — it won’t exploit anything — but it will catalog everything it finds and score it using CVSS (Common Vulnerability Scoring System). The magic number is 4.0. Any vulnerability with a CVSS base score of 4.0 or higher means an automatic failure.

Under PCI DSS Requirement 11.3.2, these scans must happen at least once every three months (quarterly), and after any significant change to your environment — new servers, major deployments, infrastructure migrations, firewall rule changes.

That second point is the one developers tend to miss. Shipped a new payment API endpoint last Tuesday? That potentially triggers a rescan requirement.

What Changed in PCI DSS 4.0.1?

Let’s clear up a common misconception: PCI DSS 4.0.1 is not a major version bump. It’s a limited revision of v4.0 — mostly typographical fixes, formatting corrections, and clarified guidance. No new requirements were added or removed.

But here’s why it matters. PCI DSS v4.0 introduced several “future-dated” requirements that became mandatory on March 31, 2025. These are the real changes, and v4.0.1 is now the only supported version enforcing them. If you’re not already compliant, you’re already behind.

The requirements that hit developers hardest:

1. Authenticated Internal Vulnerability Scans (Req. 11.3.1.2)

Previously, internal scans were typically unauthenticated — the scanner checked services without logging into them. Now, internal scans must use authenticated credentials to log into systems and inspect them from the inside. This means:

Your scanning tool needs service accounts with sufficient privileges to conduct thorough scans
Those accounts must comply with Requirement 8.2.2 (password policies, MFA considerations) if they can be used for interactive login
Systems that cannot accept credentials — some network appliances, mainframes, containers — must be explicitly documented
The scan coverage is dramatically deeper; expect more findings, not fewer

For developers, this means your staging and internal environments are now under the microscope in ways they weren’t before. That internal admin panel you never hardened because “it’s behind the VPN”? It’s in scope now.

Treat your scanning credentials as highly privileged. Protect them following PCI DSS Requirements 7 and 8. And here’s one piece of good news: authenticated scanning is not required for internal scans performed after significant changes (Req. 11.3.1.3). Only the regular quarterly scans need full credentials.

2. Payment Page Script Management (Req. 6.4.3)

Every script running on your payment pages must be:

Authorized — explicitly approved via a manual or automated workflow
Integrity-checked — using Subresource Integrity (SRI) hashes, Content Security Policy (CSP), or equivalent mechanisms
Inventoried — documented with a written business or technical justification for why each script is necessary

This is PCI’s response to the Magecart-style e-skimming attacks that have plagued e-commerce. If you’re loading Google Analytics, a chat widget, and three marketing pixels on your checkout page, each one needs to be accounted for.

One exception worth knowing: 3DS scripts are exempt from Req 6.4.3 validation. The PCI SSC considers the trust relationship established during merchant onboarding sufficient. Anything running outside the 3DS flow is still subject to the requirement.

3. Payment Page Tampering Detection (Req. 11.6.1)

You need a change- and tamper-detection mechanism that alerts your team when someone or something modifies the HTTP headers or script contents of your payment pages as received by the consumer’s browser. The mechanism must catch three scenarios: a new script appearing, an existing script changing, or a security header being removed.

PCI points you toward Content Security Policy (CSP) and Subresource Integrity (SRI), but also recognizes external synthetic monitoring, tamper-detection scripts, reverse proxies, and CDN-based detection. The key constraint: whatever you use must run at least weekly, or at a frequency justified by a targeted risk analysis per Requirement 12.3.1.

The intention is not to install anything in your users’ browsers. It’s about server-side or monitoring-layer detection of unexpected changes.

4. SAQ A Merchants Now Need ASV Scans

Previously, small e-commerce merchants using full-redirect payment flows (SAQ A) were largely exempt from ASV scanning. Under v4.0, they now need quarterly external scans too. If you maintain sites for small merchants, this is a new conversation to have with your clients.

The Top Reasons Your Scan Just Failed

After years of collective developer pain, the failure patterns are remarkably consistent. These aren’t exotic zero-days — they’re the mundane things that slip through the cracks.

TLS/SSL Configuration Issues

The single most common failure category. Your scan will fail if:

TLS 1.0 or TLS 1.1 are still supported (both are prohibited)
You’re offering weak cipher suites (RC4, DES, 3DES, export ciphers)
Your certificate is expired, self-signed, or has a hostname mismatch
You’re missing HSTS headers or have them misconfigured

Recommended Nginx TLS configuration:

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers ‘ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384’;

ssl_prefer_server_ciphers on;

add_header Strict-Transport-Security “max-age=31536000; includeSubDomains” always;

Verify before scan day: nmap –script ssl-enum-ciphers -p 443 yourdomain.com

Exposed Administrative Interfaces

phpMyAdmin on a public IP. An open RDP port. WordPress /wp-admin accessible from the internet. A Kubernetes dashboard without authentication. All automatic failures.

Move admin interfaces behind a VPN or bastion host. Use IP allowlisting at the firewall or load balancer. If external access is truly required, enforce MFA and document why.

Outdated Software and Missing Patches

ASV scanners maintain databases of known CVEs. If your Apache version has a known vulnerability with CVSS >= 4.0, you fail. It doesn’t matter if you think the vulnerability isn’t exploitable in your specific configuration.

The usual suspects: web servers (Apache, Nginx, IIS), application runtimes, OpenSSL/OpenSSH, CMS platforms and their plugins, DNS servers. Subscribe to vendor security advisories. Automate patching where possible. Cloud-hosted assets and containerized workloads are in scope too.

Open Ports and Unnecessary Services

Every open port is an attack surface. The ones that burn developers most often:

FTP (21) — especially anonymous FTP
Telnet (23) — unencrypted remote access
SMTP (25) — open mail relays
DNS (53) — recursion-enabled resolvers
Database ports (3306, 5432, 1433) — directly internet-accessible

Run only what you need. Firewall everything else. If in doubt, close it.

HTTP Security Headers

Missing headers won’t always fail your scan alone, but they contribute to findings and can push your CVSS aggregate over the line:

Content-Security-Policy: default-src ‘self’; script-src ‘self’; style-src ‘self’

X-Content-Type-Options: nosniff

X-Frame-Options: DENY

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy: camera=(), microphone=(), geolocation=()

The False Positive Problem

ASV scanners aren’t perfect. They rely heavily on banner grabbing and version detection, which means they flag vulnerabilities that have already been patched via backporting — a common practice on RHEL, Debian, and Ubuntu.

Your scan reports OpenSSH 8.2 has CVE-2023-38408. But you’re running Ubuntu 22.04, which backported the fix into their 8.2 package. The scanner sees “8.2” and panics. It doesn’t know about the backport.

You have the right to dispute findings. Do it effectively:

Gather evidence — installed package versions (dpkg -l, rpm -q), vendor security advisories confirming the backport, configs showing mitigating controls
Be specific — reference the exact CVE, explain the distribution, show the patched version string
Document when and how you collected the evidence
Submit in writing to your ASV with clear descriptions

The ASV reviews the dispute and either reclassifies the finding or confirms it as valid. This stays between you and the ASV — it doesn’t go to the PCI SSC.

Don’t dispute everything. ASVs notice when companies contest 30+ findings every quarter. Fix what you can, dispute only the genuine false positives.

Building ASV-Scan-Resilient Infrastructure

The best way to survive ASV scans is to stop treating them as a quarterly fire drill.

Run Your Own Scans First

Run vulnerability scans before the ASV does. OpenVAS, Nessus, or Qualys can surface issues weeks before the official scan window:

# TLS check before the ASV gets there

testssl.sh –severity HIGH yourdomain.com

# Common web vulnerability check

nikto -h https://yourdomain.com

Integrate Security Into CI/CD

Container image scanning before deployment (Trivy, Grype)
Dependency vulnerability scanning in your build (npm audit, pip-audit, OWASP Dependency-Check)
Infrastructure-as-code scanning for misconfigurations (tfsec, checkov)

A vulnerability caught in CI never reaches the ASV scan.

For payment pages specifically, consider adding a pipeline step that validates SRI attributes on script tags and checks CSP headers against your approved script inventory. Real coverage requires a tool that understands dynamic script loading.

Maintain a Living Asset Inventory

You must scan all external-facing IPs and domains (Req. 11.3.2). You can’t scan what you don’t know about. Shadow IT, forgotten staging servers, that test subdomain from three sprints ago — these are the things that blow up your scan.

Maintain a living inventory. Review it before each scan window. Kill what you don’t need.

Payment Page Hygiene

For your checkout pages, every script needs SRI and your CSP needs violation reporting:

<script

src=”https://js.stripe.com/v3/”

integrity=”sha384-abc123…”

crossorigin=”anonymous”>

</script>

# Nginx: CSP with violation reporting for Req. 11.6.1

add_header Content-Security-Policy

“default-src ‘self’;

script-src ‘self’ https://js.stripe.com;

object-src ‘none’;

report-uri /csp-report;

report-to csp-endpoint;” always;

You’ll need a backend endpoint (or a service like report-uri.com) that receives these violation reports and alerts your team. That’s what satisfies the alerting component of Req. 11.6.1.

One thing developers get wrong with SRI: it’s not “set and forget.” When your payment processor ships a new JS bundle, your hash breaks and the browser blocks the script. Build SRI hash regeneration into your dependency update process.

Who Owns What: Payment Page Responsibility

If you’re integrating a third-party payment provider, the responsibility split for Req. 6.4.3 and 11.6.1 depends on how you’ve built the integration:

Integration Model	You Own	Your Payment Provider Owns
Your own payment form	Every script on your page	Scripts they provide for their services
Direct post (card data goes straight to provider)	Every script on your page	Scripts they provide for their services
Embedded iframe (Stripe Elements, Adyen Drop-in)	Scripts on your page, outside the iframe	Everything inside the iframe
Full redirect (customer leaves your site)	Scripts on your page with the redirect link	Everything on their hosted page
Fully outsourced (provider hosts everything)	Nothing for 6.4.3 / 11.6.1	All of it

If you’re using Stripe Elements or Adyen Drop-in (iframe model), you’re responsible for your parent page’s scripts. They handle theirs inside the iframe. Get this wrong and you’ll either over-invest or leave a gap.

Script Inventory

PCI DSS doesn’t prescribe a format. A spreadsheet works fine for simple setups:

Script	Source	SRI Hash	Why It’s There	Approved By	Date
Stripe.js	js.stripe.com/v3/	sha384-…	Payment processing	J. Smith	2026-01-15
GA4	googletagmanager.com/gtag/js	sha384-…	Conversion tracking	M. Lee	2026-01-15
Hotjar	static.hotjar.com/c/hotjar-*.js	sha384-…	UX analytics on checkout	A. Chen	2026-02-01

The inventory needs a written justification for every script. “Marketing wanted it” is a justification. No justification at all is a finding.

The Scan Day Checklist

When your quarterly scan window approaches:

Asset inventory is current — no forgotten subdomains or IPs
Scan scope confirmed with your ASV — coordinate specifics about load balancers, CDNs, third-party providers
SSL/TLS certificates are valid and properly configured
No admin interfaces are publicly accessible
All systems patched to current levels
No unnecessary ports or services exposed
Payment page scripts match your authorized inventory
CSP headers and tamper-detection mechanisms are active and running at least weekly
Pre-scan completed with your own tools
Evidence ready for known false positives from previous quarters
Scanning credentials provisioned for authenticated internal scans
Scan accounts that allow interactive login comply with Req. 8.2.2
Systems that can’t accept scan credentials are documented

When You Fail

A failed scan isn’t the end of the world. Here’s the process:

Triage — sort findings by CVSS score; 4.0 and above are the blockers
Remediate — patch, reconfigure, or remove the offending services
Rescan — request a rescan from your ASV to verify the fixes
Document — keep records of what was found, when it was fixed, and what changed
Dispute — for genuine false positives only, file a formal dispute with evidence

You can rescan as many times as needed within your quarter. The goal is one clean passing scan per 90-day window.

If you truly cannot fix a vulnerability due to legitimate constraints, PCI DSS allows compensating controls — alternative measures that provide equivalent security. But they require formal documentation, QSA approval, and reassessment at every annual PCI DSS assessment. They’re meant to be the exception. Don’t build your compliance strategy around them.

Quick Reference

Req.	What It Requires	Frequency	Who Performs
11.3.1	Internal vulnerability scans	Quarterly	Qualified internal staff or third party
11.3.1.2	Authenticated internal scans	Quarterly (with 11.3.1)	Qualified internal staff or third party
11.3.1.3	Internal scans after significant changes	After each change	Qualified staff (no authentication required)
11.3.2	External ASV scans	Quarterly	ASV only (no Customized Approach allowed)
11.3.2.1	External scans after significant changes	After each change	Qualified staff (ASV not required)
6.4.3	Payment page script management	Ongoing	Entity (merchant and/or TPSP)
11.6.1	Payment page tamper detection	Weekly or per risk analysis	Entity

Two details from this table worth highlighting. First: post-change scans — both internal and external — don’t require an ASV. Your qualified internal team can handle them, which saves real money if you ship frequently. Second: the CVSS 4.0 automatic-failure threshold applies to external ASV scans specifically. Internal scans use your own risk-ranking process (defined per Req. 6.3.1) to classify what counts as high-risk or critical. The threshold is yours to define, not a fixed number.

The Developer’s Mental Model

Stop thinking of the scan as an audit. Think of it as an external health check that runs against the same attack surface your actual adversaries see. The ASV scanner is doing, at a basic level, what any attacker with Shodan and a CVE database would do.

Every finding in your scan report is something an attacker could also find. The green checkmark isn’t just a compliance artifact — it’s a signal that your external attack surface doesn’t have low-hanging fruit.

PCI DSS 4.0.1 raised the bar, but most of what it asks for is just good security hygiene: patch your systems, encrypt properly, don’t expose admin panels, know what scripts run on your payment pages, and scan from the inside too.

The developers who treat compliance as a continuous practice rather than a quarterly panic are the ones who sleep well the night before scan day.

Source

▪︎ PCI Security Standards Council — PCI DSS v4.0.1 Standard

▪︎ PCI SSC — Guidance for PCI DSS Requirements 6.4.3 and 11.6.1

▪︎ PCI SSC — ASV Program Guide▪︎ PCI SSC Blog — Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x

▪︎ RSI Security — PCI DSS v4.0.1: Key Updates and What They Mean

▪︎ VikingCloud — PCI DSS v4.0: Authenticated Vulnerability Scans

▪︎ Basis Theory — Payment Page Security: Embracing PCI 6.4.3 and 11.6.1

▪︎ Imperva — How to Comply with PCI DSS 4.0 Requirements 6.4.3 and 11.6.1

▪︎ UpGuard — How to Comply with PCI DSS 4.0.1 (2026 Guide)