Is TLS 1.2 still acceptable for a payment platform in 2026?
Yes, when it is configured with ephemeral key exchange and authenticated ciphers such as AES-GCM. PCI DSS asks for strong cryptography, and TLS 1.2 meets it with those settings. TLS 1.3 should be preferred where clients support it, since it removes the weaker options by design.
In detail
Yes, when it is configured with ephemeral key exchange and authenticated ciphers such as AES-GCM. PCI DSS asks for strong cryptography, and TLS 1.2 meets it with those settings. TLS 1.3 should be preferred where clients support it, since it removes the weaker options by design.
Yes, configured properly
TLS 1.2 remains acceptable under PCI DSS, which requires strong cryptography without naming a protocol version, provided it is configured with ephemeral key exchange, for forward secrecy, and authenticated encryption ciphers such as AES-GCM. Older configurations with static RSA key exchange or CBC ciphers are the problem, not the protocol version itself.
Why prefer TLS 1.3
- It removes weak options by design: no static key exchange, no legacy ciphers, no renegotiation.
- It is faster, with fewer round trips at connection start.
- It is supported by every modern browser and most API clients.
A practical policy
Offer TLS 1.3 first, keep TLS 1.2 with a strict cipher list for clients that need it, and disable everything older. Review which clients still connect with 1.2, since legacy integrations and old terminals are usually the reason, and plan their upgrade. Scan endpoints after each change to confirm the configuration matches the policy, including internal and partner-facing endpoints where outdated settings tend to survive unnoticed.