How Would Q-Day Actually Unfold? Not a Breach You Patch

Brian Couzens

2 minutes ago

8 min read

The world and Earth breaking apart with the word Q-Day next to it

Blog Post Body

Your systems are online. Payments are moving. The hospital is treating patients. Your AI platform is serving customers.

An adversary can now read information you believed was protected, or forge a signature your systems still trust.

There may be no outage to investigate. The first visible event could be a blackmail demand, a compromised operation or a competitor using knowledge you thought was exclusively yours.

Q-Day is often presented as the moment encryption breaks. That framing is wrong. Q-Day is not a breach. It is not something you can patch. And the exposure may already be accumulating before anyone confirms it has happened.

What is Q-Day?

Q-Day is shorthand for the point at which a sufficiently capable quantum computer can defeat widely deployed, quantum-vulnerable public-key cryptography.

It is not a scheduled global event. It does not mean all encryption stops working simultaneously. The exposure depends on the algorithms, implementations, captured material and systems involved.

Two threats define the risk. NCSC distinguishes them as confidentiality and signature exposures in its quantum-safe cryptography guidance. They affect different parts of the cryptographic estate. The TLS 1.3 hybrid key exchange already deployed in current browsers addresses the confidentiality side for new sessions. The signature side is a separate and slower migration.

HNDL: Harvest Now, Decrypt Later

An adversary collects encrypted information today and retains it until a future capability can defeat the vulnerable cryptographic protection involved.

The information does not need to be recent when it becomes readable. Medical histories, intelligence relationships, proprietary research and financial records can remain sensitive for years. Migrating later protects future exchanges. It does not retrieve earlier copies from an adversary. The HNDL and HNFL threat model explains the mechanics and why the exposure window opens before Q-Day, not on it.

HNFL: Harvest Now, Forge Later

HNFL describes the future threat to digital signatures. An attacker could derive a vulnerable signing key from its public key and create signatures that appear legitimate.

Unlike HNDL, prior harvesting is not necessarily required. The public key may already be available. The target is trust: an identity, instruction, software update or document that a system accepts as authentic. Whether an attack succeeds also depends on access, validation and independent safeguards.

This is not a breach. You cannot patch it.

The language of cybersecurity incident response does not apply to Q-Day. A breach is an event: someone gains unauthorised access, the organisation detects it, contains it, patches the vulnerability and restores service. Q-Day does not follow that sequence.

There is no vulnerability in your system to patch. The exposure sits in your adversary's archive and their future computational capability. You cannot patch someone else's quantum computer. You cannot retrieve intercepted traffic from an adversary's storage.

Under HNDL, information was captured months or years before the decryption capability existed. When that capability arrives, there is nothing new to detect and nothing to contain. The adversary already holds the material. They simply read it.

Under HNFL, the public keys from which a signing key could be derived may already be published. There is no exfiltration event to investigate.

Migrating to post-quantum cryptography protects future communications and future signatures. It does not make previously captured information unreadable. It does not invalidate signatures already issued with vulnerable keys. The question is not "how do we recover?" It is "what was already exposed, and what was already signed with a key that can be derived?"

Organisations whose cryptographic modernisation programmes treat Q-Day as a detectable incident followed by a containable response are planning for the wrong threat model. Patching works when the vulnerability is in your code. It does not work when the exposure is in someone else's capability applied to material they already possess. The PQC Baker's Dozen documents this as one of the recurring planning failures across migration programmes.

This distinction also changes how boards should think about timelines. The debate over when a sufficiently capable quantum computer will exist is important, but it is not the only relevant date. Under HNDL, information with a long confidentiality requirement is already at risk if it has been intercepted and the adversary is patient. Under HNFL, the risk materialises when the capability exists, regardless of when the information was first published. A programme that waits for a confirmed Q-Day date before acting has misunderstood which clock is running.

Who is exposed?

Every organisation with quantum-vulnerable cryptographic dependencies. These are hypothetical scenarios, not reports of quantum-enabled incidents. Each assumes a relevant vulnerable dependency and sufficient attacker access or captured material.

Domain	What could happen
Banking and private wealth	Captured communications become readable, exposing ownership structures, account relationships and sensitive client instructions.
Legal, investment and M&A	Previously intercepted deal-room transfers reveal negotiating limits, legal advice, acquisition targets or undisclosed liabilities.
Energy and utilities	A forged firmware signature is accepted by vulnerable equipment after the attacker also reaches the update process.
Transport and logistics	Decrypted operational exchanges reveal sensitive cargo movements, security arrangements or infrastructure weaknesses.
Defence and intelligence	Archived communications expose sources, technical capabilities and relationships that remain active.
Government and diplomacy	Confidential negotiations or personnel information become available to a hostile state.
Healthcare and genomics	Captured clinical or genomic information becomes readable, exposing patients and potentially their relatives.
Pharmaceuticals and manufacturing	Research transfers reveal experimental findings, designs or proprietary production methods.
Cloud and telecommunications	A vulnerable identity or signing dependency creates an attack route into a shared service, with potential downstream exposure.
AI development	Captured model transfers become readable, exposing proprietary weights, checkpoints or specialist research.

The mechanisms repeat across sectors. What changes is the value of the information, the authority of the signature and the consequences of losing either. A cryptographic discovery exercise establishes which of these dependencies exist in a given estate. Without that visibility, the risk register is speculative.

When AI is the target

Consider an AI company transferring proprietary model checkpoints between research and deployment environments.

