When Encryption Becomes Irrelevant: The Quantum Warning Sign

Encryption protects data confidentiality. Brilliant. Essential. But encryption doesn’t answer the questions you need during security incidents:

• Which applications transmitted data during the breach?
• Where did that encrypted data actually go?
• Can you tell the board what data is at risk?

M&S had encryption. Knights of Old had encryption. JLR had encryption. All three shut down for weeks or months because they couldn’t answer these questions.

Not because encryption failed. Because they had no forensic visibility into application data flows during the incident.

Encryption gives you confidentiality. It doesn’t give you operational resilience.

Modern crypto algorithms were designed to withstand classical computing attacks for billions of years. AES-256 should take longer than the universe has existed to crack. RSA-2048 should take trillions of years.

With quantum computing, a stable 4099-qubit device could crack RSA-2048 in 10 seconds. We’re not there yet. Today’s quantum computers have around 1,000 qubits and struggle with error rates that prevent sustained computation.

But Regev’s algorithm changes the timeline. Three orders of magnitude improvement in calculations means strong encryption could potentially be broken within six months on today’s quantum computers.

Six months!

This considerably moves the goalposts. Attackers don’t need to crack your encryption today. They just need to steal your encrypted data and wait six months for quantum computing to catch up.

“Harvest now, decrypt later” attacks just became realistic.

Here’s what companies miss: DLP monitors email and web data. Your application data such as Word documents, Excel spreadsheets, CRM systems, finance applications, flows completely outside DLP visibility.

Encrypted or not, these flows are invisible.

When I explain this to IT Directors, the response is predictable: “But the data is encrypted in transit. Even if attackers intercept it, they can’t read it.”

True. For now…

But during a security incident, you’re making shutdown decisions with zero confidence about what encrypted data left your devices. Finance system data encrypted and transmitted to attacker-controlled infrastructure? You don’t know. CRM data encrypted and exfiltrated via compromised application? You don’t see it.

Without forensic visibility into application data flows, “we don’t know what data was taken” forces panic shutdowns.

M&S was offline for months. Not because their encryption failed. Because they couldn’t answer what data was at risk during the incident.

When JLR got breached, production lines stopped. Daily revenue loss mounted while forensics teams tried to determine the scope of data compromise.

If they’d known—actually known, not assumed—which applications transmitted data during the breach and where that data went, they could have made selective decisions.

Keep production systems running where application data flows remained within legitimate vendor infrastructure. Isolate systems where encrypted data flows looked suspicious.

Strategic triage rather than wholesale shutdown.

This is what changes with forensic visibility into application data during incidents. Not “better encryption” or “faster detection”, but different operational capability during an active breach.

Process-to-destination correlation: linking which application process transmitted what data to which destination IP address.

Your firewall sees “traffic to Microsoft infrastructure”. Your DLP sees nothing (application data is outside its scope). Your EDR sees the endpoint is compromised but can’t prevent data transmission from authorised applications being abused.

None of these tools correlate application Process ID to destination IP address during incidents.

This correlation answers the question your current stack cannot: “Which application just transmitted encrypted data, and where did it actually go?”

During incidents, this forensic intelligence enables strategic decisions:

• Finance application sending encrypted data to non-vendor infrastructure? Shut it down.
• CRM system transmitting only to legitimate Salesforce infrastructure? Keep it running.
• Production systems with no suspicious encrypted flows? Maintain operations.

Strategic incident response based on facts, not assumptions.

Here’s what makes application data theft prevention fundamentally different from DLP: we don’t need to decrypt anything.

DLP operates by inspecting packet contents. It reads the actual data being transmitted to determine if it contains sensitive information. This requires decrypting HTTPS traffic, examining payload contents, applying data classification rules.

When encryption strengthens (post-quantum algorithms), DLP’s inspection challenge increases. Stronger encryption makes content inspection more complex, more resource-intensive, potentially impossible.

ZORB doesn’t inspect packet contents at all.

We operate at a different layer: correlating application Process ID to destination IP address using packet header information. This header remains unencrypted regardless of payload encryption strength.

When Word transmits encrypted data, we don’t decrypt it to see what’s inside. We validate:

• Source: Is this Word.exe (Process ID verified)?
• Destination: Is the IP address within Microsoft’s legitimate ASN infrastructure?
• Transmission: Is the communication method appropriate for Microsoft services?

This architecture provides DNS-independent validation. We verify destination IP addresses against vendor infrastructure ranges (ASN blocks), not DNS responses that can be poisoned. Even if quantum computing enables attackers to compromise DNS entirely, ZORB validates where encrypted data actually goes based on network infrastructure ownership.

The actual encrypted payload? Irrelevant to our validation process.

This means quantum computing’s impact on encryption strength doesn’t affect ZORB’s capability. Whether your data is encrypted with AES-256, RSA-2048, or post-quantum algorithms, we still provide the same forensic visibility: which application transmitted what encrypted data where.

