Today, an attacker does not have to break an encrypted connection for the attack to be successful. It is sufficient to record and store the data traffic. If sufficiently powerful quantum computers or other suitable methods are available later, the archived material can be attacked again.
This scenario is called "Harvest now, decrypt later". It postpones the crucial question of security. Companies do not need to know on what date a cryptographically relevant quantum computer will exist. They need to know whether information that is transmitted today still has to be confidential.
For short-lived data, the answer may be "no." For development documents, M&A documents, health data, identity information, government communications or long-term industrial secrets, it is often "yes". This is precisely why post-quantum cryptography is not just a topic of the future.
It is not the quantum computer that is the first deadline – but the lifespan of the data
The discussion about the so-called Q-Day often seems abstract. Some forecasts speak of years, others remain deliberately cautious. For a reliable decision, this uncertainty is less important than it first appears.
Three periods are decisive:
- How long does the affected data have to remain confidential?
- How long does the company realistically need for inventory, testing, procurement and migration?
- How long does it take for an attacker to decrypt recorded data?
If the protection period plus migration duration is greater than the remaining time until a relevant decryption option, a risk already arises today. The exact year is unknown. The protection period of one's own data and the speed of one's own change processes, on the other hand, can be determined.
An example: A construction plan is to remain confidential for another 15 years. The affected application, its interfaces, certificates, suppliers and embedded devices cannot be replaced within a few weeks. In this case, "We are waiting for a clearly proven quantum computer" is not a neutral position. It is the decision to continue to secure today's transmission of information worthy of long-term protection with cryptography that may be usable later.
What attackers can collect at all
"Harvest now" does not mean that all encrypted company data automatically ends up with an attacker. The risk depends on where data is transmitted, how attractive it is, and how realistic a record is.
Data flows via public or externally operated networks, external interfaces, partner connections, cloud services and permanently used remote access are particularly relevant. Central crossings can also be interesting because many valuable connections converge there.
Typical candidates for a higher priority are:
- intellectual property, product development and research data,
- M&A, contract and strategy documents,
- personal data with a long protection period,
- Identity, key and authorization information,
- configuration and operating data of critical infrastructures,
- Communication between locations, partners and service providers,
- firmware, signatures and update chains of long-lived devices.
The list also shows why the topic must not lie solely with the network team. Data controllers, application operations, purchasing, OT, legal and information security must jointly assess what is in need of protection in the long term.
The lock in the browser only answers today's question
TLS protects data in transit. This is indispensable. But a successful TLS connection initially only means that client and server have agreed on a procedure that is now considered secure and has been implemented correctly.
Many common methods for key exchange and digital signatures are based on mathematical problems that a sufficiently powerful quantum computer with Shor's algorithm could attack in a fundamentally different way. Symmetric encryption and hashing methods are affected by the quantum threat differently than public key methods; a blanket statement such as "everything is then broken" would therefore be wrong.
Post-quantum cryptography replaces endangered public key procedures with algorithms that, according to current knowledge, are also said to be resistant to quantum attacks. NIST finalized the first three core standards in 2024. FIPS 203 describes ML-KEM for the establishment of common keys, FIPS 204 and FIPS 205 standardize procedures for digital signatures.
The standards are therefore no longer just research. NIST specifically urges organizations to begin integration because a complete transition takes time.
Why "We'll buy a PQC product later" isn't enough
Cryptography is rarely stuck in just one place. It resides in browsers, APIs, VPNs, certificates, signatures, email systems, software updates, devices, libraries, and the products of numerous suppliers. Some components can be updated quickly. Others are built deep into applications or designed for long life cycles.
A migration therefore often fails not because of the selection of an algorithm, but because of a lack of visibility:
- Which systems use RSA, ECDH or ECDSA?
- Where does the key exchange take place?
- Which certificates and signature chains are affected?
- Which devices can be upgraded?
- Which manufacturers have a robust migration plan?
- Where can hybrid methods be used without jeopardizing compatibility and operation?
Without crypto inventory, it is not possible to prioritize risk or prove progress. A single gateway, a new certificate, or a vendor feature can cover an important part of the journey. However, it does not replace the knowledge of the entire cryptographic dependencies.
Hybrid processes create a controlled transition phase
Many current approaches combine classical and post-quantum safe methods. A hybrid key exchange is intended to make the transition more robust: The connection does not depend exclusively on a new algorithm, but at the same time a quantum-resistant device is added.
For companies, this is above all an operational question. Hybrid processes must interact with browsers, applications, inspection routes and security policies. They can bring larger messages, different performance profiles and new error patterns. That's why compatibility and performance testing should be part of the migration plan.
Zscaler now supports inline inspection of TLS connections with hybrid PQC key exchange based on ML-KEM in Zscaler Internet Access. A separate visibility report and additional log fields show which key and signature algorithms are used in web traffic. This is a concrete starting point for Zscaler customers: not to change everything immediately, but first to make visible where classic, hybrid and PQC methods actually occur.
Nevertheless, the boundary must remain clear. Web traffic visibility is not a complete company-wide crypto inventory. Code signatures, internal PKI, SSH, email, industry-specific protocols, and embedded systems still need their own consideration.
Six questions for the first management decision
Before a company announces a major PQC program, management should have six questions answered:
1. What information must remain confidential for more than five or ten years? Not all data is created equal. The term of protection creates priority.
2. Through which externally accessible or externally operated channels does this data flow? In this way, an abstract topic becomes a verifiable attack surface.
3. What cryptography protects these pathways today? What is needed is a reliable current status, not a product list.
4. Which dependencies cannot be replaced in the short term? Legacy applications, OT devices, and vendor contracts determine the real-world migration time.
5. Which manufacturers already support ML-KEM or other standardized processes – and to what degree of maturity? "On the roadmap" is not the same as being productively available, documented, and tested.
6. How is progress measured? Suitable key figures are, for example, the proportion of inventoried critical data flows, the number of evaluated suppliers, the coverage of hybrid tests and the number of unexplained cryptographic dependencies.
These six answers are enough for an initial prioritization. They prevent panic as well as waiting without consequences.
What makes sense in the first 30 days
A pragmatic start does not require a transformation program that lasts for years.
Week 1: Identify data with a long protection period and appoint a business owner in each case.
Week 2: Capture key external data flows, logs, certificates, and vendors. Existing Zscaler PQC visibility can be a data point for web traffic.
Week 3: Classify risks according to duration of protection, exposure and migration effort. It is not the technically most exciting system that begins, but the data flow with the greatest long-term damage.
Week 4: Decide on a test and supplier plan for the first three prioritized flows: target procedure, hybrid transition option, compatibility test, owner and decision date.
The result is not yet a quantum-safe organization. It is something more valuable than a general strategy paper: a comprehensible starting point with three concretely editable migration paths.
PQC is not a reason to panic – but a bad candidate for postponement
No one can seriously promise today when a quantum computer will practically break current public-key cryptography. Equally dubious would be the claim that this uncertainty means that companies can wait and see.
Harvest now, decrypt later turns a later technical capability into a data risk today. The longer information has to remain confidential and the slower it is to change one's own environment, the sooner preparation must begin.
The sensible first step is therefore neither an alarm workshop nor a blanket product exchange. It is a crypto and data flow inventory that combines protection duration, exposure, and migration effort. Only then can a decision be made as to where hybrid PQC procedures, manufacturer functions or architecture changes deliver the greatest demonstrable benefit.