Quantum Computing: You Can’t Protect What You Can’t Find
A Practical Guide to Cryptographic Discovery
The first step in quantum readiness is knowing where your cryptography actually lives
In my previous piece on Harvest Now, Decrypt Later, I argued that senior leadership need to own the quantum cryptography conversation. Mosca’s Theorem gives us a clear framework: if the time your data needs protection plus your migration timeline exceeds the arrival of Q-Day, you’re already exposed.
The response I received was telling. Most readers agreed with the urgency. But the question that came back repeatedly was disarmingly simple: “Where do we actually start?”
The answer is equally simple, and brutally difficult: you start by finding out where cryptography lives in your organisation. All of it.
This is the cryptographic inventory—the foundation upon which every quantum readiness initiative must be built. Without it, you’re not doing post-quantum migration. You’re doing post-quantum guesswork.
Why This Is Harder Than It Sounds
Most organisations dramatically underestimate the scope of cryptographic discovery. When I ask security teams where their cryptography is, I typically get confident answers: TLS certificates, VPN configurations, maybe some database encryption. These are the visible tips of an enormous iceberg.
The reality is that cryptography has become so embedded in modern enterprise architecture that it’s effectively invisible. It’s in places your security team doesn’t manage, in systems your IT department didn’t build, and in dependencies your developers never consciously chose.
Consider a typical enterprise application. The code itself might use explicit encryption libraries. But it also inherits cryptography from the framework it’s built on, the runtime environment it executes in, the container it’s packaged in, the orchestration platform that deploys it, the service mesh that routes its traffic, the API gateway that exposes it, and the cloud platform that hosts it. Each layer brings its own cryptographic implementations, configurations, and vulnerabilities.
Multiply this by hundreds or thousands of applications, add in legacy systems, third-party integrations, IoT devices, and shadow IT, and you begin to appreciate the scale of the problem.
The Five Domains of Cryptographic Discovery
Through numerous discovery exercises, I’ve found it useful to think about cryptographic inventory across five distinct domains. Each requires different tools, different expertise, and different stakeholders.
Domain 1: Network and Transport Layer
This is where most organisations start, and for good reason—it’s the most visible. TLS/SSL certificates protecting web applications, API endpoints, and internal services. IPsec configurations for VPNs and site-to-site connections. SSH keys for administrative access. Load balancer and reverse proxy configurations.
The tools here are relatively mature. Certificate discovery scanners can enumerate your external attack surface. Internal network scanning can identify services using deprecated protocols or weak cipher suites. Most organisations have some visibility here, even if it’s incomplete.
But “some visibility” isn’t enough for quantum readiness. You need comprehensive coverage, including certificates issued by internal CAs, self-signed certificates in development environments, and machine identities that nobody remembers creating. The certificate you forgot about is the one that will still be using RSA-2048 when Q-Day arrives.
Domain 2: Application Layer
This is where discovery becomes significantly more complex. Applications use cryptography in ways that don’t traverse the network—encrypting data at rest, hashing passwords, generating signatures, protecting secrets in memory.
Discovery here requires a combination of approaches. Static code analysis can identify cryptographic library usage and flag deprecated algorithms. Software composition analysis reveals cryptographic dependencies in third-party components. Runtime analysis can detect cryptographic operations that static analysis misses—dynamically loaded libraries, reflection-based invocations, and configuration-driven algorithm selection.
The challenge is coverage. Most organisations have hundreds of applications, many without source code access (vendor packages, legacy systems, acquired companies). You’ll need to accept that application-layer discovery will be iterative and incomplete, prioritising based on data sensitivity.
Domain 3: Data Layer
Databases, file systems, backup systems, archives—anywhere data persists, cryptography may be protecting it. Transparent Data Encryption in your SQL Server instances. Encrypted columns in application databases. Encrypted backups sitting in cold storage. File-level encryption on endpoints.
This domain intersects directly with your data classification efforts. Remember Mosca’s X variable—how long does this data need to remain confidential? Your most sensitive, longest-lived data should be prioritised for quantum-safe migration. But first, you need to know how it’s currently protected.
Don’t forget data in transit between systems. ETL pipelines, replication streams, backup transfers—all may use cryptographic protection that needs to be catalogued.
Domain 4: Identity and Access Management
This is my home territory, and I can tell you it’s a minefield for cryptographic discovery. Identity systems are among the most cryptographically complex components in any enterprise, and among the hardest to migrate.
Consider what’s involved: certificate-based authentication for users and devices, Kerberos encryption in Active Directory environments, SAML and OAuth token signing, smart card and hardware token integrations, federation trust relationships with partners and cloud providers. Each of these involves cryptographic keys, algorithms, and protocols that need to be inventoried.
The interdependencies make this particularly challenging. Your identity provider’s signing keys are trusted by dozens of service providers. Your Active Directory’s Kerberos implementation touches every domain-joined system. Changing cryptography in identity systems isn’t just a technical migration—it’s an exercise in coordinating trust relationships across your entire ecosystem.
Domain 5: Hardware and Embedded Systems
The most overlooked domain, and often the hardest to address. Hardware Security Modules storing your most sensitive keys. Trusted Platform Modules in endpoints. Cryptographic implementations in network appliances, IoT devices, industrial control systems, building management systems.
Many of these systems have cryptography baked into firmware that can’t be easily updated. Some have cryptographic implementations that predate current best practices. And some are connected to operational technology environments where the very concept of “patching” is fraught with safety implications.
This domain requires close collaboration with operational technology teams, facilities management, and procurement. You need to understand not just what cryptography is in use today, but what the upgrade path looks like—and whether one exists at all.
Building Your Discovery Programme
Cryptographic inventory isn’t a project with a completion date. It’s an ongoing programme that needs to be embedded in your security operations. Here’s how to structure it:
Start with what you know. Don’t let the perfect be the enemy of the good. Begin with your certificate management system, your PKI infrastructure, your known encryption implementations. Build initial inventory from existing documentation, even if incomplete.
Layer in automated discovery. Deploy network scanning for certificate enumeration. Integrate software composition analysis into your CI/CD pipelines. Use cloud security posture management tools that identify cryptographic configurations in your cloud environments.
Engage application teams. Automated tools will only get you so far. Application owners know their systems better than any scanner. Create a structured questionnaire and work through your application portfolio systematically. Yes, this takes time. There’s no shortcut.
Don’t forget third parties. Your supply chain uses cryptography to protect data you’ve entrusted to them. SaaS providers, cloud platforms, managed service providers—all should be able to articulate their cryptographic posture and their quantum readiness roadmap. Add this to your vendor risk assessments.
Maintain continuously. New applications deploy. Configurations change. Certificates rotate (or don’t, which is its own problem). Your cryptographic inventory needs to be treated as a living document, updated through integration with change management processes and continuous discovery scanning.
Structuring the Output
A cryptographic inventory that lives in a spreadsheet and never gets used is worse than useless—it provides false confidence. The output of your discovery programme needs to be structured for action.
At minimum, each cryptographic asset should be catalogued with: the system or application it belongs to, the algorithm and key length in use, the data or function it protects, the sensitivity classification of that data, the Mosca X value (how long the data needs protection), the asset owner, and the feasibility of migration.
This allows you to prioritise. High-sensitivity data with long protection requirements, protected by vulnerable algorithms, in systems that can be migrated—these are your first targets. Low-sensitivity data in systems that will be decommissioned before Q-Day can wait.
The Uncomfortable Discoveries
I’ll warn you now: cryptographic discovery surfaces uncomfortable truths. You’ll find systems using MD5 for integrity checks. You’ll find certificates that expired years ago but somehow still work. You’ll find SSH keys that were generated in 2009 and have never been rotated. You’ll find encryption implementations where nobody knows who holds the keys.
This is normal. Every organisation I’ve worked with has cryptographic skeletons in the closet. The purpose of discovery isn’t to achieve some platonic ideal of cryptographic hygiene—it’s to understand your actual posture so you can make informed decisions about risk and prioritisation.
Don’t let the scale of the problem paralyse you. Document what you find, prioritise ruthlessly based on data sensitivity and exposure, and start the migration where it matters most.
What Comes Next
Cryptographic inventory is the foundation, not the destination. With a clear picture of where cryptography lives in your organisation, you can begin the harder work: developing crypto-agility so you can swap algorithms without rebuilding systems, testing NIST’s post-quantum standards in your environment, and building the business case for the multi-year migration programme that lies ahead.
In my next piece, I’ll explore what crypto-agility actually looks like in practice—particularly in identity systems, where the interdependencies make migration uniquely challenging.
For now, start finding your cryptography. All of it. The inventory you build today is the roadmap you’ll follow when Q-Day arrives.