up:: Quantum Risk Models MOC

The Two-Clock Test

The two-clock test is the check that forces a post-quantum plan to state two dates for the system in question: the date a mandate requires the fix (the compliance clock), and the date an adversary can read what the system protects (the threat clock). The two clocks are set by different authorities, measure different things, and rarely agree, and a plan that only knows the first one can be fully compliant and fully exposed on the same day. The test itself takes one sentence to run: state both dates. What it reveals is whether the plan in front of you is managing risk or managing paperwork.

The short version:

• Every system runs two clocks. Clock 1, compliance: the date a mandate, regulator, or contract requires the migration finished. Clock 2, threat: the date an adversary can read what the system protects.
• Clock 1 is written down in documents you can go pull: Executive Order 14412, NSA CNSA 2.0, NIST IR 8547, the EU Cyber Resilience Act, and the contract language that points at them.
• Clock 2 is derived from exposure math, and for data exposed to harvest-now-decrypt-later collection it started running in the past, on the day the ciphertext was first captured.
• The test is: state both dates. A plan, a vendor roadmap, or a board deck that can only produce Clock 1 is a compliance schedule, whatever the cover slide calls it.
• Deploy it whenever anyone offers compliance as safety.

Think of a building’s fire inspection. The city sets the inspection date, and the wiring sets the fire date. Passing Tuesday’s inspection tells you a great deal about your paperwork and nothing about whether the insulation upstairs is already smoldering. The quantum transition runs on the same two calendars, and for long-lived encrypted data the harvest model means the smoldering may have started years before the inspector arrives.

What are the two clocks?

The framework has exactly two components, and the discipline is refusing to let either one impersonate the other.

	Clock 1 (compliance)	Clock 2 (threat)
What it reads	The date you’re required to have migrated	The date an adversary can read what the system protects
Who sets it	Legislators, regulators, standards bodies, your own contracts	Physics, engineering progress, and your data’s required lifetime
Where you find it	Published mandates and the agreements that reference them	Exposure math run on the system’s own data
What missing it costs	Fines, failed audits, lost contracts, market access	Disclosure of the protected data itself
Can it sit in the past?	Rarely	Routinely, for harvested long-lived data

The test applies to any system that protects data with a required lifetime, and to any artifact that proposes a date for that system: a migration plan, a vendor roadmap, an audit finding, a board deck. It has one move. State both dates, side by side, for the specific system under discussion. When a plan produces Clock 1 fluently and goes quiet on Clock 2, you’ve learned exactly what kind of plan it is.

The test earns its keep because the two clocks fail independently. A system can meet its mandate date while its data sits decryptable in an adversary’s archive, and a system can be cryptographically ahead of the threat while flunking its validation requirements. Only a plan that states both dates can even see both failure modes, let alone manage them.

How do you derive Clock 1, the compliance date?

Clock 1 comes out of documents, and the load-bearing ones each bind a different population. The table reads them side by side, together with the question each one leaves unanswered.

Instrument	Compliance date it sets (Clock 1)	Who it binds	What it says about Clock 2
Executive Order 14412 (June 22, 2026)	Key establishment by Dec 31, 2030; digital signatures by Dec 31, 2031	US federal civilian high-value and high-impact systems; national security systems are excluded	Silent
NSA CNSA 2.0 (Sept 2022)	Exclusivity staged by use case, starting 2030 for software/firmware signing and networking gear, 2033 for web, cloud, and operating systems; transition complete by 2035	US National Security Systems	Silent
NIST IR 8547 (draft, Nov 2024)	112-bit-strength RSA and ECC deprecated after 2030, all classical public-key disallowed after 2035; draft dates that can still shift	Federal systems via FIPS validation, and any organization whose contracts require FIPS-validated cryptography	Silent
EU CRA (Reg. 2024/2847)	Full obligations from Dec 11, 2027; never names PQC, and reaches PQC through its state-of-the-art requirement as harmonized standards evolve	Any manufacturer worldwide placing a product with digital elements on the EU market	Silent
NSM-10 (May 2022)	“As is feasible by 2035,” a hedged policy goal rather than a deadline	US federal policy direction	Silent

