Zero-Data PQC

This article is part of the Quantum Snake Oil Dictionary — a series examining terms used in quantum technology marketing. The series is divided into Red Flag Terms (terms with no established technical meaning that almost always signal hype or fraud) and Misused Terms (legitimate concepts routinely stripped of context in marketing). This entry is a Misused Term.

“Zero-Data PQC”

A note before we begin. This entry examines “zero-data PQC,” along with “zero-data migration” and “zero-data model” as they appear in post-quantum marketing. I am not writing about any specific company or product. There is a sensible idea underneath this term, which is why it earns the Misused label rather than the Red Flag one. The trouble is that the term blurs two different questions and then sells the answer to the easy one as if it solved the hard one.

A Coined Term for a Real Preference

“Zero-data PQC” is not a standard or a defined technique. It is a marketing coinage, and its usual meaning is that a vendor deploys post-quantum cryptography inside your environment without moving your sensitive data out to a third-party cloud to perform the migration.

As a preference, that is reasonable. Not shipping your most sensitive data to an outside service in order to upgrade your cryptography is sound data minimization, and keeping the work in place can reduce operational risk. If that were all the term claimed, it would be unremarkable. The problem starts when “we do not move your data” is presented as the security of the solution rather than as one logistical choice about how a migration is run.

Two Different Questions, Blurred Into One

The term collapses two questions that are not the same, and the collapse is where the marketing lives.

The first question is where your data physically sits during a migration. Does it stay inside your environment, or does it travel to a vendor’s cloud to be processed? The second question is which algorithms protect your data in transit and authenticate your systems. Is your key exchange and are your signatures still using RSA and elliptic-curve cryptography, or have they been replaced with post-quantum algorithms?

“Zero-data PQC” answers the first question and implies it has answered the second. It has not, because the two are independent. You can move zero data during a migration and still run RSA and elliptic-curve cryptography across every connection, which leaves you fully exposed to the quantum threat. You can move data to a cloud and emerge with a properly post-quantum stack. Where the data sits during the project and which algorithms protect it afterward are different axes. A pitch that fuses them is selling comfort about the first as though it were protection on the second.

What PQC Actually Protects

This is the heart of it. The job of post-quantum cryptography is to replace the quantum-vulnerable algorithms that secure data in transit and that authenticate identities: the key exchange in your TLS connections and VPNs, the signatures in your certificates and your public-key infrastructure. The harvest-now-decrypt-later threat is fundamentally about data in transit, traffic captured off the wire today and decrypted once a quantum computer exists.

Notice what follows. The protection of data in transit comes from the algorithms in the protocol, not from where the data lived during a migration project. Keeping your data “in place” while you migrate does nothing about your ongoing, everyday data-in-transit exposure if the transit cryptography is still classical. The thing that makes your traffic quantum-safe is swapping the algorithm. “Your data never moved” is silent on whether that swap happened, which is the only thing that determines whether the traffic is actually protected.

The “Zero” Doing the Heavy Lifting

The word “zero” then gets stretched past the logistics into absolutes: “zero exposure,” “no exposure window,” “eliminating compromise.” Those claims fail for the same reason every absolute-security claim fails. Data must be decrypted to be used, keys exist and must be managed, and the endpoints that perform the cryptography remain reachable. Avoiding data movement during a migration narrows one specific risk. It does not eliminate exposure, and a product that says it does has wandered from “we did not move your data” into “we removed your attack surface,” which is a claim no product can support.

Questions to Ask a Vendor

“Does your model change which algorithms protect my data in transit, or only where the migration runs?” This separates the two axes. The first is the actual point of post-quantum migration. The second is a logistics choice that the marketing has dressed up as security.

“If my data never moves but my TLS still uses elliptic-curve key exchange, am I quantum-safe?” The correct answer is no. If the vendor’s answer is yes, the “zero-data” framing has replaced the real question with a comfortable one.

“What exactly is ‘zero’ here, data movement or exposure?” These are different, and conflating them is the move the term depends on. A precise vendor will distinguish them without prompting.

The Bottom Line

Deploying post-quantum cryptography in place, without shipping your sensitive data to an outside cloud, is a perfectly reasonable way to run a migration. It is not, by itself, the security of the migration. “Zero-data PQC” blurs where your data sits during a project with which algorithms protect your data in transit afterward, and only the second determines whether you are actually quantum-safe. Ask which algorithms now protect the traffic that moves through your systems every day. That is where post-quantum cryptography does its work, and no amount of keeping data in place can answer it for you.