By now virtually every CISO has heard some version of the pitch: “One day, quantum computers will break your encryption, siphon off all your secrets, and terminate civilization (please buy our product)”.
This is great as a sales narrative but not particularly useful as an operating model. The real strategic problem is far subtle. Quantum capability can be said to threaten confidentiality “in the far future”, but it also destroys trust in the entire digital supply chain. It turns your vendor supply chain network into a long-term liability, and weaponizes authenticity. Further, it creates a forced migration in cryptographic resources which your operations teams are structurally incapable of executing.
Let’s talk about the three challenges which matter to the CISO—the varsity board, regulator, insurer consequences, and exactly what can be done in the next 12 months before this becomes uninsurable.
One of the primary quantum cyber risks is harvest now – decrypt later. Traditional views say if an attacker cannot decrypt our data today, then we have won. However, quantum computers break this line of reasoning. Attackers do not have to win today; they simply have to copy. Consider the following modern attack strategy -- compromise a current vendor, copy all data transmitted over the compromised connection including your IP address, regulated data, or legal exposure; wait until quantum decryption becomes available at scale (i.e., “military-grade” becomes “password123”) before decrypting the copied data. In other words, you are currently exposed; you simply have not yet reached the stage where you can be decrypted.
This is a supply chain issue because your data resides in environments outside of your own. Clinical analytic vendors contain patient history; litigation bundles contain patient history; behavioral telemetry contains user behavior; cloud cost optimizers may be storing API keys you never issued or cannot recall issuing. It is impossible for you to personally ensure that each of these entities is utilizing quantum-resistant cryptography when encrypting data both in motion and at rest – because they aren’t. Most entities are celebrating their decision to implement “TLS everywhere” and “AES-256 at rest” which will be irrelevant in the near future.
Regulators and litigators will not make the distinction between when the data was actually breached in 2025 and when it is finally decrypted in 2029. All they will want to know is, did you demonstrate due diligence based upon what was known? What will not constitute due diligence—"We had a standard vendor questionnaire with a yes/no box regarding whether they used encryption." This creates a time-differential liability issue. The actual breach occurred in the vendor's network in the present day, but the damages, litigation, and damage to reputation will occur in the future, once the vendor has the ability to utilize quantum computing. In other words, it is unaccounted for data debt.
Also Read: Safeguarding against the new frontier of cyberattacks in AI
One cannot forklift the quantum cybersecurity math. The theoretical solution to address Quantum Cryptography (QC) is simple and well-defined -- transition to post-quantum Cryptography (PQC), specifically NIST-approved cryptographic families for key exchange and signatures. However, the transition from theory to practice is where the dream of QC meets the harsh realities of industrial robots, forklifts, hospital equipment, smart meters, ID badge readers, shipping scanners, warehouse handhelds and the numerous "temporary" integrations since 2012 that have become mission critical.
PQC is computationally expensive; keys are larger, and handshakes between parties are different than traditional cryptography. While many of the current PQC algorithms are finalized and optimized for performance, some are still being finalized or tweaked. The modern cloud-based architecture has the capacity to support these changes, but many operational technology (OT) architectures do not. Your greatest limitation is that you may not even be able to manage your own cryptography; the vendor who supplies your OT controls the cryptography. The logistics company's scanning device communicates with your enterprise resource planning (ERP) system via a TLS version or variation provided by the vendor supplying the scanning device. The smart building company providing the firmware update to your access control system uses a signing method they claim is "rock-solid," which is usually vendor speak for "don't bother looking."
As such, you find yourself in an uncomfortable position -- you are responsible for the cryptographic risks associated with systems that you do not directly control and that the business does not want you to disrupt, on a schedule that the vendors will not expedite. This is not a technical problem, rather a governance issue masquerading as a technical problem.
The main threat here is that quantum does not just read secrets; it forges trust. Your entire supply chain runs on attestations. Firmware updates are “signed.” Telemetry from field sensors is “trusted.” Bills of lading, customs declarations, lot traceability, QA test results, all are “provably authentic”, payments clear because signed instructions are simply assumed to be legalese, recall notices are acted upon because they trust their origin.
Now picture an attacker who can convincingly forge or invalidate classical digital signatures—or just create enough of a doubt in your mind that you cannot tell real from fake or vice versa, in real time. That attacker can deliver bad firmware that your devices are going to delightfully accept; falsify the provenance records of safety-critical components; spoof inventory and shipment signals; falsely route or stall production; alter historic audit trails; and assert, “you never complied.”
That is not “IT outage on a Sunday.” That is production downtime, regulatory breach, product recall, and legal liability. It is also the kind of targeted disruption that a nation state would absolutely love to be able to trigger on demand. You cannot assume suppliers — especially sub-tier manufacturers, brokers, maintenance contractors and logistic aggregators have cryptographic signing and attestation chains that will withstand quantum-class attacks. Many of them barely have patch management. The ugly truth is that if signature trust fails in your supply chain, you do not have a supply chain. You have a set of unverifiable claims slotted into networks at industrial speed.
We propose action items for CISOs corresponding to each challenge.
Identify which data survives post-quantum attacks — not just how sensitive it is. Instead of simply labeling data as "confidential" or "limited," determine if the data survives quantum disclosure, e.g., yes/no. For example, source code, M&A memos, etc., do not have an expiration date but marketing A/B testing does. Any data that could potentially harm you in 5–10 years should be prohibited from leaving your perimeter unless it has been properly protected with post-quantum safeguards.
Re-write all contracts with third party vendors. Contracts that utilize long-term data for its operations, must include both (a) post-quantum-safe encryption for the storage and transmission of data within a specific time frame AND (b), liability for the supplier for any harvest now and decrypt later exposure. If procurement argues that adding these requirements will delay onboarding, tell them that is great.
Require escrow level auditing. The claim of using "industry standard encryption" has become completely meaningless. What you are looking for is the algorithm name used, the key management policy, and the rotation schedule. Make sure that vendor attestation is built into your quarterly vendor reviews and NOT annually during the normal security theater.
First identify the critical data paths that contain crown jewel data — i.e. regulated, lawsuit worthy, and market moving data. Since you do not have the personnel to boil the ocean, do not attempt to. Identify those data paths that flow to third party vendors and place them under emergency review. Everything else can wait.
The board-friendly translation—you are not buying controls; you are buying future deniability.
Create a crypto bill of materials (Crypto BOM) - Create this by documenting the cryptographic primitives and how/where/who and for which functions. Begin by creating a crypto BOM for externally linked systems and M2M links within the supply chain. If a vendor will not provide information on which algorithms and key lengths they are utilizing, then it’s a red flag right.
Create a crypto agility access condition - Require new suppliers to prove they can change algorithms and rotate keys according to your policy before you give them network connectivity, API tokens, data feeds etc. Do not argue. Crypto agility should be treated similarly to SOC 2 was years ago.
Stage PQC development through layers vs. big bang; wherever feasible begin by creating PQC wrapped tunnels or hybrid handshakes (PQC & classical) for the most sensitive links, rather than attempting to "rip & replace" entire technology stacks. The goal here is not to create elegant code. The goal is to ensure the ability to survive.
Escalate the PQC roadmap to procurement and finance. This is imperative. Frame PQC migration as a "Will we continue to ship product to Tier-1 customers after 2027 without being in breach of their security addend um? instead of "IT uplift." Once finance views this as a revenue continuity issue, the funding conversation becomes less hypothetical.
The board-friendly translation—this is supply chain continuity, not nerd crypto. If we cannot prove crypto agility in vendor ecosystems in the next contract cycle, we will lose major customers, fail audits, or both.
Identify "integrity choke points." What are the machine-signed inputs that you accept and automate in your business processes? Examples include: Accepting and installing firmware; clearing shipments from dock to stock; booking inventory; authorizing maintenance. These are your first-tier risks and where you will need to add human oversight or an out-of-band verification step as needed.
Insist that all vendors who supply you with code, patches, sensors, diagnostic interfaces etc., develop and publish their roadmaps for post-quantum safe signing and tamper evidence. If a vendor does not have a published roadmap for post-quantum safe signing and tamper evidence, then you cannot deploy their products into your production environment.
Store the provenance of your safety-critical and regulated data flows in an immutable log format (not just a centralized log). You don't need to use blockchain technology but you should be using an append-only, independently-verifiable log for both safety-critical components and regulated data flows. Your objective should be to be able to prove that anyone trying to alter the history of your data flow was unable to.
Rehearse failure of trust scenarios. We conduct tabletop exercises to simulate ransomware attacks. We should also be conducting tabletop exercises to simulate signature failures, which would cause a significant disruption to our ability to verify the integrity of the code we are executing. Ask your operations team, "If tomorrow, we could no longer trust our inbound firmware validation process, who would have the kill switch to shut down execution of that firmware?" "Who would have authority to quarantine the supplier(s) of that firmware?" "Where is the playbook for this scenario?" If you don't receive clear answers, that's a board-level issue.
The board-friendly translation—encryption loss leaks secrets; signature loss halts revenue. We’re planning for both.
Ranjan Pal (MIT Sloan School of Management, USA)Yaphet Lemiesa (MIT EECS)Bodhibrata Nag (Indian Institute of Management Calcutta)
First Published: Dec 12, 2025, 11:23
Subscribe Now