Build a cryptographic inventory for the post-quantum transition

Why inventory comes first

A cryptographic inventory for the post-quantum transition lists every place your systems use public-key cryptography, with enough context to decide what changes, in what order and who makes the change. Each entry needs the cryptographic function (key establishment or digital signature), the algorithm and key size, the library, module or service that implements it, the data it protects and how long that data must stay confidential, and the realistic upgrade path. A count of RSA keys answers none of the questions that set priority. ^[4][7]

Move things in this order. First, key establishment that protects data whose confidentiality must outlast the arrival of a cryptographically relevant quantum computer, because traffic recorded today can be decrypted later. Second, signatures verified by code or hardware that is hard to change, such as firmware roots of trust and long-lived signing chains. Third, everything else, on the schedule of ordinary upgrades. NIST's draft transition report draws the same line: the harvest now, decrypt later threat applies to key establishment and encryption, while an authentication stays sound as long as its algorithm is unbroken at the moment it is performed. ^[4]

Most organizations will never write ML-KEM or ML-DSA code. They will receive both through TLS libraries, operating systems, managed load balancers, key management services, hardware and SaaS vendors. The inventory is therefore a dependency map: which library release, configuration switch, platform upgrade or contract renewal carries each entry across. OMB's June 2026 memorandum tells federal agencies to fold PQC into planned cloud migrations, development lifecycles and hardware refreshes for that reason, and to flag systems that cannot support PQC or hybrid cryptography for replacement or decommissioning. ^[6]

Protocol detail for one row type, TLS, lives in a separate guide. Here TLS is one entry among SSH, certificates, signed tokens, managed keys, signing pipelines and vendor products, all of which need the same fields.

The dates that matter

Three standards were published and took effect on August 13, 2024: FIPS 203 specifies ML-KEM for key encapsulation, FIPS 204 specifies ML-DSA for signatures and FIPS 205 specifies SLH-DSA, a hash-based signature scheme. These are the target algorithms for nearly every inventory entry. ^[1][2][3]

NIST IR 8547, which proposes when classical public-key algorithms leave NIST standards, is still an initial public draft. It was released on November 12, 2024, its comment period closed on January 10, 2025, and NIST's publication page still listed it as a draft on October 7, 2026. Its proposed tables deprecate quantum-vulnerable signature and key-establishment schemes at 112 bits of security strength after 2030 and disallow all of them, at any strength, after 2035. Plan against those years, but describe them as proposals until a final version appears. ^[4]

For US federal civilian agencies, binding dates now come from Executive Order 14412, signed on June 22, 2026 and published in the Federal Register on June 25. It directs OMB to require agencies to move all high value assets and high impact systems to PQC key establishment by December 31, 2030 and to PQC digital signatures by December 31, 2031. It gives CISA, working with NIST, 270 days to publish the minimum elements of a cryptographic bill of materials (CBOM), and gives the FAR Council 180 days to propose a rule requiring covered contractors to comply with NIST FIPS, including the PQC standards, by December 31, 2030. ^[5]

OMB M-26-15, dated June 24, 2026, implements the order. Each agency must submit a PQC migration plan within 120 days, which falls on October 22, 2026, and must support TLS 1.3 or a successor no later than January 2, 2030. The memo's phases run from strategy and discovery in 2026 to 2027, through pilots, key establishment migration from 2028 to 2030 and signature migration in 2031, to remaining systems by 2035. Plans must align with IR 8547 or its successor, so the draft carries weight even before it is final. ^[6]

Companies outside government are not bound by either document, but they will feel both through procurement. Once a FAR rule is final, vendors that sell to agencies will need FIPS-compliant PQC by the end of 2030, and the products everyone else buys from those vendors will tend to change on the same schedule. The dates in the figure marked as due are calculated from the signing dates and day counts; check for the actual publications as each date approaches. ^[5][6]

Source. FIPS 203, 204 and 205; NIST IR 8547 initial public draft; Executive Order 14412; OMB M-26-15. ^{[1][2][3][4][5][6]}

