A failed PCI scan isn't the end of the world. Almost every business fails their first one, and most of the reasons are common and fixable. Here are the issues we see most often, and what to do about each one.
1. Expired or Self-Signed SSL/TLS Certificates
Your certificate proves to visitors that they're really talking to your server, not an impostor. If it's expired, self-signed, or doesn't match your domain name, the scan flags it, and browsers will warn your customers too.
Fix: install a valid certificate from a trusted certificate authority before it expires, and set a reminder (or use auto-renewal) so it doesn't happen again.
2. Outdated TLS Versions and Weak Ciphers
Older protocols like SSLv3 and TLS 1.0/1.1, along with weak ciphers like RC4, have known weaknesses that attackers can exploit. Scans flag any server still offering them, even if a newer, safer version is also available.
Fix: turn off SSLv3 and TLS 1.0/1.1 in your server config, and support TLS 1.2 or 1.3 only. Most web server software (Apache, Nginx, IIS) has a config setting for this.
3. Unpatched Software With Known Vulnerabilities
This is the single biggest reason scans fail. Your operating system, web server, CMS, plugins, and any other software running on the box all get checked against public vulnerability databases. If a version has a known CVE, the scan will catch it.
Fix: keep everything patched, not just your CMS core. Plugins and themes are common blind spots. A regular patch schedule, even monthly, catches most of this before it becomes a scan failure.
4. Unnecessary Open Ports
Every open port is a door. If a service doesn't need to be reachable from the public internet, an open port for it just gives attackers something else to try.
Fix: close any port you don't actively need exposed, and put the rest behind a firewall that only allows the IP ranges that actually need access. See our guide on selecting a PCI DSS compliant firewall if you're not sure where to start.
5. Default or Leftover Credentials
Default admin logins, sample files, and setup scripts left over from an install are an easy win for an attacker, and an easy flag for a scanner. This shows up a lot on databases, admin panels, and IoT-style management interfaces.
Fix: change every default password before a server goes live, and delete install files, sample content, and setup scripts once you're done with them.
6. Server and Software Version Disclosure
Some servers announce exactly what software and version they're running, right in the response headers or error pages. That's not a vulnerability by itself, but it hands an attacker a shortcut: they know exactly which known issues to try first.
Fix: turn off version banners in your web server config, and use custom error pages instead of the default ones that name your software stack.
7. Missing Security Headers
Headers like HSTS, X-Content-Type-Options, and Content-Security-Policy tell browsers how to handle your site safely. Leaving them out doesn't hand over your data directly, but it removes a layer of protection the scan expects to see.
Fix: add the missing headers in your web server or application config. Most are a few lines each, and there are free header-checking tools you can use to confirm they're working.
8. Insecure Remote Access
Unencrypted FTP, Telnet, or an RDP port left open to the whole internet are all common flags. These services send credentials in the clear, or make it easy to brute-force a login from anywhere in the world.
Fix: replace FTP with SFTP, disable Telnet entirely, and restrict RDP to specific IPs or put it behind a VPN.
9. DNS and Mail Server Misconfigurations
Open DNS zone transfers, open mail relays, and missing SPF/DKIM/DMARC records all show up as findings. They're not always exploitable on their own, but they're the kind of loose end a scanner is built to catch.
Fix: restrict zone transfers to your own name servers, close open relays, and set up SPF, DKIM, and DMARC records for every domain you send mail from.
10. SQL Injection and Cross-Site Scripting
If your scan includes your web applications, it will try safe, non-destructive versions of common attacks like SQL injection and cross-site scripting. A vulnerable form field or URL parameter can let an attacker read your database or run scripts in another user's browser.
Fix: this one usually needs a developer. Use parameterized queries instead of building SQL strings by hand, and sanitize any user input before it gets displayed back on the page.
What ServerScan Offers
Every ServerScan report includes plain-language remediation guidance for each finding, not just a raw list of CVEs. And since unlimited scanning is included on every plan, you can fix an issue and rescan the same day at no extra charge, instead of waiting on your next quarterly window to find out if it worked.
If a finding doesn't make sense, or you think it's a false positive, reach out to our support team. We'll help you sort out what's real and what isn't.