QS05 Crypto-Agility Failures: Adding Governance and Control Ownership, Plus Governance-Failure Scenario

[goubach]

Summary
QS05 mainly perceives crypto-agility as engineering disciplines and properties, as shown by the abstraction layers, negotiable protocols, and parameter selection. In an enterprise context, specifically organisational capability and capacity, this entry is missing the governance and control ownership that will determine whether agility can be exercised under certain time pressure. I am therefore keen to propose a small, in-template input.

The gaps I observe
How to Prevent has no ownership or accountability control. On the other hand, entries QS04 (Absent Cryptographic Inventory and CBOM) explicitly assign named owners per asset class. QS05 has no equivalent, so an organisation can be technically agile yet operationally unable to drive, verify, and validate the change.

No measurable definition of agility: let's take time-to-rotate, share of systems behind an abstraction layer, share of protocols, for instance, that negotiate rather than pin, which makes the control kind of tricky to be given reasonable assurance against NIS2 Article 21(2)(h) state-of-the-art expectations.

Both example scenarios are technical failures. None covers the circumstance where the technology is agile, but the governance is rigid.

The change I'm proposing (in-template, no change to verified references needed)

• Description: one phrase or sentence clarifying and, more importantly, emphasising that agility is a governed, owned and measurable capability, not only an engineering attribute.
• How to Prevent: add an ownership-and-policy control and a measurability control.
• Example Attack Scenarios: add Scenario Add OWASP Top 10 for Quantum Security entries (QS01-QS10) #3 where agility exists on paper but stalls for the absence of ownership and a tested runbook, and the delay past a deadline becomes the main exposure.

Scope and boundaries

• Staying clear of QS04 by pointing to the inventory as a driver only, not redefining it
• Staying clear of QS06 by adding no hybrid or KDF content

Open question for maintainers
The Standards and Regulatory Mapping section in QS05 still carries a TODO noting it is not part of _template.md. Meanwhile, this proposal does not talk about it, and I am happy to align to whatever the leads decide. Would a NIST crypto-agility publication be a welcome additional anchor, subject to your URL verification process?

P.S. I'd like to express my interest in serving as Entry Lead for QS05.