Method. Dates copied from the cited documents. Due dates for agency plans, the FAR proposed rule and CBOM elements are calculated as day counts from June 22 or June 24, 2026. IR 8547 dates are proposals in a draft. Ordinal layout; spacing does not represent elapsed time.

Accessible table and figure data

Figure 1 accessible table

Date	Milestone
August 13, 2024	FIPS 203, 204 and 205 published and effective
November 12, 2024	NIST IR 8547 initial public draft; still a draft at review
June 22, 2026	Executive Order 14412 signed
June 24, 2026	OMB M-26-15 issued
October 22, 2026	Agency PQC migration plans due (120 days)
December 19, 2026	FAR proposed rule due (180 days)
March 19, 2027	CBOM minimum elements due (270 days)
January 2, 2030	Federal TLS 1.3 support deadline
December 31, 2030	PQC key establishment for HVAs and high impact systems
After 2030	Draft IR 8547: 112-bit RSA and ECC deprecated
December 31, 2031	PQC signatures for HVAs and high impact systems
After 2035	Draft IR 8547: quantum-vulnerable algorithms disallowed

Figure 1 accessible table

Date	Milestone
August 13, 2024	FIPS 203, 204 and 205 published and effective
November 12, 2024	NIST IR 8547 initial public draft; still a draft at review
June 22, 2026	Executive Order 14412 signed
June 24, 2026	OMB M-26-15 issued
October 22, 2026	Agency PQC migration plans due (120 days)
December 19, 2026	FAR proposed rule due (180 days)
March 19, 2027	CBOM minimum elements due (270 days)
January 2, 2030	Federal TLS 1.3 support deadline
December 31, 2030	PQC key establishment for HVAs and high impact systems
After 2030	Draft IR 8547: 112-bit RSA and ECC deprecated
December 31, 2031	PQC signatures for HVAs and high impact systems
After 2035	Draft IR 8547: quantum-vulnerable algorithms disallowed

Download imageDownload table CSV

What to record

Federal practice already supplies a field list. OMB M-23-02 asked agencies for nine data items per cryptographic system, and CISA's August 2024 strategy for automated discovery tools sorts them by how they can be collected. Only three can come from tools: the algorithm, service provided and key length; whether the containing software is commercial, government or custom, and who supplies it; and the operating system with its version. The rest, including the system identifier, FIPS 199 categorization, hosting arrangement and the lifecycle of the data with its time to live, have to be gathered by people. ^[7]

That split is the most useful planning fact in the exercise. A scanner will find RSA in a certificate. It will not report that the certificate fronts an archive whose records must stay confidential for twenty years, or that the vendor ships a fix next spring. CISA also states that embedded cryptography in software packages, custom applications and some operating systems may be invisible to automated tools, and that agencies may have to ask vendors for algorithms and key lengths and track the answers manually. ^[7]

The field matrix lists what each entry should hold. Two fields deserve extra care. Record the cryptographic function separately from the algorithm, because the same elliptic curve key exchange carries different urgency in a session that moves backups than in one that serves a public web page. Record evidence with a date: a scan result, a log field or a vendor statement, and when it was observed. Without dates the inventory cannot show progress, and it drifts from reality after the first upgrade.

M-26-15 expects the inventory to feed a central CBOM, populated by software composition analysis of SBOMs, static and dynamic application testing that finds cryptographic functions in code, and network scanners that detect protocols and cipher suites. Until CISA publishes CBOM minimum elements, keep your own schema small and exportable so it can be mapped later. The hypothetical record below shows one shape for a single entry. ^[5][6]

