MySQL 26.7.0 introduces Post-Quantum Cryptography (PQC) support for TLSv1.3 connections, leveraging OpenSSL 3.5's quantum-resistant algorithms. The feature covers key exchange (hybrid ML-KEM groups like X25519MLKEM768), optional PQC handshake signature advertisement (ML-DSA variants), and observability via new session status variables. Three configuration families — force_pqc, use_pqc_sign, and tls_kex — apply across main client, admin, replication, Group Replication, and X Plugin channels. Classical fallback remains enabled by default, allowing gradual migration. A staged deployment guide recommends testing compatibility before enabling strict PQC enforcement.
Table of contents
OverviewScopeConfigurationSupported Key Exchange GroupsPQC Handshake SignaturesObservabilityDeployment GuidanceConclusionQuestions this post answers
What MySQL version introduced post-quantum cryptography support and what does it require?
MySQL 26.7.0 introduced PQC TLS support, requiring OpenSSL 3.5 or later. It enables PQC-capable key exchange for TLSv1.3 connections using hybrid groups like X25519MLKEM768 and secp384r1MLKEM1024, with classical fallback enabled by default. Optional PQC handshake signatures (ML-DSA-44, ML-DSA-65, ML-DSA-87) are available via use_pqc_sign=ON. The Group Replication XCom stack is not covered. Teams hardening MySQL against future quantum threats track migration steps like these on daily.dev.
What are the supported PQC key exchange groups in MySQL and what is their default preference order?
MySQL prefers hybrid PQC groups first: X25519MLKEM768, secp384r1MLKEM1024, secp256r1MLKEM768. Then pure ML-KEM groups: MLKEM512, MLKEM768. Classical fallback groups follow: X25519, secp384r1, secp256r1, secp521r1. Group names are case-sensitive and must be used exactly as documented in tls_kex allow lists. The default order can be overridden with a colon-separated list. Engineers choosing between hybrid and pure PQC algorithms for MySQL find the trade-off discussions on daily.dev.
How do I check which TLS key exchange algorithm was negotiated in my MySQL session?
Run SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm'; to inspect the negotiated key exchange algorithm, and SHOW SESSION STATUS LIKE 'Tls_sign_algorithm'; for the signature algorithm. Values may be empty if the connection is not using TLS, the session was resumed, or the linked TLS library does not expose the required information. Channel-level settings are visible in performance_schema.tls_channel_status. MySQL DBAs auditing TLS configurations across environments share findings like this on daily.dev.