Your team just finished deploying automated CBOM discovery tools across the enterprise. The dashboard shows 3,200 cryptographic implementations cataloged, tagged, and ready for your post-quantum migration roadmap. You present the findings to leadership. Six months later, during the actual migration, you discover entire payment processing systems that never appeared in the scan.
This isn't a hypothetical failure mode. It's a pattern cryptography consultant Matous Vambersky sees repeatedly: organizations discover major gaps in their cryptographic asset inventory only after they automate discovery and start treating the output as complete.
The Challenge
The core problem isn't that automated tools fail to find anything. It's that they create what Vambersky calls "a false feeling of safety, this false feeling of visibility." Your scanning tools catalog thousands of assets successfully, which makes the results feel comprehensive. Leadership sees a number. Auditors see documentation. The migration team builds a roadmap.
But legacy systems, operational technology, and custom-built implementations often sit outside the reach of automated scanners. For a bank information security officer, this means your most critical blind spots exist in precisely the environments you can't afford to miss: the mainframe handling card authorization, the custom HSM integration your payment team built in 2009, the operational technology managing physical security for branch ATMs.
Regulatory pressure compounds the risk. DORA and U.S. executive orders are pushing organizations toward comprehensive CBOMs. When your regulator asks for cryptographic inventory coverage, "we scanned what the tools could reach" isn't an acceptable answer. You're accountable for the assets the scanner missed, not just the ones it found.
Environment and Constraints
Consider the constraints a typical bank information security team faces when building a cryptographic inventory:
You're operating across decades of technology layers. Your customer-facing mobile app uses modern TLS 1.3 with ephemeral key exchange. Your core banking system runs on a mainframe where the cryptographic implementations were written before FIPS 140-3 existed as a standard. Your branch network includes operational technology that processes PIN verification locally, with custom cryptographic modules that predate your current vendor relationships.
Automated scanners excel at cataloging what speaks standard protocols over network interfaces. They struggle with:
- Embedded cryptography in compiled binaries where the implementation isn't exposed through APIs
- Hardware security modules with vendor-specific interfaces that don't respond to standard discovery queries
- Operational technology that sits on isolated networks without the agent infrastructure your scanning tools require
- Custom implementations where your team built cryptographic functions directly into application code without using standard libraries
You're also constrained by what you can scan without disrupting operations. Your card authorization system processes transactions 24/7. You can't install discovery agents that might interfere with sub-second response time requirements. Your ATM network operates on networks where introducing new scanning traffic creates compliance questions about segmentation.
A Practical Approach
Vambersky's guidance centers on treating automation as the foundation, not the complete solution. "Automation gives you the scale, but then you need to put in your expert insights into what makes sense to migrate."
The practical approach requires three parallel tracks:
Start with external-facing assets and data in transit. These systems are both easier to scan automatically and higher priority for migration. Your TLS endpoints, API gateways, and payment processing interfaces are accessible to automated tools and represent your most exposed cryptographic attack surface. If you're a bank preparing for post-quantum cryptography migration, these are the assets that will face quantum-capable adversaries first.
Build a standardized format for merging inventories. When automated tools catalog 3,200 assets and manual discovery adds another 800, you need a consistent schema for combining them. A standardized CBOM format lets you merge findings from network scanners, code analysis tools, and manual documentation without losing critical attributes like key lengths, algorithm suites, or certificate expiration timelines.
Maintain continuous discovery, not point-in-time snapshots. Vambersky emphasizes that "the challenge isn't generating some inventory document. The challenge is the continuous discovery, the ability to maintain the cryptographic inventory up to date." Your development teams deploy new services. Your infrastructure team migrates workloads. Your payment operations team integrates a new acquiring bank connection. Each change potentially introduces new cryptographic implementations that won't appear in last quarter's scan results.
Lessons Learned
The recurring lesson from organizations that discover mid-migration that entire systems were left out: document your known blind spots explicitly.
If you know your mainframe cryptography isn't visible to automated scanners, document that gap in your CBOM report. If your operational technology network doesn't allow agent-based discovery, document which systems are excluded and why. If your custom HSM integration uses proprietary interfaces that standard tools can't query, document the manual verification process you're using instead.
Vambersky frames this as risk management: "If you know where the blind spots are, you can prepare for it." The alternative is treating an incomplete inventory as complete and building a migration roadmap that underestimates the scope by 40%.
The other change: involve your architects and senior engineers in validating automated findings before you finalize the inventory. They know which payment systems have custom cryptographic implementations. They remember the branch office project from 2011 that embedded encryption in ways your current scanning tools won't detect. Their expert insights identify the gaps automation creates.
Takeaways for Your Team
If you're building or validating a cryptographic inventory right now:
Treat your first automated scan as a draft, not a deliverable. Schedule review sessions with the teams who built and operate your payment systems, card processing infrastructure, and authentication services. Ask them specifically: "What cryptographic implementations exist in your environment that wouldn't respond to a network scanner?"
Prioritize external-facing assets for both automation and migration. Your TLS configurations, API authentication, and payment processing endpoints are easier to discover automatically and represent higher risk if you miss them. Start there.
Document exclusions explicitly in your CBOM. If regulatory frameworks like DORA require comprehensive cryptographic inventories, your documentation should state clearly which systems are covered by automated discovery, which require manual verification, and which represent known gaps you're addressing through other controls.
Build continuous discovery into your change management process. When your team deploys a new payment integration or migrates a card processing workload, cryptographic inventory updates should be part of the deployment checklist, not a quarterly scanning exercise.
The false sense of security isn't that automation finds nothing. It's that automation finds enough to make the results look complete. Your job is to know the difference between "we scanned everything the tools could reach" and "we have visibility into all cryptographic assets that matter for our risk profile."
