up:: Migration Architecture MOC

Cryptographic Discovery

Cryptographic discovery is the process of finding everywhere cryptography is actually used across an environment, so it can be recorded, assessed, and migrated. It’s the activity that populates a CBOM: discovery is the search, and the CBOM is the ledger the search fills in. It’s the first real move in a post-quantum migration, because a migration can only replace the cryptography it has found, and cryptography hides in code, configuration, TLS terminators, firmware, key stores, certificates, and vendor products nobody mapped.

The short version:

• Discovery is the act of finding your cryptography; a CBOM is the structured record it produces. One is the search, the other is the ledger.
• The governing principle is that discovery comes before everything, because a migration can only move what it can see, and most estates cannot see most of their cryptography until they look for it.
• No single method finds it all. A defensible discovery pass layers configuration extraction, network and TLS scanning, source and dependency analysis, certificate inventory, and vendor attestation, because each one sees a different slice.
• Configuration extraction is the primary layer and active scanning is a cross-check, because a scan sees what a server negotiates when probed while a config shows what it actually permits.
• U.S. federal policy treats discovery as a prerequisite: OMB M-23-02 and the Quantum Computing Cybersecurity Preparedness Act require agencies to inventory their cryptography, and CISA, NSA, and NIST tell every organization to start with proactive discovery.

Think of it like surveying every lock in a very large building before you re-key it. You walk the whole property with a clipboard, opening doors nobody has opened in years, checking which locks a contractor installed and never documented, and noting which rooms each one guards. Cryptographic discovery is that survey, done for an organization’s cryptography, and almost nobody has run it until a migration forces the question.

What is cryptographic discovery?

Cryptographic discovery is the systematic identification of every place cryptography operates inside an environment, its algorithms, keys, certificates, protocol configurations, and the systems and data each one touches. CISA, NSA, and NIST define the resulting cryptographic inventory as “a descriptive record of the cryptography used across an organization’s systems, applications, services, devices, and data flows,” and discovery is the work of building that record from the real environment rather than from memory or an architecture diagram.

Source: CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” August 2023, CISA factsheet.

The distinction between discovery and the CBOM is worth holding clearly, because the two get conflated. Discovery is the ongoing activity of finding cryptography using scanners, code analysis, certificate enumeration, and vendor questionnaires. The CBOM is the durable artifact those activities feed, a granular, machine-readable inventory with an evidence grade on every entry. You run discovery to produce a CBOM, and because environments change, you keep running discovery to keep the CBOM alive.

Why is discovery the hardest part of a migration?

Because the algorithm swap is a solved problem and the estate is the unknown. NIST standardized the replacements, the IETF wired them into the major protocols, and servers and browsers increasingly ship them by default, so the cryptographic move itself has a known answer. What no one hands you is a complete, current picture of where your cryptography lives, who controls each instance, and what each one protects. That picture is exactly what discovery has to build from scratch, and it’s why migrations stall on visibility before they stall on cryptography.

The difficulty is that cryptography is nearly invisible until you go looking, and it hides in a lot of places at once. In rough order of how often teams miss them:

1. Application code and dependencies, where library calls and hardcoded parameters never appear in a live handshake, and a vulnerable primitive can arrive transitively through a dependency nobody audited.
2. Server and service configuration, where what a system permits is often older and broader than what it happens to negotiate when you probe it.
3. TLS termination points such as load balancers, reverse proxies, CDNs, and API gateways, which hold the real cipher policy, so a single un-inventoried terminator is a hole.
4. Vendor and SaaS products, invisible to internal scans and usually the majority of the footprint by surface count.
5. Firmware and embedded or OT devices, often hardcoded and on multi-year replacement cycles.
6. Key stores and HSMs, holding the keys themselves, their algorithms, and the systems that reach them.
7. Certificates and the CA hierarchy, including the signing keys of the certificate authorities, which carry estate-wide blast radius.
8. CI/CD and code-signing pipelines, where build, package, container, and release signing keys live.
9. VPN and network gear, much of it vendor firmware with legacy key-exchange groups lingering for years.
10. Identity infrastructure such as SAML, JWT, and SSO token-signing keys, frequently owned by a different team than PKI and therefore left out of the first pass.

Because the surfaces are so varied, no single tool or technique reaches all of them. The NCCoE proved this out on a live testbed: its post-quantum migration project demonstrated a multifaceted discovery approach, running multiple tools in tandem, precisely because no single product finds every instance of quantum-vulnerable cryptography.

Sources: NIST National Cybersecurity Center of Excellence, “Migration to Post-Quantum Cryptography,” NIST SP 1800-38. NIST, “Transition to Post-Quantum Cryptography Standards,” NIST IR 8547.

