Vericore · independent checks on other people's servers
The one layer your security tools cannot see
Every computer server has foundations — the instructions it follows before anything else can start, which set up the hardware and settle what the machine is. Everything runs on top of them, and once the building is up nobody looks at them again. Software inside the machine cannot see them. We check them from outside, on servers we do not run, 288 times a day.
We ask each server what its foundations are. The answer comes back from a chip, sealed as it leaves — it's a meter reading taken by the meter, not written down by the customer. On forty servers that is a million sealed readings a quarter, and not one of them is your word for it.
Nobody can create this record afterwards. Either it was taken at the time, or it does not exist. Most of what it shows is ordinary — a firmware update applied before anyone declared it, a machine rebuilt from a newer image — and increasingly it is not a person making the change at all, but a script, a pipeline or an AI agent moving at machine speed.
The moment it matters is later: diligence, a competitive bid, or the week a client's insurer starts asking. Everyone can say nothing changed. Hardly anyone can show it. Nobody at your end writes it, files it or chases it — a few hours of one engineer to set up, and then it runs without you.
In plain terms
It never looks inside.
The cryptographic mesh covers the shell and stops there. Nothing reads your files, and nothing of yours leaves the machine. What the mesh checks is the machine itself: that it is the one you registered, and that its foundations are as you left them. Every five minutes it is sealed and checked again. If anything moves, the checks come faster and somebody is told. Nothing is stopped, and the answer is written down either way.
Where this shows up
A run of certificates is a continuous record of change control at machine level, produced by a party with nothing riding on the answer and no ability to alter it afterwards. That is not the same as saying you have good change control. It is being able to hand someone else the evidence.
- In a sale process
- Diligence asks how change was controlled. The answer is a run of certificates rather than your own account of it.
- In a competitive bid
- Every provider asserts good change control. Few can hand over somebody else's record of theirs.
- When a client is asked
- Their own customer, insurer or auditor wants to know how they know. They come to you, and you have something to give them.
Providers who can show it are in a different conversation from providers who can only say it — in a bid, in diligence, and in what a buyer will pay.
Three things worth saying first
You could build the measuring.
The platform ships the attestation. The measurement layer is open source and has been for years. An engineer who already works in attestation could assemble what we assemble, and we would rather say so than have you work it out. What you cannot build is a signature that means something precisely because it is not yours.
Almost nothing ever changes.
Correct, and that is what makes the record worth keeping. Evidence is easy to produce when something happened. Showing that nothing did — months later, to someone with reason to doubt you — is the hard case, and it cannot be assembled after the fact.
It covers very little.
Boot chain and machine identity. Not credentials, not applications, not anything that happens inside a machine while it is running. A machine that starts clean and is compromised afterwards measures as stable.
Those five take effect before the operating system loads, so tooling that runs inside the operating system is not positioned to observe them. It is the other way round for almost everything else: those tools see what this does not, and this sees what they cannot. A narrow claim a reader can check is worth more than a broad one they cannot.
What a certificate records
Changes declared in advance never appear on it. They are excluded by design, before the measurement is taken. So everything on a certificate is a change that was not declared, or a gap in measurement — set against the hours that were measured, the hours inside declared change windows, and the hours with no measurement at all. Three figures, never combined into one.
In infrastructure, everyone marks their own homework.
Not because anyone is dishonest. Because there has rarely been anybody else to do it. The measurement here does not distinguish intent and does not try — whoever has to establish that later needs fixed points that were not shaped by anybody's view of what happened, including ours. A change to these five things is recorded when it happens, by a party outside the estate, rather than reconstructed afterwards from whatever survived inside it.
A specimen certificate is available on request.
If you are reading someone else's
Three steps, without contacting us and without a network connection: compare the key fingerprint against the one in their engagement letter, check the signature, and ask for the certificates either side. Positions are never skipped, so a missing number means one was withheld rather than never issued.
What it establishes, and what it does not, is set out on the certificate itself.
The mechanics, if you want them
Three pictures. Most readers do not need them, and nothing above depends on them.
01 What is measured
02 When one stops matching
What produces this
- A firmware update pushed by the hardware vendor and applied before it was declared.
- A bootloader patch in a maintenance window that ran past the end declared for it.
- A machine rebuilt from a newer image than the one registered against it.
- A vendor image trialled on one machine and never registered.
Ordinary operational causes. A deliberate change to firmware or a bootloader produces the same entry as an undeclared patch: the measurement does not distinguish intent and does not try. The cause recorded alongside an event is what the operator reported.
03 When it is not the same machine
What produces this
- An instance replaced automatically by scaling, built from a different image.
- A machine restored from a snapshot of an earlier build.
- A workload moved onto different hardware, which presents a different identity.
- A registered machine terminated and a replacement brought up under the same name.
The record states what was measured and when. Whether a substitution was routine is a question for the operator and their own records.
On the rules
The Cyber Security and Resilience Bill is before the House of Lords; the duties it creates are expected to apply from around 2028 through secondary legislation. It brings managed service providers and designated suppliers into scope, and organisations already in scope are required to manage their suppliers.
The same pattern runs through NIS2 and, more explicitly, DORA, which requires financial entities to manage their technology providers by contract and to keep a register of them.
The consequence is not that anyone must buy this. It is that evidence requirements move down the supply chain, and providers are asked to show something rather than state it.
A certificate is evidence supporting an obligation. It never discharges one.
Vericore Technologies Limited is a London company, founded by James Franklin, who spent a decade in specialist cyber underwriting — underwriting complex accounts, and designing products that translate the approaches of Fortune 1000 companies into the wider economy — and served on the International Underwriting Association's Cyber Underwriting Group. Much of that work was spent with boards, and with the people who answer to them, on risks they were being asked to take a view on.
Almost everything anyone in those conversations knows about an organisation's infrastructure is what the organisation says about it, drawn from records it keeps itself. The limits are understood on both sides of the table, and it persists because for infrastructure there has rarely been anything else. This is one narrow exception.