Check Point and the Post-Quantum Transition
In this blog
Quantum computing will change cryptography forever. It is not a question of if, but when large-scale quantum processors arrive that can run Shor's algorithm and factor the numbers that underpin RSA and elliptic-curve encryption.
The impact will be immediate and irreversible: every digital signature, VPN tunnel and HTTPS session that relies on those classical methods will be vulnerable. The concept of "harvest-now, decrypt-later" is not theoretical. State actors are believed to be already archiving encrypted traffic in anticipation of that future capability. Governments and vendors are responding in different ways, but the timeline is clear.
The U.S. National Institute of Standards and Technology (NIST) finalized its first post-quantum cryptography (PQC) standards in 2024 with FIPS 203 (ML-KEM) for key exchange and FIPS 204 (ML-DSA) for digital signatures. The National Security Agency (NSA) followed with the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), directing all National Security Systems to complete their migration to quantum-resistant algorithms by 2035, with procurement-level compliance beginning in 2027.
Check Point has positioned itself on the forward edge of this transition. The company's Quantum Security Gateways already meet or exceed CNSA 1.0 baselines, and their architecture is engineered for cryptographic agility. Three core areas define how Check Point is approaching PQC readiness today: Secure Internal Communication (SIC), IPsec VPN/IKEv2, and HTTPS Inspection with its bypass and interception modes.
SIC: Trust foundations
SIC provides the trust backbone between management servers and gateways. It authenticates and encrypts control channels that distribute policy and keys. Currently, SIC uses RSA-based mutual authentication with AES-256 for transport encryption. This design remains cryptographically strong in the classical sense and aligns with CNSA 1.0 guidance. However, RSA will not survive a cryptanalytically relevant quantum computer. Check Point has prepared for that inevitability by implementing crypto-agile certificate handling in Gaia OS and Infinity management. The SIC framework is built so its authentication layer can transition to ML-DSA (formerly CRYSTALS-Dilithium) signatures once FIPS-validated libraries are available. The change will not require reengineering of the control plane; only key material and signature verification routines will shift to post-quantum primitives. In practice, Check Point's architecture allows management domains and gateways to re-enroll using new algorithms without breaking established SIC trust chains, which is an interesting feature for minimizing downtime when the cutover to PQC begins.
VPN and IKEv2: Hybrid key exchange
VPNs represent the most visible implementation of public-key cryptography in Check Point environments. IPsec with IKEv2 negotiates encryption parameters and builds tunnels using a mix of ECDH key exchange, AES-GCM encryption, and SHA-384 integrity checks. These algorithms meet the current CNSA 1.0 and draft 2.0 recommendations for symmetric strength and integrity, but the key exchange component is vulnerable to quantum attack. Check Point addressed this in R82, which introduced hybrid post-quantum VPN capabilities that follow RFC 9242 and RFC 9370. The new implementation combines a classical Diffie-Hellman exchange with a lattice-based scheme derived from ML-KEM (the standardized successor to CRYSTALS-Kyber). When a connection is initiated, both key exchanges run in parallel, and the resulting session keys are blended to form a hybrid secret. This approach ensures that even if ECDH were compromised by a future quantum machine, the PQC component would still protect the confidentiality of the session.
Administrators can also configure hybrid IKE parameters through the API, specifying ML-KEM variants equivalent to Kyber512, 768, or 1024. Check Point's default proposal pairs DH Group 15 with ML-KEM 768, balancing performance and security. Early testing in R82 shows that gateway throughput remains stable due to optimizations in the VPN daemon and multithreaded cryptographic processing under CoreXL. Maestro's distributed fabric adds further resilience by spreading the increased computational load across the security group, which could have up to 28 appliances, and emerging BlueField DPU acceleration could offload PQC math entirely to hardware. This combination of hybrid key exchange and hardware parallelism marks one of the first practical, aligned to standards post-quantum VPN deployments in a commercial firewall.
HTTPS inspection and bypass: PQC-aware, not PQC-terminating
HTTPS Inspection is the one area where PQC has introduced a near-term limitation that affects every vendor equally. Since mid-2024, major browsers have implemented experimental hybrid TLS 1.3 handshakes that combine ECDHE with ML-KEM as part of NIST's transition strategy. Check Point gateways running R81.10 through R82 recognize these PQC cipher suites but cannot yet terminate them. In bypass mode, when inspection is disabled or an explicit bypass rule applies, the gateway simply forwards the TLS handshake without alteration. Both client and server can negotiate hybrid key exchanges, achieving end-to-end quantum-safe confidentiality. In inspect mode, where the gateway performs a man-in-the-middle proxy for decryption, it declines PQC cipher proposals and forces a fallback to classical TLS 1.3. The result is full visibility for classical sessions but opaque handling for PQC-enabled ones. Each event is logged with clear indicators of cipher negotiation, allowing administrators to identify where PQC traffic appears in their environment.
This behavior is deliberate, not a deficiency. The broader ecosystem of OpenSSL, NSS, and FIPS-validated PQC modules has yet to deliver stable support for hybrid certificate generation and dual-signature validation. To my knowledge, no vendor currently decrypts PQC-TLS traffic in an interception proxy. Check Point's approach is visibility and control: gateways can already distinguish PQC sessions, enforce policy, and maintain compliance while preserving performance. Once the hybrid TLS drafts reach final form and the supporting libraries are certified, Check Point can extend its inspection engine to participate directly in PQC handshakes without re-architecting a proxy layer.
Hardware and migration readiness
Implementing PQC introduces heavier computational requirements due to large key sizes and lattice operations. Check Point has prepared for this with a scalable hardware and software architecture. CoreXL and SecureXL distribute cryptographic tasks across multiple cores, while Maestro's hyperscale orchestration manages session load across clusters. The integration of NVIDIA BlueField DPUs could further accelerate key encapsulation mechanisms when those modules gain FIPS 203 validation, and the architecture of where the BlueField DPU would live is decided. These optimizations mean that the transition to PQC, though mathematically more demanding, will not cripple gateway performance or throughput.
Practical steps for customers
WWT encourages customers to start preparing now. Inventory where RSA and ECC are used across your Check Point infrastructure, including SIC, VPN and certificate infrastructure. Maintain current releases such as R81.20 Jumbo HFAs and prioritize moving to R82 to ensure crypto-agile support. Begin pilot testing of hybrid VPN tunnels in controlled environments and monitor TLS logs for PQC handshake activity. Coordinate with PKI and HSM vendors on their adoption of ML-DSA signatures and CNSA 2.0 compliance. Align organizational policies with NSA transition timelines: new acquisitions after 2027 should be quantum-resistant, and legacy systems should phase out non-CNSA algorithms by 2030. These steps allow a gradual and predictable migration rather than a disruptive overhaul.
Infinity architecture: Centralized control for the PQC future
Infinity's unified management gives Check Point an operational advantage. It provides a single plane for cryptographic policy, certificate distribution and gateway upgrades. As PQC support expands, Infinity can propagate algorithm changes consistently across all managed assets, on-premises, cloud, and mobile, without manual reconfiguration. ThreatCloud's telemetry already captures PQC session metadata, providing visibility into early adoption trends and aiding compliance reporting. When hybrid TLS inspection becomes available, Infinity's automation and logging will make deployment straightforward.
Wrapping up
Check Point's security stack is not yet fully post-quantum, but it is quantum-ready. SIC and HTTPS inspection still use classical key exchange and signatures, while VPNs in R82 now support true hybrid post-quantum tunnels aligned with NIST and CNSA 2.0 standards. Every core system (management, encryption and inspection) has been engineered for cryptographic agility, allowing new PQC algorithms to be integrated through software updates rather than infrastructure replacements. Organizations using Check Point today can confidently defend themselves in the present while being structurally prepared for the evolving cryptographic landscape of tomorrow.