Source: The White House, EO 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” presidential action of June 22, 2026, sec. 4(b)(ii)-(iii), whitehouse.gov; NSA, “CNSA 2.0 FAQ” (PP-24-4014, December 2024 update); NIST IR 8547 ipd, “Transition to Post-Quantum Cryptography Standards,” November 2024, §4; European Commission, “Cyber Resilience Act,” EC digital-strategy CRA page, and EUR-Lex, Regulation (EU) 2024/2847; The White House, NSM-10 §3(a), May 4, 2022, bidenwhitehouse.archives.gov.

That final column is the teaching point. Every one of these instruments is precise about when you must be done and silent about when an adversary can read your data. That silence is structural rather than an oversight: a regulator can only mandate what it can verify, and it can verify a migration date far more easily than an adversary’s capability. So the compliance corpus, read cover to cover, gives you exactly one of the two clocks.

For an organization outside the named populations, Clock 1 usually arrives through contract language instead: an agreement that requires “FIPS-validated cryptography” inherits the withdrawal dates of the approved list it points at, and the strictest jurisdiction the business touches sets the earliest date. Deriving that date from your own paperwork is its own discipline, and The Binding-Date Questions walks it in full. For this test, what matters is the output: one defensible calendar date per system.

How do you derive Clock 2, the threat date?

Clock 2 comes out of arithmetic on three facts about the system’s own data, and the arithmetic is short.

1. When can the ciphertext be captured? For data crossing networks under classical key exchange, capture is possible today, and the actor landscape documents collection as a present-day practice rather than a hypothetical. The capture date for exposed traffic is therefore now, or in the past.
2. How long must the plaintext stay secret? Health records, legal strategy, financial histories, and design data routinely carry required lifetimes of a decade or more. Add that lifetime to the capture date and you have the window during which a future decryption still counts as a breach.
3. When can the adversary decrypt? The arrival of a Cryptographically Relevant Quantum Computer (CRQC) is genuinely uncertain, so the input is a probability band rather than a year. The 2025 expert survey puts the likelihood of a CRQC able to break RSA-2048 within 10 years at 28–49%.

Source: Mosca, M. and Piani, M., Quantum Threat Timeline Report 2025 (numerical edition, published March 9, 2026, 26 experts; CRQC vs RSA-2048 at 28–49% within 10 years), Global Risk Institute / evolutionQ, globalriskinstitute.org.

Put the three together and Clock 2 reads differently than most people expect. For long-lived data on harvestable channels, the clock started at first capture: the adversary already holds the ciphertext, the commitment became irreversible on the day it was recorded, and the only open question is when the reading begins. That’s the sense in which Clock 2 for HNDL-exposed data sits in the past. The read date is unknowable; the exposure date has already happened.

The threat clock has its own arithmetic tradition: Mosca’s Theorem formalizes it as X + Y > Z, where required secrecy lifetime plus migration time is compared against time-to-break. Mosca derives the urgency on Clock 2. The two-clock test is the frame that then places Clock 1 beside it, because the organizations that get hurt are the ones running only the clock a regulator hands them.

What does the test look like on a real system?

Run it end to end on a generic case: a mid-size insurer whose claims records carry a 10-year confidentiality requirement, moving between data centers over TLS with classical key exchange through 2026, with a migration program pinned to the 2030 line that its FIPS-referencing contracts inherit from NIST IR 8547’s draft deprecation schedule.

1. State Clock 1. The contract chain points at the approved list, the draft schedule deprecates 112-bit RSA and ECC after 2030, so the program commits to completed PQC key establishment by December 31, 2030. The program hits it, and the January 2031 audit passes.
2. State Clock 2. Assume an interception point captured that TLS traffic during 2026, which the documented collection landscape makes a reasonable planning assumption for data this valuable. Records captured in 2026 must stay secret into 2036. The expert band puts a CRQC inside a 10-year horizon at 28–49%. Clock 2 therefore reads: started in 2026 at first capture, running to 2036, with double-digit probability that the reading capability arrives inside the window.
3. Compare. The migration protects sessions established after cutover. Every record that crossed the wire between 2026 and the 2030 cutover sits in the adversary’s archive in its original ciphertext, untouched by the migration, waiting on hardware. On audit day the system is fully compliant, and 5 years of captured records remain fully exposed.

