💻 computer science

Three Axes of Quantum Risk: A Unified Observability Model for PQC, QKD, and Crypto-Agility

This paper introduces a unified three-axis observability model for quantum risk that evaluates assets based on algorithmic resistance, channel protection, and crypto-agility, supported by an open-source implementation (Sezar) and empirical validation across TLS, QKD, and agility scenarios to address the limitations of current single-axis discovery tools.

Original authors: Aleaddin Ozer, Murat Aydos

Published 2026-07-07

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Aleaddin Ozer, Murat Aydos

Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are the captain of a massive fleet of ships (your company's digital assets) sailing toward a stormy horizon. The storm is a "Quantum Computer" that, once it arrives, will be able to break almost all the locks on your ships' cargo.

For a long time, security experts asked a simple question: "Is your lock made of the new, storm-proof metal?" (This is checking if you use Post-Quantum Cryptography, or PQC).

But the authors of this paper, Aleaddin Ozer and Murat Aydos, argue that this question is too simple. They say that just having a new lock isn't enough. You need to look at three different things to know if you are truly safe. They call this the "Three Axes of Quantum Risk."

Here is the breakdown using everyday analogies:

The Three Axes of Risk

1. Axis A: The Lock Itself (Algorithmic Resistance)

The Analogy: Is your door made of wood or steel?
The Paper's Point: This checks the actual math behind your encryption. Is it the old, weak wood (like RSA) that a quantum computer can easily smash? Or is it the new, super-strong steel (NIST's new standards like ML-KEM)?
The Catch: Even if you have the best steel lock, it doesn't matter if the door is left wide open.

2. Axis C: The Delivery Truck (Channel Protection)

The Analogy: How did the key get to the lock?
The Paper's Point: Sometimes, even if you have a strong lock, the key used to open it was delivered by a risky method.
- Classical Delivery: The key was sent over a regular, public road where anyone could steal it.
- QKD Delivery (Quantum Key Distribution): The key was sent via a "magic teleporter" (using physics) that makes it impossible to steal without being noticed.
The Insight: Two ships might have the exact same steel lock (Axis A), but one has its keys delivered by a secure teleporter (Axis C = High), while the other has keys delivered by a thief on a bicycle (Axis C = Low). They are in very different danger zones.

3. Axis G: The Speed of Change (Crypto-Agility)

The Analogy: If the storm gets worse tomorrow, how fast can you swap your lock?
The Paper's Point: This measures how easy it is to upgrade your security.
- Agile: You can change the lock by flipping a switch or editing a config file (like changing a setting on your phone).
- Frozen: The lock is welded into the ship's hull. To change it, you have to cut the ship apart and replace the whole engine (hardware replacement).
The Insight: If you have a weak lock, but you can swap it for a strong one in 5 minutes, you are safer than someone with a strong lock that is welded in place, because you can fix your problems before the storm hits.

The "Deadline" Factor

The paper introduces a score called q(asset, t). Think of this as a "Danger Meter" that changes based on time.

Today: If you have a weak lock but can change it instantly (High Agility), your danger meter is low. You have time to fix it.
The Deadline (e.g., 2030): As the storm gets closer, your "ability to change" matters less. If the deadline is tomorrow, it doesn't matter if you could change the lock in 5 minutes; you won't have time. The danger meter spikes.

The Tool: "Sezar"

To measure all three of these things at once, the authors built a tool called Sezar.

The Detective: Sezar is like a fleet inspector that walks around your ships.
The Three Scanners:
1. It looks at the Lock (scanning your software to see what math it uses).
2. It checks the Truck (connecting to your Quantum Key Distribution systems to see if keys are being delivered securely).
3. It tests the Switch (scanning your code to see if you can change settings easily or if you are stuck).
The Dashboard: It gives you a single score for every ship, telling you which ones need immediate attention.

What They Actually Found (The Results)

The authors didn't just build the theory; they tested it in three real-world experiments:

