Post-quantum cryptography inventory

• Code, build files and configuration are searched for cryptographic libraries, algorithms, key sizes and protocol settings, read-only, with the file and line for every finding.
• Certificate stores, key managers and your scanners' TLS results are pulled into one inventory, recording algorithm, key size, issuer, expiry and the service each one protects. Private keys are never read.
• Supplier contracts, product documents and security statements are read for what each supplier says about its cryptography and its post-quantum plans, and the gaps become drafted questions for the supplier's owner to send.
• Every finding is classified as quantum-vulnerable, already post-quantum, hybrid, not affected or unknown, with the evidence linked. Unknowns are a tracked category, not dropped.
• A draft priority is suggested for each system from how long its data must stay confidential, how exposed it is and how hard it will be to change. System owners confirm the facts and set the priority.
• The inventory becomes a living record with a named owner. New repositories, certificates and suppliers are picked up as they appear, and the migration plan is drafted from it for people to finish and the board to approve.

• NCSCTimelines for migration to post-quantum cryptography (20 March 2025)
  →

  Indicative milestones, not law: by 2028 define goals, complete discovery and build an initial plan that covers supplier dependencies and long-lived hardware roots of trust; by 2031 finish the highest-priority migrations; by 2035 complete migration. The NCSC says discovery doesn't need to be a formal asset register, just enough understanding to plan. This design keeps the inventory as light as that allows, but owned and kept current, because the plan will be revised for years.

• NCSCNext steps in preparing for post-quantum cryptography (white paper, updated August 2024) and Using TLS to protect data (version 1.2, 15 October 2026)
  →

  The NCSC recommends ML-KEM-768 and ML-DSA-65 for most uses, treats hybrid post-quantum and traditional schemes as an interim step, and suits SLH-DSA or carefully managed LMS and XMSS to firmware and software signing. Its TLS guidance lists hybrid key exchange groups such as X25519MLKEM768, asks you to enable a post-quantum key exchange as soon as your software supports it, and doesn't yet recommend post-quantum certificates. The classification rules in the inventory follow these documents, held in the retrieval index so every classification cites them.

• NCSCCyber Assessment Framework v4.0, where the NIS Regulations apply
  →

  For operators of essential services, the inventory supports asset management (A3) and supply chain (A4), including A4.b, which expects suppliers to understand the third-party components in the software they provide. The agents are a new system too: they need their own access control, logging and a place in the CAF self-assessment.

• FCA and Bank of EnglandFCA 'Act now to be resilient in the quantum future' (4 November 2026) and the G7 Cyber Expert Group roadmap (January 2026)
  →

  If you're FCA-regulated: the FCA expects firms to build an accurate picture of where and how cryptography is used as a first step, to follow the NCSC milestones without waiting for them, and for senior managers to commit enough time and money. The G7 group, co-chaired by the Bank of England, set a non-binding 2035 planning horizon for the financial sector. Keep the inventory and plan in a form you could show your supervisor.

• ICOUK GDPR Article 32: security of processing
  →

  Security must take account of the state of the art and the risks. For personal data that must stay confidential for many years, harvest-now-decrypt-later is a risk to weigh now, so long-lived personal data is one of the priority factors. The discovery tools also read commit history, which names developers: keep findings to what the plan needs and control who sees them.

• NISTFIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), August 2024
  →

  The standards the NCSC's recommendations are built on. NIST selected HQC as a backup key encapsulation algorithm in March 2025, and FN-DSA (from Falcon) is still going through standardisation. NIST says it will remove quantum-vulnerable algorithms from its standards by 2035. The inventory records algorithm names exactly, so new standards can be added without reclassifying everything.

On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →

