Nearly every piece of data that moves across your network and the internet at large is protected by encryption. Encryption works by using math problems that today’s computers simply can’t solve fast enough to crack. That’s about to change.
Quantum computers are a new kind of machine. Without delving into physics, what matters is this: the encryption that takes today’s supercomputers millions of years to break will soon be breakable within hours. Already today, it’s thought that attacker groups and nation-state actors are capturing and stockpiling encrypted data, awaiting the moment when it can all be unlocked. Sensitive data crossing your network right now (financial records, intellectual property, system credentials) can be captured today and exposed tomorrow.
The solution is a new class of encryption algorithms called post-quantum cryptography (PQC). PQC is built on different math problems that quantum computers can’t shortcut the way they can with today’s algorithms. NIST has finalized these algorithms as formal standards, and governments and industry are moving quickly to require their adoption.
The NSA is requiring all National Security Systems purchases made after January 2027 to be future-proofed for these “quantum safe” standards. Australia has set an aggressive 2030 migration target. The European Union published its own roadmap with phased deadlines through 2035. Whether or not your organization is bound by these mandates, they will become de facto baselines for the entire world. The partners you connect with, the cyber insurance policies you carry, and the customers whose data you handle will all increasingly measure you by these standards.
Cisco Secure Firewall uses encryption for many things: VPN tunnels, remote management, hardware-level trust, and inline decryption. For network administrators this raises a very practical question: what does this transition to post-quantum cryptography look like for our infrastructure? This post lays out where we are, where we’re headed, and what you should be thinking about today.
NIST’s PQC standards define three algorithms, each designed to replace a specific class of classical cryptography. They also define stronger baselines of security for existing algorithms, which are already incorporated into Cisco Secure Firewall.
ML-KEM (FIPS 203) protects the moment two devices agree on a shared secret, the handshake at the start of every encrypted session. Today that job is done by algorithms like ECDH, which quantum computers will break. ML-KEM is different, built on a fundamentally different type of math problem (lattice-based cryptography) that resists both classical and quantum safe attacks. Support arrives in Secure Firewall Threat Defense (FTD) 10.5 and ASA 9.25, targeted for General Availability in late 2026.
ML-DSA (FIPS 204) is how devices prove their identity and how software proves it hasn’t been tampered with. Every time your firewall authenticates a VPN peer or verifies a signed software image, it relies on digital signatures. Today we use RSA or ECDSA, both of which quantum computers will break. ML-DSA is the quantum-safe replacement, also built on lattice-based cryptography. Support is planned for FTD/ASA 11.0, in the second half of calendar year 2027.
SLH-DSA (FIPS 205) is cryptography’s way of “diversifying your investments.” ML-KEM and ML-DSA are both built on lattice-based cryptography. SLH-DSA is intentionally built differently, using a different hash-based math problem. Its signatures are larger, but since its technique is different, it provides a critical safeguard for networks in case the lattice-based math problem is ever weakened by future research. Support is planned for FTD/ASA 11.0.
Cisco’s approach operates on two tracks:
Secure Communications: integrating PQC into the protocols that carry data – IPsec, TLS, SSH
Secure Products: securing the products themselves, ensuring the firewall’s own identity, software integrity, and boot chain are quantum-safe.
Both tracks align to the NIST standards and are being delivered into the platform well in advance of compliance deadlines and well before quantum computers capable of breaking today’s encryption exist.
For many organizations, IPsec VPN is the most immediate PQC concern — particularly for site-to-site tunnels protecting sensitive or classified data that could be subject to harvest-now-decrypt-later attacks. The good news is that Cisco hasn’t been waiting for the NIST algorithms to ship before providing transitional protections.
Several critical RFCs are already supported on ASA and coming to FTD in 10.5:
RFC 8784 (Mixing Preshared Keys in IKEv2) allows a post-quantum pre-shared key (PPK) to be mixed into the IKEv2 key derivation, adding quantum-resistant entropy to every session even before native PQC algorithms are deployed. This has been available on ASA since version 9.18.
RFC 9242 (Intermediate Exchange in IKEv2) and RFC 9370 (Multiple Key Exchanges in IKEv2) enable hybrid key exchange, where both a classical and a post-quantum key agreement are performed simultaneously. This approach is endorsed by NIST, the NSA, Germany’s BSI, and France’s ANSSI as the recommended transitional strategy — providing protection against both classical and quantum adversaries during the migration period. This has been available on ASA since version 9.19.
Additionally, Cisco has developed the Secure Key Integration Protocol (SKIP), currently in RFC draft status, which enables devices to securely import distributed pre-shared keys from third-party providers / Quantum Key Distributed (QKD) devices. SKIP has seen wide adoption across other part of Cisco’s networking portfolio, and is a proven part of Cisco’s WAN and service provider infrastructure today. Bringing SKIP to Secure Firewall in FTD 10.5 and ASA 9.25 extends that same framework, giving organizations a consistent quantum-safe key management solution for the network.
These capabilities mean that organizations requiring quantum-resistant protections for IPsec can often begin the journey today, and complete the most important pieces with Cisco Secure Firewall’s next software release.
TLS touches the firewall in ways that go well beyond simple web browsing. Each use case has its own PQC considerations:
TLS decryption — the firewall’s ability to inspect encrypted traffic inline — gains PQC support in stages. TLS decryption with PQC algorithms is targeted for FTD 10.5. PQC metadata logging, providing visibility into PQC-negotiated sessions, is planned for FTD 11.0, the same release planned to bring QUIC decryption with PQC support.
Remote Access VPN using TLS or DTLS is planned for ML-KEM and ML-DSA support in ASA/FTD 11.0, pending the outcome of RFC standards currently in draft. DTLS-based RAVPN depends on the availability of DTLSv1.3 in the underlying TLS library (OpenSSL), which does not yet have a confirmed timeline.
Management access and monitoring round out the TLS surface area. PQC support for TLS client features is planned for ASA/FTD 11.0, while management web server PQC support depends on underlying web server library readiness.
Cryptography doesn’t start at the protocol layer — it starts at boot. Aligned with our Secure Products pillar for end-to-end protection, Cisco hardware uses Secure Boot to establish a chain of trust. This ensures only valid and signed software runs on the device. Transitioning Secure Boot to PQC-capable algorithms is essential to protect against supply-chain and firmware-level attacks in a post-quantum world.
All future firewall platforms currently in development will ship with PQC-capable hardware Secure Boot at first customer shipment. Recently released platforms such as the Secure Firewall 1200 and 6100 series have the necessary hardware support and will receive PQC-enabled Secure Boot through future software updates. Platforms released prior to 2025 are being evaluated, but most are expected to lack the hardware prerequisites for PQC Secure Boot.
You don’t need to overhaul your network tomorrow. But you do need to start making deliberate choices now so you’re not left scrambling. Here’s where to start:
Know where your encryption lives. Understand where your firewalls rely on encryption: VPN tunnels, inline decryption, management access, logging, authentication. Each of these has its own path to post-quantum readiness, and you can’t plan a transition if you don’t know what needs transitioning.
Build the upgrade paths into your planning cycles. FTD 10.5 (and ASA 9.25), targeted for late 2026, introduces ML-KEM, allowing VPN tunnels to gain post-quantum resilience. FTD and ASA 11.0 complete the picture in 2027 with ML-DSA and SLH-DSA, along with broader coverage for inline traffic inspection.
If you’re not familiar with these algorithm names, that’s OK. The most important thing is to know that the full suite of coverage is coming soon. Plan your upgrade windows accordingly.
Think about hardware now, not later. If you’re purchasing new firewall platforms, Cisco’s newest hardware will support PQC Secure Boot. If you’re running older platforms and concerned about this feature, start factoring a hardware refresh into your longer-term migration plans.
The quantum threat isn’t theoretical, and the timelines aren’t distant. The standards are published, the algorithms are selected, and the roadmap is in motion. Cisco Secure Firewall is building post-quantum cryptography into every layer of the platform, so that when your organization is ready to make the transition, your firewall is ready too.
Many of the products and features described herein remain in varying stages of development and will be offered on a when-and-if-available basis. The delivery timeline of these products and features is subject to change at the sole discretion of Cisco, and Cisco will have no liability for delay in the delivery or failure to deliver any of the products or features set forth in this document.
We’d love to hear what you think! Ask a question and stay connected with Cisco Security on social media.
Cisco Security Social Media
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。