PCI ASV Certification: How It Differs From PCI Certified and PCI Compliant
PCI ASV certification explained: how it differs from PCI certified and PCI compliant, who validates each, and how to verify a PCI approved scanning vendor.
• An ASV scan covers the externally reachable hosts and services that serve your APIs. It does not test API logic.
• The scan is unauthenticated and outside-in. It cannot log in, so it cannot test authorization, business logic or post-login flows.
• Scope is defined by IP addresses and domain names, not by individual API routes. An API hostname that routes to in-scope systems belongs in the scan.
• A passing ASV report is not evidence that your API is secure. It says nothing about the things the scanner could not see.
• Pair the ASV scan with API-focused penetration testing, secure development controls and runtime protection.
Does an ASV scan cover APIs? Partly. The scan tests the infrastructure that exposes your API to the internet, but it does not test what your API does once a request gets through. SaaS and fintech teams ask this because they are told they need a quarterly ASV scan, and they want to know whether it also covers the API their product is built on. The answer matters because APIs are now the default integration layer for payment processing, so most modern architectures route cardholder data through them.
This guide explains what an ASV scan sees, how API endpoints fall into scope, what the scan cannot test, and what to use alongside it. We are Secusy, an ASV vendor, so we sell scanning and not API penetration testing. We would rather tell you where the scan stops than let a clean report give you false comfort.
ASV scan: the external vulnerability scan PCI DSS Requirement 11.3.2 requires at least every three months, run by a PCI SSC Approved Scanning Vendor. See what an ASV scan is.
Unauthenticated scan: a scan that tests what any anonymous internet user could reach, without logging in.
API (application programming interface): the interface your product, partners or mobile apps use to send requests and receive data, usually over HTTPS.
Cardholder data environment (CDE): the people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, plus connected systems. The CDE decides which APIs are in scope.
Business logic flaw: a weakness in how an application's rules are enforced, such as changing an order total or reading another customer's record. Scanners rarely detect these.
BOLA (broken object level authorisation): an API flaw where a user can access objects that belong to someone else by changing an ID. It is the top item on the OWASP API Security Top 10.
API penetration test: a manual, authenticated test in which a qualified tester tries to exploit your API.
An ASV scan covers the internet-facing hosts and services in front of your API: open ports, server software, TLS settings and known vulnerabilities. It does not log in or test how your API behaves.
An ASV scan runs from outside your network and acts like an anonymous visitor. The customer supplies the IP addresses and domain names, and the ASV runs a discovery check to confirm nothing obvious is missing. The ASV Program Guide does not require authenticated scanning. When the scanner reaches your API hostname, it can typically report:
• Exposed services: unexpected open ports or admin interfaces on the API host. See open ports and ASV failures.
• Known vulnerable software: server, framework and gateway versions matched against known CVEs. Findings scored CVSS 4.0 or higher fail the scan.
• TLS and certificate problems: old protocols, weak ciphers and bad certificates. See ASV scan TLS failures.
• Misconfigurations: default pages, verbose banners and exposed documentation that reveal software versions.
It is a check on the front door of your infrastructure. It is not a test of what happens behind the door.
Submit your API hostnames and IPs and get your quarterly report.
Scope is set by IP addresses and domain names, not by API routes. If an API hostname routes to systems in or connected to your cardholder data environment, it belongs in the scan scope.
The merchant or service provider defines the scope, not the ASV. Every public IP address routed to your in-scope environment, and every URL that points to those addresses, should be submitted. A clean report on an incomplete scope proves little. For the full process, see PCI DSS 11.3.2 explained. For an API-based product, that usually means listing:
• API hostnames: the production API, any regional variants and the payment or tokenisation endpoints.
• The entry layer: load balancers, API gateways, CDN or WAF edges, and any origin IP that is reachable directly.
• Supporting services: authentication or identity hosts, admin consoles and webhook receivers that connect to the cardholder data environment.
• Reachable non-production hosts: staging or sandbox hosts that are internet-facing and connected to production data or networks.
Two practical points. First, the scanner sees individual routes only if it can discover them without logging in, and a typical ASV scan does not import an OpenAPI specification. Some vendors sell separate web or API scanning as an add-on, but that sits outside the ASV scan itself. Second, cloud autoscaling and Kubernetes ingress can change your IP addresses between scans, so use stable addresses where you can and agree with your ASV on how changing ranges are handled. For more on scope, see PCI ASV scan requirements.
An ASV scan cannot test authorization, business logic, authenticated flows or abuse resistance. These are the weaknesses attackers most often use against APIs.
Because the scan is anonymous and automated, these API risks sit outside it:
• Broken object and function-level authorisation: one customer reading or changing another customer’s data, or a normal user calling an admin function.
• Business logic abuse: replaying payment requests, tampering with amounts, skipping steps in a flow or exploiting refund logic.
• Authentication and token handling: weak token validation, long-lived tokens, and flaws in login, reset, and session flows.
• Injection in API parameters: testing request fields, headers and bodies with crafted input, which usually needs authenticated requests.
• Excessive data exposure and mass assignment: responses that return more fields than they should or accept fields they should ignore.
• Rate limiting and abuse resistance: whether the API can be scraped, brute-forced or flooded.
• GraphQL-specific exposure: introspection and query-depth abuse are typically not checked by an ASV scan.
• Tenant isolation: in a SaaS product, whether one tenant can reach another tenant’s data.
• Anything behind a login: the scan never sees authenticated endpoints.
This is why a passing ASV report is not a statement about API security. It means no finding scored CVSS 4.0 or higher among the things the scanner could see. The OWASP API Security Top 10 is a useful list of what the scan leaves out.
Use API-focused penetration testing, secure development controls and runtime protection next to the ASV scan. PCI DSS rarely names APIs outright, but they are bespoke software and fall under the application requirements.
|
Question
|
What answers it
|
Related requirement
|
|---|---|---|
|
Are my external hosts and services patched and configured safely?
|
ASV scan
|
11.3.2, plus 11.3.2.1 after significant changes
|
|
Can an attacker abuse my API logic or authorisation?
|
API penetration test, manual and authenticated
|
11.4, which expects application-layer testing
|
|
Is my code free of common flaws before release?
|
Code review, static and dynamic testing
|
6.2.3 and 6.2.4
|
|
Are public-facing apps and APIs protected continuously?
|
WAF or API gateway protection, or another automated technical solution
|
6.4.2
|
|
Do we know every API and component we run?
|
API and software inventory
|
6.3.2
|
See what each part of an ASV report tells your assessor.
An ASV scan tests exposed infrastructure automatically and anonymously each quarter. A penetration test is a manual, authenticated attempt to exploit your API, expected at least every 12 months and after significant changes. Neither replaces the other.
An ASV scan is automated and anonymous, runs at least every three months, and must be done by an ASV. A penetration test is manual and human-led, is expected at least every 12 months and after significant changes, and must be done by a qualified, independent tester. The scan measures breadth across your exposed infrastructure. The test measures depth against your API. Neither replaces the other.
For API penetration testing under PCI, give the tester your API inventory, test accounts for each role, and your documentation so they can test authenticated and cross-tenant behaviour. Application-layer testing is expected to cover at least the attack types in requirement 6.2.4, including injection, business logic and access control.
A proper API assessment goes well beyond running automated tools against an endpoint. It should include:
• Authentication and session management: API keys, OAuth tokens and JWTs are configured securely, cannot be guessed, and are invalidated on logout or expiry.
• Authorisation: every endpoint enforces access control at both object level and function level, not only at login.
• Input validation and injection: how the API handles malformed or malicious input across parameters, headers and bodies.
• Data exposure: responses return only the minimum necessary fields, with no extra cardholder data or internal metadata.
• Rate limiting and resource controls: limits that prevent credential stuffing, scraping and denial of service.
• Third-party integrations: how the API talks to payment gateways, processors and webhook receivers.
Retest after significant changes such as new API versions, new endpoints that touch the cardholder data environment, changed authentication or changed third-party integrations. Many teams under-test APIs because they apply the quarterly ASV cadence to their whole security program, when penetration testing runs on its own schedule.
List every public IP and hostname that serves or supports in-scope APIs, keep addresses stable, tell your ASV about any WAF or CDN, and re-scan after significant changes.
Use this routine for a PCI ASV scan for SaaS:
1. Inventory your public surface. Pull API hostnames from DNS, your gateway and your cloud account, not from memory.
2. Decide what is in or connected to the cardholder data environment. Payment, tokenisation, authentication and admin services usually are.
3. Prefer stable addresses. Elastic or static IPs make scope and rescans predictable.
4. Declare your WAF, CDN and gateway. Scan the edge and any origin that can be reached directly.
5. Allowlist the scanner. An IPS or WAF that blocks it can invalidate results. Document the rule you add.
6. Attest the scope. You, not the ASV, confirm that it is complete.
7. Rescan after significant changes. New hosts, moved gateways and changed data flows need a fresh external scan.
8. Book the API penetration test separately. Hand the tester the same inventory.
If you use a hosted payment page or tokenisation provider, your own scope may be smaller. Ask your QSA or acquirer before assuming. To check what to look for in a vendor, read how to choose an ASV vendor.
SaaS platforms carry extra risk because the architecture is API-first. A SaaS payment product typically exposes many endpoints, serves multiple tenants, receives webhooks from several processors, and ships code continuously. A quarterly ASV scan checks the exposed infrastructure, but between penetration tests the APIs themselves go largely unexamined. Layer the rest of the program around the scan:
• Change-triggered retesting: retest targeted areas when authentication, data flows or API architecture changes.
• Continuous API monitoring: runtime tools that watch for unusual endpoint access, data exfiltration patterns and abuse between test cycles.
• Developer training: teach engineers the OWASP API Security Top 10 so flaws are prevented before testing finds them.
• API inventory: keep a current list of every API so scope, testing and monitoring cover all of them.
So, does an ASV scan cover APIs? It covers the hosts and services that expose them, and it will catch known vulnerabilities, risky services and weak TLS on those hosts. It does not test your API logic, authorization or anything behind a login. Treat the ASV scan as the perimeter check PCI requires, scope it by hostname and IP, and pair it with API penetration testing, secure development and runtime protection. These controls are complementary, not interchangeable, and teams that treat them that way get the layered defence payment security needs.
Walk through 11.3.2, rescans and the evidence auditors ask for.
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.