• A named inventory owner, usually in security architecture, who is accountable for the record being true and current, with a quarterly sign-off.
• Classification rules written by people from the NCSC guidance and your own crypto policy, held under change control and versioned, so a reclassification can be traced to a rule change.
• System owners confirm findings within an agreed time; overdue confirmations are reported to the CISO, not left open.
• Priorities set by people using agreed factors: how long the data must stay confidential, exposure to the internet or partners, signing roots and long-lived devices, and how hard the change is.
• Supplier owners ask every critical supplier for its post-quantum roadmap, and new contracts include support for algorithm updates.
• The plan is refreshed at least yearly against the 2028, 2031 and 2035 milestones and taken to the board.

1. 3–4 weeks

   Discovery

   Agree scope, the classification rules and the priority factors. Pick one business service to trace end to end: its code, certificates, network path, devices and suppliers. Set up read-only access with security architecture.

2. Gate · must be true to passRules approved, read-only identities reviewed, inventory owner named, system owners for the pilot service agreed.

3. 8–10 weeks

   Pilot

   Run discovery on the pilot service. Owners confirm every finding. Compare with what the team knew before and with a manual sample.

4. Gate · must be true to passFinding precision and coverage within agreed limits, no write access anywhere, unknowns listed with next steps, CISO sign-off.

5. 6–8 weeks

   Production

   Extend to the rest of the high-priority services, switch on event-driven updates, and start supplier questions.

6. Gate · must be true to passMonitoring and audit in place, owners trained, unowned queue being worked, first draft plan reviewed by the risk committee.

7. Ongoing

   Scale

   Cover the full estate, keep the inventory current, and track migrations against the plan towards 2031 and 2035.

8. Gate · must be true to passEach new area passes the same confirmation gate; the plan is approved by the board ahead of 2028.

R ResponsibleA AccountableC ConsultedI Informed· not involved

Where I'd fit

1. 1

   Goes wrong

   A pattern search finds 'RSA' in thousands of places, and owners are flooded with false findings.

   How the design avoids it

   The agent reads the context and cites evidence, precision is measured weekly, and owners confirm before anything counts.

2. 2

   Goes wrong

   The inventory is built once as a project spreadsheet and is out of date within six months.

   How the design avoids it

   A living record with a named owner, events from new certificates, repositories and suppliers, and a quarterly sign-off.

3. 3

   Goes wrong

   The agent is given rights to rotate certificates 'while it's there'.

   How the design avoids it

   No write tools at all. Changes go through your change board, tested like any other change.

4. 4

   Goes wrong

   Embedded devices, plant equipment and supplier-run services are left out because they can't be scanned.

   How the design avoids it

   Unknowns are a tracked category with an owner, and supplier questions cover what you can't see.

5. 5

   Goes wrong

   Priorities follow the algorithm, not the data, so long-lived secrets wait behind easy wins.

   How the design avoids it

   Priority factors set by people, starting with how long the data must stay confidential.

1. 31 March 2027
   The NCSC's post-quantum cryptography pilot, part of its Assured Cyber Security Consultancy scheme, is expected to run to this date before review. It assures consultancies for discovery and migration planning, and for advice.

   If you bring in outside help for discovery, ask whether it's assured under the NCSC scheme, and make sure what it produces lands in your inventory, not a separate report.

2. Not yet dated
   Post-quantum certificates for TLS, FN-DSA (FIPS 206) and the HQC standard are still being finalised. The NCSC says it will update its TLS guidance once post-quantum authentication is standardised.

   Record algorithms precisely and keep certificate lifetimes short, so new standards mean a re-run of the rules, not a new inventory.

3. 2028
   The NCSC's first milestone: migration goals defined, discovery complete and an initial plan, including supplier dependencies.

   Have the inventory confirmed for high-priority systems and the plan in front of the board before then.

4. 2031
   The NCSC's second milestone: highest-priority migrations complete.

   Start with what's easiest to switch on, such as hybrid key exchange where your software already supports it, while the harder changes are planned.

5. 2035
   The NCSC's final milestone, and the date NIST says it will remove quantum-vulnerable algorithms from its standards.

   Ask suppliers now for dates, and stop buying products that can't be updated before then.