{
  "entryId": "crypto-0147",
  "system": "claims-archive-replication",
  "owner": "records-platform-team",
  "hosting": "AWS account 111122223333, eu-west-1",
  "function": "key-establishment",
  "context": "TLS 1.3 from replication agent to storage API endpoint",
  "algorithm": "x25519",
  "quantumVulnerable": true,
  "implementation": {
    "component": "example-replication-agent",
    "version": "4.2.1",
    "supplier": "Example Vendor (commercial)"
  },
  "dataConfidentialUntil": "2046-12-31",
  "priorityTier": 1,
  "upgradePath": "vendor release that offers X25519MLKEM768",
  "evidence": [
    {
      "source": "CloudTrail tlsDetails.keyExchange",
      "value": "x25519",
      "observed": "2026-10-01"
    },
    {
      "source": "vendor roadmap statement",
      "value": "hybrid TLS planned",
      "observed": "2026-09-15"
    }
  ],
  "nextReview": "2027-01-15"
}

Source. Conceptual field set adapted from the M-23-02 data items described by CISA and the CBOM sources in OMB M-26-15. ^[6][7]

Method. Conceptual synthesis. Field names and examples are this guide's; they are not an official CBOM schema.

Accessible table and figure data

Figure 2 accessible table

Field	Example entry	Typical source
Owner and system	Team, system ID, account or subscription	Asset inventory, cloud tags
Function	Key establishment, signature or symmetric	Protocol and code review
Algorithm and size	x25519, RSA-2048, ECDSA P-256	Scanners, certificates, key metadata
Implementation	Library, module or service with version	SBOM, SCA, supplier statement
Data lifetime	Confidential until a stated year	Data owner, records schedule
Exposure	Internet TLS, internal mTLS, stored data	Architecture review, network scans
Hosting	Cloud provider, SaaS supplier or on premises	Contracts, asset inventory
Upgrade path	Setting, upgrade, supplier release or replacement	Supplier roadmap, engineering
Evidence	Log field, scan or statement with date	CloudTrail, scanners, supplier

Figure 2 accessible table

Field	Example entry	Typical source
Owner and system	Team, system ID, account or subscription	Asset inventory, cloud tags
Function	Key establishment, signature or symmetric	Protocol and code review
Algorithm and size	x25519, RSA-2048, ECDSA P-256	Scanners, certificates, key metadata
Implementation	Library, module or service with version	SBOM, SCA, supplier statement
Data lifetime	Confidential until a stated year	Data owner, records schedule
Exposure	Internet TLS, internal mTLS, stored data	Architecture review, network scans
Hosting	Cloud provider, SaaS supplier or on premises	Contracts, asset inventory
Upgrade path	Setting, upgrade, supplier release or replacement	Supplier roadmap, engineering
Evidence	Log field, scan or statement with date	CloudTrail, scanners, supplier

Download imageDownload table CSV

Where to find cryptography in cloud estates

In a cloud estate, public-key cryptography concentrates in a few places, and each has its own discovery method. The illustration places them around a single service. The first few are machine-readable; the later ones usually need code review, pipeline configuration or supplier answers.

• TLS endpoints. Load balancers, API gateways, CDNs and service meshes all negotiate key exchange. An external scan shows what the edge offers; only a per-hop observation shows what each connection used.
• Cloud API calls. On AWS, the CloudTrail tlsDetails element records tlsVersion, cipherSuite and keyExchange for calls from external clients, with documented example values X25519MLKEM768, x25519 and secp256r1. It is absent when an AWS service calls on your behalf. ^[12]
• Managed keys. AWS DescribeKey returns each key's KeySpec. Google's Asymmetric PQC insights dashboard and Cloud Asset Inventory list asymmetric keys by algorithm at project or organization scope, and Google leaves symmetric ENCRYPT_DECRYPT keys out because they are generally considered resistant to quantum attacks. ^[13][15]
• Certificates and PKI. Public and private CAs, mTLS client certificates and federation signing certificates state their algorithm and key length directly, which is why CISA uses certificates as the example of data that discovery tools can read. ^[7]
• Libraries and code. TLS stacks, JWT libraries, language cryptography APIs and direct calls that static analysis can find. SBOMs tell you which versions are deployed. ^[6]
• SSH and administrative access. Host keys, user keys and SSH certificate authorities, including those embedded in golden images.
• Signing pipelines. Code, package, container image and firmware signing. NIST notes that devices unable to update their verification code need quantum-resistant signatures designed in if they will still be in use once a capable quantum computer exists. ^[4]
• Data at rest. Mostly symmetric, but check where data keys are wrapped with RSA or agreed with ECDH, as in some client-side envelope schemes and key import flows.

