11.4 Quantum Security Risks & Post-Quantum Readiness

11.4 Quantum Security Risks & Post-Quantum Readiness

The Blueprint Requirement

Task 3.5 asks you to "identify and describe quantum security risks (e.g., harvest now, decrypt later attacks) and Palo Alto Networks platform capabilities to address them (e.g., post-quantum readiness, hybrid cryptography)." It sits inside domain 3, the 30% domain. This is not futurology on the NetSec-Pro exam — it is a set of configurable PAN-OS features with version requirements and specific behaviours.

---

Harvest Now, Decrypt Later

A cryptographically relevant quantum computer (CRQC) does not exist yet. The attack does.

In a harvest now, decrypt later (HNDL) campaign, an adversary captures encrypted traffic today — VPN tunnels, TLS sessions, backup replication — and stores it. They cannot read it now. They intend to read it once a CRQC becomes available. Adversaries are stealing encrypted data today specifically in order to decrypt it later, which converts a future capability into a present-day confidentiality risk.

Which Data Is Actually at Risk

Risk is proportional to how long your data must stay secret. The standard way to frame it:

   X = how many years your data must remain confidential
   Y = how many years your migration to post-quantum crypto will take
   Z = how many years until a CRQC exists

   If  X + Y  >  Z   then data you transmit TODAY is already exposed.

Traffic where X is small — a session cookie, a stock quote, a chat message about lunch — carries little HNDL risk. Traffic where X is large is where the exposure concentrates:

What Quantum Computing Actually Breaks

Exam Trap Alert: Quantum computing does not "break encryption." It breaks the asymmetric algorithms used for key exchange and signatures. Symmetric ciphers and hashes are weakened, not defeated, and the mitigation is simply longer keys and digests. Any answer claiming AES-256 must be abandoned is wrong.

---

The Standards

NIST published the first post-quantum standards in 2024, and Palo Alto Networks aligns to them:

PAN-OS also supports pre-standard key-encapsulation mechanisms including HQC, Classic McEliece, BIKE, and Frodo, plus hybrid algorithm concatenation. Hybrid is the important design idea: you combine a classical key exchange with one or more post-quantum KEMs, so the session is secure if either component holds. If a PQC algorithm is later broken by classical cryptanalysis, the classical component still protects you; if a CRQC arrives, the PQC component still protects you.

---

PAN-OS Capabilities

1. RFC 8784 — Post-Quantum Pre-Shared Keys for IPSec

The simplest and most immediately deployable mitigation. A quantum-resistant post-quantum pre-shared key (PPK) is mixed with the classical Diffie-Hellman key material during IKEv2 key derivation. Two properties make it powerful:

• The PPK is configured out of band on both VPN peers and is never transmitted over the network, so an attacker capturing the entire IKE exchange still cannot derive the session keys.
• Because the PPK never crosses the wire, no future quantum capability helps — the attacker never had the ciphertext of the secret to begin with.

This provides immediate quantum resistance for site-to-site VPNs and directly counters HNDL against tunnelled traffic.

2. RFC 9242 and RFC 9370 — Hybrid Key Exchange for IKEv2

The standards-based option, supported on PAN-OS 11.2 or later. RFC 9242 adds the IKEv2 intermediate exchange, and RFC 9370 allows multiple key exchanges so a hybrid key can be derived from a classical exchange plus one or more PQC KEMs.

Configuration facts the exam can test:

• Create an IKE Gateway using IKEv2 only or IKEv2 preferred mode, and enable Post-Quantum Key Exchange in the advanced options.
• Configure the IKE Crypto profile with the classical components first, then add additional key exchange rounds.
• A maximum of seven additional key exchange rounds (Round 1–7) is permitted, for both IKE and IPSec.
• At least one PQC KEM is required for quantum resistance.
• IPSec permits only one PQC KEM per round, whereas IKEv2 permits multiple.
• Both peers must be configured in coordination — this is not something one side can enable unilaterally.

Prisma SD-WAN also supports post-quantum cryptography on its tunnels, extending the same protection to the SD-WAN fabric.

3. PQC Detection and Control in TLS Decryption

This is the capability most likely to appear as a troubleshooting scenario, because it produces a user-visible failure. Supported from PAN-OS 11.1.

The firewall detects post-quantum cryptography in three steps: it inspects the ClientHello's supported_groups TLS extension, compares the hexadecimal values against known PQC algorithms, and then acts based on the decryption disposition.

Because the interesting events are logged against no-decrypt sessions, the documentation recommends enabling Log Successful SSL Handshakes and Log Unsuccessful SSL Handshakes for full visibility. Licensing note: an AIOps for NGFW Premium license is required when the firewall is managed by Strata Cloud Manager; no additional license is needed under PAN-OS or Panorama management.

Exam Trap Alert: There is a genuine architectural tension here. Decryption and post-quantum TLS are in direct conflict: to inspect a session the firewall must be able to negotiate it, so it strips PQC groups. As browsers ship PQC-only configurations, blanket decryption will start dropping sessions. Recognising that a "sites suddenly unreachable after a browser update" scenario is a PQC-versus-decryption interaction — resolved by a targeted no-decrypt rule — is exactly the kind of judgement this domain tests.

4. Quantum Readiness in Strata Cloud Manager

Palo Alto Networks provides a Quantum Readiness view in Strata Cloud Manager, together with a cryptographic inventory insights dashboard. These let an organisation inventory and assess cryptography usage as secure, weak, or vulnerable, validate compliance against government standards, and remediate through inline workflows. This is the "post-quantum readiness" half of blueprint task 3.5 — you cannot migrate what you have not inventoried.

5. PAN-OS 12.1 Orion

PAN-OS 12.1 Orion delivers quantum-safe site-to-site VPN tunnels and SSL/TLS sessions to protect against harvest-now-decrypt-later attacks, and adds post-quantum TLS protection for administrative access to next-generation firewalls and Panorama.

---

A Migration Sequence

1. INVENTORY  -> SCM Quantum Readiness / cryptographic inventory:
                 classify every use as secure, weak, or vulnerable
2. TRIAGE     -> rank by secrecy lifetime (X), not by traffic volume
3. QUICK WIN  -> deploy RFC 8784 PPKs on site-to-site VPNs carrying long-lived
                 secrets; no peer software dependency beyond PAN-OS support
4. HYBRID     -> move those tunnels to RFC 9242/9370 hybrid key exchange on
                 PAN-OS 11.2+, coordinating both peers
5. HARDEN     -> AES-256 and SHA-384 or stronger everywhere symmetric
6. PREPARE    -> review decryption policy for PQC-only clients before they arrive;
                 plan targeted no-decrypt rules rather than emergency ones
7. AUTOMATE   -> certificate lifecycle automation (section 11.3) so algorithm
                 changes can actually be executed at estate scale

Steps 6 and 7 are the ones organisations skip and then regret. The decryption interaction produces outages on somebody else's release schedule, and an estate that cannot re-issue certificates on demand cannot change algorithms no matter how good its inventory is.