Most organisational trust rests on promises: contracts, certifications, and terms of service. Cryptography offers something different — guarantees that hold regardless of whether anyone keeps their word.
Part 1 of 10 in Trust through mathematics
Ask most organisations why they trust a supplier with their data, and the answer, once unpacked, is a stack of paper. A contract with a confidentiality clause. A SOC 2 report. An ISO 27001 certificate. A data processing agreement. Perhaps a redacted penetration-test summary. Each of those documents says, in essence, the same thing: we promise to behave.
Promises are not worthless. Commercial law exists, breach of contract carries consequences, and certification regimes do raise the floor of acceptable practice. But be clear-eyed about what a promise actually protects you from. A contract does not prevent a breach; it allocates liability after one. A certification does not stop an insider; it confirms that, at the time of audit, certain processes existed. Terms of service can be changed, acquired companies can be re-platformed, and well-intentioned suppliers can be compelled by courts or governments to do the very things they assured you they never would.
There is another way to establish trust, and it behaves quite differently.
Two Kinds Of Trust
It helps to distinguish assured trust from verifiable trust.
Assured trust is what contracts, audits, and certifications provide. You believe the other party will behave because they have said so, because a third party has inspected them, and because misbehaving would cost them. The guarantee lives in incentives and consequences; it is, at bottom, a bet on human and institutional behaviour.
Verifiable trust is what cryptography provides. When a message is end-to-end encrypted with sound algorithms and sound key management, the service operator cannot read it – not because they have promised not to, but because doing so would mean solving mathematical problems that are computationally infeasible. The guarantee does not depend on the operator’s honesty, their staff vetting, their acquisition history, or the jurisdiction they wake up in next year. It holds even when every one of those things goes wrong.
The practical difference is stark. A promise can be broken silently, and you typically discover a breach of assured trust months later, through a regulator or a journalist. A cryptographic guarantee, properly built, cannot be broken silently by the party it constrains. It can only be circumvented at the endpoints or through implementation flaws – which narrows the attack surface to something you can actually reason about.
Why This Distinction Is Becoming Operational
For a long time this was a philosophical point, of interest mainly to cryptographers. Several developments have made it a board-level one.
First, the supply chain has become the attack surface. Organisations now depend on layers of suppliers, each of whom depends on layers more. Every link in that chain is an assured-trust relationship, and the past decade of supply-chain incidents has shown what that assurance is worth under pressure. The UK’s National Cyber Security Centre has been steadily raising its expectations on supply-chain security precisely because contractual assurance has proved such a weak control.
Second, jurisdiction has become unstable. Data that is lawfully protected today may be lawfully accessible tomorrow, without your supplier doing anything but complying with a new legal demand. Contractual promises are bounded by law; cryptographic guarantees are not. If the operator holds the keys, who can read your data is ultimately a legal question. If you hold the keys, it is a mathematical one.
Third, the cost of verification has collapsed. Twenty years ago, building systems that mathematically excluded the operator from the data was exotic and expensive. Today, end-to-end encryption, client-side key generation, hardware-backed key storage, and verifiable build pipelines are well-understood engineering. The tools have caught up with the principle.
What Shifting Trust Actually Looks Like
Moving trust from contract to mathematics is not a slogan but a set of specific design decisions, each of which can be asked about plainly in procurement.
Who generates the keys, and where? If encryption keys are generated server-side, or escrowed by the provider “for recovery purposes”, the cryptography is decorating an assured-trust relationship rather than replacing it. Keys generated and held on the client’s own devices change the answer at the root.
What can the operator see? Not what they promise to look at, but what they are technically capable of seeing: message content, metadata, access patterns, file names. The honest answer for most platforms is “rather a lot”, and the documentation seldom volunteers it.
What happens if the operator is compromised, compelled, or acquired? This is the question that separates the two models cleanly. In an assured-trust system the answer is “your data is exposed”. In a verifiable-trust system the answer should be “nothing changes, because the operator never had the ability to expose it”.
Can the claims be checked? Published protocols, independent audits of the cryptographic design, reproducible builds, and open standards all move a system towards verifiability. “Proprietary military-grade encryption” moves it the other way – a phrase we return to at the end of this series.
The Limits, Stated Plainly
It would be convenient to claim that mathematics solves trust outright. It does not, and anyone who implies otherwise should be treated with caution.
Cryptography protects data in specific states against specific adversaries. It does not protect a compromised endpoint: if an attacker controls the device where content is decrypted and displayed, no algorithm helps. It does not, on its own, protect metadata – who communicated with whom, when, and how often – which is frequently more revealing than content. And it is only as strong as its implementation and its key management; the notable cryptographic failures of the past have almost all been failures of engineering or operations rather than of the underlying mathematics.
Nor does verifiable trust remove the need for assured trust. You still need contracts, because cryptography says nothing about service availability, support quality, or commercial conduct. The point is not that contracts are obsolete. It is that contracts should be doing the work only contracts can do, and mathematics the work it does better – and the most common architectural failure we see is the inverse: contracts straining to cover risks that a different system design would simply have removed.
A Question to Ask
Our own work has pushed us steadily towards this principle. When we conducted a national-security review of outsourced defence logistics for the Ministry of Defence, the central question was not whether the provider intended to behave well – it plainly did – but what the country’s position would be if intentions ceased to matter. Designing for the case where assurance fails is not cynicism. It is the discipline that separates resilient architectures from hopeful ones.
So the question to put to any system that holds something you care about is a simple one. If every promise this supplier has made were broken tomorrow, what would actually protect you? If the answer is “the contract”, you have a liability position. If the answer is “the mathematics”, you have a security one. Most organisations, examined closely, have rather more of the former than they realise, and the gap between the two is where the next decade of serious incidents will live.
This post opens a series on trust through mathematics: what modern cryptography can and cannot do for organisations, how to weigh the claims made about it, and what changes when machines, as well as people, begin deciding whom to trust.