Discover
Instrumented inventory of cryptographic assets, dependencies and protocol behaviour across the estate — including the inherited and forgotten.
Produces: An evidenced inventory, with an explicit record of what could not be reached and why.
Applied Cryptography & Quantum-Safe Readiness
Your exposure started before the machine exists.
Encrypted traffic captured today can be decrypted years from now, by an adversary who only has to wait. That makes quantum readiness a question about the data you are protecting right now, not about a machine that arrives later. Most organisations cannot answer the first question that follows: where does our cryptography actually live?
2Doctorate-level applied cryptographers in the practice
6Weeks to a board-ready readiness assessment
4Cryptographic jobs your estate depends on — each affected differently
The uncomfortable truth
A report that treats encryption as one thing cannot say anything useful.
Cryptography does four separate jobs in your estate. It keeps content secret, so an interceptor learns nothing. It detects alteration, so a changed message is recognised rather than accepted. It proves origin, so a receiver knows who sent something. And it makes that proof undeniable, which is the property your contracts, audit trails and financial records actually rest on.
Those are different jobs. They use different mathematics. And — this is the part that determines whether any of the advice you have been given is worth acting on — quantum computing affects them very differently. Some are barely touched. Others are structurally broken.
A readiness report that says “we assessed your encryption” has already failed, because it has collapsed four distinct exposures into one word. You cannot sequence a migration from that. You cannot cost it, and you cannot defend it to a regulator.
Ask any vendor which of the four jobs they assessed. The answer tells you whether you bought an assessment or a template.
Bounding the problem
The exposure is severe and it is specific. It is not everything.
Two algorithms, both published more than thirty years ago, define the threat. Their consequences are asymmetric and well understood, and the asymmetry is good news that almost never survives contact with a vendor pitch.
Shared-secret and hash-based constructions are weakened but survive, with adjustments that are largely tractable. Public-key cryptography — the part that lets two parties who have never met establish trust — does not survive. And because that is the mechanism sitting underneath essentially all internet-scale security, the break propagates a long way past the places you would think to look.
Longer keys do not help. This is not a problem of insufficient key length, and any remediation plan whose first move is to increase key sizes was written by someone who has not understood the mechanism.
The practical consequence: this is a dependency-tracing exercise before it is a cryptography exercise. The question is not which algorithms you use. It is which of the things you depend on inherit a break they never declared.
The discovery problem
Nobody knows where their cryptography is. That is the normal finding.
Ask an engineering organisation to inventory its cryptographic dependencies and you will get a document listing the places people remember. It will omit the certificate embedded in a device fleet, the signing key in a build pipeline nobody has touched in four years, the library three layers down a dependency tree, the hardware security module protecting a system that was decommissioned but not disconnected, and the protocol negotiated at runtime that silently falls back to something older.
This is not incompetence. Cryptography is deliberately invisible when it is working. It is configured once, by someone who has since left, and then it simply does not surface again until it fails or until someone asks a question like this one.
So discovery has to be tooled. A questionnaire returns the estate people can recall; instrumentation returns the estate that exists. The gap between those two is consistently the most uncomfortable finding in any assessment, and it is the reason the assessment is worth commissioning at all.
The inventory your team can produce from memory is not wrong. It is just not the estate.
Standards
Several bodies have published. Only some of it binds you, and it does not all agree.
There is now a substantial body of published standards and national guidance on post-quantum migration. It is genuinely useful, and it is where any competent programme starts. It is also not a plan, for three reasons that surface immediately in real work.
Different bodies are answering different questions. Some publish the algorithms. Some publish the migration process. Some publish sector obligations. Reading the wrong document for your question produces confident, misdirected effort.
Only a subset actually binds a given organisation. The rest is advisory, and treating advisory guidance as mandatory is how migration budgets get spent in the wrong order. Establishing what genuinely binds you is a determination, not a lookup.
In places, the published guidance conflicts. Recommendations from different authorities diverge on real questions — not edge cases, but decisions you have to make early and cannot easily reverse. Resolving those conflicts for a specific estate requires someone who can reason from the underlying mathematics rather than reconcile two documents by picking the more recent one.
Some of this guidance is also still in progress and expected to change. A migration architecture that assumes today’s published position is final has built in a rework cost it has not budgeted for.
We tell clients where these conflicts fall and how we resolve them for their estate. We do not publish that analysis, because it is the part of the work that is genuinely ours.
Method
Five stages, each producing evidence rather than opinion.
Assess
Risk-ranking against the four cryptographic jobs, the data’s required confidentiality lifetime, and the obligations that actually bind you.
Produces: A prioritised exposure register a board can read and an engineer can act on.
Plan
Sequenced migration with dependency ordering, cost analysis and the decisions that must be made before anything is changed.
Produces: A costed, ordered plan with the trade-offs stated.
Migrate
Execution, including running old and new schemes together through the transition, which is where most of the operational risk actually sits.
Produces: Working systems, and the evidence that they work.
Adapt
Cryptographic agility, so the next transition is a configuration change rather than a programme.
Produces: The capability to do this again without repeating the cost.
Existing frameworks cover parts of this competently. They stop at the points where a general framework cannot help — the determinations, the conflicts, the estate-specific trade-offs. Those stages need an applied cryptographer, and that is where we work.
Engagement
Six weeks, fixed fee, a defensible artefact at the end.
Stages 01 and 02, delivered as a defined engagement with a fixed fee and a fixed duration. No discovery phase to scope the discovery phase.
What you get
- An evidenced inventory of cryptographic assets and dependencies, including what discovery could not reach
- A risk-ranked exposure register, mapped to the four cryptographic jobs and to your data’s confidentiality lifetime
- A determination of which published obligations actually bind you, with reasoning
- The decisions you must make before migration begins, and what each one forecloses
- An explicit statement of what this assessment does not establish
Why the artefact matters beyond the findings
Boards, auditors and regulators are beginning to ask what an organisation has done about this. An evidenced assessment with stated limitations is a defensible answer. An internal spreadsheet is not, and a vendor report that overclaims is worse than either — it creates a documented position you may not be able to sustain.
Book a readiness conversation Limits
We would rather lose the engagement than overstate the finding.
There is real, active uncertainty in this field, and any advisor who does not volunteer it is either not close enough to the research or is selling you something.
Nobody can tell you when.
Credible published estimates for when a relevant machine exists span a wide range, and the range is moving in both directions as engineering advances and as resource requirements are revised. We will give you the state of the published position and what would constitute a genuine warning sign. We will not give you a date, and you should decline to work with anyone who does.
An assessment cannot prove absence.
Discovery finds what instrumentation can reach. Coverage gaps are stated explicitly rather than presented as clean results, because a clean result you cannot trust is worse than a partial one you can.
It does not establish that you are secure.
It establishes what you have, what is exposed, and in what order to act. Those are different claims, and conflating them is the most common failure in this market.
Some guidance will change.
Parts of the published standards landscape are still in progress. A plan built today needs to be revisable, and we build it that way.
The claims we refuse to make are a better guide to the quality of the work than the claims we do.
Risk
The transition introduces its own failure modes.
Replacing working cryptography is not a neutral act. Migrations create new exposure in several predictable ways — through the operational cost of new schemes landing unevenly across an architecture, through classes of algorithm that carry constraints most teams have never had to manage, through the period where old and new run alongside each other, and through the temptation to remediate the visible before the important.
We flag these before the plan is written, not during execution. A migration programme that discovers its own risk model in month five has already lost the confidence it needs to finish.
The team
Cryptographers, not generalists with a checklist.
In applied cryptography, the practitioners are the credential. This practice is led by two applied cryptographers, both holding doctorates in the field, who work as consultants in production alongside the rest of our engineering practice — on systems where cryptographic failure has consequences, not in an advisory function separated from delivery.
We maintain cryptographic components in production on public blockchain infrastructure, where the code is open, the failures are visible, and the review is adversarial by default.
Start here
Start with the question you cannot currently answer.
Tell us what you are protecting and how long it has to stay protected. We will come back with an honest view of your exposure, what a six-week assessment would establish, and what it would not.
- Evidenced cryptographic inventory & exposure register
- A determination of what actually binds you
- Sequenced migration — we can own it end to end
Want the field guide? Ask for it here — we’ll send it with the readiness conversation.
Let’s talk
The clock started when the traffic was captured.
Harvest-now-decrypt-later means quantum readiness is about the data you hold today. Find out where your cryptography actually lives — and what to do about it, in what order.