Vericore · independent checks on other people's servers

The one layer your security tools cannot see

Every server has foundations — the instructions it follows before anything else can start. Software inside the machine cannot see them. We check them from outside, on servers we do not run, 288 times a day, and write down what we find.

It never looks inside.

Nothing reads your files, and nothing of yours leaves the machine. The cryptographic mesh covers the shell and stops there: it checks that this is the machine you registered at the time, and the foundations are as you left them.

Each 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. If anything moves, the checks come faster and a named person is told. Nothing is stopped, and the answer is written down either way.

5things checked on each server as it starts

288checks per server per day

0changes we make to your servers, ever

Where this shows up

Nobody can create this record afterwards. Either it was taken at the time, or it does not exist. It matters later, when someone asks how change was controlled and your own account of it is not enough.

Increasingly, the change is not made by a person at all, but by a script, a pipeline or an AI agent moving at machine speed. The more of it that happens without anyone watching, the more the record is worth.

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 customer, insurer or auditor wants to know how they know. They come to you, and you have something to give them.

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.

Is it built?

Yes. The code exists.

The agent that asks each server for its reading, the service that checks the reading against your baseline and signs the result, and the workflow that lets planned maintenance pass without raising anything.

We did not build the part that does the measuring, and would rather say so first. The chip and the signed reading are the cloud platform's; the measurement layer is open source. An engineer who works in attestation could assemble the same. What cannot be assembled is a signature that means something precisely because it is not yours.

For the engineering mind

Role: Independent of whoever runs the machine. The machine reports, we check, someone else relies.
Evidence: A reading of the boot chain, signed by the server's own hardware and tied to a fresh challenge each time. A replayed reading does not check out.
Platform: AWS.
Footprint: One small agent per instance. Outbound only, to one fixed address. No inbound ports.
Permissions: Reads the measurement. Cannot stop, restart, isolate or change credentials on anything, at any severity.
Leaves the box: Boot measurements and the machine's identity. No files, logs, memory or workload data.
Cadence: Continuous. More often when something changes.
Fits in: Alerts land in the ticketing and on-call tools your team already runs, not another console. One incident per event, updated rather than repeated. Exactly where, and how, is set with each partner.
Out of scope: Everything after boot. A machine compromised at runtime attests as stable.

How readings are checked, signed and kept is the part we walk through on a call.

Two things worth saying plainly

It covers very little.

Boot chain and machine identity. Not credentials, not applications, not anything that happens inside a machine while it runs. A machine that starts clean and is compromised afterwards measures as stable. Tools inside the operating system see what this does not; this sees what they cannot.

Almost nothing ever changes.

Correct, and that is what makes the record worth keeping. Showing that nothing happened — months later, to someone with reason to doubt you — is the hard case, and it cannot be assembled after the fact.

What a certificate records

What changed that nobody declared, and how much of the period was actually measured. Nothing more.

In infrastructure, everyone marks their own homework.

Not because anyone is dishonest; because there has rarely been anybody else to do it. The measurement does not distinguish intent and does not try. It records a change when it happens, from outside the estate, rather than reconstructing it afterwards from whatever survived inside.

Anyone handed a certificate can check it themselves, without contacting us.

See it run

Twenty minutes, on a call.

A reading taken and checked while you watch. A value changed, and what follows: who is told, what speeds up, what is left alone. Then the certificate that comes out the other end.

If it fits your estate, the next step is small: two or three of your own servers, and a few hours of one engineer.

Ask for a walkthrough

The mechanics, if you want them

Three pictures. Nothing above depends on them.

01 What is measured

Five things, measured once as a machine starts: firmware, bootloader, boot manager code, boot configuration, and the identity of the machine itself. Each is checked against a registered baseline and the result recorded. Everything to the right is the machine doing its work, and none of it is measured here.

02 When one stops matching

A measured value no longer matches the baseline registered for that machine. It is classified, one named person is told, and the checks come faster. No instance is stopped, no credential revoked, nothing gated — and a change declared in advance raises nothing at all.

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 produces the same entry as an undeclared patch: the measurement does not distinguish intent. The cause recorded alongside an event is what the operator reported.

03 When it is not the same machine

The mark in a position is not the one registered for it: a different machine is presenting itself as the one under measurement.

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, now before the House of Lords, brings managed service providers into scope. NIS2 and DORA already push supplier oversight down the chain. The effect is not that anyone must buy this. It is that 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 and served on the International Underwriting Association's Cyber Underwriting Group, much of it with boards taking a view on risks they could not see directly.

Almost everything anyone in those conversations knew about an organisation's infrastructure was what the organisation said about it. This is one narrow exception.

hello@vericore.uk · See it run