From 445c02911f160be0384df965ab83455bb9e17500 Mon Sep 17 00:00:00 2001 From: goubach Date: Thu, 6 Aug 2026 16:09:25 +0700 Subject: [PATCH 1/2] 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/2] 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:**