Digital trust is one of those terms that appears in board packs and vendor decks without ever being defined precisely. It usually gets discussed alongside privacy policies, certifications and transparency commitments — all of which matter.
Underneath those, though, sits a set of technical controls that do the actual work, and they are worth understanding on their own terms.
The four properties
Strip away the terminology and digital trust reduces to four things, each delivered cryptographically.
- Identity. Proof that a person, device or service is what it claims to be.
- Integrity. Assurance that data has not been altered in transit or at rest.
- Confidentiality. Assurance that only the intended recipient can read it.
- Non-repudiation. Evidence that an action took place, and who took it.
Certificates, digital signatures and encryption deliver all four. This is the layer that lets two systems who have never interacted establish trust automatically, in milliseconds, billions of times a day — and it is almost entirely invisible when it works.
What the data says about how organisations respond
Research published by the Information Commissioner's Office in October 2024 found that 55% of UK adults have had personal data lost or stolen, which is close to 30 million people.
The figures underneath that headline are the more instructive ones. Of those affected, a quarter received no support from the organisation responsible, and almost a third found out through the media rather than directly.
Those are not measures of technical control. They describe what happened after the incident — and that tends to determine whether trust survives it. Organisations that detect a problem, communicate promptly and support the people affected generally retain confidence. The response is as much part of the trust model as the encryption.
Where problems usually start
In cryptographic estate assessments, trust failures rarely begin with a sophisticated attack.
More often they begin with a certificate nobody owned — issued for a short-term project that became production, with the renewal reminder going to a mailbox nobody monitors. The service fails publicly, at an inconvenient moment, and the first anyone hears about it is from a customer.
Or they begin with a private key somewhere it should not be: hardcoded in source, sitting in a configuration file, copied between systems during a migration and never cleaned up. Breaches involving encrypted data almost never involve breaking the cipher. They involve finding the key.
Neither is a failure of cryptography. Both are failures of operational visibility, which is a more tractable problem and a less interesting one, which is possibly why it gets less attention.
Two changes worth planning for
Two things are raising the operational bar over the next few years, and both have fixed dates.
Public TLS certificate lifetimes are falling to 47 days by 2029, taking renewal frequency up roughly eightfold on every affected certificate. Processes that work annually will need rethinking well before then.
And the migration to post-quantum cryptography will eventually require replacing the algorithms underpinning much of this. That cannot be scoped without knowing which algorithms are in use and where.
Both depend on the same underlying capability: knowing what you have, and being able to change it without rebuilding systems around it.
A useful question to ask internally
Not "how many certificates do we have", which is a technical question a board cannot easily act on.
Something closer to: which business services would stop working if a certificate expired without anyone noticing, and could we answer that today?
It is a cheap question to ask and the answer tends to be clarifying either way. Establishing it costs nothing and it turns an abstract topic into a specific one.
We have written more on why digital trust depends on cryptographic controls rather than stated intent, and on why key management matters more than algorithm choice.
Unsung is a UK consultancy working exclusively on public key infrastructure and cryptographic systems. We are vendor-neutral and our consultants hold SC and DV clearance. More at unsungltd.com.
