Vendor compatibility
Check Point post-quantum VPN support
Check Point Quantum Security Gateways running Gaia, managed through Security Management or Multi-Domain Security Management, terminating site-to-site IPsec.
Last reviewed
2 compatibility records
Direct answer
Check Point post-quantum VPN capability depends on the Gaia software version, the installed jumbo hotfix take, and the management server version, which must generally be at or ahead of the gateway. Establish all three per gateway before assessing migratability. The management server version is frequently the constraint that determines when a gateway change can actually be made.
Practical status
What this means in a real estate
Check Point estates carry a coupling that most other vendors do not: the management server version gates what can be configured on the gateways it manages. A capability present in a gateway release is not usable until management supports expressing it. Any inventory of a Check Point estate must therefore record the management topology alongside the gateway versions, and migration waves must sequence management upgrades before gateway changes.
What to establish about key exchange
Establish per version and hotfix take which IKEv2 mechanism is available, and whether it is configurable through SmartConsole or only through a lower-level configuration path. A capability reachable only through a per-gateway file edit is not a viable migration mechanism across a large estate and changes the effort estimate substantially.
Why authentication is a separate question
Peer authentication is unchanged by a key establishment migration. A Check Point tunnel using a hybrid key exchange continues to authenticate using its existing certificate or preshared key, and post-quantum authentication remains dependent on separate certificate and PKI capability.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| Check Point Quantum Security Gateway on Gaia | Post-quantum key establishment: Unsupported |
| Check Point Quantum Security Gateway on Gaia | Post-quantum key establishment: Requires exact-version review |
Check Point Quantum Security Gateway on Gaia
R81.xCapability depends on the Gaia version and the installed jumbo hotfix take, and on whether the management server version can express the setting.
Migration implication: Sequence management upgrades ahead of gateway changes. A migration wave that assumes the gateway is the only dependency will stall on the management server.
Caveats
- Management server version gates what can be configured on the gateway
- Behaviour can change between jumbo takes within a single version
Last reviewed · medium confidence · 1 source
Check Point Quantum Security Gateway on Gaia
R82.xNewer Gaia versions must still be paired with a management server at or ahead of the gateway version before the capability is usable.
Migration implication: Where management is shared across domains, one management upgrade can be a prerequisite for many gateways at once, which makes it a natural wave boundary.
Caveats
- Gateway and management upgrades are separate change events with separate risk
Last reviewed · low confidence · 1 source
Prerequisites
Establish these before assessing migratability.
- Gaia version and jumbo hotfix take per gateway
- Security Management or Multi-Domain Management server version
- Confirmation that management version supports configuring the intended mechanism
- Cluster member consistency across ClusterXL pairs
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- Both peers must negotiate the same mechanism
- Where the community spans multiple managed domains, each domain's management version applies
- Externally managed peers require independent confirmation
Operational limitations
Constraints that shape the plan rather than block it.
- Management server version gates gateway configuration, adding an upgrade dependency
- Jumbo hotfix takes change available behaviour within a single version
- ClusterXL members must be migrated in a defined order to preserve state
Migration paths
The routes available when the current state is not the target.
- Upgrade management first, then gateways, where the capability exists
- Apply a jumbo hotfix take that carries the capability where a full upgrade is not viable
- Replace gateways that cannot reach a supporting version
- Defer and track, with the management dependency stated explicitly
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm the negotiated key exchange on the active cluster member
- Verify after failover, since the standby member carries its own state
- Record evidence against the change ticket for both peers
Sources
No primary sources have been recorded for this entry yet. Until they are, nothing here is presented as a confirmed capability.
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual Check Point estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.