Post-quantum deadlines make cryptographic inventories urgent

NIST draft guidance recommends dropping quantum-vulnerable algorithms RSA-2048 and ECC P-256 after 2030 and banning RSA and ECC entirely after 2035. Most organizations cannot say where their cryptography lives. Darren Davies, CEO of U.K. consultancy Unsung, argues that gap is now expensive and sets out how to close it.

Two forces have changed the stakes. Post-quantum migration plans all start with knowing what you have. Separately, AI agents are adding new cryptographic dependencies faster than most estates can track them.

What is a cryptographic inventory?

A cryptographic inventory is a structured record of all cryptography in use. Each entry should capture the algorithm, key length, the systems using it, dependent systems and an owner. It is broader than a certificate inventory. A full record covers:

• Encryption keys in hardware security modules, cloud key management services or files on disk.
• Cryptographic libraries and versions embedded in software.
• Protocols and cipher suites negotiated between systems.
• SSH keys, code signing keys and API secrets.
• Trust stores that decide which certificates a system accepts.

A cryptographic bill of materials (CBOM) is a machine-readable standard format for storing and sharing this information, analogous to a software bill of materials (SBOM).

Why do the deadlines matter now?

In the U.K., NCSC migration timelines require organizations to complete discovery and an initial plan by 2028, high-priority migration by 2031 and all migration by 2035. Both regimes share one premise: you cannot migrate what you cannot find.

Some data is already exposed. Under "harvest now, decrypt later," attackers capture encrypted traffic today and store it until a quantum computer can decode it. Data that must stay confidential for 10 years or more is at risk now, not in 2035.

AI agents accelerate the problem. Every agent that calls an API, connects to a tool server or authenticates to another service relies on certificates, keys and trust stores. Industry workload-identity work now treats agents as workloads with their own credentials. Developers often create them using notebooks, ad hoc container images and tools outside IT asset management.

What can existing data reveal?

Much of the picture assembles within a few weeks of focused effort, Davies writes. Sources already held by most organizations include:

• Internal certificate authorities, such as Microsoft Active Directory Certificate Services, which record algorithms, key lengths, expiry dates and requesters.
• Certificate Transparency logs, which show every public TLS certificate issued for your domains, including ones you were not told about.
• Network scans of internal and external endpoints, often already collected by vulnerability scanners.
• Cloud key management services and hardware security modules, which report stored keys and their algorithms.
• SBOMs, which list cryptographic libraries and versions.
• Certificate lifecycle management, configuration management and asset management tools.

This visible half lets teams size the problem and name owners. It is not the whole estate.

Where are the gaps?

The harder cryptography is not centrally issued, not visible on the network and not under direct control. Davies lists the areas that surprise teams late in a migration:

• Cryptography hardcoded in application code, invisible to CA databases and network scans.
• Operational technology and embedded devices with fixed cryptography, long replacement cycles and limited scanability.
• Third parties and SaaS, where you rely on supplier statements.
• Data at rest and backups using algorithms chosen years ago, where harvest-now risk peaks.
• SSH, code-signing keys and secrets created by individuals, rarely expiring and seldom recorded.
• Trust stores in OSes, language runtimes, container images and appliances, rarely counted or updated.

Davies adds a subtler distinction: knowing which algorithms a system supports is not the same as knowing which it actually uses. A server may offer modern cipher suites while negotiating older ones with legacy clients.

How should teams close the gaps?

Four approaches make the difference, according to Davies:

• Prioritize by risk, not coverage. Rank systems by confidentiality lifetime, business criticality and change difficulty. A payments platform holding decade-long customer data outranks a test server.
• Look inside the code. Static analysis and software composition tools find cryptographic calls in source and build artifacts, catching hardcoded algorithms before production.
• Ask suppliers directly. Questionnaires and contract clauses should cover algorithms used, post-quantum roadmaps and delivery dates, with answers recorded and reviewed.
• Make system owners accountable. A documented estimate with a named owner beats a blank entry.

Systems that genuinely cannot be inventoried should be recorded as known exceptions.

How does the inventory stay current?

The record is out of date the day after completion, Davies warns. Maintenance requires continuous scheduled discovery with change flagging, cryptographic checks inside CI/CD pipelines and change control, procurement standards that specify algorithms and post-quantum support, a named accountable owner reporting to senior leadership, and a structured CBOM format. Done well, the inventory becomes normal operations and delivers crypto agility: the ability to change algorithms quickly when standards shift.

Davies has more than 20 years in IT across defense, manufacturing, financial services and retail, specializing in public key infrastructure (PKI) and identity and access management. At Unsung he doubled the managed service portfolio, introduced a PKI Health Check service and led the firm to ISO 27001 certification.