The Web Scan: They scanned the top 1,000 websites on the internet. They found that while about 44% of them could use the new "steel locks" (PQC), the scan couldn't tell you if those sites were using the "magic teleporter" (QKD) or if they could change their locks quickly. This proved that looking at just one thing (the lock) gives you an incomplete picture.
The Simulation: They built a fake Quantum Key Distribution system (a simulator) to test how their tool handles broken connections. They found that Sezar could correctly tell the difference between a "bad connection" and a "total failure," even when different parts of the system were acting differently.
The Code Check: They tested their "Speed of Change" scanner against 11 popular open-source software projects. It correctly identified whether the software was easy to update or "frozen" in 91% of the cases.

The Bottom Line

The paper argues that we need to stop asking, "Is your crypto quantum-safe?" and start asking, "What is your Lock, how is your Key Delivered, and how Fast can you change it?"

By looking at all three axes together, operators can prioritize their work better. They can fix the ships that are both weak and hard to fix, rather than wasting time on ships that are weak but easy to repair, or ships that are strong but have no keys.

Note: The paper does not claim this tool fixes the quantum threat itself, nor does it claim to solve all cybersecurity problems. It simply provides a better way to measure and prioritize the risk so humans can make better decisions.

Technical Summary: Three Axes of Quantum Risk

1. Problem Statement

The post-quantum migration has transitioned from research to operational necessity, driven by NIST's finalization of FIPS 203/204/205 and the NSA's CNSA 2.0 deadlines (2025–2033). However, current cryptographic observability tools suffer from a critical limitation: they answer a single question for each asset—"Is its primitive post-quantum (PQ) resistant?"

This single-axis approach fails to capture the full quantum-risk posture because:

Channel Protection is Ignored: Two assets with identical algorithms (e.g., ECDSA-P256) have vastly different risk profiles if one operates over an unprotected link and the other over a Quantum Key Distribution (QKD) link.
Crypto-Agility is Invisible: An asset using a classical algorithm that can be changed via configuration is in a different risk state than one where the algorithm is hard-coded into firmware. Current tools do not surface "migration agility" as a first-class telemetry metric.
Lack of Unified Modeling: PQC and QKD are often treated as mutually exclusive alternatives in literature, whereas operators need a unified model to assess environments where hybrid deployments are the reality.

Consequently, operators cannot accurately answer "Can we become PQ-ready in time?" because they lack a unified view of algorithmic resistance, channel security, and migration speed.

2. Methodology

The authors propose a Three-Axis Quantum-Risk Posture Model that treats risk as a multi-dimensional observation problem. Each asset is graded on three independent axes, which are then collapsed into a single, deadline-adjusted score, $q(asset, t)$.

The Three Axes

Axis A (Algorithmic Resistance): Scores the cryptographic primitives on a scale of [0, 1].
- 1.0: PQ-resistant (e.g., ML-KEM, ML-DSA).
- 0.9: PQ-hybrid (e.g., X25519 + ML-KEM).
- 0.3: Classical (e.g., RSA-2048, ECDSA).
- 0.0: Deprecated/Broken (e.g., SHA-1, RC4).
- Scores are weighted by role (signature, key exchange, encryption, hash).
Axis C (Channel Protection): Scores the key delivery mechanism on a scale of [0, 1].
- 1.0: QKD-only.
- 0.7: QKD-Hybrid PSK (QKD-derived keys used in hybrid modes).
- 0.0: Classical only.
- This axis accounts for link degradation (e.g., high Quantum Bit Error Rate) by discounting the score proportionally.
Axis G (Migration Agility): Scores the ability to change primitives on a scale of [0, 1].
- 1.0 (Negotiated): Algorithm selected per session (e.g., TLS 1.3).
- 0.75 (Configurable): Changeable via config file.
- 0.50 (Pinned): Hard-coded in source, changeable via software upgrade.
- 0.20 (Locked): Fixed in firmware or FIPS-validated modules.
- 0.0 (Frozen): Fixed in silicon/ROM.

The Unified Score

