Your automated scanners just cataloged 847 cryptographic assets across your environment. Your compliance dashboard shows green. Your CBOM submission is ready for review.
You're missing half your crypto inventory.
The problem isn't your tooling; it's assuming automation equals completeness. Legacy systems with custom TLS implementations, operational technology with hardcoded certificates, and that air-gapped development environment nobody documented don't show up in automated scans. They won't appear in your CBOM. When DORA enforcement hits or your next DoD contract requires cryptographic inventory attestation, those gaps become audit findings.
Here's how to build a cryptographic discovery program that catches what automation misses.
The Problem: Automation Creates Confidence Without Coverage
Organizations often discover major gaps in cryptographic inventory once they automate discovery. Legacy systems, operational technology, and custom-built implementations often sit outside the reach of automated scanners. You end up with a false sense of coverage, a CBOM that looks complete but leaves entire system categories undocumented.
This matters because regulatory pressure is accelerating. DORA requires financial institutions to maintain cryptographic inventories as part of ICT risk management. U.S. executive orders are pushing federal agencies and contractors toward structured cryptographic asset tracking. If you can't produce a complete CBOM during an assessment, you're not just facing a documentation gap, you're showing you don't know what cryptographic controls protect your CUI or federal data.
What You Need Before Starting
Before you run a single scanner, establish these foundations:
System categorization framework: Document every system that processes, stores, or transmits data subject to regulatory controls. Include legacy applications, OT environments, embedded systems, and air-gapped networks. If it touches CUI or federal data, it's in scope.
Risk tolerance boundaries: Define what "complete enough" means for your program. A 95% coverage target with documented exclusions beats a 100% claim you can't defend.
Cross-functional access: You need credentials and cooperation from application owners, OT teams, network engineering, and development groups. Cryptographic discovery isn't an infosec solo project.
Tooling baseline: Select at least one automated discovery tool (open-source options include testssl.sh for external TLS scanning, SSLyze for protocol analysis, and custom scripts using OpenSSL). Commercial CBOM platforms provide broader coverage but won't eliminate manual work.
Documentation repository: Set up a structured location for cryptographic inventory data, not just the output files from scanners, but the context around what each asset does, who owns it, and why it exists.
Step-by-Step Implementation
Phase 1: Automate the obvious
Start with external-facing assets and data in transit, the systems your automated tools can actually reach.
Run TLS/SSL scanners against all external endpoints. For each discovered certificate, document the issuing CA, expiration date, key length, and cipher suites in use. Cross-reference against your asset inventory to identify certificates protecting undocumented services.
Scan internal network traffic for cryptographic protocols. Use packet capture tools filtered for SSL/TLS handshakes, SSH connections, and IPsec tunnels. Don't just catalog what you find; map each cryptographic session back to a business process or data flow.
Query certificate stores on servers, workstations, and mobile devices. Extract installed certificates, identify their purpose (code signing, authentication, encryption), and flag any that don't match your PKI policy.
Phase 2: Document the gaps automation can't reach
Schedule interviews with system owners for legacy applications, OT environments, and custom-built platforms. Ask specific questions:
- What cryptographic libraries does this system use?
- Where are certificates and keys stored?
- How are cryptographic operations initiated and logged?
- When was the last cryptographic component update?
For air-gapped systems, arrange on-site access or request configuration exports. You're looking for hardcoded keys, embedded certificates, and cryptographic parameters buried in configuration files.
Review source code repositories for custom cryptographic implementations. Search for imports of crypto libraries, hardcoded initialization vectors, and deprecated algorithm calls. Flag any implementation that doesn't use FIPS 140-2 validated modules if you're subject to federal cryptographic requirements.
Phase 3: Merge and deduplicate
Combine automated scan results with manual discovery data into a single inventory. Use a standardized CBOM format, CycloneDX and SPDX both support cryptographic asset documentation and make it easier to merge inventories from different tools.
Deduplicate entries where the same certificate or key appears in multiple scans. Retain the most complete metadata record for each unique cryptographic asset.
Tag each entry with risk context: Is this asset protecting CUI? Does it face the internet? Is it subject to NIST SP 800-171 requirements? Will it need post-quantum migration?
Validation: How to Verify It Works
Your CBOM is complete when you can answer these questions with documentation:
- Can you trace every cryptographic asset back to a specific system or data flow?
- Do you have owner contact information for every certificate and key?
- Can you identify which assets would fail if a specific CA were compromised?
- Do you know which systems would break if you disabled TLS 1.0 or 1.1?
Run a tabletop exercise: pick a cryptographic vulnerability (expired root CA, deprecated cipher suite, quantum threat to RSA-2048) and walk through your CBOM to identify affected systems. If you can't complete the exercise without discovering undocumented assets, your inventory isn't ready.
Test your automation cadence by comparing this week's scan results against last week's. New certificates should appear when services launch. Expired certificates should trigger alerts before they cause outages.
Maintenance: Ongoing Tasks
Cryptographic inventory isn't a one-time deliverable, it's continuous discovery.
Weekly: Run automated scans against external endpoints and high-value internal systems. Alert on new certificates, expiring credentials, and deprecated protocols.
Monthly: Review manual discovery logs for changes to legacy systems and OT environments. Interview system owners about planned cryptographic changes.
Quarterly: Validate CBOM completeness by cross-referencing against your asset inventory. Any new system that processes regulated data needs cryptographic documentation.
Annually: Reassess risk tolerance and coverage targets. As post-quantum cryptography standards mature and regulatory requirements evolve, your "complete enough" threshold will shift.
Automation gives you the scale, but you need to add expert insights into what makes sense to migrate, what risks you're accepting, and where your blind spots remain. The biggest risk isn't the gaps themselves; it's the false feeling of safety when you don't know where they are.
