Security · 2026-08-31
The PQC Inventory Your 2027 Audit Will Ask For
By J. W. Bouckaert
The question coming in 2027
Two things changed the conversation about post-quantum cryptography from a research topic into an audit line item.
The first is that the standards are done. NIST finalized FIPS 203 (ML-KEM, key establishment), FIPS 204 (ML-DSA, digital signatures), and FIPS 205 (SLH-DSA, hash-based signatures) on 13 August 2024. "The algorithms are not standardized yet" stopped being a defensible answer that day.
The second is that the deadlines are now inside most planning horizons. The NSA's CNSA 2.0 timeline expects operating systems to support and prefer the new algorithms by 2027, and expects new National Security System acquisitions to be CNSA 2.0 compliant by default from 1 January 2027. NIST's draft roadmap, NIST IR 8547, sets a plan to deprecate the classical public-key algorithms (RSA, ECDSA, ECDH, DH) after 2030 and disallow them after 2035. 2030 is closer than a typical hardware refresh cycle, and 2035 is inside the retention window of data you are signing and encrypting today.
You do not need to be a defense contractor for this to reach you. The expectation is arriving through commercial channels: vendor security reviews, cyber-insurance questionnaires, and sector regulators are all converging on the same first request. Before anyone asks how post-quantum your stack is, they will ask you to prove you know what your stack uses. That proof is a cryptographic inventory, and CISA, the NSA, and NIST have been explicit since their 2023 joint factsheet that the inventory and a migration roadmap are step one.
This post is about building that inventory, and about the rows most teams miss: the long-lived identity artifacts.
Long-lived identity artifacts first
Not every row in the inventory is equally urgent. The prioritization is a shelf-life calculation, and identity artifacts tend to sit at the wrong end of it.
The reason is harvest-now-decrypt-later. An adversary does not need a cryptographically relevant quantum computer today to threaten data today. They need only to record now what they intend to break later. Anything whose confidentiality or verifiability must survive past the moment a quantum computer arrives is already exposed, because the ciphertext or the signature can be collected in the present and attacked in the future. We covered the threat model in Harvest Now, Decrypt Later; the practical consequence for the inventory is a rule of thumb attributed to Michele Mosca: if the time your data must stay protected plus the time it takes you to migrate exceeds the time until a quantum computer exists, you are already late.
Identity artifacts are where that inequality bites first, because their protection windows are long by design:
| Artifact | Why its clock already started |
|---|---|
| Signing keys for identity assertions and tokens | A signature you emit today may be verified, or forged against, for the life of the trust relationship it anchors. |
| Root and intermediate CA keys, code-signing keys | Multi-year to multi-decade validity. A forged signature under a harvested key is indistinguishable from a real one. |
| Verifiable credentials and long-lived attestations | Issued once, verified for years. The proof has to remain sound the whole time. |
| Audit logs and signed event records | Retained for compliance for 7 to 10 years or more, and their integrity guarantee is the signature. |
| Encrypted archives of personal data | Confidentiality horizon measured in decades, well past any credible quantum timeline. |
Short-lived artifacts (a 5-minute access token, an ephemeral TLS session key that is discarded when the connection closes) carry far less harvest-now-decrypt-later risk. They still belong in the inventory, but they are not the rows that fail an audit or lose data retroactively. Rank the long-lived rows first.
Inventory contents
An auditor is not asking for a sentence that says "we use TLS." They are asking for a structured, per-asset record that a migration plan can be built on. Every row needs enough to answer three questions: what algorithm is here, how long does what it protects need to survive, and what does it migrate to.
A workable row schema:
| Field | What it captures |
|---|---|
| Asset | The concrete thing: a specific key, certificate, token type, protocol endpoint, or data store. |
| Algorithm and parameters | Not "RSA" but RSA-2048; not "ECDSA" but ECDSA P-256; the exact primitive and parameter set. |
| Purpose | Signature, key establishment, encryption at rest, MAC. The purpose decides the post-quantum target. |
| Protection horizon | How long the protected data or trust relationship must stay sound. This is the field most inventories omit, and the one that drives priority. |
| Owner and dependency | Who controls it, and what depends on it. A key you cannot rotate without a vendor is a longer migration. |
| Migration target | The FIPS or SP algorithm this row moves to, filled in at inventory time so the roadmap writes itself. |
| Status | Classical only, hybrid deployed, or migrated. |
The protection-horizon field is what turns a static list into a priority queue. A row with a 30-day horizon and a row with a 10-year horizon are not the same risk even if they use the same algorithm today.
The identity rows most inventories miss
General cryptographic inventories are good at the obvious surfaces: the TLS termination, the disk encryption, the database at rest. Identity systems hide cryptography in places a network scan does not reach. These are the rows to add by hand.
| Identity asset | Typical primitive today | Post-quantum target |
|---|---|---|
JWT / JWS assertion signing (the alg in your tokens) | RS256, ES256 | ML-DSA (FIPS 204), deployed alongside the classical signature |
| mTLS and client-certificate key exchange | ECDHE, RSA | ML-KEM (FIPS 203) |
| Session and refresh-token signing | HMAC, ECDSA | ML-DSA for asymmetric cases; symmetric MACs are quantum-resilient at doubled key length |
| Webhook and Security Event Token (SET) signing | ES256, RS256 | ML-DSA (FIPS 204) |
| Code-signing and firmware-signing keys | RSA, ECDSA | LMS or XMSS (SP 800-208), the stateful hash-based schemes CNSA 2.0 specifies for signed code that must verify for decades |
| KMS / HSM key holdings | Provider-managed RSA, EC | Provider PQC roadmap, tracked as a dependency row |
| Third-party IdP and federation crypto | Whatever Okta, Entra, or Ping negotiate | A dependency row: their timeline is your timeline |
| Archived encrypted PII and signed audit logs | RSA-OAEP, AES with RSA-wrapped keys | ML-KEM for the key-wrap; re-signing plan for the logs |
Two of these deserve emphasis. Code and firmware signing is the one case where the post-quantum answer is not the lattice signature. CNSA 2.0 specifies the stateful hash-based schemes LMS and XMSS for software and firmware signing, because hash-based signatures rest on the most conservative security assumptions available for code that has to remain verifiable for decades. We went deeper on that trade-off in LMS and XMSS for audit logs and in ML-DSA-87 versus SLH-DSA-256.
The third-party rows are the ones that quietly set your timeline. If your identity provider, your KMS, or your HSM has not committed to a post-quantum date, that uncertainty is a finding, and it belongs in the inventory as a dependency you are tracking rather than a blank you are ignoring.
Choosing the migration target per row
The purpose field decides the target, and the mapping is now standardized rather than a matter of opinion:
- Digital signatures move to ML-DSA (FIPS 204). Long-lived code and firmware signatures move to LMS or XMSS (SP 800-208) instead.
- Key establishment moves to ML-KEM (FIPS 203). The mechanism changes shape here: a KEM replaces a key exchange, which is not a drop-in swap, as we described in why KEM replaces key exchange.
- Symmetric encryption and hashing mostly survive at larger parameters. AES-256 and SHA-384/512 are the CNSA 2.0 selections; the work is in the public-key layer, not the symmetric one.
There is a parameter-level decision inside the signature rows. ML-DSA ships in three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87, corresponding to NIST security categories 2, 3, and 5. CNSA 2.0 mandates the highest, ML-DSA-87 (category 5) and ML-KEM-1024, for National Security Systems. Many commercial risk contexts standardize on ML-DSA-65 (category 3), which is a common balance of assurance against signature size. The inventory should record the parameter set, not just the algorithm family, because "we use ML-DSA" does not tell an auditor whether you meet the bar that applies to you.
The pragmatic deployment pattern for the next several years is hybrid: emit both the classical signature and the post-quantum signature over the same content, and require both to verify. Hybrid protects you if the new lattice assumptions are weakened before they have accumulated enough years of cryptanalysis, and it protects you against harvest-now-decrypt-later on the classical side today. It is also what lets you populate the "hybrid deployed" status on your longest-lived rows now, rather than waiting for a flag day. We walk through the construction in dual-signing identity assertions with ES256 and ML-DSA, and addressed the recurring "is the lattice math sound" question in Is ML-DSA Broken.
A passing answer
A passing answer in 2027 is not "we have migrated everything." Nobody has. A passing answer is evidence of control:
- A cryptographic inventory that includes the identity rows above, each with an algorithm, a parameter set, a protection horizon, and an owner.
- A roadmap that maps each row to a FIPS or SP target and a date, with the longest-horizon rows scheduled first.
- Hybrid signatures already live on the highest-value, longest-lived artifacts, so the rows that carry harvest-now-decrypt-later risk are already covered rather than merely planned.
- Named dependency rows for every third party whose timeline you do not control.
The gap between that and a blank stare is mostly inventory work, and inventory work is cheapest before the deadline compresses it.
PasskeyBridge as a row
When you reach the identity-signal rows of the inventory, one of them can point at a vendor that already shipped the hybrid pattern rather than a migration you still owe.
PasskeyBridge dual-signs every identity attestation: a classical ES256 (ECDSA P-256) JWS plus a detached ML-DSA-65 signature (FIPS 204, security category 3), both computed over the same content, both required to verify. The ML-DSA-65 signature is 3,309 bytes. ML-DSA-87 (category 5) with an ES384/P-384 classical layer is available per tenant for contexts that require the higher parameter set. The whole verification stays inside the request's own latency budget, so the post-quantum signature is not a performance trade you have to argue for internally. And because identifiers are stored only as keyed HMAC-SHA-256 digests under a server-held pepper, the row also carries no plaintext personal data to harvest in the first place.
That is one row on your inventory you can mark "hybrid deployed" without running a migration project. The details are on the post-quantum identity page, and the standards background is in what FIPS 204 means for your auth stack.
Rows you cannot redo
The reason to build the inventory now, rather than when the audit lands, is that the long-lived rows are the ones you cannot fix in arrears. You can re-issue a short-lived token next week. You cannot un-harvest a decade of signed audit logs or encrypted archives whose keys were collected while they were still classical. For those rows, the migration you do in 2027 does nothing for the data an adversary already recorded in 2026.
The inventory is a spreadsheet before it is a project. Start it with the identity artifacts whose protection horizon runs past 2030, fill in the algorithm and the parameter set and the target, and let the roadmap fall out of the rows you sorted by shelf life. That is the artifact the audit is going to ask for, and it is the one that also happens to tell you where your real exposure is.