What is an audit log hash chain?

An audit log hash chain is a way of storing log entries so that each entry includes a cryptographic hash of the entry before it, which makes any later edit, deletion or insertion in the middle of the log detectable.

How it works

Each new entry is written with two parts: the event itself, and the hash of the previous entry. The hash of the new entry then covers both. Change one old entry and its hash changes, so the next entry no longer points to it, and every entry after that breaks too. Checking the log means walking from the start and recomputing each hash.

Certificate Transparency, described in RFC 6962, uses a related structure, a Merkle tree, to keep public, append-only logs of TLS certificates that anyone can audit.

What it proves and what it doesn't

A hash chain is tamper-evident, not tamper-proof:

• It detects changes to entries in the middle of the log.
• It does not stop whoever controls the database from rebuilding the entire chain from some point onward with new hashes.
• It does not prove that every event was logged in the first place.

The usual answer to the second point is to keep copies, or at least the latest hash, somewhere the log's operator cannot change. If a later version of the log does not extend your saved copy, someone rewrote history.

How Crunu does it

Crunu's audit log records sign-ins, devices, invitations, role changes, versions, rotations, machines, tokens, share links, denials and network rule changes. Entries are linked in a hash chain.

• Verify integrity checks the chain in one click, and the organization status page shows the result.
• Export JSONL downloads the log so you can check the chain with your own tools and keep copies outside Crunu.
• Filters narrow the log by person, action, environment and period.
• Showing, copying and exporting a value are recorded too. Those entries are signed by the person and marked Client-reported, because only the client knows they happened.
• Retention is 365 days on the server by default. An organization can extend it, up to 36,500 days or forever, but not shorten it. When old entries are trimmed, a checkpoint stays, so verification still covers the whole chain.

Secret values never appear in the log, since the server does not know them. Crunu does not publish its chain to an external transparency log, so regular JSONL exports kept elsewhere are your independent point of comparison. See audit log and the audit log feature.

Sources

• RFC 6962: Certificate Transparency, checked October 27, 2026.