An adversary captures the encrypted transfer. Years later, the relevant vulnerable key protection is defeated and the captured material proves sufficient to recover the files.

This is not a claim that quantum computing automatically breaks AES. The scenario requires a vulnerable route to the keys protecting the material. Protecting encryption keys is central to protecting the underlying data.

Model weights are not simply another confidential report. With the necessary architecture, software and computing resources, a usable copy may allow another party to operate or adapt the capability. Official AI guidance treats model security and data security as distinct, connected responsibilities.

For a specialist company, losing exclusive control could threaten its economic foundation. A competitor might avoid part of the development effort. Customers might question premium pricing. Investors or acquirers might reassess the business.

The company could remain operational while losing the advantage that justified its valuation. That is a credible existential scenario for a business. It is not evidence of an existential threat to humanity.

Where the cost lands

The following are conditional commercial pathways, not forecasts of inevitable quantum losses. Extortion, fraud, business interruption and financial harm already feature in established cyber-risk assessments.

Impact	How the exposure could translate
Blackmail and coercion	Sensitive personal, financial or medical information becomes leverage for money, access or influence.
Insurance	Underwriters may reassess premiums, excesses, limits, exclusions and evidence of protective controls. Coverage depends on policy wording and circumstances.
M&A	Buyers may demand deeper due diligence, price reductions, escrow arrangements or specific indemnities. Completion could be delayed or abandoned.
Competitive position	Exposed pricing, research or production methods could weaken margins and shorten a commercial advantage.
Litigation and regulation	Investigations, legal defence, compensation and disputes over reasonable protection could follow, depending on jurisdiction and facts.
Contract eligibility	Customers may require stronger assurance or reconsider suppliers unable to address vulnerable dependencies.
Operational recovery	Organisations may need to validate software, instructions and records rather than assume replacing a certificate resolves the incident.
Enterprise value	Uncertain liabilities and reduced exclusivity could change how investors, lenders and acquirers assess the business.

M&A deserves particular attention. The buyer is not only acquiring systems that need migration. It may be acquiring historical information exposure, supplier dependencies and liabilities whose extent is difficult to establish.

"What will remediation cost?" is only one question. "What can no longer be remediated?" may matter more. A PQC Readiness Assessment before a transaction closes establishes whether the target's cryptographic posture is a measured position or an assumption.

Why some consequences persist

A restored system is not the same as a restored position. Keys can be replaced. Software can be updated. Services can resume. But some losses persist.

Disclosed information cannot be made unknown.
Exposed intelligence sources may remain vulnerable.
Medical and genomic information cannot be replaced like a password.
Proprietary knowledge cannot reliably be withdrawn from another party.
Physical injury or destruction cannot be resolved through cryptographic remediation.
A copied AI model may remain outside its owner's control.

Not all consequences are permanent. Information can lose relevance, fraudulent transactions may be recovered and operational damage may be repaired. The distinction is between recovering a service and reversing the harm.

This is why the difference between deploying PQC and proving it works matters. A migration that protects new traffic is necessary. Evidence that the migration actually covers what it claims to cover is what governance requires.

When will you know Q-Day has arrived?

You won't.

Not necessarily when the capability first exists. Not necessarily when it is first used against you.

You may discover consequences later: a blackmail demand, an exposed source, a compromised transaction or proprietary knowledge appearing elsewhere. None of those events would, by itself, prove a quantum attack. You could see the harm without knowing how the information was obtained.

Q-Day could become public knowledge after your organisation has already been affected.

If you cannot rely on knowing when it happens, what are you prepared to leave exposed until then?

The governance question comes before the quantum date

Organisations need to establish what must remain confidential, which signatures authorise consequential actions, and which products or suppliers will remain in service beyond their current cryptographic protection.

NCSC's guidance connects product lifetime with cryptographic lifetime and recommends the ability to change algorithms as requirements evolve. That makes migration a lifecycle and dependency problem, not an algorithm replacement exercise. A governance-first approach to PQC transformation treats the case for cryptographic modernisation as a board-level ownership question before it becomes a technology project.

Ownership matters. So do procurement, retention, supplier commitments and evidence that the transition actually protects the intended information. The sovereign algorithms debate across national standards bodies reflects the same structural question at policy level: which cryptographic dependencies are acceptable, and who decides when they must change.

Cryptographic agility is not a property claimed in a programme document. It is an operational capability demonstrated by testing what happens when an algorithm, a certificate authority or a protocol version must change. A programme that cannot demonstrate substitution has demonstrated adoption. It has not demonstrated resilience. The crypto-agility governance discipline sets out how to structure that evidence.

The board question is direct: if Q-Day were confirmed tomorrow, what in this organisation's estate was protected by cryptography that is no longer trustworthy, and what was signed with keys that can now be derived? If the answer is unknown, the programme has a gap that no quantum timeline debate resolves. That gap is tested independently by the Quantum Trust PQC Assurance standard, which examines whether migration evidence exists and whether it covers what it claims to cover.

About the author

Brian Couzens is CEO of SITG-Consulting, an independent advisory firm working on post-quantum cryptography governance, cryptographic risk and board-level assurance across financial services, critical infrastructure and government. SITG-Consulting is vendor-independent and holds no product vendor partnerships. The PQC Discovery Sprint establishes cryptographic visibility across an estate, and the PQC Readiness Assessment reviews a programme's preparation before implementation begins.

SITG-CONSULTING