Both statements are true on the same day, which is the entire point of the test. The audit measured Clock 1 and measured it correctly. Clock 2 was never on the audit’s instrument panel, and only a plan that states both dates can tell the board the whole sentence: “we met the mandate, and the 2026-to-2030 archive remains a live exposure with these probabilities attached.”

Common misconceptions

• “We passed the audit, so the data is safe.” The audit verified Clock 1. Every instrument in the mandate table is silent on Clock 2, so a clean audit is evidence about paperwork and process, and carries zero information about what an adversary’s archive already holds.
• “The deadline is when we need to start.” Compliance dates are finish lines. If the date is 2030 and the migration in front of it takes 5 years, the start date was 2025, and treating the deadline as a starting gun quietly concedes the entire interval to the harvest.
• “The company has one clock.” Every system runs its own pair. Clock 1 varies by jurisdiction and contract, with the strictest one the business touches setting the earliest date, and Clock 2 varies with each system’s data lifetime and capture exposure. An org-wide date is an average, and averages hide the systems that are already late.
• “Clock 2 is Q-Day, some year out in the future.” For long-lived data on harvestable channels, Clock 2 started at first capture. Waiting to react until a working machine is announced means reacting years after the loss became irreversible.
• “Regulators set the compliance date to beat the threat date.” Mandate dates are negotiated against migration feasibility, budget cycles, and standards maturity, and the threat estimates they were set against keep moving. Nothing in the process guarantees Clock 1 lands before Clock 2 for your particular data, which is why the mandates decline to promise it.
• “If we beat the threat clock, the compliance clock takes care of itself.” The clocks fail independently in both directions. A team that deploys PQC early can still miss a mandate that requires validated modules, because validation runs on its own schedule, so an ahead-of-the-threat deployment can sit non-compliant while the paperwork catches up.

Pro tips

• Give each clock its own risk-register row. One row for “mandate date missed,” one row for “data readable by adversary,” per system, each with its own owner, likelihood, and treatment, in The Cryptographic Risk Register. Merged into a single row, the compliance date always wins the framing, because it’s the one with a number a committee can see.
• Ask vendors which clock their roadmap answers. A “PQC-ready by 2030” commitment is a Clock 1 answer about future product versions. The follow-up that sorts serious vendors from brochure vendors: what happens to the traffic your product protected for the last decade? An evasive answer to that question is itself the finding.
• Write Clock 2 with its assumptions attached. Record the capture-exposure judgment, the required secrecy lifetime, and the expert band used, right in the register entry. The date survives an auditor’s challenge because the reasoning is inspectable, and it updates cleanly when the annual timeline survey moves.
• Re-run the test on events, both kinds. Clock 1 moves when mandates do: the IR 8547 draft finalizing, a harmonized standard being cited under the CRA, a customer contract renewing with new language. Clock 2 moves when the threat estimate does. A test run once in 2026 and filed away is a snapshot; the value is in the standing habit.

Where does the test break down?

The test assumes the two clocks can diverge, and for some systems they can’t.

Systems with no long-lived data collapse the distinction. Ephemeral telemetry, short-lived session tokens, and data whose value expires in weeks have a Clock 2 equal to the CRQC arrival itself, because there’s nothing worth harvesting today that will still matter when decryption arrives. For those systems the mandate date genuinely is the binding constraint, the two clocks converge, and running the test adds ceremony without information. The test earns its keep in proportion to data lifetime.

Signature and trust systems change Clock 2’s shape rather than removing it. Forgery requires the machine to exist at attack time, so there’s no backdated capture exposure on authentication itself, and Clock 2 reads as the arrival window. The nuance is that long-lived signed artifacts, firmware images, certificates, and archived documents whose signatures must verify for years, reintroduce the long-lifetime problem in trust form; the Forge-Later Attack covers that mechanics. The test still applies, with Clock 2 derived from trust lifetime instead of secrecy lifetime.

