Preparing for post-quantum migration starts with knowing your cryptographic estate 

Encryption has become so embedded in everyday business that most of us barely think about it. Employees open browsers, connect to applications, access cloud services and transfer information, while encryption does its work under the hood.

 

That apparent simplicity can be misleading. Most organisations know that their communications are encrypted. Far fewer can say precisely which protocols, algorithms and cypher suites are being used, where they are being used, or whether the protections they intended to deploy are the ones being negotiated in practice.

 

Encryption has often been treated as something that can be configured and then largely forgotten about. This approach is no longer sufficient. Older protocols and vulnerable cypher suites remain present in many environments, while the emergence of post-quantum cryptography is introducing an entirely new migration challenge. Before organisations can address either problem, they need an accurate picture of their current cryptographic estate.

 

Easier said than done. A large enterprise may have cryptographic assets spread across certificate and key-management infrastructure, software-development pipelines, internal applications, cloud services and third-party systems. Individual application owners may understand how encryption is used within their particular service, but few organisations have one reliable view across the whole environment.

 

The network provides an important piece of that puzzle because it shows what systems are actually doing when they communicate. Getting this visibility does not require organisations to decrypt the content of those communications. By passively observing connection negotiations and the associated network evidence, security teams can identify the protocols and cryptographic methods being used between clients, servers and services.

 

That distinction matters. The objective is not to look inside every encrypted session. It is to understand the organisation’s cryptographic posture from the exchanges that take place as systems establish those sessions.

 

This can reveal, for example, where outdated versions of TLS are still in operation or where weak cypher suites continue to be negotiated. It can also show whether newer cryptographic features are being adopted successfully. A server may support a post-quantum-capable option, but the connecting client may be unable to use it and force the communication back to classical encryption. If teams only check what the server is configured to offer, they may believe the migration is further ahead than it really is.

 

The difference between capability and actual use is crucial. Configuration records can tell you what should happen. Network evidence tells you what actually did happen.

 

This is particularly important as organisations prepare for the potential impact of quantum computing. Today’s computers cannot simply break the encryption protecting modern enterprise communications. Nobody can say with certainty when that capability will arrive. It might take several years or much longer and will likely be enabled by the power of quantum computers.

 

However, that uncertainty does not remove the present-day risk. Sophisticated adversaries can capture valuable encrypted communications now, store them and attempt to decrypt them once the necessary capability becomes available. This “harvest now, decrypt later” model is especially relevant to governments, financial institutions and organisations holding information that will remain sensitive for many years.

 

The response cannot be to replace every cryptographic system overnight. Post-quantum migration will be gradual, and most organisations will pass through a lengthy hybrid phase in which classical and post-quantum algorithms coexist. Different applications, devices and protocols will make that transition at different speeds.

 

During this period, organisations must be able to see where post-quantum-capable cryptography is being offered, where it is successfully negotiated and where older technology is preventing its use. The same challenges extend beyond web traffic. Cryptographic algorithms are used across protocols and applications such as SSH and RDP, so the inventory must extend beyond HTTPS.

 

This is why a cryptographic inventory cannot simply be a spreadsheet produced at the start of a migration project. It needs to remain current as applications change, software is updated, new services appear, and connection behaviour evolves.

 

The term increasingly used for this is Automated Cryptography Discovery and Inventory, or ACDI/ CBOM. It reflects a growing recognition that cryptographic assets need to be discovered and managed with the same discipline organisations apply to hardware, software and identities.

 

Network monitoring is not the entire answer for generating a crypto inventory. Certificate systems, code repositories, vulnerability-management tools and application owners all contribute different parts of the picture. The network’s value lies in providing a broad, passive view of real communications, including systems that may be missing from formal asset records.

 

It can also expose the gaps between policy and reality. An organisation may have mandated a newer encryption standard, yet an old browser, forgotten application or unmanaged device may continue to negotiate something weaker. Without evidence of those communications, the problem can remain hidden.

 

The first step towards cryptographic modernisation is therefore not choosing a new algorithm. It is understanding and cataloguing where encryption is used, what is being negotiated and which systems are holding back progress.

 

Organisations cannot manage encryption risk based on assumptions about how their infrastructure was designed to behave. They need a living view of how it is behaving now. Once they have that evidence, they can prioritise the weakest areas, measure the progress of migration and make decisions based on the real state of the network.

 

---

 

Vincent Stoffer is Field Chief Technology Officer at Corelight

 

Main image courtesy of iStockPhoto.com and chaofann