Since NIST finalized the first three post-quantum cryptography standards in 2024, the next question seems simple: When will companies replace their current practices with ML-KEM, ML-DSA, or SLH-DSA?
In practice, this question is asked too late. Before a method can be replaced, an organization needs to know where cryptography is used, which systems depend on each other, how long data needs to be protected, and whether an algorithm can be changed at all without disrupting operations.
This skill is called crypto-agility. It is not a single product or switch in a TLS configuration. Crypto-agility means being able to find, evaluate, exchange and monitor cryptographic procedures, keys, certificates and protocols in a controlled manner.
For post-quantum readiness, this is the actual starting point.
Why "we use TLS" is not a sufficient answer
Many companies document encryption at a rough level: database encrypted, VPN available, TLS active. This is not enough for migration. The same business process can use different procedures in several places:
- Browser or client establishes a TLS connection.
- A proxy or security service inspects and terminates the connection.
- The application calls other internal or external APIs.
- Certificates are issued through different PKI processes.
- Data is stored, archived, exported, or copied to backups.
- Devices or appliances have their own crypto libraries that are slow to update.
If only one component supports a new algorithm, the chain has not yet migrated. If an old device no longer communicates after the change, a theoretically correct measure can become a production problem.
Crypto-agility makes these dependencies visible before the transition.
Three timelines that should not be confused
1. Data lifespan
Some information loses its value after days. Others remain confidential for years: development data, health information, personal archives, contract or infrastructure data. The longer the required confidentiality, the more relevant the risk of recording encrypted communication today and decrypting it later with more powerful methods.
2. Service life of the systems
A browser or cloud service can be updated relatively quickly. Production plants, network components, embedded devices and industry-specific applications often remain in use for much longer. The migration must therefore take into account not only modern standard software, but also the slowest relevant component.
3. Duration of the organizational change
Inventory, responsibilities, testing, procurement, contracts, exceptions, and rollout take time. Even if no acute algorithm change is required today, the preparation time may be longer than the migration window available later.
A robust roadmap connects these three timelines. It prioritizes the data and systems that combine long protection periods, long lifespans and low changeability.
What belongs in a crypto inventory
A crypto inventory is more than a list of certificates. For each relevant relationship, at least the following information should be collected:
- Business process and data category,
- Source, goal and communication channel,
- protocol and crypto library used,
- Certificate and key responsibility,
- algorithm and parameters, as far as can be determined,
- TLS inspection, proxy or gateway involvement,
- Manufacturer and product dependency,
- Update and test option,
- required term of protection,
- technical and professional owner.
Not everything has to be complete on the first day. It is important to make uncertainty visible. At this stage, transparently marked audit gaps are more valuable than a supposedly complete inventory that only looks at the central PKI.
The Special Role of TLS Inspection and Security Services
In existing Zscaler environments, many relevant traffic routes run through security and access layers. TLS inspection, certificate chains, browser and application compatibility, and bypass rules all influence which procedures can be used in practice.
This does not automatically make a Zscaler environment "quantum safe" or "non-quantum safe". It means that it must be considered as an active component of the connection in the migration analysis.
A sensible readiness check asks:
- Which traffic routes are inspected, scheduled or exempted?
- Which certificates and chains of trust are involved?
- Which applications or devices are sensitive to change?
- What guidelines distinguish internal, external and particularly sensitive communication?
- How are tests, exceptions, and fallback options documented?
These questions connect PQC with real network and security operations, rather than leaving the topic in an isolated cryptography working group.
A pragmatic approach in four work packages
Work Package 1: Need for Protection and Scope
First, particularly durable or regulatory-sensitive data classes and their most important business processes are selected. This prevents the initiative from getting stuck in a company-wide full inventory.
Work Package 2: Traffic and Crypto Inventory
For the selected processes, communication channels, TLS inspection, certificates, policies, applications and technical owners are recorded. Automated finds are compared with architectural knowledge and interviews.
Work Package 3: Compatibility and Policy Review
The organization examines which components support new or hybrid processes, where dependencies exist and which exceptions already limit visibility or controllability today. Critical paths are given concrete test cases.
Work Package 4: Crypto-Agility Roadmap
Risk, lifespan, changeability, and dependencies create a prioritized roadmap. It names those responsible, test environments, procurement requirements, decision times and fallback paths.
The result is not a claim "PQC-ready". It's a verifiable list of next choices.
Five typical false starts
Only certificates count. Certificates are important, but they do not represent all protocols, libraries and stored data.
Waiting for the perfect scanner. Tools help with finding. Context, term of protection and responsibility remain organizational tasks.
Start with the nationwide exchange. Without a compatibility test, the algorithm change creates new operational risks.
Treat PQC as a pure PKI project. Network, security, applications, devices, purchasing and risk are also affected.
Equating product support with complete readiness. A single compatible component does not yet make the end-to-end chain migration-capable.
Get started with existing Zscaler environments
For companies with Zscaler, a focused traffic readiness sprint makes sense. It looks at a limited number of critical data flows and answers three questions:
- Where is the long-term need for protection?
- Which inspection, certificate, policy and application dependencies shape the transport route?
- What tests and decisions are necessary before a later migration?
This can be followed by a Policy & Compatibility Review and a Crypto-Agility Roadmap. PKI/HSM design, detailed legal assessment and specialized cryptography implementation are clearly delineated and, if necessary, worked on with suitable special partners.
Conclusion: Migration capacity is measurable today
No one can seriously guarantee the exact time of a cryptographically relevant quantum threat. However, companies can now determine whether they could change their cryptography in a controlled manner.
This is exactly where the benefit of crypto-agility lies: not in a futuristic security claim, but in shorter search, decision-making and testing paths. Those who know data flows, responsible persons and dependencies can introduce new standards in a planned manner. If you don't know them, you start the later migration with an inventory under time pressure.
The first sensible step is therefore a limited readiness scope – not the purchase of a supposed PQC complete package.