And where neither clock exists, the test is silent by design. A system with no mandate reaching it and no data outliving a routine refresh cycle is ordinary lifecycle management, and pretending it carries quantum urgency is the kind of overstatement that spends the credibility the genuinely exposed systems will need.

How do you use the test in a boardroom?

Deploy it the moment anyone offers compliance as safety, and in an executive setting that moment arrives constantly: the deck slide that says “on track for 2030,” the vendor pitch that says “fully compliant with the coming mandates,” the auditor’s summary that reads clean. The wield-upward form is a single sentence: “State both dates for this system.”

The answers sort themselves. A team that produces one date fluently and reaches for the mandate document when pressed on the second is running a compliance program, which is necessary and is also half the job. A team that states both dates, with the threat date carrying its assumptions, is running a risk program. Boards fund the second kind differently, because the second kind can say out loud what the audit can never say: whether the thing the company actually fears, disclosure of the data itself, is getting closer or further away.

The test also protects the board from the reverse failure. When a vendor or an internal champion argues urgency from the threat clock alone, the same discipline, both dates stated, forces the compliance obligations into the frame, so the program that gets funded satisfies the auditor and the adversary math at once instead of lurching between them.

Questions people ask

Is the two-clock test the same as Mosca’s theorem? They’re complements. Mosca’s Theorem is arithmetic on the threat clock: it compares secrecy lifetime plus migration time against time-to-break. The two-clock test places the compliance date beside that result and asks the plan to hold both. Mosca tells you whether Clock 2 makes you late; the test catches the organizations that never computed Clock 2 at all.

Can a system really be compliant and exposed on the same day? Yes, and the mechanism is mundane. Compliance is measured against a mandate date, exposure is measured against captured ciphertext plus data lifetime plus adversary capability, and the mandate documents are silent on the second measurement. A system that migrates on schedule in 2030 while its 2026 traffic sits in an archive holds both properties at once.

Which clock should drive the migration plan? The earlier one, decided per system. For systems holding long-lived confidential data on harvestable channels, Clock 2 almost always leads, because it started at capture. For systems with short-lived data, Clock 1 leads and the mandate schedule is honestly the constraint.

Where do I find Clock 1 for my organization? In the mandates that name you, and failing that, in your own contract language: any agreement requiring FIPS-validated or nationally approved cryptography inherits the withdrawal dates of the list it references, and the strictest jurisdiction you operate in sets the earliest date. The Binding-Date Questions derives it step by step.

What date do I write down for Clock 2 when nobody knows when a CRQC arrives? A range with recorded assumptions. Anchor the start at first plausible capture, run it for the data’s required secrecy lifetime, and attach the published expert band (28–49% within 10 years, per the 2025 survey) as the probability weight. A range with inspectable reasoning is defensible; a false-precision single year is what gets a register laughed out of the room.

Does the test apply to signatures and PKI? Yes, with Clock 2 reshaped. Authentication has no harvest exposure, since forging requires the machine at attack time, so Clock 2 is the arrival window. Long-lived signed artifacts pull the lifetime math back in on the trust side, which the Forge-Later Attack note covers.

Do vendor PQC roadmaps answer the threat clock? As shipped, they answer Clock 1: validation targets, default-algorithm changes, mandate alignment by a stated year. Their answer about already-emitted ciphertext, and about how existing deployments get re-keyed, is where Clock 2 lives, and it’s the question worth asking in the room.

Isn’t the compliance clock sometimes the harder one to meet? Often, and the test respects that. Validation pipelines, procurement cycles, and staged mandates like CNSA 2.0’s use-case schedule can make Clock 1 the tighter constraint even where Clock 2 is comfortable. The test never ranks the clocks in advance; it requires both to be stated so the ranking is a finding instead of an assumption.

---

Everything here is the map, given freely. When both dates need to be stated for your own estate, system by system, with the mandates traced and the exposure math quantified into a register that survives scrutiny, that’s the work I do. Request the workshop.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.