Post-quantum cryptography is often presented as an exchange of individual algorithms. For a productive security environment, the task is greater: applications, clients, TLS libraries, certificates, proxies and inspection points must withstand the same change.
NIST published the first standards for post-quantum cryptography in 2024. ML-KEM is a standardized mechanism for key agreements. However, it does not follow that every existing compound can be switched immediately and without side effects.
For companies with Zscaler environments, a traffic and compatibility check is therefore the pragmatic starting point.
Why TLS inspection is part of the PQC question
With TLS inspection, an encrypted connection ends at the inspection service and is then reestablished. The inspection point must support protocols and procedures on both sides. At the same time, certificates, applications, and exception rules influence which connections are actually checked.
A PQC roadmap must therefore not only look at servers and browsers. It must map the entire data path:
- Client and used crypto library,
- Zscaler Client Connector or other forwarding path,
- ZIA or SSE inspection point,
- Target application and its frontend,
- Certificate chain and trust store,
- existing exceptions and bypass rules,
- private applications and ZPA paths,
- Monitoring and fault diagnosis.
Step 1: Inventory cryptographically relevant paths
A complete inventory of each system is rarely the best first step. It makes more sense to prioritize an inventory of data value, retention period, and exposure.
Particular attention should be paid to data that could be tapped today and decrypted later, as well as business-critical connections with a long technical lifespan. Depending on the organization, this includes administrative processes, intellectual property, identity data, machine communication or long-term sensitive customer data.
For each prioritized path, it documents which TLS version, which remote sites, and which inspection or proxy components are involved. Unknown values are not estimated, but recorded as a test step.
Step 2: Separate visibility and actual usage
Manufacturer reports and telemetry can provide visibility into where PQC procedures are being observed. Zscaler documents a post-quantum cryptography visibility report, among other things.
However, visibility does not answer all questions. An observed handshake does not automatically mean that the entire application chain is compatible. Conversely, an invisible connection can be excluded, routed differently or outside the path under consideration.
Therefore, reporting data is checked against policy, SSL inspection rules, exceptions, and representative connection tests.
Step 3: Test compatibility in a controlled manner
A test plan should include positive and negative cases:
- supported client to supported application,
- Connection with active TLS inspection,
- justified exception without inspection,
- older client or server component,
- certificate error,
- fallback behavior,
- private application via ZPA,
- Diagnostics in the service and security process.
The aim is not to activate PQC everywhere as quickly as possible. The goal is to identify where support, configuration, or replacement is needed.
Step 4: Clean up policy and exception
Grown SSL inspection exceptions make any crypto migration more difficult. An exception without owner, reason and review date is not only a security risk, but also a blind spot for the readiness assessment.
Before a major changeover, exceptions should be classified:
- technically mandatory,
- for business reasons,
- only historically existing,
- currently unclear.
For unresolved cases, application owner, data path and compatibility are verified in a controlled test.
Step 5: Establish Crypto-Agility as an operational capability
Crypto-agility does not mean switching algorithms at will. It describes the ability to know the procedures used, to evaluate effects, to roll out changes in a controlled manner and to control recidivism.
A resilient work product contains:
- prioritized crypto and data flow inventory,
- Risk and Compatibility Matrix,
- documented policy and exception assessment,
- Pilot and migration path,
- Owner, measuring points and follow-up,
- concrete examination steps for open facts.
SourcingBlox focuses on existing Zscaler data paths, TLS inspection, policies, and an actionable crypto-agility roadmap. PKI, HSM, legal or cryptographic detailed questions are dealt with with specialized partners if necessary.
In this way, an abstract quantum topic becomes a controllable modernization path.
A practical test grid per data path
To prevent the inventory from becoming an unconnected table, each prioritized data path receives the same questions:
- What data is transferred and how long does it remain worthy of protection?
- Which clients, libraries and remote stations establish the connection?
- What Zscaler and other proxy components does the traffic go through?
- Is TLS inspected, excluded, or kept outside the platform?
- Which certificates and trust stores are involved?
- Which PQC or hybrid methods are observed today?
- What happens in case of incompatibility or fallback?
- Who is responsible for the test, decision and re-examination?
This grid combines business risk with technical verifiability. It prevents the creation of a long system list without priority.
Typical findings and their consequences
In practice, very different findings can occur. A modern browser application supports a new procedure, while an upstream system or an older library causes problems. A connection is compatible, but is not inspected at all because of a historical exception. A report shows PQC usage, but the business owner does not know the underlying data path.
The reaction is different in each case:
- If there is a lack of compatibility, a test and upgrade path is required.
- In the case of unknown exceptions, a policy and owner check follows.
- If there is a lack of visibility, routing or telemetry must be understood.
- For long-term sensitive data, earlier prioritization may be necessary.
- In the case of detailed legal or cryptographic questions, specialized expertise is involved.
A blanket traffic light "PQC-ready" would be too rough for these differences.
Pilot and rollback belong together
A pilot defines not only what is activated, but also how a problem is detected and reversed. The test group, time period, affected data paths, monitoring and success criteria must be determined before the change.
For each deviation, it is documented whether client, inspection point, target application, certificate or policy was the cause. This creates knowledge that can be transferred to further rollout waves. Without this error classification, each new test remains a single event.
What the board needs to know – and what it doesn't
A decision overview does not need a list of all cipher suites. It should show which long-term sensitive data paths are prioritized, where dependencies exist, what measures are pending in the next period and who bears the risks.
The technical system may be more detailed. However, the management view remains tied to decisions: budget, owner, migration window, and accepted transition risks.