You Can't Migrate What You Can't See PQC Discovery
Cryptographic Asset Discovery: Why PQC Migration Starts with Visibility
Before any building contractor can safely remove asbestos, they need a full survey of where it lives. Ripping out walls without knowing what’s behind them doesn’t solve the problem—it makes it worse. The same principle applies to post‑quantum cryptography migration. Cryptographic asset discovery — knowing exactly where cryptography exists across your environment, what algorithms are in use, and what depends on them — is the essential first step. Without it, no PQC migration programme can succeed.
For CISOs and security architects beginning to think seriously about post-quantum cryptography (PQC), the journey starts not with algorithm selection or vendor procurement. It starts with an honest, comprehensive inventory of the cryptographic estate you already have. This article explains why, and what good looks like in practice.
Why post‑quantum migration begins with cryptographic visibility
The quantum threat is no longer theoretical. Cryptographically relevant quantum computers capable of breaking RSA and elliptic‑curve cryptography are projected within the next decade. The UK’s NCSC published its three-phase migration roadmap in March 2025, setting deadlines at 2028, 2031 and 2035. DORA has been in force since January 2025. NIST’s post‑quantum standards (ML‑KEM, ML‑DSA and SLH‑DSA) were published in August 2024.
Compounding this urgency is the threat of “harvest now, decrypt later” attacks, where adversaries are already collecting encrypted data today, intending to decrypt it once quantum computers become capable. Any data that needs to remain confidential for five or more years carries real risk right now, underlining why the clock on PQC migration is already running.
The organisations that will navigate this transition most successfully are those that move first to establish cryptographic visibility across their estate. Not because visibility is the end goal, but because it is the pre‑requisite for everything else: risk assessment, migration planning, regulatory compliance and the crypto‑agility that regulators are increasingly requiring. You cannot plan a route if you don’t know where you are starting from.
Where cryptography hides inside modern infrastructure
Ask most organisations where their cryptography lives and you will receive either a blank look or an incomplete answer. The honest reality is that for most enterprises, cryptography has accumulated over decades across dozens of systems, teams and third‑party integrations, with no single team keeping a complete record.
According to industry estimates, a typical large UK financial institution may have more than 50,000 TLS/SSL certificates, over 10,000 applications with embedded cryptographic libraries, hundreds of Hardware Security Modules (HSMs) and hundreds of third‑party APIs—many of which have no cryptographic documentation at all. For financial services organisations this creates specific exposures under DORA and the broader quantum risk landscape facing banks and insurers. And that is before accounting for legacy systems quietly running in the background.
• Network infrastructure: TLS certificates on web servers, load balancers, firewalls and internal services
• Application layer: cryptographic libraries embedded in custom and commercial software, signing keys and token generation
• Identity and access management: PKI infrastructure, authentication tokens, digital signatures and certificate authorities
• Data storage: encryption at rest across databases, cloud storage and backup systems
• Hardware: HSMs, smart cards, embedded devices and IoT endpoints, some of which cannot be updated remotely and will require physical replacement
• Third-party and supply chain: SaaS platforms, APIs, partner integrations and managed services where cryptographic choices sit outside your direct control
• Cloud-native environments: containerised workloads, serverless functions, CI/CD pipelines and cloud key management services
This is not a tidy checklist. It is a sprawling, interdependent web in which the same algorithm may appear in dozens of different contexts, owned by different teams, with different sensitivity levels and different migration timelines. That complexity is precisely why a structured cryptographic inventory is necessary before any migration activity begins.
Why traditional asset inventories miss cryptography
Many organisations assume their existing asset‑management processes (such as CMDB, ITAM tools and vulnerability scanners) will provide the cryptographic visibility they need. They do not, for several important reasons.
Traditional asset inventories record what systems exist. They do not record which cryptographic algorithms those systems use, which certificates are embedded within them, which keys are in scope, or how one cryptographic asset depends on another. A CMDB will tell you that a server exists; it will not tell you that the server is running RSA‑2048 for key exchange, or that three downstream applications depend on the same certificate chain.
Vulnerability scanners are similarly constrained. They are designed to surface weaknesses in known configurations; not to conduct a comprehensive crypto‑asset discovery exercise across a complex estate. They scan what is reachable, miss what is embedded in application code or third‑party services, and rarely surface cryptographic dependencies at all.
The result is what practitioners increasingly call “shadow cryptography” — cryptographic assets that exist, are actively in use, and carry real quantum risk, but that nobody has formally catalogued. In most organisations, this represents the majority of the cryptographic estate.
This gap is also a regulatory compliance exposure. Under GDPR’s accountability principle, DORA’s cryptographic resilience requirements and NIS2’s expectations for critical infrastructure, organisations are expected to understand and manage their cryptographic posture. An undiscovered cryptographic asset is an unmanaged risk, and regulators are beginning to ask questions about PQC readiness that many organisations cannot yet answer.
This is why a PQC readiness assessment must begin with dedicated cryptography‑discovery tooling, not a repurposed spreadsheet or a manual audit that will be out of date before it is finished.
What a cryptographic asset discovery programme should include
Effective application cryptography discovery, sometimes formalised as a Cryptographic Bill of Materials (CBOM), goes well beyond listing certificates. A mature programme should deliver the following capabilities:
1. Algorithm-level visibility
Not just which systems use encryption, but which algorithms, key lengths and protocol versions are in use. RSA-2048 and RSA-4096 carry different risk profiles. TLS 1.2 and TLS 1.3 behave differently. SHA-1, still present in many older systems, is already considered cryptographically weak. Granularity at this level is what separates a useful cryptographic inventory from a superficial one.
2. Cryptographic dependency mapping
Understanding not just where cryptography exists, but what depends on it. If you replace a root certificate, which applications break? If a shared cryptographic library is updated, which services are affected? Cryptographic dependency mapping is essential for safe, sequenced migration, and one of the most commonly overlooked elements of the discovery process. Without it, well-intentioned migrations create outages.
3. Full estate coverage
Discovery must extend beyond the network perimeter. Cloud environments, SaaS platforms, CI/CD pipelines, code repositories, and third-party integrations all require coverage. Cryptography embedded in containerised workloads or serverless functions carries the same quantum risk as cryptography in a traditional data centre, and is far easier to miss.
4. Continuous, not point-in-time
A one-time audit produces a snapshot that is immediately out of date. New certificates are issued. New applications are deployed. New third-party services are onboarded. Effective cryptographic visibility is continuous; maintaining a live, updated view of the cryptographic estate rather than a stale report that is obsolete by the time it reaches the board.
5. Risk classification and prioritisation
Discovery alone is not enough. The output must feed directly into risk assessment — identifying which cryptographic assets are most exposed to the quantum threat, which protect the most sensitive long-lived data, and which carry the greatest regulatory exposure. This is what transforms a raw cryptographic inventory into a structured PQC migration strategy. For organisations in regulated sectors such as financial services, this prioritisation also needs to account for implementation sequencing under DORA and the NCSC’s phased deadlines.
Turning discovery into crypto‑agility: what comes next
The end goal of cryptographic asset discovery is not a spreadsheet. It is the foundation from which everything else in the PQC migration programme flows, including the crypto‑agility that regulators are now explicitly requiring.
Crypto‑agility — the ability to swap cryptographic algorithms quickly and safely as standards evolve — is impossible to build without first knowing what you have. DORA’s Article 6 mandates the ability to “update or change cryptographic technology based on developments in cryptanalysis.” The NCSC’s guidance reinforces the same principle. But an organisation cannot demonstrate algorithm independence or rapid switchover capability if it has never mapped the cryptographic estate it is trying to make agile.
What cryptography‑discovery tools need to deliver, in practical terms, is a continuously updated, dependency‑aware picture of the cryptographic estate that can be used to plan and sequence migration safely. That means understanding which systems can be updated by vendor patch, which require custom development, and which, particularly in hardware, will require physical replacement and a longer lead time.
This is the operational challenge that Venari’s Adaptive Cryptographic Intelligence Platform is designed to address. It provides continuous cryptographic visibility across the full enterprise estate — mapping algorithms, certificates, keys and dependencies in real time — and translates that visibility into a risk‑prioritised, NCSC‑aligned migration plan. For security teams under pressure to demonstrate PQC readiness to boards, regulators and auditors, it replaces static point‑in‑time audits with defensible, live assurance.
The bottom line
The NCSC’s Phase‑1 deadline — cryptographic inventory and migration planning complete — is 2028. For organisations with complex, distributed estates, that timeline is already tighter than it appears.
The organisations that navigate PQC migration successfully will not necessarily be those with the largest budgets or the biggest security teams. They will be the ones that establish comprehensive cryptographic asset discovery early, because without that foundation, no migration programme, however well‑resourced, can proceed with confidence.
You cannot migrate what you cannot see.
Common questions
What is cryptographic asset discovery?
Cryptographic asset discovery is the process of systematically identifying every instance of cryptography in use across an organisation’s estate — including algorithms, certificates, keys, cryptographic libraries and the dependencies between them. It goes beyond traditional asset inventories, which record what systems exist but not what cryptographic algorithms those systems use or what depends on them. The output is typically a Cryptographic Bill of Materials (CBOM): a structured, continuously maintained record of the full cryptographic estate.
Why is cryptographic discovery the first step in PQC migration? Can’t we just start replacing algorithms?
Not safely. Cryptography is deeply embedded and interdependent across modern infrastructure. Replacing an algorithm without understanding what depends on it is how well‑intentioned migrations cause outages. Before any migration activity can be sequenced, risk‑prioritised or costed, organisations need to know what algorithms are in use, where they live, and what breaks if they change. Discovery is not a preparatory step — it is the foundation the entire migration programme is built on.
What should a cryptographic inventory include?
A comprehensive cryptographic inventory should capture TLS/SSL certificates (including issuing authority, key size, expiry and renewal process); cryptographic libraries and APIs embedded in applications; Hardware Security Modules (HSMs) and their firmware versions; PKI infrastructure and authentication systems; encrypted data stores with associated data sensitivity and retention periods; network infrastructure performing cryptographic operations; and third‑party and supply‑chain dependencies. Critically, it should also map dependencies — which systems and applications rely on each cryptographic asset — so migration can be sequenced without breaking services.
How do I know if my organisation is ready to begin PQC migration?
Ask whether your organisation can answer three questions: Do you know every algorithm in use across your estate and its key length? Do you know what depends on each cryptographic asset? And do you know which assets protect data that needs to remain confidential beyond 2030? If the answer to any of these is “no” or “partially”, your organisation is not yet ready to migrate, but it is ready to begin discovery. A structured PQC readiness assessment will surface the gaps and provide the baseline from which a migration roadmap can be built.
Related Content
Why organisations are delaying post-quantum cryptography migration (and how to fix it)
Banks are not delaying post-quantum cryptography migration because they don’t understand the threat. They are delaying it because…
NCSC Guidance on Post-Quantum Cryptography (PQC) What UK and EU Organisations Need to Know Now
Key Takeaways Timeline: NCSC three-phase roadmap (2028, 2031, 2035 deadlines) for UK/EU PQC standards migration For: CISOs, IT…