ROOTKey vs immutable storage (WORM, object lock): what is the difference?
Short answer
Immutable storage, such as WORM (write once, read many), an object lock with a retention period or an append-only database, is a preventive control: it tries to stop a record from being modified or deleted once it has been written. ROOTKey adds a layer of cryptographic verification: it seals a fingerprint of every version in an independent public registry, so a third party can confirm that a record is exactly as it was, and it shows what changed - who, when and where - and restores only what was altered. Immutability is a promise about how a system behaves; verifiability is proof that a third party can confirm for themselves. The two complement each other.
- Fingerprint
- SHA-256for every version, with a timestamp
- Detection
- Continuouswhat, who, when and where
- Scope
- File · table · rowonly what was altered
- Direct connectors
- 4SharePoint · OneDrive · Amazon S3 · Cloudflare R2
Side by side: immutable storage and ROOTKey
Two questions are commonly confused: "can this record be changed?" and "can I prove to a third party that it wasn't?". The table sets out which one each answers.
| Immutable storage | ROOTKey | |
|---|---|---|
| What it answers | Can this record be changed? | Can I prove to a third party that it wasn't? |
| What it records | The data itself, kept unchangeable for a retention period | A SHA-256 fingerprint of every version, sealed with a timestamp in an independent public registry; with connectors and custom deployments, the content stays where it is |
| Third-party proofintegrity proven to others | Its guarantee is a statement about how a system is configured and administered, a system the auditor does not control | Anyone can recalculate the fingerprint and compare it with the sealed one; external auditors can verify without access to the original data |
| Change detailwhat, who, when and where | Designed to prevent change, not to explain it | Yes: every change is caught and explained - what, who, when and where |
| Selective restoreonly what was altered | Protected records stay as written; restoring data held elsewhere is outside its scope | Yes: the last version proven valid, down to one file or one row |
| Independent verification | Depends on the system's configuration and on the permissions of whoever administers it | The reference point is an independent public registry, not controlled solely by whoever stores the data |
| Existing storageworks with what you use | It is a storage layer: data has to be written to it | Works on top of existing storage: direct connectors to SharePoint, OneDrive, Amazon S3 and Cloudflare R2, the REST API and webhooks |
| Regulatory evidence | Supports requirements to keep records unchanged for a set period | A cryptographic audit trail, integrity reports and evidence packs for NIS2 (Art. 21, 23), DORA (Art. 9, 17) and GDPR (Art. 32), exportable for regulators |
When you need each
- Immutable storage
- When records, logs or backups must be kept unchanged for a retention period and protected against modification or deletion once written.
- ROOTKey
- When you have to prove integrity to someone who does not control your systems - an auditor, a regulator or a court - when data sits on ordinary storage, when you need to see exactly what changed, or when the proof has to outlive a migration or a change of vendor.
Immutable storage preserves whatever was written. If data was already tampered with when it was written, it keeps that state with the same rigour, and so would any seal made over it. ROOTKey proves that your data has not changed since it was sealed and shows any change made after that.
How they work together
A record can be verifiable even if it sits on ordinary storage, as long as its fingerprint has been anchored somewhere independent. On immutable storage, the same seal adds proof that a third party can check.
Keep
Immutable storage keeps records, logs and backups from being modified or deleted for their retention period.
Anchor
Every version of every file, table or record gets a unique fingerprint, sealed in an independent public registry with a timestamp. With connectors and custom deployments, the original content stays where it always was.
Verify
To verify, the fingerprint of the file as it is today is recalculated and compared with the one that was sealed. If they match, the content has not changed since the moment of sealing. Every action is sealed with a cryptographic timestamp, forming a chain of custody that is ready for auditors and exportable for regulators.
ROOTKey connects directly to Amazon S3 and Cloudflare R2, so the data you keep there can be sealed and verified where it is: Integrations.
Frequently asked questions
Is immutable storage enough for an audit?
Immutability is useful and often necessary, but an audit needs proof that can be independently confirmed. Immutable storage prevents changes; verifiable proof lets any third party confirm that they never happened. ROOTKey adds that proof on top of the storage you already use.
If my storage is immutable, what is left to verify?
Immutable storage preserves whatever was put into it. If data was already tampered with when it was written, if an event was never recorded, or if a process failed silently, it keeps that state with the same rigour, and a seal made later cannot see it either. From the moment it is sealed, ROOTKey proves your data has not changed and shows any later change: what, who, when and where.
What does ROOTKey record in the independent public registry?
A fingerprint: a short value unique to that exact content, sealed with a timestamp. Only the fingerprint goes to the registry, never the content. With connectors, the original content stays where it always was; with a custom deployment, your data stays on your own infrastructure. On the SaaS platform, ROOTKey hosts it in the EU.
Does ROOTKey replace immutable storage?
No. Immutability is a preventive control, and ROOTKey adds a layer of cryptographic verification. Neither replaces the other: they work best together.