From 445c02911f160be0384df965ab83455bb9e17500 Mon Sep 17 00:00:00 2001 From: goubach Date: Thu, 6 Aug 2026 16:09:25 +0700 Subject: [PATCH 1/5] QS05: add governance, ownership and measurability controls. Addresses #35 What changes - Description: frames crypto-agility as a governed, owned and measurable capability. - How to Prevent: adds two controls (ownership and governing policy; agility measurability), with a one-line pointer to the inventory in QS04. - Example Attack Scenarios: adds Scenario #3, a governance failure where agility cannot be exercised in time. What does not change - No edits to Reference Links or the Standards and Regulatory - Mapping section (open TODO for the leads). - No overlap introduced with QS04 (inventory) or QS06 (hybrid). --- quantum-top-10/QS05_Crypto-Agility-Failures.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index 5e94827..41a4821 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -2,7 +2,9 @@ **Description:** -Cryptographic agility is the engineering property that allows an algorithm, key size, or parameter set to be replaced without rebuilding the system around it. Most production systems hard-code cryptographic algorithms, key sizes, parameter sets, and key formats deep in code, configuration, hardware, and protocols. Systems that lack agility - algorithms baked into source, protocol logic, custom data formats, or non-updatable firmware - require replacement, not migration. As ML-KEM, ML-DSA, and SLH-DSA move into production and parameter sets continue to evolve through subsequent NIST rounds (Falcon, HQC, others), organisations without negotiable algorithms, abstracted crypto APIs, version-aware protocols, and dynamic policy will be unable to respond to standards updates, broken parameter sets, or future migrations. Crypto-agility is itself a security control. Symmetric primitives are more quantum-resilient, but "quantum is only a public-key problem" must not be read as "symmetric needs no work": AES key sizes, hash strengths, MAC lengths, and KDFs all need review end-to-end. +Cryptographic agility is the engineering property that allows an algorithm, key size, or parameter set to be replaced without rebuilding the system around it. Most production systems hard-code cryptographic algorithms, key sizes, parameter sets, and key formats deep in code, configuration, hardware, and protocols. Systems that lack agility - algorithms baked into source, protocol logic, custom data formats, or non-updatable firmware - require replacement, not migration. As ML-KEM, ML-DSA, and SLH-DSA move into production and parameter sets continue to evolve through subsequent NIST rounds (Falcon, HQC, others), organisations without negotiable algorithms, abstracted crypto APIs, version-aware protocols, and dynamic policy will be unable to respond to standards updates, broken parameter sets, or future migrations. Crypto-agility is itself a security control. Like any other control, it must have named owner, governed by policy, and measurable: a system can be technically agile but operationally unable to exercise that agility if no one is held accountable for authorising, driving, verifying and validating cryptographic changes. + +Symmetric primitives are more quantum-resilient, but "quantum is only a public-key problem" must not be read as "symmetric needs no work": AES key sizes, hash strengths, MAC lengths, and KDFs all need review end-to-end. **Common Examples of Vulnerability:** @@ -20,6 +22,8 @@ Cryptographic agility is the engineering property that allows an algorithm, key 4. Test the rotation path end-to-end in non-production, including embedded and mobile clients, to surface agility blockers before migration. 5. Include agility requirements in procurement: new contracts should require PQC support and demonstrable algorithm replacement on a defined timescale. 6. Track IETF PQUIP and TLS working-group output for documented migration patterns and failure modes. +7. Assign accountable owner and develop governing policy for cryptographic change, identify who will authorise it and maintain a tested runbook for time-pressure events. +8. Make agility measurable and inventory-driven: track time-to-rotate, share systems behind the abstraction layer, and share protocols that negotiate rather than pin, since we can only utilise agile what the inventory (QS04) reveals. **Example Attack Scenarios:** @@ -27,6 +31,8 @@ Scenario #1: A NIST parameter set for a deployed PQC algorithm is later found we Scenario #2: A team adds a crypto abstraction layer but never tests rotation. When migration day arrives, an embedded client that pins a classical algorithm identifier silently fails PQC negotiation and continues on classical crypto, and the untested "agility" turns out to be theoretical - the attacker targets the client that never actually migrated. +Scenario #3: An organisation that is technically agile, with crypto abstraction layer and negotiable protocols. When a deployed parameter set is deprecated, there is no named owner, no policy on who must approve the change, and no tested runbook. Ownership is disputed between platform, security, operation and application teams, the change stalls, and the deprecated parameter set stays in production past a regulatory deadline while an adversary harvesting the affected traffic benefits from every week of the delay. The agility exists on paper but could not be exercised, yielding the exposure a governance problem rather than a technical concern. + **Reference Links:** From 33315659b99531da6cb72a3cde4d8aecc0b67ac0 Mon Sep 17 00:00:00 2001 From: Goutama Bachtiar Date: Sat, 8 Aug 2026 16:07:48 +0700 Subject: [PATCH 2/5] Update QS05_Crypto-Agility-Failures.md Revising the wording based on nmcitra's feedback --- quantum-top-10/QS05_Crypto-Agility-Failures.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index 41a4821..f3d7e6c 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -2,7 +2,7 @@ **Description:** -Cryptographic agility is the engineering property that allows an algorithm, key size, or parameter set to be replaced without rebuilding the system around it. Most production systems hard-code cryptographic algorithms, key sizes, parameter sets, and key formats deep in code, configuration, hardware, and protocols. Systems that lack agility - algorithms baked into source, protocol logic, custom data formats, or non-updatable firmware - require replacement, not migration. As ML-KEM, ML-DSA, and SLH-DSA move into production and parameter sets continue to evolve through subsequent NIST rounds (Falcon, HQC, others), organisations without negotiable algorithms, abstracted crypto APIs, version-aware protocols, and dynamic policy will be unable to respond to standards updates, broken parameter sets, or future migrations. Crypto-agility is itself a security control. Like any other control, it must have named owner, governed by policy, and measurable: a system can be technically agile but operationally unable to exercise that agility if no one is held accountable for authorising, driving, verifying and validating cryptographic changes. +Cryptographic agility is the engineering property that allows an algorithm, key size, or parameter set to be replaced without rebuilding the system around it. Most production systems hard-code cryptographic algorithms, key sizes, parameter sets, and key formats deep in code, configuration, hardware, and protocols. Systems that lack agility - algorithms baked into source, protocol logic, custom data formats, or non-updatable firmware - require replacement, not migration. As ML-KEM, ML-DSA, and SLH-DSA move into production and parameter sets continue to evolve through subsequent NIST rounds (Falcon, HQC, others), organisations without negotiable algorithms, abstracted crypto APIs, version-aware protocols, and dynamic policy will be unable to respond to standards updates, broken parameter sets, or future migrations. Crypto-agility is itself a security control. Like any other control, it must have a named owner, a governing policy, and a measurable definition of agility: a system can be technically agile but operationally unable to exercise that agility if no one is held accountable for authorising, driving, verifying and validating cryptographic changes. Symmetric primitives are more quantum-resilient, but "quantum is only a public-key problem" must not be read as "symmetric needs no work": AES key sizes, hash strengths, MAC lengths, and KDFs all need review end-to-end. @@ -23,7 +23,7 @@ Symmetric primitives are more quantum-resilient, but "quantum is only a public-k 5. Include agility requirements in procurement: new contracts should require PQC support and demonstrable algorithm replacement on a defined timescale. 6. Track IETF PQUIP and TLS working-group output for documented migration patterns and failure modes. 7. Assign accountable owner and develop governing policy for cryptographic change, identify who will authorise it and maintain a tested runbook for time-pressure events. -8. Make agility measurable and inventory-driven: track time-to-rotate, share systems behind the abstraction layer, and share protocols that negotiate rather than pin, since we can only utilise agile what the inventory (QS04) reveals. +8. Make agility measurable and inventory-driven: track time-to-rotate, share of systems behind the abstraction layer, and share of protocols that negotiate rather than pin, since agility can only be exercised over what the inventory (QS04) reveals. **Example Attack Scenarios:** @@ -31,7 +31,7 @@ Scenario #1: A NIST parameter set for a deployed PQC algorithm is later found we Scenario #2: A team adds a crypto abstraction layer but never tests rotation. When migration day arrives, an embedded client that pins a classical algorithm identifier silently fails PQC negotiation and continues on classical crypto, and the untested "agility" turns out to be theoretical - the attacker targets the client that never actually migrated. -Scenario #3: An organisation that is technically agile, with crypto abstraction layer and negotiable protocols. When a deployed parameter set is deprecated, there is no named owner, no policy on who must approve the change, and no tested runbook. Ownership is disputed between platform, security, operation and application teams, the change stalls, and the deprecated parameter set stays in production past a regulatory deadline while an adversary harvesting the affected traffic benefits from every week of the delay. The agility exists on paper but could not be exercised, yielding the exposure a governance problem rather than a technical concern. +Scenario #3: An organisation that is technically agile, with crypto abstraction layer and negotiable protocols. When a deployed parameter set is deprecated, there is no named owner, no policy on who must approve the change, and no tested runbook. Ownership is disputed between platform, security, operation and application teams, the change stalls, and the deprecated parameter set stays in production past a regulatory deadline while an adversary harvesting the affected traffic benefits from every week of the delay. The agility exists on paper but could not be exercised, leaving the exposure as a governance problem rather than a technical one. **Reference Links:** From e59ea822dbdeacc408e953bfbeaa4710ac24a757 Mon Sep 17 00:00:00 2001 From: Goutama Bachtiar Date: Sat, 22 Aug 2026 21:17:36 +0700 Subject: [PATCH 3/5] QS05: Scenario 3 names the trigger-detection gap --- quantum-top-10/QS05_Crypto-Agility-Failures.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index f3d7e6c..11f0aa6 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -31,7 +31,7 @@ Scenario #1: A NIST parameter set for a deployed PQC algorithm is later found we Scenario #2: A team adds a crypto abstraction layer but never tests rotation. When migration day arrives, an embedded client that pins a classical algorithm identifier silently fails PQC negotiation and continues on classical crypto, and the untested "agility" turns out to be theoretical - the attacker targets the client that never actually migrated. -Scenario #3: An organisation that is technically agile, with crypto abstraction layer and negotiable protocols. When a deployed parameter set is deprecated, there is no named owner, no policy on who must approve the change, and no tested runbook. Ownership is disputed between platform, security, operation and application teams, the change stalls, and the deprecated parameter set stays in production past a regulatory deadline while an adversary harvesting the affected traffic benefits from every week of the delay. The agility exists on paper but could not be exercised, leaving the exposure as a governance problem rather than a technical one. +Scenario #3: An organisation has an abstraction layer, negotiable protocols, and a documented rotation runbook. Therefore, technically it is agile. No accountable owner is assigned to watch the triggers, so a broken parameter set, a CNSA 2.0 milestone, and a binding regulatory deadline all pass unobserved, and the runbook is not opened until an audit forces the question. The exposure undetected triggers, rather than slow execution. By then, the organisation is in breach with a rotation it has never timed against the deadline. **Reference Links:** From 5ac0c5b94e49ef37bf5f1cb4db4083f6ebb9527b Mon Sep 17 00:00:00 2001 From: Goutama Bachtiar Date: Mon, 24 Aug 2026 17:15:16 +0700 Subject: [PATCH 4/5] QS05: Adding NIST CSWP 39upd1 as crypto-agility anchor --- quantum-top-10/QS05_Crypto-Agility-Failures.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index 11f0aa6..beafe4d 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -42,10 +42,13 @@ Scenario #3: An organisation has an abstraction layer, negotiable protocols, and 3. [EU Coordinated Implementation Roadmap for PQC](https://digital-strategy.ec.europa.eu/en/library/coordinated-implementation-roadmap-transition-post-quantum-cryptography): Explicit agility expectation. 4. [IETF PQUIP Working Group](https://datatracker.ietf.org/wg/pquip/about/): Agility documents and migration patterns. 5. [IETF - Hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)](https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/): Hybrid KEM negotiation. +6. [NIST CSWP 39upd1 - Considerations for Achieving Crypto Agility](https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final): Ownership and measurable agility. **Standards and Regulatory Mapping:** > **TODO:** This section is carried over from the source document and is not part of `_template.md`. Confirm whether to keep it in the final entry format, and verify each standard/citation. +NIST CSWP 39upd1, Considerations for Achieving Crypto Agility: Strategies and Practices (Final, 29 June 2026, superseding CSWP 39 of 19 December 2025), is the authoritative crypto-agility anchor and directly addresses ownership and measurable agility. Companion anchors: NIST IR 8547 for migration-timeline framing, NSA CNSA 2.0 for dated deadlines, and NIST SP 1800-38 for practice detail. Offered subject to the leads' URL verification process. + CISA, NSA, NIST Quantum-Readiness fact sheet (cryptographic agility recommendation). NCSC guidance on crypto-agility. EU Coordinated Implementation Roadmap explicit agility expectation. NIS2 Article 21(2)(h) implies agility through state-of-the-art and risk-based requirements. IETF PQUIP working group agility documents; IETF TLS working group on hybrid KEM and signature negotiation. From 2bc6b7069afdf8f768e273e34ca3c339ddce1cd0 Mon Sep 17 00:00:00 2001 From: Goutama Bachtiar Date: Mon, 24 Aug 2026 18:02:44 +0700 Subject: [PATCH 5/5] QS05: tighten measurability control and fix Scenario 3 wording --- quantum-top-10/QS05_Crypto-Agility-Failures.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/quantum-top-10/QS05_Crypto-Agility-Failures.md b/quantum-top-10/QS05_Crypto-Agility-Failures.md index beafe4d..103198c 100644 --- a/quantum-top-10/QS05_Crypto-Agility-Failures.md +++ b/quantum-top-10/QS05_Crypto-Agility-Failures.md @@ -23,7 +23,7 @@ Symmetric primitives are more quantum-resilient, but "quantum is only a public-k 5. Include agility requirements in procurement: new contracts should require PQC support and demonstrable algorithm replacement on a defined timescale. 6. Track IETF PQUIP and TLS working-group output for documented migration patterns and failure modes. 7. Assign accountable owner and develop governing policy for cryptographic change, identify who will authorise it and maintain a tested runbook for time-pressure events. -8. Make agility measurable and inventory-driven: track time-to-rotate, share of systems behind the abstraction layer, and share of protocols that negotiate rather than pin, since agility can only be exercised over what the inventory (QS04) reveals. +8. Make agility measurable and inventory-bounded: track cryptographic time-to-rotate (cMTTR) as the primary metric, capped by the share of the estate visible in the CBOM (QS04), with abstraction-layer coverage and negotiation posture reported wherever useful. **Example Attack Scenarios:** @@ -31,7 +31,7 @@ Scenario #1: A NIST parameter set for a deployed PQC algorithm is later found we Scenario #2: A team adds a crypto abstraction layer but never tests rotation. When migration day arrives, an embedded client that pins a classical algorithm identifier silently fails PQC negotiation and continues on classical crypto, and the untested "agility" turns out to be theoretical - the attacker targets the client that never actually migrated. -Scenario #3: An organisation has an abstraction layer, negotiable protocols, and a documented rotation runbook. Therefore, technically it is agile. No accountable owner is assigned to watch the triggers, so a broken parameter set, a CNSA 2.0 milestone, and a binding regulatory deadline all pass unobserved, and the runbook is not opened until an audit forces the question. The exposure undetected triggers, rather than slow execution. By then, the organisation is in breach with a rotation it has never timed against the deadline. +Scenario #3: An organisation has an abstraction layer, negotiable protocols, and a documented rotation runbook. Therefore, technically it is agile. No accountable owner is assigned to watch the triggers, so a broken parameter set, a CNSA 2.0 milestone, and a binding regulatory deadline all pass unobserved, and the runbook is not opened until an audit forces the question. The exposure is undetected triggers rather than slow execution. By then, the organisation is in breach with a rotation it has never timed against the deadline. **Reference Links:**