How often should a PSP scan its TLS endpoints?

After every configuration change and on a regular schedule, at least as often as the quarterly vulnerability scans PCI DSS already requires. Public endpoints, internal services and partner-facing APIs should all be included, since outdated settings tend to survive on the endpoints nobody looks at.

Two triggers

A TLS scan should run after every configuration change, because that is when regressions appear: a new load balancer with default settings, a certificate renewal that reset the cipher list, a service deployed with an old base image. It should also run on a schedule, at least as often as the quarterly external vulnerability scans PCI DSS already requires, so drift is caught even when nobody changed anything on purpose.

What to include

• Public endpoints: checkout pages, APIs, merchant and customer portals.
• Internal services that talk to each other over TLS.
• Partner-facing APIs and webhooks, where an old setting can break a provider integration.
• Certificates: expiry dates, chain validity, key sizes.

Why the forgotten endpoints matter

Outdated TLS settings rarely survive on the main checkout page, which everyone tests. They survive on the status page, the old API version kept for one partner, the SFTP server used for reports. An inventory of every endpoint with its last scan date is the control that catches those. Automating the scan and failing a deployment when the policy is not met turns the control into a gate rather than a report.