Cryptographic inventory: deprecated after 2030, gone 2035

NIST's draft transition plan puts a date on cryptography you are running today. Classical public-key algorithms at the 112-bit security level are deprecated after 2030 and disallowed after 2035, and everything stronger — RSA, ECDSA, EdDSA, finite-field and elliptic-curve Diffie-Hellman — is disallowed after 2035 too. A cryptographic inventory is the deliverable that tells you how much of that is yours, and most engineering organisations cannot produce one.

This post covers what those two words actually mean, the five layers cryptography hides in, and how a codebase scan plus an LLM triage pass finds it. It also covers the part the tooling pitches skip: the three places that method hands you false confidence, and what you have to do by hand instead.

Deprecated after 2030, disallowed after 2035 — the exact wording

The document is NIST IR 8547, Transition to Post-Quantum Cryptography Standards, published November 2024. Read the status line before you quote it anywhere expensive: as of 1 October 2026 it is still an initial public draft. The comment period closed on 10 January 2025 and no final version has been published. Plenty of secondary coverage describes 2030 and 2035 as NIST deadlines. They are a published intent in a draft, which is a good enough basis to plan against and a bad basis to tell your board the rule is settled.

The vocabulary matters more than the years, because IR 8547 inherits it from SP 800-131A and the three terms mean very different things to whoever owns the system:

• Acceptable — approved for use in line with the associated guidance.
• Deprecated — "may be used, but there is some security risk. The data owner must examine this risk potential and decide whether to continue to use" it. Deprecation is a decision handed to you, not a switch thrown for you.
• Disallowed — "no longer allowed for the stated purpose". No judgement call left.
• Legacy use — may only process already-protected information: decrypt old ciphertext, verify an old signature. You cannot sign or encrypt anything new.

Applied to the algorithms actually deployed in a normal estate, the draft reads like this:

Algorithm family	Parameters	Transition
RSA, ECDSA (signatures)	112-bit security strength	Deprecated after 2030, disallowed after 2035
RSA, ECDSA, EdDSA (signatures)	128-bit security strength and above	Disallowed after 2035
Finite-field DH/MQV, elliptic-curve DH, RSA key transport	112-bit security strength	Deprecated after 2030, disallowed after 2035
The same key-establishment schemes	128-bit security strength and above	Disallowed after 2035
Symmetric standards at the 112-bit level	—	Disallowed in 2030

One detail is worth flagging to anyone who built a plan off the older guidance. SP 800-57 Part 1 had projected that NIST would disallow 112-bit public-key schemes on 1 January 2031. IR 8547 softens that to deprecation, explicitly so organisations can keep running them while they migrate. If your roadmap assumed a hard 2031 cut-off, the draft gives you five more years at the bottom end — and takes nothing off the 2035 date at the top.

The replacements already exist. FIPS 203, 204 and 205 were published in August 2024: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures, with HQC selected as a fourth-round key-encapsulation alternative still being standardised. The algorithms are not the hard part. Finding every place you use the old ones is.

What a cryptographic inventory actually has to contain

CISA, the NSA and NIST published a joint factsheet, Quantum-Readiness: Migration to Post-Quantum Cryptography, that is unusually specific about scope. It tells organisations to use discovery tools across three places: network protocols; assets on end-user systems and servers, "including applications and associated libraries, both within application functionality and for firmware and software updates"; and "cryptographic code or dependencies in the continuous integration/continuous delivery development pipeline".

That third one is the giveaway. An inventory that stops at the TLS handshake is a report about your load balancer. The factsheet also carries the sentence that should set your expectations for any scanning tool, ours included: "Discovery tools may not be able to identify embedded cryptography used internally within products, hindering discoverability or documentation. Organizations should ask vendors for lists of embedded cryptography within their products."

The output format has largely settled on a cryptography bill of materials (CBOM) — the CycloneDX extension that records algorithms, keys, certificates and their relationships to software components. Treat it the way you treat an SBOM: a build artefact regenerated on every merge, not a spreadsheet someone owns.

Five layers, and the one teams miss

Cryptography in a typical platform stacks up in five places, and they get progressively harder to see.

1. TLS termination. Your edge, your load balancers, your service mesh. This is the layer external scanners can check for you, which is why it is the layer everyone starts with — you can confirm it today with a post-quantum encryption check on your own domain.
2. Application libraries. JWT signing (RS256 and ES256 are both classical signatures), session tokens, password hashing, envelope encryption, webhook signatures, internal mTLS. This is where a code scan earns its keep.
3. Stored data. Field-level encryption, database-level encryption, backups and archives, signed build artefacts, long-lived secrets. Anything here with a confidentiality requirement past 2035 is a harvest-now-decrypt-later problem and should be migrated before anything in layer one.
4. Third-party dependencies. Payment gateways, identity providers, SDKs, managed queues, the SaaS your finance team bought. The cryptography is inside someone else's binary, and your scanner cannot read it.
5. Hardware. HSMs, TPMs, secure elements, firmware signing keys, IoT and telemetry devices in the field. Often the only layer with a replacement cost measured in trucks.

