A post-quantum migration roadmap can have an approved budget, an executive sponsor, and firm delivery dates, yet still rest on a dangerous assumption: that the organization knows what it needs to change. If nobody can explain where cryptography operates inside the application portfolio, those dates describe an ambition. They do not describe an executable plan.
The problem starts well below the dashboard. Encryption may sit inside application code, shared libraries, database connections, file transfers, identity services, or a vendor component nobody has examined in years. Different teams own different pieces, and each may reasonably believe another team has the complete picture.
This is the fourth post in our eight-part quantum readiness series. After examining exposure, standards, and obligations, we now reach the work that makes a credible response possible: discovering what actually runs, what it protects, and what must change together.
The Asset Register Does Not Answer the Question
An application inventory might identify the finance system, its servers, and its support vendor. A certificate inventory might identify expiration dates and issuing authorities. A software bill of materials might identify installed components. Each provides useful evidence, but none automatically explains how the application establishes trust or protects information throughout a business process.
Consider a legacy claims application. Its public connection uses TLS, an internal service validates signed identity tokens, and a nightly job encrypts files for an external administrator. Updating the web gateway addresses one boundary. It leaves the token verification, file protection, and administrator’s ability to accept a changed format unresolved.
That distinction drives scope. NIST’s National Cybersecurity Center of Excellence explicitly connects cryptographic discovery with understanding where and how cryptography protects data and systems, then using that inventory to support migration priorities. Discovery provides the evidence the roadmap depends on.
Why the Map Is Missing
Organizations accumulated cryptographic decisions over decades, usually while delivering something else. A developer added a library to meet an integration requirement. An infrastructure team configured a secure connection. A supplier embedded cryptography in a product. An acquisition brought in applications with different standards and incomplete records.
The resulting knowledge follows organizational boundaries rather than application behavior. Security may understand certificate policy, operations may manage keys, and developers may understand individual calls. Nobody necessarily connects those facts to the customer transaction that depends on all three.
Documentation creates another gap. Architecture diagrams describe the intended design, while production configuration, emergency fixes, and library upgrades determine actual behavior. A retired engineer may have understood the exception that never made it into the diagram. The system still works, so the missing knowledge remains invisible until someone tries to change it.
A reliable map therefore requires evidence from the running estate. Asking application owners to complete a spreadsheet can start the work, but you need to verify their answers.
Inventory the Function, Not Just the Algorithm
The title refers to encryption, but the inventory must cover cryptography more broadly. Digital signatures, authentication, certificate validation, and key establishment also determine whether systems can trust each other. Missing these functions can leave a migration incomplete even when data encryption appears covered.
The distinction also prevents wasted effort. Quantum risk does not make every cryptographic mechanism equally vulnerable. RSA and elliptic-curve public-key schemes require particular attention; symmetric encryption such as AES presents a different assessment. An AES-encrypted file may still depend on a vulnerable public-key mechanism to protect or exchange its encryption key.
For each cryptographic use, record its location, purpose, algorithm and parameters, library or provider version, and active configuration. Link it to the application, protected data, business owner, technical owner, and systems that must interoperate with it. Include key and certificate references, lifecycle responsibilities, and vendor support constraints, without copying secret key material into the inventory.
The decision becomes concrete: can this dependency move through configuration, a supported upgrade, a code change, or replacement? An algorithm name alone cannot answer that.
No Single Discovery Method Sees Everything
Network inspection can reveal negotiated protocols and certificates on observed connections. It cannot establish everything an application does internally, and a short observation window may miss a monthly batch job or a rarely used recovery path.
Source analysis can locate cryptographic calls, embedded assumptions, and dependencies. It does not prove that every discovered path executes in production, or that production runs the same version. Configuration inspection, runtime evidence, and reviews of key stores and cryptographic services supply other parts of the picture.
NIST’s preliminary cryptographic discovery guidance explores multiple discovery approaches. The practical lesson is to combine evidence rather than treat one scan as proof of completeness. Reconcile findings with application teams and investigate disagreements between documentation, deployed software, and observed behavior.
Vendor products require their own evidence. Ask which versions support the planned algorithms, which interfaces remain dependent on older mechanisms, and what customers must change. A general statement that a supplier is “quantum ready” does not establish readiness for your deployed product and configuration.
Start Small, But Make the Scope Honest
Discovery should enable action, rather than become an open-ended prerequisite for every change. Start with a defined group of applications that protect long-lived sensitive information, support critical operations, or provide shared trust services. Follow their dependencies far enough to understand the migration boundary, including external partners.
Publish what the team examined, how it examined it, and what remains unverified. Distinguish confirmed production use from a code reference, a vendor assertion, or an assumption. Assign an owner and a next action to material gaps. An explicitly incomplete inventory supports better decisions than a supposedly complete inventory with no supporting evidence.
Measure coverage against that scope, including assessed applications, verified interfaces, and unresolved dependencies. Counting discovered certificates alone says little about whether the team understands a critical transaction.
Then use the findings to sequence the work. Separate supported upgrades from applications needing engineering, coordinate changes across shared services, and identify candidates for retirement. Test a representative dependency chain before committing the broader portfolio to the same approach.
Keep the Inventory Attached to Delivery
The map starts aging as soon as software changes. Refresh discovery during builds, deployments, configuration changes, and supplier upgrades, and run periodic checks to catch drift. Give the inventory an accountable owner and connect it to existing architecture, security, and change processes.
Leaders should challenge a roadmap with one question: what evidence shows that we understand the dependencies behind these dates? If the answer is a server list or an unverified questionnaire, the discovery work remains unfinished.
You cannot responsibly commit to migrating what you have not located. Build enough visibility to make the next decision, expose the remaining uncertainty, and keep improving the map as delivery proceeds.
Book a Call with Aspen
If your legacy application portfolio lacks that visibility, book a call with Aspen to discuss a discovery scope that connects application dependencies, cryptographic exposure, and modernization decisions. Start with the systems that matter most and establish what the roadmap must address.
Schedule a discovery call: https://calendly.com/aspen-ess/aspen-ess-discovery-chat
