You're in a meeting, and someone says, "We need to inventory our cryptography." You're wondering where to even begin. You're not alone. Most compliance and security teams have never conducted a full cryptographic migration. With post-quantum cryptography (PQC) deadlines looming, questions are piling up faster than answers.
These questions arise from real Slack channels, vendor calls, and planning sessions where teams are trying to turn NIST standards into actionable work plans. Here's what you need to know.
Do We Really Need to Inventory Everything Before We Start?
Yes, but not as you might think.
The typical advice is to create a complete cryptographic bill of materials for your entire environment. In practice, this results in a list of findings with no clear starting point. You'll spend months documenting everything and still won't know what to fix first.
Start with a problem that has a business deadline. Public certificates are a good starting point because certificate lifetimes are decreasing, making manual renewal processes unsustainable. Identify your public certificates, establish ownership, and determine whether they should be public. Then, build the automation and orchestration processes to replace them safely.
Your inventory should capture more than asset names. Include protocol and protocol version, cipher suite, certificate chain, key usage, signature, and related metadata. Map each cryptographic component to the business service and data it supports, and document how it connects to applications, data flows, and your broader security stack.
Once you've built that capability for certificates, apply the same process for quantum-resistant algorithms. You're building muscle memory, not just checking boxes.
How Do We Prioritize When Everything Feels Critical?
Start with revenue and core services.
Identify the systems that generate revenue or support your most important business functions. Within those services, determine which data must remain protected and for how long. Biometric records, identity documents, intellectual property, and other long-lived sensitive data may already be exposed to "harvest now, decrypt later" attacks, where adversaries collect encrypted information for future decryption.
Map how those systems connect to public endpoints, third parties, cloud environments, and other system boundaries. Create a prioritization list that ranks data and cryptography by business importance, sensitivity, and required confidentiality period.
Not all encrypted data carries the same risk. A routine video call doesn't present the same long-term exposure as customer financial information or personally identifiable information. Size the problem to your capacity. Don't try to solve everything on day one.
What Does "Crypto Agility" Actually Mean in Practice?
It's about building the capacity to change algorithms safely and proportionately to risk.
Crypto agility requires governance, process, and automation. You need a system around people, processes, and technology that lets your organization change cryptography at a speed that matches the threat. Critical services still require testing, approvals, assurance, and rollback procedures.
This isn't a one-person job. You'll need architects, network and platform engineers, application owners, and program managers who can coordinate work across teams. Procurement, legal, and architectural review boards must prevent the company from introducing new products with inflexible or obsolete cryptography.
External specialists can help, but don't outsource your underlying competency. Retain the ability to execute cryptographic changes within your environment and teams. If you build the muscle memory internally, you'll be in a far better state when standards change again.
What Should We Ask Vendors About Their Crypto Agility?
Establish an SLA around cryptographic updates in your procurement documents and contracts.
Ask whether a vendor can provide a deployable patch within six months of a standards change. Don't accept vague promises about product roadmaps. You need specific commitments about response timelines when cryptographic requirements change.
Be skeptical of any vendor claiming to provide a complete crypto-agility solution. If someone tells you they can handle everything for PQC, they're either misinformed or don't understand the scope of the problem.
Cryptographic-discovery products can't provide all the capabilities you need. You may also require network monitoring to inspect traffic and microsegmentation tools to enforce policies between systems. You need rich data from discovery vendors, network visibility and deep packet inspection from network vendors, and microsegmentation capabilities from security vendors. This is a multi-tool problem.
How Do We Know If We're Making Progress?
Set measurable outcomes and track both coverage and speed.
You might set a goal of bringing 80% of public certificates under end-to-end management by a specific date, while recognizing that difficult legacy systems may account for the remaining 20%. The inventory tells you the scale of the problem, which lets you budget it.
Track the time required to make a cryptographic change. The speed of performing crypto agility becomes just as important as the number of algorithms your systems support. If it takes you nine months to update a cipher suite today, you won't be ready when quantum-vulnerable algorithms are deprecated.
What's the Realistic Timeline for Building This Capability?
Longer than you think, which is why you need to start now.
A major enterprise initiative typically requires a one-year budgeting cycle followed by a two- or three-year implementation. NIST finalized its first three post-quantum cryptography standards in 2024 and is calling on organizations to begin using them now, with quantum-vulnerable algorithms scheduled for deprecation and removal by 2035. High-risk systems are expected to transition earlier. Google set a 2029 target for its own PQC migration.
Waiting for certainty about when a cryptographically relevant quantum computer will arrive could leave you without enough time to prepare. The timeline has been shrinking, not expanding.
Where Do We Go From Here?
Start with certificates. Build automation. Establish ownership. Create your prioritization framework based on business impact and data sensitivity.
Then apply that same capability to the next bounded problem. The goal isn't to solve post-quantum cryptography. The goal is to build an organization that can respond to cryptographic changes without disrupting critical services.
This won't be the last time standards change.
