A cryptographic inventory tells you where RSA and elliptic curve keys are used, but not how hard each system will be to change, and that difficulty is what decides the cost and order of a post-quantum migration. This template gives a repeatable way to score individual systems on how easily their algorithms, keys and certificates can be replaced, and to combine that score with exposure to rank migration work. NIST defines crypto agility in CSWP 39upd1 as the capabilities needed to replace and adapt cryptographic algorithms across protocols, applications, software, hardware, firmware and infrastructure while preserving security and ongoing operations; this template turns that definition into ten scored criteria. The scoring scale and weights are NHI Mgmt Group's own, not a NIST method. It is written for cryptography leads, architects and system owners running a post-quantum readiness programme.
How to use this template
- Assess one system per sheet. A "system" is something with one owner and one change process: an application, a platform service, a device family or a supplier product.
- Start from the system's entries in your cryptographic inventory (see the Cryptographic Inventory and CBOM Guide). This template does not replace discovery; it scores what discovery found.
- Score each criterion in section 5 from 0 to 3 using the anchors, and record the evidence. Where evidence is missing, score 0: an unknown is treated as hard to change.
- Score exposure in section 6, then use section 7 to place the system in a priority band.
- For the organisation-wide view, use the Post-Quantum Readiness Maturity Model. For design patterns that raise a score, see the Crypto-Agility Guide.
1. Purpose
This assessment measures how readily each [Organisation] system can change cryptographic algorithms, key sizes, certificates and libraries without redesign or outage, and ranks systems for migration to post-quantum cryptography and for future algorithm changes. It supports NIST SP 800-53 SC-12 (cryptographic key establishment and management), SC-13 (cryptographic protection) and CM-8 (system component inventory), and NIST CSF 2.0 ID.AM-02 and ID.RA-04.
2. Scope
- Systems in [In-scope estate] that use public-key cryptography for key establishment, signatures or authentication, starting with those that protect data with a long confidentiality lifetime.
- Machine identities: TLS and mTLS certificates, SSH keys, code-signing keys, token-signing keys for SSO and workload identity, and hardware roots of trust.
- Supplier products and managed services, assessed from supplier evidence.
- Symmetric-only uses are recorded but scored only on criteria 1, 2 and 10 unless key sizes or modes need to change.
3. Roles
| Role | Responsibility |
|---|---|
| [Cryptography lead] | Owns the method, calibrates scores across assessors, approves priority bands. |
| System owner | Provides evidence and agrees the score; owns the remediation plan. |
| [Architecture] | Scores criteria 2, 3 and 4 for in-house systems. |
| [Procurement and supplier management] | Collects supplier evidence for criterion 8. |
4. System record
| Field | Entry |
|---|---|
| System name and ID | [ ] |
| Owner and assessor | [ ] |
| Cryptographic uses | [TLS server, mTLS client, data-at-rest encryption, code signing, token signing, VPN, SSH, firmware verification] |
| Algorithms and key sizes in use | [RSA-2048, ECDSA P-256, ECDH, AES-256-GCM] |
| Libraries, modules and hardware | [library and version, HSM or KMS, secure element] |
| Data protected and confidentiality lifetime | [data type, years it must stay confidential] |
| Assessment date and evidence location | [ ] |
5. Agility criteria and scoring anchors
Score 0 (brittle) to 3 (agile). The anchors describe what each score looks like.
| # | Criterion | 0 | 1 | 2 | 3 |
|---|---|---|---|---|---|
| 1 | Visibility | Cryptographic use unknown | Known from documentation only | Discovered by scanning or code analysis | Recorded in a maintained inventory or CBOM, updated on change |
| 2 | Configurability | Algorithm and key size hard-coded in source or firmware | Changeable by code change and full release | Set in configuration per deployment | Set by central policy and applied without redeploying the system |
| 3 | Abstraction | Custom or embedded cryptographic code | Direct calls to one library's algorithm-specific functions | Maintained library with algorithm-neutral interfaces | Provider model or service (KMS, HSM, platform library) where new algorithms arrive by upgrade |
| 4 | Negotiation and downgrade protection | Single fixed algorithm, no negotiation | Negotiates, but cannot add new groups or signature types | Supports adding new and hybrid options | Supports new options and enforces a minimum, so peers cannot force an old algorithm |
| 5 | Key and certificate lifecycle | Manual, long-lived keys and certificates | Manual renewal with tracking | Automated renewal, fixed key type | Automated issuance and renewal that can change key type and issuing CA |
| 6 | Data and message format | Stored data or messages carry no algorithm identifier | Algorithm implied by version | Algorithm and key identifiers in headers | Identifiers present and re-wrap or re-sign possible without bulk re-processing |
| 7 | Hardware and performance headroom | Fixed-function hardware or tight limits on key, signature or packet size | Upgrade needs hardware replacement | Firmware update path exists | Headroom tested for larger post-quantum keys and signatures |
| 8 | Supplier control | Supplier unknown or product end of life | No published cryptographic roadmap | Roadmap published, no dates | Dated roadmap, contract commitment and cryptographic component list |
| 9 | Test and rollback | No test environment | Manual testing only | Automated tests cover cryptographic paths | Algorithm change can be trialled in a ring and rolled back by configuration |
| 10 | Ownership and change process | No owner | Owner without budget or change window | Owner and change window | Owner, funded plan and tested change procedure for cryptographic updates |
Agility score: sum of the ten criteria, 0 to 30. Weighting is optional; if you weight, NHI Mgmt Group suggests doubling criteria 2, 5 and 8 (ours), because hard-coded algorithms, manual certificate handling and supplier dependence are the most common blockers in practice. Record the weighting so scores stay comparable across assessments.
6. Exposure factors
Exposure answers "how much does it matter if this system is slow to change?" Score each 1 (low) to 3 (high).
| Factor | 1 | 2 | 3 |
|---|---|---|---|
| A. Confidentiality lifetime of data protected | Under [2 years] | [2 to 10 years] | Over [10 years] (exposed to "harvest now, decrypt later") |
| B. Quantum-vulnerable public-key use | Symmetric only | Public-key use internal only | Public-key key establishment or signatures on external interfaces |
| C. Trust role | Leaf system | Issues or verifies tokens or certificates for others | Root of trust: CA, firmware signing, identity provider signing keys |
| D. Service lifetime | Retiring within [3 years] | [3 to 10 years] | Over [10 years] or embedded in long-lived devices |
Exposure score: sum of A to D, 4 to 12.
7. Priority bands
| Band | Rule (ours) | Action |
|---|---|---|
| P1 | Exposure 10 to 12, or any factor C scored 3, with agility 15 or below | Plan migration or replacement now; fund agility fixes as part of it. |
| P2 | Exposure 10 to 12 with agility above 15, or exposure 7 to 9 with agility 15 or below | Raise agility first (configuration, automation, supplier commitments) so migration is a configuration change when standards and products are ready. |
| P3 | Exposure 7 to 9 with agility above 15 | Migrate in the normal upgrade cycle; reassess yearly. |
| P4 | Exposure 6 or below | Migrate on replacement or by the organisation's final deadline; reassess every [2 years]. |
The bands are designed to fit the UK NCSC migration timeline: by 2028 define goals, complete discovery and build an initial plan; by 2031 carry out the highest-priority migration and refine the roadmap; by 2035 complete migration of all systems, services and products. P1 and P2 systems belong in the 2031 tranche. NCSC also advises starting with services that process the most valuable or long-lived data, and expects confidentiality protection to be available before certificate-based PKI and IoT and industrial protocols, which supports keeping PKI-dependent systems in P2 until their agility improves.
8. Findings and remediation record
| Criterion scored 0 or 1 | Typical remediation | Owner and date |
|---|---|---|
| 1 Visibility | Run discovery and record a CBOM for the system. | [ ] |
| 2 Configurability | Move algorithm choice into configuration or central policy. | [ ] |
| 3 Abstraction | Replace custom code with a maintained library or KMS call. | [ ] |
| 4 Negotiation | Upgrade the protocol stack; set a minimum accepted algorithm. | [ ] |
| 5 Lifecycle | Automate certificate and key issuance and renewal. | [ ] |
| 8 Supplier | Request a dated roadmap; add cryptographic requirements at renewal. | [ ] |
9. Framework mapping
| Criterion or step | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| 1 Visibility, system record | CM-8 | ID.AM-02, ID.AM-07 |
| 2, 3, 6 Design for change | SA-8, CM-2 | PR.DS-01 |
| 4 Downgrade protection (MITRE ATT&CK T1689 Downgrade Attack) | SC-13 | PR.DS-01 |
| 5 Key and certificate lifecycle | SC-12, IA-5 | PR.AA-01 |
| 8 Supplier control | SA-9, SR-3 | GV.SC-05 |
| Exposure and priority bands | SC-13 | ID.RA-04, GV.RM-01 |
10. Review
Reassess each system when its cryptographic libraries, protocols or suppliers change, when a priority band's migration work completes, and at least every [12 months] for P1 and P2 systems. Report the distribution of agility scores, the number of P1 systems and the number with criterion 8 at 0 or 1 to [Risk committee]. Related documents: [Cryptography Standard], [Key Management Standard], [PQC Migration Plan], [Supplier Security Requirements].
Implementation guidance
- Calibrate on five systems first: score a mix (an in-house web application, a database, a supplier SaaS product, a device family and the PKI) with two assessors each, compare scores and tighten the anchors where they disagree.
- Score machine identities as systems: the internal CA, the identity provider's token-signing keys and the code-signing service usually land in P1, because factor C is 3 and their relying parties all depend on them. See the Machine Identity, PKI and Certificate Lifecycle Guide and the Post-Quantum Migration for NHIs guide.
- Feed scores into the migration plan: P2 work (configuration, automation, supplier commitments) is often cheaper than migration and lowers the cost of every later algorithm change, not only the post-quantum one.
- Use findings in procurement: turn criteria 2, 4, 5 and 8 into requirements for new purchases, so new systems arrive with a score of 2 or more.
- Keep scores honest: scores rise only on evidence, such as a configuration change tested in a ring or a supplier commitment in a contract, not on plans.
Small organisations can score their ten to twenty most important systems in a workshop and focus on supplier evidence, since most of their cryptography sits in purchased products. Large organisations should store scores alongside the inventory, recalculate exposure when data classifications change, and track the median agility score and the count of P1 systems over time. Weak legacy algorithms found during scoring can be handled with the Weak Cipher and Legacy Protocol Retirement Playbook.
Standards and references
- NIST: CSWP 39upd1, Considerations for Achieving Crypto Agility: Strategies and Practices
- NIST: IR 8547, Transition to Post-Quantum Cryptography Standards
- NCSC: Timelines for migration to post-quantum cryptography
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Downgrade Attack
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: Crypto-Agility Guide · Post-Quantum Cryptography Migration Guide · Cryptographic Inventory and CBOM Guide · Q-Day Planning Guide