# Example fragment (read-only). Lists the key spec of every AWS KMS key in the current Region.
for key in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
  aws kms describe-key --key-id "$key" \
    --query 'KeyMetadata.[KeyId,KeySpec,KeyUsage,KeyManager,KeyState]' --output text
done

# Counts TLS key exchange values in CloudTrail log files already downloaded to ./cloudtrail
gzip -dc ./cloudtrail/*.json.gz \
  | jq -r '.Records[] | select(.tlsDetails != null)
      | [.eventSource, .tlsDetails.tlsVersion, (.tlsDetails.keyExchange // "absent")] | @tsv' \
  | sort | uniq -c | sort -rn

# Lists classical asymmetric Cloud KMS keys across an organization (Google's documented PQC insights filter)
gcloud asset list --organization=ORGANIZATION_ID \
  --asset-types="cloudkms.googleapis.com/CryptoKey" --content-type=resource \
  --filter='(resource.data.purpose = "ASYMMETRIC_SIGN" OR resource.data.purpose = "ASYMMETRIC_DECRYPT" OR resource.data.purpose = "KEY_ENCAPSULATION") AND NOT (resource.data.versionTemplate.algorithm:PQ_SIGN* OR resource.data.versionTemplate.algorithm:ML_KEM* OR resource.data.versionTemplate.algorithm = "KEM_XWING")' \
  --format='table(name, resource.data.purpose, resource.data.versionTemplate.algorithm)'

Source. Conceptual illustration based on the discovery sources in OMB M-26-15 and CISA's automated inventory strategy. ^[6][7]

Method. Conceptual hand-authored illustration. Marker placement shows typical uses, not a scan of any real system.

Accessible table and figure data

Figure 3 accessible table

Element	What it represents
Edge TLS endpoint	Load balancer or gateway negotiating key exchange
Service and libraries	Application code, TLS stack and token libraries
Key service	Managed keys and their key specs
Certificates	Public and private PKI, mTLS and federation
Data store	Stored data and its confidentiality lifetime
Signing pipeline	Code, image and firmware signatures
Circle marker	Key establishment, urgent for long-lived data
Triangle marker	Signature, urgent where verifiers are fixed
Square marker	Symmetric encryption, lower quantum risk

Figure 3 accessible table

Element	What it represents
Edge TLS endpoint	Load balancer or gateway negotiating key exchange
Service and libraries	Application code, TLS stack and token libraries
Key service	Managed keys and their key specs
Certificates	Public and private PKI, mTLS and federation
Data store	Stored data and its confidentiality lifetime
Signing pipeline	Code, image and firmware signatures
Circle marker	Key establishment, urgent for long-lived data
Triangle marker	Signature, urgent where verifiers are fixed
Square marker	Symmetric encryption, lower quantum risk

Download imageDownload table CSV

What the scans will miss

The commands above cover two cloud-native sources that need no new tooling: key metadata and API connection logs. They miss SaaS applications, network appliances, partner connections, mobile clients and anything compiled into a vendor's binary. For those, the inventory entry is the supplier's written statement, its date and the product version it covers, held alongside the machine-collected rows rather than in a separate spreadsheet. ^[7]

Ask suppliers concrete questions that map to your fields: which algorithms the product uses for key establishment and signatures, which library and version implements them, which release adds ML-KEM or hybrid key exchange and which adds ML-DSA, and whether the change is a default or a setting. M-26-15 tells agencies to engage their FedRAMP-authorized cloud providers to divide PQC migration responsibilities within the shared responsibility model; private buyers can put the same question in renewal questionnaires and security reviews. ^[6]

Prioritize by data lifetime

NIST's draft report restates Mosca's inequality. If data must stay secure for X years and migration takes Y years, migration has to begin before X plus Y exceeds Z, the time until a cryptographically relevant quantum computer is built. Nobody knows Z, so the practical use is comparative: entries with a large X move first, because their exposure starts when traffic is recorded, not when the machine arrives. ^[4]

Turn that into a ranking with two fields you already hold, function and data lifetime. M-26-15 gives agencies a concrete threshold: prioritize systems with data expected to remain mission-sensitive in 2030, along with logical access control systems built on public key infrastructure. CISA's 2024 strategy used 2035 for the same test, defined as data that would still be sensitive if recorded now and decrypted in 2035. Pick a year, apply it to every entry and write it down, so reviewers can see the rule rather than infer it. ^[6][7]

A hypothetical pair of services shows why lifetime beats count. Both terminate TLS on the same managed load balancer with x25519 key exchange. One serves a public product catalog; the other receives insurance claim records that must stay confidential for decades. A count-based inventory scores them equally. A lifetime-based one puts the claims link in tier 1 and the catalog near the bottom, even though both will move when the load balancer gains a hybrid option.

Signatures carry less urgency but still have lead time. Session authentication can follow the upgrade path, since it only has to resist the attacks available at the moment of use. Trust anchors cannot: a device that checks firmware against a fixed public key, a root certificate with a long validity period or a signed record that must be verified years from now all need the verifier to accept the new algorithm before the old one is switched off. ^[4]

Symmetric encryption is not where the effort goes. AWS states that theoretical large-scale quantum attacks would reduce the effective security of AES-256-GCM ciphertexts to 128 bits, which it considers sufficient, and Microsoft describes 256-bit AES keys in Key Vault Premium (in preview) and Managed HSM as quantum-resistant. NIST's draft does plan to disallow the few 112-bit symmetric standards in 2030, so record those uses. ^[4][11][17]

Size and performance consequences

Post-quantum keys, ciphertexts and signatures are much larger than the classical values they replace, large enough to break fixed-size assumptions. FIPS 204 Table 2 gives ML-DSA-44 a 1,312-byte public key and a 2,420-byte signature, ML-DSA-65 1,952 and 3,309 bytes, and ML-DSA-87 2,592 and 4,627 bytes. RFC 8032 gives Ed25519 a 32-byte public key and a 64-byte signature, so an ML-DSA-44 signature is about 38 times larger. An RSA-2048 signature is as long as its modulus, 256 bytes. ^[2][8][9]

SLH-DSA inverts the profile. FIPS 205 lists SLH-DSA-SHA2-128s with a 32-byte public key and a 7,856-byte signature, and the faster SLH-DSA-SHA2-128f variant at the same security category produces 17,088-byte signatures. That suits infrequent signatures checked against a small, long-lived public key, such as firmware roots, and suits per-request tokens poorly. ^[3]

Key establishment grows as well. FIPS 203 Table 3 lists ML-KEM-768 with a 1,184-byte encapsulation key and a 1,088-byte ciphertext, against 32-byte X25519 values in RFC 7748. The shared secret stays at 32 bytes, so everything downstream of the key exchange is unchanged. ^[1][10]

Record any place where these numbers meet a limit: database columns sized for 256-byte RSA signatures or short elliptic curve keys, signed tokens carried in HTTP headers or cookies, certificate chains in which every certificate holds both a key and a signature, HSM and smart card storage, and constrained device links. As a calculated example from FIPS 204 Table 2, one ML-DSA-65 public key plus one signature is 5,261 bytes before any encoding overhead, against 512 bytes for RSA-2048. ^[2][9]

For network protocols, AWS notes that hybrid key exchange slightly increases the size and processing time of some handshake messages, with an impact it calls imperceptible for most workloads. It also warns that legacy intermediate hosts, proxies or firewalls with deep packet inspection may block requests because of the new key exchange groups in the ClientHello or the larger messages. Test from every network path clients actually use, and record middleboxes as inventory entries with their own upgrade paths. ^[11]

Source. FIPS 204 Table 2, FIPS 205 Table 2, RFC 8032 section 5.1 and RFC 8017 section 8.2. ^[2][3][8][9]

Method. Values copied from the cited tables. RSA-2048 values are the modulus length in bytes (2,048 bits divided by 8), which RFC 8017 defines as the signature length; the public key value excludes the exponent and encoding. Raw sizes, not encoded certificate or token sizes.

Accessible table and figure data

Figure 4 accessible table

Algorithm	Public key (bytes)	Signature (bytes)
Ed25519	32	64
RSA-2048	256	256
ML-DSA-44	1312	2420
ML-DSA-65	1952	3309
ML-DSA-87	2592	4627
SLH-DSA-SHA2-128s	32	7856

Figure 4 accessible table

Algorithm	Public key (bytes)	Signature (bytes)
Ed25519	32	64
RSA-2048	256	256
ML-DSA-44	1312	2420
ML-DSA-65	1952	3309
ML-DSA-87	2592	4627
SLH-DSA-SHA2-128s	32	7856

Download imageDownload table CSV

What cloud providers offer now

Provider support changes from month to month, so store the review date with every provider-dependent entry. The table reflects documentation read on October 7, 2026.

AWS documents hybrid post-quantum TLS, combining ECDH with ML-KEM, for all API calls to KMS in every Region where KMS is available, including FIPS endpoints, and says many AWS SDKs support it. CloudTrail confirms the result per call, because keyExchange shows a hybrid value such as X25519MLKEM768. The same page is explicit that encryption under KMS keys remains AES-256-GCM. For signing, the key spec reference lists ML_DSA_44, ML_DSA_65 and ML_DSA_87 with the ML_DSA_SHAKE_256 algorithm, and no ML-KEM key spec. ^[11][12][13]

Google made its Cloud KMS signing algorithms generally available on July 16, 2026: the three ML-DSA parameter sets in pure and external-mu forms, plus SLH-DSA-SHA2-128s in pure and pre-hash forms. Its key encapsulation algorithms, ML_KEM_768, ML_KEM_1024 and KEM_XWING (ML-KEM-768 combined with X25519), were announced in preview on September 23, 2025, and the release notes record no general availability announcement since. The algorithms page lists all of them for the software protection level only. A preview from August 6, 2026 adds quantum-safe key import using HPKE with ML-KEM or X-Wing. ^[14][16]

Microsoft's Key Vault key documentation, updated October 6, 2026, lists RSA, EC and preview oct-HSM keys for vaults and RSA-HSM, EC-HSM and oct-HSM keys for Managed HSM. It names no ML-KEM or ML-DSA key type. Entries that depend on Key Vault asymmetric keys therefore have no in-service post-quantum path at review time; record that as a dependency to recheck, not as a finished assessment. ^[17]

Two consequences belong in the inventory. Turning on a provider's PQC feature changes only the operations that use it: server-side encryption at rest was symmetric before and still is, while your application's own TLS clients, tokens and certificates are untouched. And a signing workload that needs hardware-backed keys must check the protection level as well as the algorithm, since Google's post-quantum algorithms currently run only at the software level. ^[11][14]

What a first usable inventory needs

A first usable inventory does not need every field filled for every system. It needs consistent rules and the high-priority rows complete. A workable sequence:

• Write down the threshold year, the tier rules and the field list before anyone scans, so every team scores entries the same way.
• Pull machine-readable sources first: KMS key metadata, certificate stores, CloudTrail tlsDetails and SBOMs. They fill the three fields tools can collect.
• Ask data owners for confidentiality lifetimes and suppliers for dated roadmaps. Those fields decide priority and cannot be scanned.
• Within tier 1, sequence by upgrade path: configuration changes first, then library and platform upgrades, then vendor dependencies and replacements.
• Re-check dated evidence quarterly and after each provider release. IR 8547 is still a draft, and the CBOM minimum elements are due around March 2027.