Tamper-Evident vs Tamper-Proof vs Immutable: What Each Word Promises

The short answer

Tamper-proof says a record cannot be changed. Tamper-evident says that if a record is changed, the change will show. Immutable says the place the record is stored will refuse to change or delete it.

The first is a promise about prevention, the second about detection, and the third about storage. They are often used as if they meant the same thing, including by vendors who should know better. The difference matters most on the day someone has a reason to change a record, because each word fails in a different way.

Tamper-proof: the word to be careful with

A medicine bottle with a foil seal is not tamper-proof. Anyone can open it. The seal is there so you can see that someone did. Very little in the physical world is truly tamper-proof, and software is no different.

Every system has someone who can change it: a database owner, a cloud account's root user, the vendor's own engineers, or an attacker who has borrowed their access. When a product page says its logs are tamper-proof, it usually means ordinary users cannot edit them through the product. That is a real and useful control. It is a much smaller claim than the word suggests.

If you write security documentation, this is the word to avoid. It invites the one question you cannot answer well: what about your own administrators?

Immutable: against whom?

Immutability is a property of storage, and it comes in strengths.

At the strong end is write-once storage, often called WORM. Amazon S3 Object Lock in compliance mode is a common example: AWS documents that a locked object version cannot be overwritten or deleted by any user, including the account's root user, until its retention period ends. In the middle are append-only database tables, where rules in the database reject updates and deletes. Those stop every normal path through the application, but a person with owner access to the database can remove the rules. At the weak end is a table that the application simply never updates.

All three get called immutable. So the useful question is not "is it immutable?" but "who could still change it, and what would they have to do?"

Regulators have moved the same way. The US Securities and Exchange Commission long required broker-dealers to keep records on storage that could not be rewritten or erased. In 2022 it amended Rule 17a-4 to allow an alternative: a system that keeps a complete, time-stamped audit trail of every change, so the original record can be recreated. That is a shift from preventing change to making change visible.

• Amazon S3 Object Lock How compliance mode and governance mode differ.
• SEC Release No. 34-96034 The 2022 amendments to Rule 17a-4, including the audit-trail alternative.

Tamper-evident: a change would show

Tamper-evident does not try to make change impossible. It makes change detectable, and it relies on arithmetic instead of on who has access. Four techniques do most of the work.

A signature on each record. The record is signed with a private key when it is written. Change one character afterwards and the signature no longer verifies.

A sequence number with no gaps. Each record gets the next number. A missing number shows that a record was removed.

A hash chain. Each record carries a fingerprint of the one before it, so changing or removing an old record breaks every link after it.

A copy outside the system. Records, or a fingerprint of them, are sent somewhere the operator does not control: the customer's own storage, a public log, another party. Certificate Transparency, the public record of website certificates, works this way.

No single technique catches everything. A signature will not tell you a record is missing. A sequence will not tell you a record was altered. And only an outside copy catches the hardest case, where the newest records are removed and the counter is quietly set back. Try it in the log below.

• RFC 6962: Certificate Transparency A public, append-only log that anyone can audit.

Evident to whom?

This is the question that separates a strong claim from a weak one. If only the vendor can run the check, then tamper-evident is still a promise: you are trusting the vendor to check its own records and tell you the truth about the result.

It becomes evidence when someone outside can check for themselves. That takes three things. The customer can get the records, through an export or a stream. The customer can get the public key from somewhere stable. And the check runs on the customer's side, ideally with no call back to the vendor at all.

When you review a vendor, ask to see that check run on a record you choose.

• Verify a signed record offline with any Ed25519 library What an outside check looks like in practice.

Which word should you use?

Use the word that matches what you can demonstrate.

If your logs are rows in your own database that the product never edits, say that: "Audit log entries cannot be edited or deleted through the application. Database access is restricted to named engineers and is itself logged." That is an access control, and it is fine to describe it as one.

If your storage enforces write-once retention, say immutable and name the mechanism and the retention period.

If each record is signed, numbered or chained, and a customer can verify it, say tamper-evident and say how the customer checks.

Avoid tamper-proof. A good reviewer will ask about your administrators, and the honest answer is always that someone has access. It is better to have said so first.

Six questions to ask a vendor

1. Who at your company can change or delete a stored record, and how would that be noticed?

2. What exactly is signed or hashed: each record, a batch, or nothing?

3. If one record were deleted, what would reveal it?

4. If the newest records were deleted, what would reveal that?

5. Can I verify a record myself, without calling your API?

6. Can I keep my own copy as events happen?

Most vendors answer the first two easily. Questions four and five are where the difference between a slogan and a mechanism shows.

What Invoance claims, and what it does not

Invoance describes its records as tamper-evident. In Audit Logs, each event is signed with an Ed25519 key when it is written and given the next sequence number for that customer organization, with no gaps. Rules in the database block deletes on the audit tables. Customers can stream events to their own systems as they happen, and anyone holding an event can verify its signature offline with the SDK.

Each of those covers a different case, as the demo above shows. The signature catches an edited event. The sequence catches a removed one. The stream is what catches the newest events being removed along with the counter, which takes direct database access and is not something the sequence alone can see.

Invoance does not describe its records as tamper-proof. A person with owner access to the database is a case to detect, not one to pretend away, and the customer's own copy is what makes detection possible. A signature also says nothing about whether an event was true when it was written, or about an action your application never recorded.

• Audit Logs Signed activity logs for each of your customers.
• What is audit logging? The plain guide to audit logs and audit trails.