White paper · Matrix CR Studio
Evidence you can check without us.
Regulated organizations now face two questions that look unrelated and are not. Which of our cryptography will a quantum computer break, and can we show a plan to replace it? And when software and AI agents do work on our behalf, what can we show afterwards about what they did?
Both are questions about evidence. In both, the usual answer is a report whose authority rests on trusting whoever wrote it. This paper describes the approach we work by: seal each step of the work into a signed, linked record the client keeps, give anyone a free checker that verifies it on their own machine, and publish our own claims with their status, including the ones we got wrong.
It also states what this does not prove, and how far it has been exercised. As of 2026-09-24, 0 of 1 published receipt has been recomputed and declared by a party outside the studio. That number is here because a method built on being checked is worth what people actually check.
1 · The quantum timeline
Two probabilities and several deadlines.
Nobody knows when a quantum computer will break today’s public-key cryptography. No quantum computer has yet broken a key of the size in real use. Two things do not wait for that answer. An attacker who records traffic protected by today’s public-key key exchange can hold it until that cryptography fails. And the deadlines are published. Each binds different organizations, and a date is only as strong as the body that sets it.
chance of a cryptographically relevant quantum computer, within 10 years
chance of a cryptographically relevant quantum computer, within 15 years
Probability bands from the Global Risk Institute Quantum Threat Timeline Report 2025 (Mosca and Piani, published March 2026, 26 experts surveyed).
Issued 22 June 2026
US federal agencies, for high value assets and high impact systems. It also directs a proposed rule requiring covered federal contractors to comply with NIST post-quantum standards by 31 December 2030.
31 December 2030. Post-quantum key establishment
31 December 2031. Post-quantum digital signatures
Issued 23 June 2025
A recommendation to EU Member States, not a law that binds a firm directly. It cites DORA and NIS2 as rules that already require state-of-the-art cryptography.
31 December 2026. National transition plans and first pilots
31 December 2030. High-risk use cases transitioned
31 December 2035. Medium-risk use cases transitioned
Issued 12 November 2024
US guidance, still a draft. US agencies must align their plans with it.
31 December 2030. Classical key establishment deprecated
After 2035. Classical public-key algorithms disallowed
The executive order’s own words, from the Federal Register text: agencies are to “transition all HVAs and high impact systems to use PQC for key establishment by December 31, 2030” and “for digital signatures by December 31, 2031”, with National Security Systems excluded, and the FAR Council is to “publish a proposed rule amending the Federal Acquisition Regulation (FAR) to require covered contractors to comply by December 31, 2030”. A proposed rule is not yet a rule. Read the order
What already binds EU financial entities
DORA has applied since 17 January 2025 (Article 64). Its technical standard on ICT risk does not mention quantum computers. It does require the following, quoted from the text.
“provisions for updating or changing, where necessary, the cryptographic technology on the basis of developments in cryptanalysis”
Your encryption policy has to say how you will replace cryptography that stops being safe.
“a requirement to record the adoption of mitigation and monitoring measures adopted in accordance with paragraphs 3 and 4 and to provide a reasoned explanation for doing so”
Where you cannot update yet, you record what you did instead, and why.
“managing cryptographic keys through their whole lifecycle, including generating, renewing, storing, backing up, archiving, retrieving, transmitting, retiring, revoking, and destroying those cryptographic keys”
Retiring a key is part of the policy, which is what a migration does to every quantum-vulnerable key.
“a register for all certificates and certificate-storing devices for at least ICT assets supporting critical or important functions”
You need to know where your certificates are before you can replace them.
In our reading, a quantum computer that breaks today’s public-key algorithms is a development in cryptanalysis. That reading is ours, not the standard’s. These articles sit in Title II of the standard; smaller entities listed in DORA Article 16(1) follow the simplified framework in Title III instead. DORA · the technical standard · our page on DORA
These are our summaries of public texts. They are not legal advice.
2 · The evidence gap
From “what did the user do?” to “what did the system do?”
When a person made a change, the log showed what they typed. When an automated system takes fifty steps from one instruction, an auditor asks what the system did, and whether the record of it was touched afterwards. That record cannot be written after the fact. An organization keeps it from the start, or does not have it.
In a 2026 Grant Thornton survey of nearly 1,000 US senior business leaders, 78 percent were not fully confident they could pass an independent AI governance audit within 90 days. Grant Thornton, April 2026
The EU AI Act requires automatic logging for high-risk AI systems (Article 12). The 2026 Digital Omnibus moved that deadline to December 2027, and to August 2028 for AI inside regulated products such as medical devices. The requirement stands. The Act asks for logging. It does not ask for the log to be tamper-evident or checkable by an outside party. That is a property we add, not one the statute requires. EU AI Act · Regulation (EU) 2026/1744
A scan summary, a dashboard, or a PDF signed off by the vendor all share one weakness: the reader has to trust the party that produced them. Accounting settled this long ago with the ledger and the counterfoil, the stub you keep when a ticket or check is issued. Automated work needs the same thing.
3 · The method
Find, rank, plan, keep the evidence.
- 01
Find
Every place the organization uses cryptography: code, libraries, certificates, network connections, and key management. Each finding records where it was seen.
- 02
Rank
Each asset by one test: how long the data must stay secret, plus how long the migration takes, against the horizon the organization plans for. If the first two add up to more than the third, the asset is exposed. The horizon is the organization's own planning assumption. We do not supply a date for the arrival of a quantum computer, because nobody has one.
Try the exposure test - 03
Plan
A migration to the NIST post-quantum standards, usually running old and new side by side first, with a way back at every phase.
Try the algorithm selector - 04
Keep the evidence
A signed, linked record of the work that the client keeps and an auditor can check without us. The assessment tooling seals each step, the cryptography inventory, the exposure ranking and the migration plan, as linked receipts in one evidence file.
How Counterfoil works
The ranking test is the inequality Michele Mosca proposed: with X the years the data must stay secret, Y the years the migration takes and Z the years until a quantum computer can break the cryptography, an asset is exposed when X + Y > Z.
A complete worked example is public: an assessment of paramiko 5.0.0, an open-source SSH library, not a client, with the three sealed steps in one evidence file that verifies in the browser or offline. That one reads source code. A client assessment can also measure what the client’s servers negotiate. See the assessment
4 · The record format
Counterfoil: record, link, sign, check.
Each step is written down: what ran, what it found, and when. Each record carries a SHA3-256 hash of the record before it, in one linear chain, so changing or removing any record breaks every link after it. The finished chain is signed with our Ed25519 key. Anyone can then run the checker on the receipt, on their own machine. It is one Python file. It needs no account and makes no network calls, and its only dependency is the open-source cryptography package, which includes compiled code of its own.
By default the checker requires our key, comparing the whole public key, so a receipt sealed by any other key fails. A reviewer can name a different expected key, or skip the identity check, in which case the checker reports identity as not checked, never as passed.
A receipt contains fingerprints of the input and output, not the raw content, so it can be handed to an auditor without handing over the data behind it. One caution: a fingerprint of a short or guessable input can be confirmed by anyone who guesses the input. A receipt hides content. It does not hide content that is easy to guess.
The record has not been changed since it was sealed. Any edit, deletion or reordering fails the check.
The claim you are shown is the one that was sealed.
It was sealed with our published key.
That what was recorded was true. A record can be intact and the event behind it wrong.
That nothing happened off the record.
That the key is ours, unless you take it from a source you trust.
That no second, different receipt exists. The copy you hold cannot be changed without the check failing. Whoever holds the signing key could still seal a different record, and without an independent timestamp both would pass. Your copy, kept from the day it was issued, is what protects you.
That the tools were correct, that a scan saw every file that matters, or that the plan is the right one.
The limits of the seal itself
A paper about cryptography that ages should apply the test to its own format. These limits stand today.
The seal is a classical signature
The chain is SHA3-256. The best known quantum attack on a hash, Grover's algorithm, would lower its preimage strength to roughly 128 bits, which is still out of reach. The seal is Ed25519, which a large enough quantum computer would break. A receipt that has to stay convincing past that point needs a post-quantum seal or an independent timestamp. Neither is in the published format yet.
One key, pinned in the checker
The published checker pins a single signing key. It carries no revocation list, and a receipt carries no independent timestamp. If that key were compromised, a receipt alone could not show whether it was sealed before or after. Publishing key rotation and revocation alongside the checker is open work.
The fingerprint is a label, not the pin
The 16-character fingerprint a receipt prints is the first 64 bits of the SHA3-256 hash of the public key. That is too short to be a trust root: a well-resourced attacker could in principle search for a different key that shares it. Until 6 October 2026 the checker's default compared only that fingerprint. A review of this paper found it, and the checker now compares the full public key. A fingerprint is still accepted on request, and the verdict then says that only the fingerprint was compared.
The hardware signature is not checked by the free checker
A receipt can carry a second signature from a hardware chip (TPM 2.0). The free checker does not verify it yet, so treat it as our statement, not as something you have verified.
No outside review yet
The checker and the format have not been audited by an independent party.
One property does not depend on us at all. The checker is a single file that runs offline. A client who keeps the checker, the receipt and the public key can verify that receipt for as long as they can run Python and the cryptography package, whether or not Matrix CR Studio or this website still exists.
Testing the checker itself
A checker that passes everything is worthless. We publish a set of 26 conformance vectors, each a named attack on a receipt together with the verdict a correct checker must return. Anyone who writes their own checker, or doubts ours, can run it against the set:
python verify_counterfoil.py --benchmark counterfoil_conformance_vectors.jsonConformance proves agreement with the reference on these named attacks. It does not prove the absence of other bugs.
These digests are computed from the served files when the site is built, so they identify the versions you can download now. They are plain SHA-256 because every common system has a built-in tool for it. Verify it yourself, step by step
5 · AI agents
The same discipline for agents.
The hard question about AI agents is not what they can do. It is what an organization can show, afterwards, about what they did. We apply the same rule to agents that we apply to assessments: constrain the action in code, record every attempt, and seal the record.
In our own stack today, every shell command our agents attempt goes through an allowlist, actions are tiered by scope and an action above its tier raises an error, and every attempt, allowed or refused, is logged with the reason. Receipts for agent actions and post-quantum keys are built and tested. Agreement across several nodes and identity bound to hardware are not finished. The status of each piece is kept in one place. Each piece, with its real status
Four limits belong next to that. Every status is our own statement about our own stack, and the command log behind it is an internal record a reader cannot open. We have not yet deployed this for a client. The command log is an ordinary database table: it records every attempt, but it is not tamper-evident by itself, which is what sealing records into receipts adds. And we do not claim immunity to prompt injection. The gate limits what an agent can do. It does not make the model trustworthy.
The design assumption underneath is that a model states a made-up fact as confidently as a true one. So the gate does not depend on the model being right, and we treat every model, including our own, as an untrusted source.
6 · Holding ourselves to it
A firm that sells checkable evidence has to be checkable.
of our public technical claims are marked corrected, next to the original. Registry updated 2026-09-18
Read the claims registrypublished receipts recomputed and declared by an outside party, as of 2026-09-24. Our own runs never count
Recompute one and declare itThe corrected rows include results we published in March 2026 that turned out to have been computed on a simulator, not the quantum hardware they were labeled with. We found it and corrected it in public.
IBM issues a job ID when a job is submitted, so we cannot create one later to fit a story. The job pages are visible only inside our account, so the ledger is a record we cannot edit, not a page a reader can open. An ID shows that a job was submitted at that time. It does not by itself show which circuit the job ran. The ledger is here as a record of how we handle our own claims. It is not offered as a post-quantum migration capability.
The recomputation count is a floor. Declared means a signed attestation file, written by the checker and sent to us. The checker never reports back, so a check nobody tells us about is invisible, and the figure counts signing keys, not people. We print it because it is the honest measure of how far the central claim of this paper has been exercised by others. The format is built to be checked. It has not yet been checked by anyone who would tell us.
A demonstration that one of our claims overstates its floor is a finding we want. How to overturn a claim
What we do not do
- Touch a client's systems without written permission. Before an engagement we read only what is public.
- Sell attack tooling. We build it to test our own defences, and it never leaves the studio.
- Present an unchecked result as checked.
- Give legal or investment advice. Legal conclusions belong to the client's counsel.
- Predict the arrival of a quantum computer.
- Claim that a receipt makes the underlying work correct.
7 · Where to start
Check us before you write to us.
The work is aimed at regulated organizations, with a focus on regulated finance in Latin America and the EU, and at organizations that cannot send their data to a cloud AI. An engagement starts with a two-week readiness assessment: what cryptography the organization runs, where the exposure is, and what its auditor will see. The deliverable is a document and an evidence file the client owns.
Before any conversation, run the checker in your browser on the sample receipt, change one field and watch it fail. Then read the claims registry, starting with the corrected rows. Our scanner, PQC-Scout, is open source under the Apache 2.0 license. Read it before you trust it. PQC-Scout on GitHub
Regulatory and survey texts were read at their primary sources: the executive order, the DORA technical standard, the AI Act and Regulation (EU) 2026/1744 on 6 October 2026, the EU roadmap and NIST dates on 19 September 2026, and the survey on 30 September 2026.