Binoy Koonammavu
• An ASV scan fails if any vulnerability on a component has a CVSS base score of 4.0 or higher. That means Medium, High and Critical findings. Scores of 3.9 or lower do not fail the scan.
• Certain conditions fail the scan at any score, such as unsupported operating systems, databases open to the internet, default accounts, and SQL injection or cross-site scripting.
• The "4.0" in the rule is a score on the 0 to 10 scale. It is not CVSS version 4.0. The current ASV Program Guide requires CVSS v3.1 base scores.
• There is no single numeric scan score. A scan is pass or fail, and it passes only when no component fails.
• If you believe a finding is wrong, dispute it with your ASV, not with the PCI SSC.
The ASV scan passing score is not a number you aim for. It is a line you stay under: a CVSS base score of 4.0, plus a short list of conditions that fail at any score. Buyers often ask “what score fails an ASV scan?” because the answer is stricter than most internal policies, and because the number 4.0 appears in several unrelated places.
This guide explains the threshold, the automatic failures, how scores are assigned, how to dispute a score, and what a pass and a fail look like in practice. We checked it against ASV Program Guide v4.0 r2 (December 2022), the current version listed by PCI Watch at the time of writing. Confirm against the PCI SSC document library in case a newer release has appeared.
We are Secusy, an ASV vendor. For the wider rulebook, see our ASV Program Guide explainer. For what to do after a failing result, see why an ASV scan fails.
CVSS (Common Vulnerability Scoring System): an open framework from FIRST that rates the severity of a vulnerability on a 0 to 10 scale.
CVSS base score: the score for a vulnerability's inherent characteristics, before any adjustment for your environment.
NVD (National Vulnerability Database): the US government repository that publishes CVSS scores for catalogued vulnerabilities (CVEs).
Component: the IP address or host in your scan that a result is assessed against.
Automatic failure: a condition the ASV Program Guide says must fail a component regardless of its CVSS score.
a finding the scanner reports that does not actually apply to your system.
A vulnerability with a CVSS base score of 4.0 or higher fails the component it is found on. A scan passes only when every finding scores 3.9 or lower and no automatic failure is present. There is no single scan score: the result is pass or fail.
|
CVSS base score |
Severity band |
Effect on the scan |
|---|---|---|
|
0.0 to 3.9 |
Low |
Listed in the report. Does not fail the scan |
|
4.0 to 6.9 |
Medium |
Fails the component |
|
7.0 to 10.0 |
High (includes what CVSS calls Critical) |
Fails the component |
Run a scan and see which findings are at 4.0 or higher.
The 4.0 in the ASV rule is a score threshold on a 0 to 10 scale. It has nothing to do with CVSS version 4.0, the scoring system FIRST released in November 2023. The current ASV Program Guide requires CVSS v3.1 base scores.
|
What |
What it is |
Relevance to your scan |
|---|---|---|
|
CVSS base score of 4.0 |
The pass/fail threshold |
The rule: 4.0 or higher fails |
|
CVSS v4.0 |
The newest version of the scoring system, released by FIRST in November 2023 |
Not required by the current guide. Its scores are not directly comparable with v3.x scores |
|
ASV Program Guide v4.0 |
The version of the PCI SSC rulebook for ASVs (revision 2, December 2022) |
Sets the threshold and requires CVSS v3.1 |
|
PCI DSS v4.0 and v4.0.1 |
The versions of the PCI standard |
Requirement 11.3.2 calls for the quarterly ASV scan |
Some conditions fail a component regardless of CVSS score, including unsupported operating systems, databases reachable from the internet, default accounts, and common web application flaws like SQL injection and cross-site scripting.
The ASV Program Guide requires the scan to treat certain findings as automatic failures because of the risk they carry. The categories most often seen are:
• Unsupported operating systems or software: no longer patched by the vendor.
• Databases open to the internet: direct internet access to a database server.
• Built-in or default accounts and passwords: factory logins left in place.
• Unrestricted DNS zone transfers: a DNS server that hands the full zone to anyone who asks.
• Web application flaws: SQL injection, cross-site scripting, directory traversal and HTTP response splitting.
• Backdoors and malware: including rootkits.
• SSL and early TLS: support for SSL or TLS 1.0. See ASV scan TLS failures.
The list is defined in the guide and has changed between versions, so confirm it against the current appendix. See also open ports and ASV failures for the exposed-service cases. Check your internet-facing assets against this list before each scan. Many failed first scans trace back to one of these conditions, such as a forgotten default login or an exposed database, rather than to a batch of mid-scored CVEs. For a preparation routine, see how to prepare for PCI vulnerability scanning.
A separate category is the Special Note. A Special Note flags software that is risky if configured insecurely, such as remote access software. It does not fail the scan by itself and does not override a CVSS score, but you must supply the scan customer declaration the ASV asks for, and the report stays failed until you do.
The ASV uses the CVSS v3.1 base score published in the NVD for each CVE. If the NVD has no v3.1 score, or there is no CVE, the ASV calculates a v3.1 base score itself.
The process, per the ASV Program Guide, runs like this:
1. The scanner detects a service or version. It matches banners and versions and checks against known vulnerabilities.
2. The NVD score is used when available. If the NVD entry includes a CVSS v3.1 score, the ASV reports that score.
3. A score is calculated when it is not. If the NVD has no score or no entry, the ASV calculates a base score using CVSS v3.1.
4. Each component is judged. A component with any finding at 4.0 or higher fails. The report lists the CVSS score and compliance status for each finding.
It is the base score that counts. Your own view of how exploitable something is in your setup does not change it, so a finding your team rates low-risk in context can still fail if its base score is 4.0 or higher. If you can show a finding does not apply, that is a dispute covered below.
The denial-of-service exception. A vulnerability that is purely a denial-of-service flaw, where both the confidentiality and integrity impact are “None”, is not ranked as a failure, whatever its score. A DoS-only flaw can score 7.5 and still not fail the scan.
Turn failing findings into a fix list and rescan.
Raise the dispute with your ASV, not the PCI SSC. The ASV must investigate false positives scored 4.0 or higher, and you support the dispute with evidence.
The ASV Program Guide requires the ASV to tell you that disputes are not submitted to the PCI SSC and to investigate false positives that carry a failing score of 4.0 or higher. The ASV decides whether to accept your evidence. A dispute works best when it is specific and provable:
• Identify the finding and the reason. Name the exact finding and say why it does not apply.
• Show evidence. Examples include proof that a patch was backported when version-based detection assumed it was missing, configuration output showing a service is not reachable, or a vendor statement.
• Describe any mitigation. If a control stops the issue being exploited, document it.
• Expect a rescan or a revised report. An accepted dispute is reflected in the report.
A disagreement alone is not a dispute. Fixing the finding is often faster than contesting it. For the full process, see false positive disputes.
One failing finding on one host fails that host and the scan. After you fix or dispute every failing finding and rescan, the scan can pass.
This is an illustrative example using documentation IP addresses. The findings are hypothetical.
Host | Finding | Score or type | Result |
|---|---|---|---|
203.0.113.10 | Outdated SSH service with a known CVE | 5.3, Medium | Fails the host |
203.0.113.10 | Server still accepts TLS 1.0 | Automatic failure (early TLS) | Fails the host |
203.0.113.10 | Web server version disclosed in banner | 2.6, Low | Does not fail |
203.0.113.10 | Denial-of-service-only flaw in the web server | 7.5, but confidentiality and integrity impact are None | Does not fail |
203.0.113.11 | Database port reachable from the internet | Automatic failure | Fails the host |
203.0.113.12 | No findings at 4.0 or higher | None | Passes |
Result: two hosts fail, so the scan fails. The 2.6 and the DoS-only finding are listed in the report but do not count against you.
The fix: patch the SSH service, restrict the web server to TLS 1.2 and above, and close the database port to the internet. Then request a rescan. If all three hosts have no finding at 4.0 or higher and no automatic failure, the rescan passes and the ASV issues the Attestation of Scan Compliance. See how to pass an ASV scan the first time for preparation tips.
The ASV scan passing score comes down to one threshold and one short list. Any vulnerability scored 4.0 or higher on the CVSS base scale fails the component it is on, and certain conditions fail at any score. The 4.0 is a score, not a version, and the current guide uses CVSS v3.1. Scores come from the NVD or are calculated by the ASV, and you dispute them with your ASV using evidence. Know the rule, check your findings against it before you scan, and rescan until the report passes.
See how a false positive dispute works and what evidence to bring.
Binoy Koonammavu, is the Founder and CEO of Secusy ASV, where he helps SMBs and fintech companies meet PCI DSS scanning requirements without the complexity of enterprise-grade tools. His writing focuses on making ASV compliance straightforward for growing businesses.