Unit 3 · Level 2 → Level 3 · Inventory, CBOM & Crypto Agility
Discovery Tooling —
How Organizations Find Their Crypto
You know what a CBOM is, what it contains, and how to read it. The question this lesson answers is: how do you actually build one? Discovery tooling automates the hardest part, finding cryptographic assets you didn't know existed.
Part 1
Why Manual Discovery Fails at Scale
At the end of Lesson 3.2, you saw the Meridian Agency CBOM, seven assets, one fictional 48-person marketing agency. That was straightforward to produce manually because the organization was small and its technology stack was simple and well-defined.
Now consider a company with 500 employees, 40 SaaS applications, three cloud environments, an on-premise data center, a fleet of networked devices, and 12 years of legacy software. How many cryptographic assets does that organization have? The honest answer is: nobody knows until they look. And looking manually, asking each system owner, reading every config file, chasing every TLS handshake, is not a viable approach at that scale.
This is why discovery tooling exists. These tools automate the process of finding cryptographic assets across an organization's environment, scanning networks, inspecting code, analyzing protocols, and parsing certificates, then produce structured output that can be directly imported into a CBOM.
⚠ Scope Reminder
This lesson is awareness of what discovery tooling does, not a technical implementation guide. By the end of this lesson, you will understand what categories of tools exist, what each does, what output it produces, and how to choose an approach for your organization. You will not need to run any of these tools yourself to complete the course or the Unit 3 deliverable.
Part 2
The Four Phases of a Discovery Engagement
A cryptographic discovery engagement, whether done manually, with tools, or by a vendor, follows a consistent four-phase structure. Understanding the phases helps you know what to ask for and how to evaluate what you receive. Click each phase to see what it involves.
Phase 1 — Scope & Asset Inventory
Before any scanning begins, the discovery team or tool defines the scope: which networks, which applications, which cloud environments, and which endpoints are in scope. This phase produces a rough asset inventory, the known systems, that feeds into Phase 2.
What this involves:
- Listing all known systems, applications, and services (from CMDB, cloud asset inventories, network diagrams)
- Identifying which environments are in scope (production only? dev/staging too?)
- Establishing access permissions for scanning tools
- Defining what "complete" looks like, which gaps are acceptable
Common gap: Undocumented systems, shadow IT, forgotten VMs, deprecated services still running, are not in the initial scope list. Phase 2 scanning often finds them anyway if the network is scanned broadly.
Phase 2 — Active Discovery
Tooling actively scans the environment to find cryptographic assets. This is where the automation pays off, tools can process thousands of endpoints in hours, inspecting TLS handshakes, parsing certificate chains, analyzing source code, and reading configuration files.
What tools do in this phase:
- Network scanners probe open ports and capture TLS negotiation parameters, certificate details, cipher suites, protocol version
- Code scanners parse source code repositories looking for cryptographic API calls, hardcoded keys, and algorithm references
- Certificate scanners query internal CAs and certificate management platforms to enumerate all issued certificates and their algorithms
- Agent-based tools deploy lightweight agents on endpoints to capture runtime cryptographic operations, including ones that don't appear in static analysis
Why this matters: Phase 2 always finds assets that Phase 1 missed. This is the most common reason CBOMs built from Phase 1 alone are incomplete, and why tooling is necessary for any organization above a small scale.
Phase 3 — Classification & Risk Scoring
Once raw discovery data is collected, the tooling (or an analyst) classifies each asset. Classification maps directly to the CBOM fields from Lesson 3.2: algorithm, key size, quantum security level, vulnerability status, and priority tier.
What good classification looks like:
- Each algorithm is assessed against NIST's quantum vulnerability categories (Shor's / Grover's / not affected)
- Certificates are assessed for both algorithm vulnerability and expiry timeline, a cert expiring in 30 days gets elevated priority regardless of algorithm
- Assets are tagged by system owner and business criticality where that data is available from the asset inventory
- Dependencies are mapped, which assets depend on which other assets (the relatedCryptoMaterialRefs logic from Lesson 3.2)
Human review: No tool gets classification right 100% of the time. Phase 3 always includes a human review step for any edge cases, unusual algorithms, third-party library results that don't map cleanly to standard identifiers, or assets in unusual deployment configurations.
Phase 4 — CBOM Output & Reporting
The discovery engagement produces a CBOM as its primary deliverable. Most enterprise discovery tools produce CycloneDX 1.6 JSON or XML output directly. They also typically produce a human-readable report and a prioritized remediation list.
What the CBOM output includes:
- A complete CycloneDX CBOM document with one entry per cryptographic asset
- A summary table (similar to the Meridian table from Lesson 3.2) for stakeholder review
- A prioritized remediation list sorted by risk tier and agility score
- An executive summary with key metrics: total assets found, percentage quantum-vulnerable, and estimated migration complexity
What to check: Verify that the output includes the five mandatory CBOM fields: asset name, algorithm, vulnerability status, proposed replacement, and priority tier. A report without structured CBOM output is not a substitute for a CBOM, it is an audit finding, not an inventory.
Part 3
The Tool Landscape — What Exists and What It Does
Discovery tools fall into four categories based on how they find cryptographic assets. Most organizations use a combination. Click any tool card to expand its details.
How they work: Connect to every reachable host on specified ports and inspect the TLS handshake, capturing the certificate chain, negotiated cipher suite, protocol version, and key exchange algorithm. Some also perform passive network capture (listening to traffic rather than initiating connections).
What they find: Web server certificates, load balancer TLS configs, internal service TLS, expired or soon-to-expire certificates, deprecated protocol versions (TLS 1.0/1.1), weak cipher suites.
What they miss: Certificates not exposed on network ports (code signing certs, email signing certs, internal CA certs stored in files), application-layer cryptography not visible in TLS.
How they work: Parse source code repositories (or decompile binaries) to find cryptographic API calls, algorithm identifiers, key sizes, and hardcoded cryptographic material. They understand the APIs of major crypto libraries (OpenSSL, Bouncy Castle, Java JCE, .NET Cryptography) and flag uses of quantum-vulnerable algorithms.
What they find: Hardcoded algorithm choices in application code, uses of deprecated APIs (e.g., new RSACryptoServiceProvider(1024)), cryptographic library versions with known vulnerabilities, and, critically, cryptographic operations that never appear on a network interface.
What they miss: Runtime algorithm selection driven by configuration files (the algorithm isn't in the code, it's read at runtime). Network-level cryptography not implemented in application code.
How they work: Query the certificate authority (CA) database and any certificate lifecycle management (CLM) platform to enumerate every certificate the organization has ever issued or obtained, including ones not currently deployed on a network port. This is the authoritative source for certificate inventory.
What they find: Every certificate in the organization's PKI, including code signing certs, email certs (S/MIME), client authentication certs, internal service certs, and root/intermediate CA certificates. Also flags certificates with upcoming expiry, weak algorithms, and missing revocation endpoints.
What they miss: Certificates obtained outside the managed PKI (shadow IT certificates purchased directly, self-signed certificates not registered anywhere).
How they work: Combine network scanning, code analysis, certificate enumeration, and agent-based endpoint discovery into a single platform. Designed specifically for post-quantum migration planning, they classify all findings against NIST's quantum vulnerability framework and produce CycloneDX CBOM output directly.
What they find: The broadest coverage of any single tool category, network cryptography, application-layer cryptography, certificate inventory, and runtime cryptographic operations detected by agents. These platforms also typically include a migration workflow layer, not just discovery.
What they miss: Vendor-managed third-party systems (like Google Workspace TLS) where the organization has no inspection rights. Air-gapped or isolated networks not reachable by the scanner.
📌 No Single Tool Covers Everything
Every tool category has blind spots. A network scanner misses application-layer crypto. A code scanner misses runtime configuration. A certificate management platform misses shadow IT certificates. A mature discovery engagement uses at least two tool categories — typically a network scanner and either a code scanner or an integrated platform, and treats the combined output as the working CBOM draft before human review.
Part 4
What Discovery Output Looks Like
When a discovery tool completes its scan, it produces two forms of output: a machine-readable CycloneDX CBOM file, and a human-readable summary. Below is a representative sample of both, the kind of output you would receive from a network + code scanner run against a small organization.
Machine-readable output: CycloneDX 1.6 JSON (abbreviated):
Notice the occurrences field in Asset 2, the code scanner has pinpointed the exact source file and line number where the RSA algorithm is hardcoded. This is what makes code scanners so powerful for agility assessment: they tell you not just that an algorithm exists, but where in the codebase it lives and whether it is configurable or hardcoded.
Also notice that the AES-256 asset is included even though it is not vulnerable. The CBOM is a complete inventory, it documents what is safe as well as what needs to change.
Part 5
Three Approaches: DIY, Vendor-Assisted, Fully Managed
Organizations choose their discovery approach based on size, technical capacity, budget, and how quickly they need results. The three approaches below are not mutually exclusive, many organizations start with one and evolve to another.
Best for: Organizations with internal security engineering capability and time to invest. Typically mid-size organizations with a dedicated security team.
Run network/TLS scanners (testssl.sh, sslyze, or Qualys SSL Labs) against all known network endpoints. Export results as a CSV or JSON.
Run a code scanner (cbomkit-theia or Semgrep PQC ruleset) against source code repositories. Focus on cryptographic API calls and library imports.
Query your certificate management platform (AWS Certificate Manager, ADCS, Venafi if deployed) for a full certificate inventory. Export with algorithm and expiry data.
Merge and deduplicate the three outputs into a single CBOM draft. Apply the classification schema from Lesson 3.2. Human review for gaps and edge cases.
Produce the CBOM in the table format from Lesson 3.2 (or CycloneDX JSON if tooling supports it). This is your working migration inventory.
Typical time investment: 2–5 days for a 50-person organization; 2–4 weeks for 500+ people with multiple environments. The bottleneck is usually data merging and human review, not scanning.
Risk: Coverage gaps are more likely without integrated tooling. Agent-based runtime discovery is rarely done in DIY approaches, which means application-layer cryptography not visible on the network may be missed.
Best for: Organizations that want professional coverage assurance but have some internal technical capacity to run tools and interpret results. The most common approach for mid-market organizations.
Engage a vendor (IBM, Thales, Keyfactor, or a specialist PQC consultancy) for tooling and methodology. The vendor provides the integrated platform license and configuration support.
Internal team handles deployment: installing agents, granting network scan access, providing code repository access. Vendor handles tool configuration and output interpretation.
Vendor produces a draft CBOM from the tool output. Internal team reviews for accuracy against their knowledge of the environment, adds context the tools cannot see.
Joint output: Final CBOM document in CycloneDX format plus a prioritized remediation report. Organization retains ownership of the CBOM and continues to maintain it internally.
Typical time investment: 3–6 weeks for scoping, deployment, scanning, and review. Higher coverage than DIY; lower cost than fully managed.
Best for: Organizations with large, complex environments; limited internal security capacity; or regulatory pressure that requires defensible, third-party-validated CBOM evidence. Common in financial services, healthcare, and critical infrastructure.
Full engagement by a specialist firm — scoping, tooling, deployment, scanning, analysis, and CBOM production are all handled by the vendor. The organization provides access and business context.
Comprehensive coverage: Network scanning, code analysis, certificate inventory, agent-based runtime discovery, and interview-based discovery for vendor-managed systems all included.
Deliverable package: CycloneDX CBOM, executive summary, technical report, prioritized remediation roadmap, and agility assessment for each asset. Structured to be handed directly to a PKIMM assessor.
Ongoing monitoring option: Many fully managed engagements include a continuous monitoring component, the tool stays deployed and alerts when new cryptographic assets appear or existing ones change.
Typical time investment (org side): 2–3 weeks of access facilitation and review. The vendor carries the project. Cost is significantly higher than DIY, but the deliverable is audit-ready and defensible.
Part 6
What Discovery Cannot Find — The Gaps
No discovery engagement produces a perfectly complete CBOM. Understanding the standard gap categories helps you document limitations honestly and plan for residual risk. Every mature CBOM includes a "known gaps" section.
You cannot scan inside Google Workspace, Salesforce, or any SaaS platform you do not control. These systems use cryptography you have no visibility into directly. Mitigation: Request a cryptographic disclosure or security questionnaire from each SaaS provider. Major providers (Google, Microsoft, AWS) publish their PQC migration roadmaps publicly.
Operational technology networks (industrial control systems, SCADA, building management) are often isolated from IT networks by design. Network scanners cannot reach them. Mitigation: Physical or on-site agent deployment by authorized personnel. Requires a separate scoping engagement with OT network access.
Cryptography implemented in hardware (HSMs, smart cards, TPMs, IoT chips) may not be detectable by software scanners. The cryptographic algorithm is in firmware or silicon, not in accessible code or network traffic. Mitigation: Hardware inventory from procurement records, vendor documentation, and manual inspection. This is often the most time-consuming gap to close.
Legacy applications built with custom cryptographic implementations (not using standard libraries) may not be recognized by scanners looking for standard API patterns. Mitigation: Code review by a cryptography specialist. This is rare in modern systems but common in 10–20 year old enterprise applications.
📌 Document Your Gaps
A CBOM with a clearly documented "Known Gaps" section is stronger compliance evidence than one without, because it demonstrates that the organization understands the limits of its discovery and has a plan to close them. PKIMM assessors expect to see gap documentation; its absence raises questions about the completeness of the engagement.
Persona Perspectives
Discovery Tooling at Your Level
The discovery phase looks very different depending on your role and your organization's scale.
Persona A — The Motivated Learner
If you want hands-on experience with discovery tooling, the open-source tools in this lesson are freely available and worth experimenting with. testssl.sh is a shell script you can run against any public HTTPS endpoint, try it on your own domain or a test site and read the cipher suite output. IBM's cbomkit-theia is available on GitHub and can scan a container image or repository for cryptographic findings.
These are not production-grade engagements, they are skill-building exercises. The goal is to see what discovery output actually looks like so that the concept is concrete rather than abstract. When you sit down to complete the Mini CBOM Exercise, having seen real scanner output will make the exercise feel familiar.
For the job market: The ability to describe the discovery tooling landscape, what categories exist, what each finds, what a CycloneDX CBOM output looks like, is a differentiator in PQC consulting and PKI engineering interviews. Employers hiring for these roles in 2025–2026 are specifically looking for people who understand not just the algorithm standards but the operational migration workflow. This lesson is that knowledge.
Persona B — The SMB Decision-Maker
For a 48-person marketing agency like Meridian Creative Agency, a fully managed engagement is almost certainly overkill, and a DIY approach may be adequate, especially combined with the MSP prompt from Lesson 3.2. Here is the practical path for your scale:
Step 1: Use the MSP prompt from Lesson 3.2 to ask your IT vendor to run a network TLS scan and certificate inventory against your environment. This addresses the most visible cryptographic assets, web server certs, VPN configs, email certs.
Step 2: For any custom-developed software your organization uses or distributes, ask the developer (or development vendor) to run a code scanner. If you distribute a software tool to clients (as Meridian does), the code-signing certificate and any application-layer cryptography in that tool need to be in your CBOM.
Step 3: For SaaS tools (Google Workspace, your CRM, your invoicing platform), request the provider's security disclosure or check their published PQC roadmap. Add those as "vendor-managed" entries in your CBOM with a monitoring action rather than a direct migration action.
That three-step process is a complete discovery engagement at your scale. It will take an afternoon of your IT vendor's time and produce a CBOM that is ready for the Unit 3 exercise format.
Persona C — The IT Professional
For you, this lesson is primarily about tool selection and engagement design. The key decision is not which individual tool to use, most enterprise environments will use a combination, but how to structure the discovery engagement so that it produces a CBOM that is complete, auditable, and maintainable.
Tool recommendation by asset type: Start with your certificate management platform (Venafi, Keyfactor, ADCS reporting, or AWS ACM), this gives you the most complete certificate inventory in the shortest time. Then layer network scanning (sslyze or Qualys) for anything not in the CLM system. Then code scanning for any internally developed applications. Agent deployment (via an integrated platform like IBM Guardium) for high-value systems where runtime discovery matters.
On tooling integration: The most efficient setup is one where your CLM platform (certificate lifecycle management) already has CBOM export support. Most enterprise CLM platforms added CycloneDX export in 2024–2025. Check your current platform's release notes, you may already have the output capability without needing a separate tool.
On maintenance: A CBOM is a living document, not a one-time artifact. Build your discovery tooling into a continuous monitoring posture from the start, schedule quarterly rescans, set up alerts for new certificate issuance outside the managed PKI, and integrate CBOM updates into your change management process. An outdated CBOM is a liability, not an asset.
Comprehension Check
3 QuestionsQuestion 1 of 3
A code scanner flags an RSA-2048 algorithm call at src/auth/rsa_auth.c:47. What additional information does this finding provide beyond what a network TLS scanner would report for the same system?
Question 2 of 3
An organization completes a network TLS scan and certificate management platform export, and declares their CBOM complete. Which of the following asset types is most likely missing from their inventory?
Question 3 of 3
A PKIMM assessor reviewing an organization's CBOM notes that it has no "Known Gaps" section and covers only internally managed systems, with no reference to SaaS providers or vendor-managed infrastructure. How should the assessor interpret this?