Layer four is the one teams consistently miss, and it is missed for a structural reason rather than a careless one: it is the only layer where the answer cannot be derived from anything you control. In the modernisation and integration work we do, the slow part is never swapping an algorithm in our own code. It is getting a straight answer out of a dependency about what its SDK negotiates, and then discovering the answer is "whatever the server offers".

How a codebase scan plus an LLM triage pass actually finds this

Cloudflare published the clearest worked description of the method so far, in a write-up of CryptoLabe, the internal tool it built to chart its own migration against a 2029 readiness target. The architecture is two stages, and the split is the whole trick.

Discovery sweeps a repository for cryptographic artefacts across "source, configuration, manifests, lockfiles, scripts, tests, and documentation" and emits raw observations — key agreement, signatures, asymmetric encryption, PKI, tokens, credentials. It is deliberately noisy.

Analysis then takes each observation on its own and re-checks it against the source, looks at runtime behaviour, walks dependencies and inspects related repositories before classifying it. Cloudflare's classes are practical rather than academic: classical encryption, classical signature, classical token, PQ-ready hybrid key exchange, PQ-ready. Crucially, the model is allowed to return insufficient evidence instead of guessing.

The argument for this over grep -r "RSA" is one Cloudflare states directly: pattern matching both overcounts, by flagging code that never executes, and undercounts, by missing defaults and indirect dependencies. An LLM pass is not better at finding the string. It is better at answering the second question — is this actually used, and by what.

The other technique worth stealing is the separate "hard cases" prompt, run holistically across all repositories with organisational context, which ignores vanilla usage and looks for the things that will not migrate cleanly: custom protocols, size-constrained fields, cryptography embedded in hardware, external-party dependencies. Cloudflare's example is a certificate carried in an HTTP header, where a post-quantum signature's larger size could blow past the header limit. That is a finding no inventory row would have surfaced, and it is the kind that reshapes a timeline.

Where this approach gives you false confidence

Four failure modes, in rough order of how badly they bite.

You cannot measure recall. Cloudflare says plainly that it does "not yet have a ground-truth dataset for reproducibly comparing different versions of the prompts". Neither will you. An inventory with 400 findings and no known false-negative rate is evidence of effort, not coverage. Say so in the document, in writing, before someone cites it as a completeness claim in a security questionnaire.

The model reports what the code says, not what runs. Negotiated protocol versions, environment variables, feature flags and platform defaults all sit outside the repository. A library that supports ML-KEM is not a deployment that negotiates it. Pair every code finding with a runtime observation before you call it closed — the same discipline that makes a CVSS 9.8 wait while a 6.5 ships today applies here: reachability beats presence.

Vendor and hardware cryptography is invisible to it. A code scan of your repositories says nothing about what your payment provider's SDK does internally, and nothing at all about an HSM. This part is procurement work and vendor questionnaires, and CISA's factsheet is explicit that you have to ask.

A clean scan ages instantly. The day after the report, someone adds a dependency. Unless the scan runs in CI and the CBOM is regenerated on merge, you have bought a snapshot and called it a control. This is the same mistake as running a one-off dependency audit — compare the operational discipline behind GitHub's SSH key-strength enforcement, which worked because it was a gate, not a memo.

The case for doing nothing yet, and why it loses

The strongest argument against starting: no cryptographically relevant quantum computer exists, the NIST dates are in a draft that has not been finalised, and post-quantum deployment shapes are still moving. Spending 2026 budget on a 2035 problem is a genuine opportunity cost, and an inventory produced too early will be stale by the time anyone acts on it.

That argument defeats an early migration. It does not defeat an early inventory, for three reasons. The inventory carries no algorithm risk — it is a map, and the map stays valid whichever algorithm wins. It is reusable immediately for TLS posture, FIPS boundary questions, certificate lifecycle and audit evidence, none of which are quantum problems. And it has the longest lead time of anything in the programme, because it ends in conversations with vendors who are not ready to answer yet.

Where to start on a normal enterprise codebase

1. Scope by data lifetime, not by repository size. Anything whose confidentiality must survive past 2035 goes first. Cloudflare's own advice to other organisations is to start with high-value systems rather than attempt an exhaustive scan.
2. Snapshot before you scan. Analyse an immutable copy so findings are reproducible and nothing the agent runs touches a working tree.
3. Run discovery wide, triage narrow. Accept noise in stage one. Make stage two re-check each observation against the source and permit "insufficient evidence" as an answer.
4. Validate with the team that owns the code. Every published account of this, including Cloudflare's, has a human review step with the maintainers. The inventory is wrong until an owner has read their rows.
5. Emit a CBOM and wire it into CI. Regenerate on merge. Diff it. Alert on new classical primitives entering the codebase.
6. Open the vendor conversations now. Ask for a post-quantum roadmap and a list of embedded cryptography, in writing. The lead time here is measured in quarters.

If you only do one of these, do the last one. Everything else is work you control and can schedule; the vendor answers are the ones that will set your actual date, and they are the ones nobody has started asking for. This is ordinary legacy application modernisation work with an unusually firm deadline attached — and the firmest thing about it is that the deadline is not yours to move.