The Integrity Crisis: Trust Now, Forge Later. 🤓 In my last post, I discussed HNDL (Harvest Now, Decrypt Later)... the threat where attackers hoard encrypted data today to read it tomorrow. That is a crisis of confidentiality. (see link in comments) But there is a second, arguably more dangerous vector emerging in post-quantum security discussions. It targets integrity and authenticity. It is called TNFL: Trust Now, Forge Later. What is the basic mechanism? Current public-key signature algorithms (like RSA and ECDSA) rely on math that a Cryptographically Relevant Quantum Computer (CRQC) will break using Shor’s algorithm. The threat model is simple: ➡️ Trust Now: An attacker records a digitally signed artifact today, a firmware update, a digital identity, or a long-term contract. These are valid and trusted right now. ➡️ Forge Later: Once a quantum computer becomes available (est. 2030s), the attacker uses the public key information from those recorded artifacts to derive the private key. 🤯 The Breached Future: They can now retroactively sign new, malicious artifacts that your systems will accept as authentic. So why this is different (and dangerous)? 🤷♂️ Well... while HNDL reads your diary, TNFL hijacks your car ‼️ HNDL (Confidentiality): Exposes past secrets. The damage is informational. TNFL (Integrity): Allows active compromise. A forged signature on a firmware update in an OT (Operational Technology) environment doesn't just leak data; it could cause physical damage to critical infrastructure. We often mistakenly think signatures are ephemeral, overlooking the significant "long-tail" of trust they actually create. Examples 👩🏫 software/Firmware: Embedded devices often have lifecycles of 15–20 years. A satellite or medical device deployed today with a hard-coded root of trust could be hijacked in 2035 via a forged update. Legal & Finance: Blockchain ledgers and digital contracts signed today must remain immutable for decades. TNFL threatens to rewrite that history. The Fix: Crypto-Agility and Post Quantum Cryptography 🤩 We cannot simply wait for the quantum era to arrive. The mitigation strategy is crypto-agility: building systems today that allow us to swap out cryptographic primitives without rewriting the entire infrastructure. There are good choices of Post Quantum Cryptography already available for implementation. All around the world governments recommend implementing them. It's time to "keep secrets" and "maintain trust". Join Quantum Security Defence for continuous education, business networking and advisory, link in the comments. 💚 🔜 In my next post I will discuss evidence logs as the proof of what happened in the past. #PQC #QuantumSecurity #DigitalTrust #Cybersecurity #TNFL #Integrity #CISO #TechTrends2026 #QSECDEF #QuantumComputing
Securing OT Systems for the Quantum Era
Explore top LinkedIn content from expert professionals.
Summary
Securing OT (Operational Technology) systems for the quantum era means preparing the hardware and software that run critical infrastructure—like energy grids, factories, and transport networks—to withstand threats posed by quantum computers, which could eventually break today’s encryption methods. Organizations must act now to protect sensitive data and ensure long-term trust, as quantum risks impact both the confidentiality and integrity of systems whose lifespans stretch decades into the future.
- Map dependencies: Begin by identifying where current cryptography is used within your OT environment, including certificates, firmware, and device identities.
- Prioritize upgrades: Focus on updating long-lived assets, especially those connected to critical infrastructure or sensitive information, to support quantum-resistant algorithms.
- Demand clarity: Ask vendors for clear plans on how their products will transition to post-quantum cryptography and meet evolving security standards.
-
-
We’re all bracing for “Harvest Now, Decrypt Later.” The risk that keeps me up at night is its more dangerous twin: “Trust Now, Forge Later.” This isn’t about reading your secrets tomorrow. It’s about forging the signatures and certificates your systems trust today - software updates, firmware, documents, device identities - once quantum computers can break RSA/ECC. When the control plane (signing and verification) fails, attackers can push "validly signed" malware and instructions that our systems accept without a blink. Why this matters - especially in OT and cyber‑physical environments: - Integrity -> safety. In factories, energy, healthcare, and transport, forged signatures can become physical harm. - Long‑lived devices. Roots of trust burned into ROM, narrow maintenance windows, and legacy protocols mean PQC migration in OT is harder (much harder) and slower than in IT. - Evidence and provenance. If signatures become forgeable, non‑repudiation and long‑term legal trust need PQ‑secure timestamping and re‑signing strategies. I lay it out here - including why “Sign Today, Forge Tomorrow / Trust Now, Forge Later” is often a bigger risk than HNDL for OT and critical infrastructure, and why the migration is uniquely complex. #QuantumThreat #QuantumComputing #TrustNowForgeLater #TNFL #QuantumSecurity #PQC #PostQuantum #QuantumReadiness
-
Transitioning to post-quantum cryptography (PQC) is one of the largest and most impactful changes #industrial organizations can implement to improve their security posture. Through a series of activities to map cryptographic dependencies and develop crypto-agile architectures, organizations can prepare to get ahead of the threat curve rather than respond to it. Leaders have more to gain than mere #compliance, as they shift the organizational focus toward operational confidence, #supplychain trust, and enduring cyber resilience that can be a true competitive advantage. With the tools, standards, and regulatory frameworks in place, industrial leaders willing to act now will look at the post-quantum era as not a threat to manage, but more of an architecture to build. Industrial Cyber reached out to experts to gauge the urgency of the post-quantum threat in OT environments. They also look into what industrial security leaders should understand about the likely timeline before today’s cryptographic protections become insufficient. “The quantum threat is significant because of the ‘harvest now, decrypt later’ risk,” Dustin Moody, a mathematician in the Computer Security Division at the U.S. (National Institute of Standards and Technology (NIST) and head of its PQC standardization project, said. “While a cryptographically relevant quantum computer (CRQC) doesn’t exist yet, data with long-term sensitivity intercepted today could be decrypted in the future. For any environment with long-lived assets, the time to begin planning is now, as the transition to quantum-resistant algorithms will likely take years to fully implement across an enterprise.” “For OT, the post‑quantum problem is less about ‘Q‑day’ and more about asset useful life versus how long it will take to migrate to quantum-resistant #cryptography,” Jen Sovada, general manager for public sector at Claroty, said. “Many control systems deployed today will run for 10–30 years, well into when cryptanalytically relevant quantum computers (CRQC) are expected to be operational. Even conservative estimates place them in the 2030-2035 range.” Michael Hoffman, technical leader at Dragos, Inc. said that the post-quantum threat in OT is real but not immediate, and its impact is uneven across OT verticals and across their network architectures. “Most ICS/OT protocols already lack native cryptography, or if they do include it, it is rarely enabled, so the risk is concentrated in higher-level systems, such as OT-to-IT communications, remote access, and identity services.” “The post-quantum threat is not immediate. It will take years before quantum computing can break widely used cryptographic algorithms at scale,” according to Anton Shipulin, an industrial cybersecurity evangelist at Nozomi Networks. “However, OT organisations should not delay action. Industrial systems have long lifecycles, often 10–15 years, and are difficult to modify due to limited maintenance windows and operational constraints.”