You Can’t Protect What You Can’t Find
Imagine asking the leadership of a large organization a simple question:
Where is your cryptography?
The first answers would probably sound reassuring. It protects customer information, secures cloud services, authenticates systems, and runs inside the applications and technologies that keep communications safe.
That reassurance begins to fade when the discussion becomes more specific. Which algorithms are being used? Which applications depend on them? Which certificates authenticate critical systems? Which devices contain cryptography that cannot easily be upgraded? Which implementations are controlled by cloud providers or software vendors? Which systems still depend on technology installed ten or twenty years ago?
The answers quickly become less clear.
This is one of the most important challenges organizations face as they prepare for the Quantum Era. Cryptography is everywhere in modern digital infrastructure, yet the people responsible for managing risk rarely need to know where it resides.
For decades, that invisibility was largely a sign of success. Cryptography became embedded in the background of digital life, quietly authenticating users, protecting transactions, securing communications, verifying software, and establishing trust between machines. The transition to post-quantum security is bringing that invisible infrastructure back into view.
Before an organization can change its cryptography, it first has to find it.
The infrastructure we stopped seeing
Most people interact with cryptography constantly without knowing it. When an employee connects remotely to a corporate network, when a customer logs into a bank account, when software verifies that an update is legitimate, or when two systems exchange sensitive information, cryptography is working somewhere in the background.
Inside a large organization, these mechanisms have accumulated over decades. Some were built internally. Others arrived inside commercial software, network equipment, cloud platforms, identity systems, industrial devices, or third-party services. New systems were added while older ones remained in operation. Vendors changed. Standards evolved. Applications were updated. Companies merged and infrastructure was integrated.
The result is a cryptographic environment that may be far more complex than the organization realizes.
This matters because post-quantum migration requires organizations to identify which cryptographic mechanisms may eventually become vulnerable and determine how they can be replaced. That process becomes considerably harder without a complete picture of what already exists.
This is where cryptographic visibility becomes essential.
An inventory needs context
The concept sounds simple: create an inventory of the cryptography used across the organization. In practice, discovering an algorithm, certificate, or cryptographic library is only the beginning.
Finding a cryptographic mechanism tells an organization that something may eventually need to change. Understanding the system around it tells the organization how important that change is and how difficult it may be.
A cryptographic mechanism protecting information that must remain confidential for twenty years deserves different attention from one protecting short-lived data. A mechanism embedded in specialized hardware may be harder to replace than one contained in a routinely updated application. A system that depends on an external vendor or requires regulatory recertification may take significantly longer to migrate.
Inventory tells you what exists. Context tells you what matters.
That context connects cryptography to the information it protects, the systems that depend on it, the parties that control it, and the effort required to change it. Once those relationships are understood, an organization can move from discovery to risk management.
That distinction becomes particularly important in large environments. An organization may ultimately discover thousands, or potentially far more, cryptographic components across its infrastructure. Treating every component with equal urgency would make migration unmanageable. Understanding the context behind each one allows leaders to establish priorities and focus resources where the consequences of delay are greatest.
Context creates priority.
The cryptography you do not control
The discovery problem extends beyond technology owned directly by an organization.
Consider a company that relies on a cloud service for a critical application. That application may depend on cryptographic mechanisms implemented by the cloud provider. The provider, in turn, may rely on hardware manufacturers, software libraries, certificate authorities, or other technology suppliers. The organization at the end of that chain may control only a small part of the cryptography on which its business depends.
This makes supply-chain visibility an important part of quantum readiness. Organizations need to understand which cryptographic dependencies they control directly and which they inherit through vendors and partners. They also need to know whether those providers have their own post-quantum migration plans, and whether the products they buy today can support tomorrow’s cryptographic changes.
A system with a ten-year operational life creates a very different risk if its manufacturer has no practical way to update its cryptography after deployment.
The boundary of an organization’s cryptographic environment therefore extends well beyond its own network. It reaches into the technology ecosystem supporting it.
For procurement teams, technology leaders, and boards, supplier readiness will increasingly become part of the same conversation as internal readiness.
The cryptography no one remembers
Large organizations often contain technology that no longer has a clear owner.
An application may have been created years ago by a team that no longer exists. A developer may have introduced a cryptographic library for a specific project. A certificate may continue operating long after the system around it has changed. An embedded device may contain cryptographic functions that were never documented centrally.
Over time, these components become part of the organization’s invisible infrastructure.
The cybersecurity industry has spent years discussing shadow IT, technology deployed outside normal governance processes. A similar problem can occur with cryptography. Implementations can exist across applications, devices, libraries, and legacy systems without being visible to the teams responsible for enterprise-wide security.
Post-quantum migration can expose these blind spots. Finding them late can also extend the Migration Clock, because discovery becomes part of the migration effort rather than something completed before it begins.
From discovery to priority
In my previous article, I suggested thinking about quantum readiness through three clocks.
The Quantum Clock measures the uncertain time until quantum computers can threaten today’s widely used public-key cryptography. The Data Clock measures how long sensitive information must remain protected. The Migration Clock measures how long an organization will need to prepare and change its cryptographic infrastructure.
Cryptographic visibility directly affects how effectively organizations can act on the last two.
Consider two systems that both use cryptography that will eventually need to be replaced. The first protects information that loses its sensitivity within a few months and can be upgraded through a routine software deployment. The second protects strategic information that must remain confidential for fifteen years and runs on specialized equipment requiring vendor support, hardware replacement, testing, and regulatory approval.
On a basic inventory, the cryptographic issue may appear similar. From a risk perspective, the two systems are very different.
The Data Clock tells leaders how long the information matters. The Migration Clock tells them how long the system may take to change. Combining those perspectives helps determine where migration should begin first.
Discovery creates visibility. Context creates priority.
Visibility needs to stay current
There is a temptation to treat cryptographic discovery as a one-time project: conduct an assessment, create an inventory, identify vulnerable systems, and move on to migration.
Digital infrastructure does not stand still.
New applications are deployed, cloud services are adopted, certificates are renewed, software libraries are updated, devices are added, suppliers change, and standards evolve. A cryptographic inventory that accurately describes an organization today can gradually become inaccurate.
Cryptographic visibility therefore needs to become an ongoing capability. Organizations preparing for the Quantum Era should be able to understand which cryptographic mechanisms they use, what those mechanisms protect, which systems depend on them, and how those relationships change over time.
That visibility also creates the foundation for something broader: cryptographic agility.
An organization that knows where its cryptography resides and understands its dependencies is in a much stronger position to replace it when circumstances change. Future changes may come from quantum computing, newly discovered vulnerabilities, updated standards, regulatory requirements, or technologies that have not yet emerged.
You can only change what you can see.
Visibility is a leadership issue
Cryptographic discovery may sound like work for cybersecurity teams, but the decisions that follow quickly reach the executive level.
Leadership needs to determine which information matters most, which systems are critical to operations, where strategic supplier dependencies exist, and which infrastructure will remain in service long enough to create future migration challenges.
Technical teams can discover cryptographic assets. Leadership determines their business significance and sets the priorities for addressing them.
Procurement has a role because technology purchased today may still be operating when post-quantum requirements become standard. Risk teams help determine how long information must remain protected. Technology leaders understand which architectures can change easily and which cannot. Boards ultimately oversee the long-term exposure, dependencies, and investment decisions involved.
Quantum readiness becomes far more manageable when these responsibilities sit within normal organizational governance rather than stand apart as an isolated technical exercise.
Making the invisible visible
For decades, cryptography has done its job quietly in the background. Most people never needed to know which algorithm authenticated a connection, protected a software update, verified an identity, or secured a transaction. They simply needed the system to work.
The Quantum Era changes that calculation.
Organizations preparing for post-quantum migration need visibility into the cryptographic foundations on which their digital infrastructure depends. They need to understand what they use, where it resides, what it protects, what depends on it, who controls it, and how difficult it will be to change.
That knowledge will not eliminate uncertainty about when cryptographically relevant quantum computers will arrive. It gives organizations something more useful: the information they need to prepare on their own timeline.
The Migration Clock begins with discovery.
You can’t protect what you can’t find.
In my next article, I will explore the question that follows naturally from discovery: who inside an organization should actually own quantum readiness? As post-quantum migration moves from a technical concern to a long-term business and infrastructure challenge, clear ownership becomes increasingly important.