DLP’s challenge increases as encryption strengthens. ZORB’s capability remains constant because we never needed to decrypt in the first place.

Combine the quantum threat with the application data gap, and you have a genuine operational resilience problem:

1. Attackers breach your perimeter (they will)
2. They exfiltrate encrypted application data (DLP doesn’t see it)
3. You discover the breach weeks later
4. Forensics can’t determine what encrypted data left or where it went
5. Board asks: “What data is at risk?”
6. Answer: “We don’t know! Everything is encrypted, but we have no visibility”
7. Decision: Panic shutdown of everything, just to be safe
8. Meanwhile, attackers decrypt that stolen data within six months

This isn’t theoretical. This is the M&S scenario playing out while quantum computing makes “harvest now, decrypt later” attacks increasingly viable.

NIST has selected post-quantum algorithms: CRYSTALS-Kyber (ML-KEM), CRYSTALS-Dilithium (ML-DSA), FALCON (FN-DSA). Migration will take years. Even when available, these algorithms don’t solve the forensic visibility problem during incidents.

Quantum-resistant encryption still doesn’t tell you which applications transmitted what data where during a breach.

You’ll still face the same shutdown decisions with the same lack of confidence about what data is at risk.

Better encryption is necessary. But encryption, quantum-resistant or not, doesn’t provide the forensic visibility required for strategic incident response.

If I were lecturing my students today, I’d offer updated advice: encryption remains essential, plan your post-quantum migration, and implement application data theft prevention now.

Not because prevention stops all attacks. Because forensic visibility into application data flows enables strategic decisions during incidents.

ZORB validates every outbound transmission through 3-point verification: source application, destination infrastructure, transmission method. If any validation fails, real-time prevention blocks transmission instantly, before encrypted data leaves the device.

But here’s what matters for operational resilience: complete forensic visibility linking application Process ID to destination IP address.

During incidents, you immediately know which application transmitted what encrypted data where. Strategic triage becomes possible: shut down compromised systems, maintain operations where application data flows remain legitimate.

Turn systems back on faster because you have confidence about what encrypted data left during the breach.

This is operational resilience during incidents, not prevention theatre.

Encryption protects data confidentiality. Application data theft prevention provides the forensic visibility required for strategic incident response.

When quantum computing makes “harvest now, decrypt later” attacks realistic, you need both:

• Post-quantum encryption (preventing future decryption)
• Forensic visibility into application data flows (enabling strategic decisions during incidents)

The companies that survive breaches aren’t the ones with perfect prevention. They’re the ones that maintain operations during incidents because they have confidence about what data is actually at risk.

Encrypted or not.

Q. Does encryption prevent data theft during security incidents?
No. Encryption protects data confidentiality but doesn’t provide forensic visibility during incidents. IT Directors can’t determine which applications transmitted encrypted data or where it went, which forces shutdowns. Strategic incident response requires knowing what data left your devices, encrypted or not.
 
Q. How does ZORB work without decrypting data?
ZORB correlates application Process ID to destination IP address using unencrypted packet header information. We don’t inspect encrypted payload contents. Instead, we validate which application transmitted data and where it actually went. This means quantum computing’s impact on encryption strength doesn’t affect ZORB’s forensic visibility capability.
 
Q. How long until quantum computers can break today’s encryption?
Regev’s algorithm suggests strong encryption could potentially be broken within six months on today’s quantum computers, down from billions of years with classical computing. This makes “harvest now, decrypt later” attacks realistic: attackers steal encrypted data today, decrypt it within months as quantum computing advances.
 
Q. What is a harvest now decrypt later attack?
Attackers steal encrypted data today, knowing quantum computing will enable decryption within months. Rather than attempting to crack encryption immediately, attackers simply wait for quantum technology to catch up, making encrypted data theft a viable long-term strategy.
 
Q. Can DLP provide visibility into encrypted application data?
No. DLP monitors email and web data by inspecting packet contents (requires decryption). Desktop application data flows from Word, Excel, CRM systems, finance applications operate outside DLP’s scope. The application data gap exists regardless of encryption. DLP complements email/web monitoring; application data theft prevention fills the gap DLP was never designed to cover.
 
Q. What does forensic visibility mean during security incidents?
Forensic visibility means knowing which application process transmitted what data to which destination IP address, without decrypting payload contents. This enables strategic decisions: shut down systems with suspicious encrypted flows, maintain operations where application data remains within legitimate vendor infrastructure, rather than shutdown all systems.
 
Q. Is application data theft prevention the same as DLP?
No. DLP prevents accidental data loss via email and web by inspecting and decrypting packet contents. Application data theft prevention addresses deliberate data exfiltration from desktop applications during active security incidents, by using process-to-destination correlation without requiring decryption. ZORB complements endpoint protection (EDR/EPP) and DLP: endpoint protection defends devices, DLP monitors email/web, ZORB prevents application data theft.