How do you actually discover cryptography?

You combine several methods, because each one sees a different slice of the estate and none sees the whole thing. A defensible discovery pass layers all five below, with configuration extraction as the primary layer and active scanning as a cross-check rather than the source of truth.

Method	What it finds	What it misses
Configuration extraction (primary layer)	What each server and terminator permits, parsed from the real config files: cipher policy, permitted protocol versions, key-exchange groups, certificate references	Cryptography outside the parsed config scope, hardcoded in binaries, inside vendor products, or in firmware
Network and TLS scanning (active cross-check)	What a live endpoint negotiates when probed: the selected cipher suite, the served certificate chain, SSH host keys. Tools include sslyze and testssl.sh	Permitted-but-uninvoked fallbacks, anything not reachable or not probed, and all hardcoded or at-rest cryptography a handshake never touches
Source and dependency analysis (static)	Library calls, hardcoded algorithms and parameters, key-management patterns, and vulnerable primitives pulled in transitively through dependencies	Systems you have no source for (vendor, SaaS, firmware), and runtime configuration that overrides a code default
Certificate inventory	Every leaf, intermediate, and root certificate, its signature and key algorithms and sizes, expiry, and the CA hierarchy including CA signing keys	Non-PKI cryptography such as symmetric at-rest keys, raw key-exchange groups, and token-signing keys held outside the certificate stores
Vendor attestation (inquiry)	The cryptography inside third-party products you can’t scan, gathered through structured questionnaires and roadmap statements	Proof, since the answers are documented rather than verified evidence, plus whatever a vendor doesn’t disclose or doesn’t know

Sources: NIST NCCoE, NIST SP 1800-38; CISA, “Strategy for Migrating to Automated Post-Quantum Cryptography,” September 2024, CISA discovery and inventory tools strategy. Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

The reason configuration extraction leads is that a network scanner observes only what a server negotiates under the conditions it’s probed, and that undercounts real exposure. A 2026 corpus study of production TLS found that 21.8% of TLS-enabled contexts still permitted TLS 1.0 or 1.1 as configured even though most would negotiate a modern version in a single probe, and 53.3% carried leaf-only certificate references that pass permissive clients but fail strict ones. A scan sees the negotiated version and walks past the permitted one, so the primary layer parses the config grammar of each termination point, normalizes it into one schema, and classifies every cipher suite by its constituent algorithms. The scan then rides on top as a runtime cross-check.

Source: Balaji et al., arXiv:2605.17955 (2026).

What does good discovery evidence look like?

Discovery is only as trustworthy as the evidence behind each finding, so every entry carries an evidence grade. The two grades separate what has been proven from what has merely been asserted:

1. Verified evidence (high confidence) comes from a technical artifact that independently proves the implementation exists and behaves as described: a TLS handshake capture showing the negotiated cipher suite, a certificate export showing the algorithm and key size, HSM audit logs, a packet capture.
2. Documented evidence (lower confidence) comes from a record that asserts an implementation without proving it: an architecture diagram, vendor documentation, a configuration standard, a self-reported survey. Documented evidence can be wrong, because systems don’t always run the way the paperwork claims.

A discovery pass built mostly on documented evidence is fine as a starting sketch and unreliable as a migration plan. High-risk findings get promoted to verified evidence before anyone sequences work against them, and documented-only entries get flagged and scheduled for confirmation. A frequent first task on an estate that “already did discovery” is re-verifying prior documented findings against real artifacts, because vendor attestation and diagrams age badly.

Where does cryptographic discovery fit in a migration?

Discovery is phase one, and everything downstream depends on it. The migration runs in a rough order, and discovery is what makes the rest possible:

1. Discover the cryptography and record it in a CBOM.
2. Prioritize the inventory by risk, which the risk models can only do once discovery has produced the systems, data classes, and control boundaries to score.
3. Make it swappable with crypto-agility, targeting the surfaces discovery surfaced as brittle.
4. Bridge safely with hybrid key exchange and the certificate bridges, rolled out to the endpoints discovery mapped.

The dependency is strict at the front. Mosca’s theorem needs a system that discovery has actually found, HNDL exposure needs the data class discovery records for each algorithm, and blast radius needs the dependency map discovery builds. That’s why teams that skip ahead to picking algorithms watch the work go nowhere: the plan has no estate to act on.

How does discovery feed a CBOM?

Each discovery method contributes fields to the CBOM entry for a given cryptographic asset. Configuration extraction and scanning supply the algorithm, parameters, purpose, and layer; certificate inventory supplies the certificate and CA-hierarchy detail; source analysis supplies the hardcoded and dependency-borne findings; and vendor attestation supplies the entries for surfaces you can’t reach directly. Discovery also supplies the two fields teams most often omit and most need:

1. Data class, the sensitivity and secrecy lifetime of what a finding protects, which drives HNDL exposure and is invisible to a scanner.
2. Control boundary, whether the surface is customer-managed, vendor-configurable, vendor-opaque, or hardcoded, which decides whether you or a vendor owns the migration timeline.

Because environments drift, discovery is continuous rather than a one-time sweep. An inventory produced once is stale within roughly six months as systems, algorithms, and vendor products change, so mature programs re-run discovery on a cadence (quarterly for high-risk systems, annually for low-risk ones) and treat the CBOM as a living document.

Who requires cryptographic discovery?

Cryptographic discovery has moved from best practice to mandate, most sharply in the U.S. federal space:

• OMB M-23-02 requires U.S. federal agencies to produce and maintain a cryptographic inventory as part of the quantum-migration program.
• The Quantum Computing Cybersecurity Preparedness Act (Public Law 117-260, codified at 6 U.S.C. 1526) directs federal agencies to inventory their cryptographic systems and prioritize migration.
• CISA, NSA, and NIST jointly urge every organization, especially critical-infrastructure operators, to begin with proactive cryptographic discovery and an inventory of quantum-vulnerable systems.
• NIST IR 8547 frames inventory as a prerequisite for migration planning.

Sources: OMB M-23-02; 6 U.S.C. 1526. CISA, NSA, NIST, “Quantum-Readiness: Migration to Post-Quantum Cryptography,” CISA factsheet.

Common misconceptions

• “A scan will find it all.” A network scan is one evidence layer, and a weak one alone. It sees what a server negotiates when probed and walks past permitted fallbacks, hardcoded primitives, at-rest keys, and everything vendor-opaque. Configuration extraction is the primary layer, and the scan cross-checks it.
• “Discovery and a CBOM are the same thing.” Discovery is the activity of finding cryptography; the CBOM is the record it produces. You run discovery to build a CBOM, and you keep running it to keep the CBOM current.
• “We finished discovery.” If the pass only covered internally-managed systems, the vendor-controlled surfaces, often most of the footprint, are still uncounted. And a completed sweep goes stale within months without a review cadence.
• “Our asset inventory covers it.” An asset inventory lists systems; cryptographic discovery finds the cryptography inside them. They’re different artifacts, and treating one as the other is the most common starting error.
• “Documentation is good enough.” A diagram or a vendor datasheet asserts an implementation; it doesn’t prove one. High-risk findings need verified evidence, because systems don’t always run the way the paperwork claims.

Questions people ask

How is cryptographic discovery different from a CBOM? Discovery is the process of finding cryptography across an environment; the CBOM is the structured inventory that captures what discovery finds. Discovery is the verb and the CBOM is the noun, and one produces the other.

Where do I start discovery? On your crown-jewel and highest-risk systems, not the whole estate at once. Pull their certificate inventories and configuration files first, because a scoped pass ships while a boil-the-ocean pass stalls before it produces anything usable.

Can one tool do it? No current tool provides complete coverage, which is why NIST’s own testbed ran multiple tools together. Production discovery combines configuration extraction, scanning, static and dependency analysis, certificate enumeration, and vendor inquiry, plus human review.

Do I need complete discovery before I start migrating? No. You need enough to prioritize, then you migrate the top risks while discovery continues in phases. Trying to inventory everything before acting is a common way to never ship anything.

Why do first passes miss so much cryptography? Because the highest-count surfaces are the hardest to see: vendor and SaaS products invisible to internal scans, firmware that’s hardcoded, and configurations that permit weak fallbacks a single probe never reveals. A pass that only surveys internally-managed systems undercounts the real footprint.

How often do I have to re-run discovery? Treat it as continuous. A practical cadence is quarterly for high-risk systems and annually for low-risk ones, because new systems, algorithm changes, and vendor updates make a one-time snapshot stale within roughly six months.

What about systems I can’t scan, like a SaaS vendor? You reach those through vendor attestation, structured questionnaires that document the cryptography inside a product. Treat the answers as documented evidence rather than proof, and verify the highest-risk ones against a real artifact where you can. See Vendor-Controlled Crypto Surfaces.

Is discovery legally required? For U.S. federal agencies, yes: OMB M-23-02 and the Quantum Computing Cybersecurity Preparedness Act both require a cryptographic inventory, which you can only produce through discovery. For everyone else it’s strongly recommended and increasingly arrives through vendor and procurement requirements.

---

Everything here is the map, given freely. When your team needs its cryptography discovered, graded by evidence, and turned into a defensible inventory against your actual environment, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.