A secure TLS configuration is more than enabling HTTPS: it combines DNS CAA records, HSTS headers, TLS 1.2 and 1.3 only, ephemeral elliptic-curve key exchange, authenticated ciphers and regular external testing. For PSPs, PayFacs and ISVs operating a payment platform, this checklist is also what PCI DSS expects under its strong cryptography requirements.
The padlock in the browser only says that a connection is encrypted, not that it is well encrypted. This article, first written by Damien Fleuriot and updated in October 2026, explains why the padlock is not enough, which TLS versions remain acceptable, which attacks still matter, which settings make a safe configuration, how to test it, what PCI DSS requires, and what a PSP's leadership should ask its teams.
Why does the browser padlock not mean a payment page is secure?
Because TLS is not a single switch. The padlock appears as soon as a valid certificate and an encrypted connection exist, whatever protocol version, key exchange or cipher was negotiated. A server that still accepts outdated versions or weak ciphers shows the same padlock as a well-configured one.
For a payment platform, the gap matters: checkout pages, merchant consoles and APIs carry card data, credentials and payment instructions, and their security depends on choices the visitor never sees.
What is TLS and which versions are still acceptable?
Transport Layer Security encrypts and authenticates communication between a client and a server, from web browsing to APIs and email. The two parties agree on keys, then use them to encrypt and sign every message.
Only TLS 1.2 and TLS 1.3 remain acceptable. The PCI Security Standards Council required early TLS to be retired from June 30, 2018, and major browsers removed TLS 1.0 and 1.1 in 2020. TLS 1.3, defined in RFC 8446 in 2018, is faster and removes the weaker options of earlier versions.
Which TLS attacks still matter for a payment platform?
Most historic attacks targeted options that a modern configuration simply disables: DROWN exploited SSLv2, POODLE exploited SSLv3 and CBC padding, Logjam exploited weak Diffie-Hellman groups, ROBOT exploited RSA key exchange, and Heartbleed exploited an implementation bug in OpenSSL in 2014.
They still matter because legacy endpoints, internal services and third-party integrations often keep old settings long after the public website is fixed. The OpenSSL vulnerability retrospective shows how implementation flaws keep appearing.
Which settings make a safe TLS implementation?
- DNS CAA records: publish which certificate authorities may issue certificates for your domains.
- HSTS headers: instruct browsers to always use HTTPS, rolled out carefully, since a mistake can make a site unreachable.
- TLS 1.2 and 1.3 only, with TLS 1.3 preferred.
- Ephemeral elliptic-curve key exchange (ECDHE) for forward secrecy, and hybrid post-quantum key exchange where supported.
- Authenticated ciphers only: AES-GCM and ChaCha20-Poly1305; disable CBC-mode suites and static RSA key exchange in TLS 1.2.
Post-quantum protection is no longer theoretical: according to PostQuantum.com, hybrid ML-KEM key exchange, the default in Chrome and Firefox since late 2024, was standardized in RFC 10024 in August 2026, and more than two-thirds of human-initiated TLS traffic to Cloudflare used it by April 2026.
How do you test a TLS configuration before and after a change?
With external scanners that negotiate every protocol, key exchange and cipher your servers accept: Qualys SSL Labs, ImmuniWeb and the open-source testssl.sh for internal endpoints.
Test before announcing a change, warn integrators well in advance when older clients will lose access, and test again afterwards. Expect partners and enterprise merchants to run the same scans on your domains during due diligence.
What does PCI DSS 4.0 require for TLS on a payment platform?
PCI DSS requires strong cryptography wherever cardholder data travels over open, public networks, with certificates confirmed as valid and not expired, and an inventory of trusted keys and certificates. Early TLS and SSL are not acceptable.
Operators can reduce the number of endpoints in scope by having card data captured on pages and fields served by a validated provider, as with Smart Checkout. The PCI DSS v4.0 guide for PayFacs covers the wider requirements.
What should a PSP's CTO or compliance officer ask their team?
- Which protocol versions, key exchanges and ciphers do our public and internal endpoints accept, and why?
- When were they last scanned, and what changed since?
- Do we support hybrid post-quantum key exchange where our edge and clients allow it?
- How do we track new attacks and library vulnerabilities, and how fast can we patch?
On NORBr, these controls are part of platform operations and security, so operators building on the platform inherit them for the checkout and API layers.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