The model calculates a deadline-adjusted risk score $q(asset, t)$:
$q(asset, t) = 1 - (\alpha \cdot A + \beta \cdot C + \gamma(\tau) \cdot G)$
Where $\tau$ represents "deadline tension" (how close the current date $t$ is to the operator's deadline $D$ ). As the deadline approaches, the weight $\gamma$ assigned to agility shrinks, reflecting that high agility is less forgiving when time is short. A BLOCKED flag is raised for assets with low agility that cannot be migrated in time, regardless of their current score.

Implementation: Sezar

The authors implemented Sezar, an open-source observability platform in Rust, to operationalize this model. Key components include:

Schema Extension: Extended the crypto_inventory_event v1 schema to include channel_protection and agility fields.
Five Agents:
1. sezar-net: eBPF-based TLS/SSH/IPsec observation.
2. sezar-qkd: ETSI GS QKD 014 collector and a synthetic KME emulator for testing.
3. sezar-agility: Static scanner using Semgrep rules to analyze source code and binaries for agility levels.
4. sezar-cert: X.509 inventory via CT logs and host scans.
5. sezar-chain: Public blockchain observation.
Rollup Engine: A pure function that ingests events and computes the unified score based on operator-configured weights and deadlines.

3. Key Contributions

The Three-Axis Model: A formal framework separating algorithmic resistance, channel protection, and migration agility, acknowledging that PQC and QKD are complementary observables.
Schema Extension: A strictly additive update to the crypto_inventory_event schema (v1.1) enabling interoperable telemetry for QKD and agility.
Sezar Reference Implementation: A complete, open-source stack (agents, collector, dashboard) that unifies eBPF network observation, REST-based QKD telemetry, and static code analysis.
QKD Emulator: An open ETSI GS QKD 014 Key Management Entity (KME) emulator allowing practitioners to test QKD-aware software without physical hardware.
Agility Rubric & Corpus: A five-level ordinal scoring system operationalized via a Semgrep rule pack, validated against a hand-graded ground-truth corpus of 50 open-source server projects.

4. Empirical Results

The paper validates the model through three reproducible studies:

Study 1 (Axis A - Tranco Top-1k):
- Scanned 724 responsive hosts from the Tranco top-1k.
- Result: 43.8% of hosts negotiated a hybrid PQ key exchange (X25519MLKEM768) when offered. However, 16.9% still negotiated TLS 1.2 (structurally PQ-ineligible), and the certificate signature distribution remained RSA-dominant (64.9%).
- Insight: Single-axis scans miss the structural constraints (TLS version) and the lack of certificate agility.
Study 2 (Axis C - QKD Emulator):
- Tested the system against 13 induced state transitions across five failure scenarios (steady-state, degradation, hard failure, stale PSK, bifurcated SAE).
- Result: 13/13 state changes were correctly classified. The system correctly distinguished between link-level failures and per-session attribution issues (e.g., one SAE failing while another succeeds).
- Insight: Link-level telemetry alone is insufficient; per-session attribution is required to accurately score channel protection.
Study 3 (Axis G - Agility Pilot):
- Compared the sezar-agility scanner against hand-graded ground truth for an 11-project subset of the 50-project corpus.
- Result: 91% agreement (10/11 projects). The single disagreement involved chrony, where static evidence was ambiguous between "configurable" and "pinned."
- Insight: Static analysis can achieve substantial agreement with human grading, though Go-ecosystem coverage gaps (initially missing crypto/tls patterns) required rule updates.

5. Significance and Claims

The paper claims that the "single-bit" PQ-readiness metric is insufficient for operators facing 2030–2033 deadlines. The significance of this work lies in:

Holistic Risk Assessment: It demonstrates that an asset's risk is not just about the algorithm it uses, but also how the keys are delivered and how fast the algorithm can be swapped.
Operational Feasibility: It proves that a unified observability model covering PQC, QKD, and agility can be built using commodity hardware and open-source tools, without requiring proprietary commercial stacks.
Actionable Prioritization: By collapsing three axes into a deadline-adjusted score, the model allows operators to prioritize migration efforts based on a realistic "time-to-fix" rather than just "current vulnerability."
Reproducibility: The authors provide the full schema, emulator, rule sets, and ground-truth corpus, inviting the community to verify, critique, and refine the scoring constants and weights rather than accepting them as absolute truths.

The authors explicitly state that the model does not solve the economic or political constraints of migration but provides the necessary telemetry layer to make those decisions informed. The contribution is the model and the tooling, not the specific numerical scores, which are intended to be operator-configurable.