PCI Compliance for PayPal Merchants: Full SAQ Guide 2026
PCI compliance for PayPal merchants explained: which SAQ you need, when ASV scans apply, and how the 2026 PCI DSS v4.0.1 rules changed eligibility.
An open-ports PCI ASV scan failure shows up in almost every quarterly scan report, and it rarely arrives with a plain-English explanation. What you get instead is a port number, the service running behind it, a CVSS score, and remediation language that assumes you already know the difference between a bastion host and an egress rule. If you’re the person who has to close the finding before the compliance deadline, that gap between “here’s the finding” and “here’s what to change in the firewall” is where remediation usually stalls.
PCI DSS Requirement 1 governs network security controls, and it’s explicit: organisations must restrict inbound and outbound traffic to only what the cardholder data environment actually needs. An ASV scan is the external, third-party verification that this control is real and working, not just documented on paper. When open ports fail that test, the gap is real, and the only credible response is remediation, not a dispute for the sake of buying time.
This guide breaks the finding down completely: which ports get flagged most often, why PCI DSS treats them as a compliance issue rather than a technical nuisance, which open-port findings are automatic failures, and the exact remediation sequence, including the cases where closing the port isn’t the right fix at all.
Open port: a network port actively listening for incoming connections. ASV scanners test every port in scope from outside your network, the same vantage point a real attacker would use.
Unnecessary open port: a port reachable from the public internet without a documented business purpose, whether because the service should only be accessible internally or isn't in active use at all.
Cardholder Data Environment (CDE): the systems, network segments, and components that store, process, or transmit cardholder data, plus anything that could affect the security of that data. The CDE is the primary scope of PCI DSS obligations, including ASV scanning.
Automatic failure condition: a finding class the PCI ASV Program Guide requires scanning vendors to fail outright, regardless of compensating controls, because the underlying risk is considered unacceptable on its own.
Rescan: a follow-up scan against the same in-scope IPs and ports after remediation, required to produce the clean report your Attestation of Scan Compliance depends on.
The recurring offenders are FTP (21), Telnet (23), RDP (3389), VNC (5900/5901), SMTP (25) misconfigurations, unauthenticated database ports (3306 MySQL, 1433 MSSQL, 6379 Redis, 27017 MongoDB), and admin panels exposed on non-standard ports like 8443 or 8080.
These ports aren’t flagged because the number itself is dangerous. They’re flagged because the service typically running behind them transmits data unencrypted, allows weak or default authentication, or exposes an administrative interface that shouldn’t be reachable by anyone outside your team. A database port open to the internet without an authentication layer is functionally an invitation; an admin dashboard on a non-standard port is still an admin dashboard, however it’s numbered.
Anonymous FTP and unencrypted Telnet sit in a more serious category; both are called out directly as automatic failure conditions in the PCI ASV Program Guide, which is covered in more detail in our breakdown of PCI ASV scan requirements.
Talk to an Approved Scanning Vendor who explains every finding in plain language and supports you through remediation, not just the report.
Unnecessary open ports fail PCI DSS requirements because they violate least-privilege network access; it is a testable, verifiable control under Requirement 1, not a best-practice suggestion. If a port has no documented, necessary business function inside your CDE, its presence is a finding by definition.
The scanner doesn’t know and isn’t designed to assume whether an open port serves a legitimate purpose. It reports what’s externally reachable, and the burden of demonstrating necessity sits with your organisation. This is least privilege applied to network access, the same logic that governs user permissions: a port should only be open when it serves an active, secured, and necessary function, not because it was left running after a project ended or inherited from a previous team’s configuration.
Businesses sometimes push back on this kind of finding by pointing out the service “isn’t really being used.” Under PCI DSS, that’s not a mitigating factor; it’s confirmation that the port should be closed. If it isn’t needed, it shouldn’t be open, and remediation is as simple as updating the firewall ruleset to deny external access.
Open ports tied to specific high-risk or deprecated protocols meet the PCI ASV Program Guide's automatic failure threshold, meaning no dispute or compensating control can override the finding without closing or replacing the underlying service.
The Program Guide defines special circumstances and automatic failures: vulnerability classes severe enough that a scan cannot pass regardless of anything else in the report. A CVSS score of 4.0 or higher on an externally facing finding is itself a failing condition, and many open-port vulnerabilities, unauthenticated database access, known remote-code-execution paths, and exposed management interfaces like RDP or SSH with no restriction routinely score at or above that line.
It’s worth understanding what the scanner is actually doing here: it’s reproducing exactly what an external attacker’s reconnaissance would find. The ASV’s obligation under PCI SSC rules is to report that accurately, which is why a finding that meets the automatic failure threshold can’t be issued as a passing report, and why your acquiring bank can’t accept it as evidence of compliance until the port is genuinely resolved.
FTP (port 21) and Telnet (port 23) are among the most consistently cited PCI ASV scan open ports remediation items because both protocols transmit data, including login credentials, in plaintext, with a long, well-documented history of exploitation.
Neither protocol was designed with encryption in mind, which puts them at odds with PCI DSS’s requirement to protect cardholder data in transit, whether the exposure is inside the CDE or simply reachable from the internet. They also show up more often than almost any other finding for a mundane reason: they’re default services that get left running long after anyone stopped actively using them. A server configured years ago may still have FTP enabled by default; a network device may have Telnet on because it was the factory management interface when it was deployed.
PCI DSS Requirement 2 addresses this directly; unnecessary services, protocols, and daemons must be disabled. If there’s no active business need for FTP on a CDE-connected system, disable the service and confirm at the firewall that port 21 is blocked externally. For teams that genuinely need file transfer or remote administration, the fix isn’t to keep the insecure version open; it’s to replace FTP with SFTP or FTPS and Telnet with SSH. These aren’t workarounds; they’re the compliant substitutes PCI DSS expects.
Remediation follows a defined sequence: identify the service, assess its business necessity, close or harden it, document the change, and rescan to confirm. Skipping steps in this order is the most common reason a finding recurs on the next quarterly scan.
The first response to a flagged port shouldn't be to close it blindly; closing a port without understanding its function can break a legitimate business process. Determine what's running on the port, who owns it, and why it was opened.
If the service has no documented business purpose in the CDE, close it: block external access at the firewall, disable the service, and document the change. If it is necessary, the next question is whether the service and its configuration meet PCI DSS requirements on their own merits; a necessary service on an outdated version with weak authentication still fails, and the finding doesn't go away just because the port has a reason to exist.
For ports that must remain reachable, hardening means patching the service to a current, supported version, restricting access to the specific IP ranges or VPN that legitimately need it, enforcing strong authentication, enabling logging, and disabling unnecessary default features. Each step narrows the attack surface without eliminating the function the business relies on.
PCI DSS expects firewall rule changes to be documented and business justifications for necessary open ports kept on record. This documentation also supports any legitimate dispute process later.
Remediation isn't complete until an external rescan confirms the fix. Teams that remediate but delay the rescan extend their own compliance gap for no reason; our guide to passing a PCI ASV scan on the first attempt covers how to structure this timeline against a quarterly deadline.
Get a compliance specialist to walk through your report and tell you what's a quick fix, what needs hardening, and what's genuinely disputable.
Closing open ports for PCI compliance is primarily a firewall task, but a firewall rule alone isn't the complete fix; pair it with disabling the underlying service, or a later configuration change can silently re-expose the port.
A firewall rule blocking external access is the fastest way to stop the ASV scanner and a real attacker from reaching a service. But if the service is still running internally, it’s a residual risk, and PCI DSS Requirement 2’s language on unnecessary services applies independently of the firewall rule. Best practice is a two-layer close: disable the service at the OS or application level first, then confirm the firewall blocks any external path to that port. That way, even if the firewall rule is later modified or removed, there’s no live service behind it to exploit.
Before requesting a rescan, verify both layers: use an internal scan to confirm the service is no longer listening, and review the firewall ruleset to confirm the external block is actually in place. Disabling, blocking, verifying, and rescanning in that order is the reliable path to clearing an open-port finding for good.
On hosted e-commerce platforms, some open-port findings belong to the platform's own infrastructure rather than your store configuration; the finding still appears because your IP is in scope, even though you can't change the port yourself.
This comes up often enough on Shopify specifically, with non-standard ports like 8443 tied to the platform’s own load balancers, so it needs a different remediation path than a self-managed server. You can’t SSH into infrastructure you don’t own. The correct steps are to confirm with the platform whether the port is expected and already secured on their end, document that confirmation for your ASV, and in some cases request a scope adjustment so the finding is scanned and attested correctly rather than flagged against infrastructure outside your control.
Our Shopify PCI compliance guide and BigCommerce PCI compliance guide walk through this scoping question for each platform. WooCommerce stores sit closer to the self-managed end of the spectrum since the store runs on infrastructure you typically do control; see our WooCommerce PCI compliance guide for that distinction.
Test the port from outside your network, not from inside it; an internal test will show a port as closed even when it's still reachable externally, because it's checking the wrong vantage point entirely.
A firewall rule that only affects internal traffic, or a security group update that didn’t propagate to every instance behind a load balancer, are both common reasons a “resolved” finding reappears on rescan. Before requesting one:
Yes, through the ASV's formal exception process, but only when the finding is a genuine false positive or documented compensating controls exist, and automatic failure conditions like anonymous FTP or unencrypted Telnet generally can't be disputed away.
Disputing a finding requires substantial evidence and ASV review, and it’s rarely faster than simply closing or hardening the port. Save the dispute path for cases where the scanner has genuinely misread the environment, not as a way to delay remediation you already know is needed.
An open ports PCI ASV scan failure is a specific, actionable signal, not an ambiguous one, it tells you exactly where your network configuration falls short of what PCI DSS requires, whether that’s a forgotten FTP service, a Telnet-enabled legacy device, or a database port exposed with no access control. The remediation path is consistent regardless of which port triggered it: identify the service, assess whether it’s actually needed, close it or harden it, document the change, and confirm the fix with an external rescan before you consider the finding resolved.
Treating these findings as a structured audit of your real security posture, rather than paperwork standing between you and a passing report, is what makes the process repeatable every quarter instead of a scramble each time. An open port that fails your scan today is the same port a real attacker could probe tomorrow; closing or restricting it is substantive risk reduction, not compliance theater.
This guide draws on PCI DSS v4.0 and the PCI ASV Program Guide published by the PCI Security Standards Council. For requirement-level citations, consult the official documentation library at pcisecuritystandards.org. See also PCI DSS v4.0 and ASV scanning and how open port findings differ from a general failed scan for related context.
See how the Secusy ASV reseller program helps agencies and MSPs deliver scanning and remediation support at scale.
Open ports represent potential entry points into a cardholder data environment. PCI DSS requires that only necessary ports remain accessible, so an ASV scanner flags any open port without documented business justification as a finding that must be resolved before the scan can pass.
No. Ports tied to services the business actually needs can usually be restricted to approved sources, such as a VPN, a bastion host, or specific IP ranges, instead of being closed outright. Closing a port that's still needed just creates an outage in place of a finding.
Automatic failure conditions are specific findings, including anonymous FTP, unencrypted Telnet, and open DNS zone transfers; that the PCI ASV Program Guide requires scanning vendors to fail regardless of CVSS score or compensating controls.
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.