What is Crypto Agility?
Crypto-agility is the ability to exchange cryptographic algorithms, keys, certificates, and protocol parameters in a controlled manner while maintaining security, interoperability, and operations. For post-quantum cryptography, this means not immediately switching on ML-KEM everywhere, but making dependencies visible, testing migration paths and mastering changes repeatably.
The specific problem: No one can see the full cryptographic path
A typical security organization knows its public certificates and central PKI systems. Less visible, however, are the cryptographic dependencies along a complete data path: client, browser or agent, local proxy, Zscaler service edge, TLS inspection, target application, API gateway, load balancer, application component, and connected partner services.
If an algorithm or key length is changed in one place, this can lead to incompatibility, failed inspection or unreachable applications in another. Particularly critical are long-lasting confidential data whose need for protection exists longer than the expected period of use of today's public key procedures.
A company wants to make its Zscaler and TLS architecture "PQC-ready". However, it does not have a complete inventory of TLS endpoints or an assignment of data classes, certificates, application managers and third-party products. A premature rollout would therefore shift technical risks, not control them.
What needs to be technically recorded?
1. Need for protection and service life
What data must remain confidential for years? Which communication channels could be relevant for "Harvest now, decrypt later"?
2. Cryptographic endpoints
Where do TLS, signatures or key exchange begin and end? Which proxies, gateways, appliances, and cloud services terminate connections?
3. Procedures and dependencies
Which algorithms, certificate types, libraries, firmware versions and protocol versions are in use? Who controls their updating?
4. Interchangeability and testing capability
Can processes be changed in a configurable way? Are there hybrid tests, proof of compatibility, telemetry, and a resilient fallback path?
What does this mean for a Zscaler environment?
Zscaler is part of the traffic and control path, but it does not automatically own every cryptographic dependency. For a reliable readiness test, at least the following areas must be considered separately:
- TLS inspection: Which connections are decrypted, which exceptions exist and which applications react sensitively to changed handshakes or certificate chains?
- Client and browser compatibility: Do operating systems, browsers, client components, and target systems support the intended procedures and hybrid transitions?
- Private Applications: Which ZPA access paths, App Connector, servers, and internal PKI dependencies are affected?
- Policy and Governance: Who is allowed to change cryptographic parameters, who checks exceptions and how are decisions, tests and rollbacks documented?
- Vendor dependencies: What specific PQC support is actually released for product, version, region, and tenant?
Architectural note: The maturity level of quantum-safe functions differs depending on the product, data path and dependency. That's why we combine up-to-date manufacturer information with an examination of the specific environment.
How SourcingBlox turns it into an actionable program
Traffic Readiness Sprint
Capture data classes, critical traffic routes, TLS endpoints, and responsible systems. The result: prioritized examination map instead of an incomplete product list.
Policy & Compatibility Review
Check TLS inspection, exceptions, certificate chains, client and application compatibility, and operational dependencies in a controlled manner.
Crypto-Agility Roadmap
Transfer waves of changeovers, tests, responsibilities, vendor dependencies, measurement points, and fallback options into a resilient roadmap.
Checklist for the first workshop
- Which data needs long-term confidentiality or integrity?
- Which external and internal traffic routes transport this data?
- Where are connections terminated, decrypted, re-encrypted or signed?
- What certificates, libraries, appliances, and SaaS services are involved?
- Which Zscaler policies, inspection exceptions, and private applications are affected?
- Which components can be independently tested and reset in a controlled manner?
- What evidence and manufacturer commitments are still missing?
What Crypto Agility Doesn't Automatically Solve
Crypto agility does not replace protection needs analysis, PKI governance, key management, secure implementation, or vendor verification. Even a standardized algorithm such as ML-KEM alone does not guarantee a secure end-to-end architecture. The decisive factor is how the procedure is integrated into protocols, products and operational processes.
Frequently Asked Questions
Is ML-KEM the same as crypto agility?
No. ML-KEM is a key encapsulation mechanism standardized by NIST. Crypto-agility describes the organizational and technical skills to introduce, exchange and operate procedures such as ML-KEM in a controlled manner.
Do companies need to replace all their cryptography immediately?
No. The sensible first step is a risk-based inventory. Protection requirements, data lifespan, exposure and technical dependencies determine the order.
Is it enough to wait for manufacturer roadmaps?
Manufacturer roadmaps are an important input, but they don't replace your own inventory. Companies need to know which data paths and systems depend on which manufacturer's decision.
Where does SourcingBlox start?
With a demarcated data and traffic route. This is technically recorded, checked against policies and product dependencies and then described as a pilot and migration path.
Determine PQC readiness for a critical data path.
We don't start with an abstract quantum strategy, but with a representative traffic route, its TLS endpoints, policies and dependencies.
Related Content
Technical Primary Sources
- NIST CSWP 39: Considerations for Achieving Crypto Agility
- NIST FIPS 203: ML-KEM
- NCCoE: Migration to Post-Quantum Cryptography
- BSI: Making cryptography quantum-secure
Audit date: July 25, 2026. Product-related statements must also be checked against the then current Zscaler documentation before publication.