Tamper-Proof Logging: How to Build Logs You Can Defend
No software can make a log truly tamper-proof. What you can build is a log where any edit or deletion is detected, and where an independent party can check that nothing changed. In practice that means three things working together: append-only storage, cryptographic hashing (ideally Merkle trees), and an external anchor that an attacker with admin rights cannot rewrite. This guide explains each layer, what to record, where the limits are, and how to present it to auditors and buyers.
TL;DR
- “Tamper-proof” aims to make changes impossible. “Tamper-evident” makes changes detectable. Software alone can reliably deliver only the second.
- Combine layers: append-only enforcement in the database or storage, hash chains or Merkle trees, and an external anchor outside the logging system’s control.
- Tampering is only caught if someone verifies. Schedule checks and keep them routine.
- Record event type, time, location, source, outcome and identities, and keep personal data to what you need.
- Evidence-grade logs are a commercial asset: buyers and investigators trust records they can verify.
Table of Contents
- Tamper-proof, tamper-evident, append-only, immutable: what each term means
- The layers of a defensible log
- What to record
- Limits you should plan for
- Performance, storage and privacy costs
- Why trustworthy records matter after an incident
- A practical rollout in six steps
- Our perspective
- Turn log integrity into a market advantage
- FAQ
- Sources
Tamper-proof, tamper-evident, append-only, immutable: what each term means
The four terms get used interchangeably, but they describe different promises.
Tamper-proof means tampering cannot happen. That is a physical-world standard, and one Quipu-Log’s threat-model chapter says software by itself cannot meet. Its approach is to use a Merkle tree and an external anchor so edits become hard to hide rather than impossible.
Tamper-evident means that if someone alters a record, the alteration shows. Academic work on this problem is blunt about the boundary: tamper-evident logging cannot stop a malicious logger from destroying or altering records, and it cannot detect tampering in a log nobody ever examines.
Append-only means the system accepts new entries but rejects changes to or deletion of existing ones. A PostgreSQL trigger can enforce this at the database engine level by blocking updates and deletes. Privileged administrators may still be able to bypass some controls, which is why append-only is a layer and not a finish line.
Immutable logging is the storage-side version of the same idea: write-once media or object storage settings that stop an object from being overwritten for a retention period.
The practical conclusion: design for tamper-evidence with strong prevention layered underneath, and say so honestly in your documentation. Auditors trust a clear threat model more than a bold claim.
The layers of a defensible log
The Immutable documentation describes defense in depth for audit logs as several layers: application-level controls, database-level triggers, cryptographic hash chains, and external anchoring. Each covers a hole the others leave open.
Layer 1: Application controls
The application writing the log should expose only an “add event” operation. There should be no update or delete endpoint at all. This stops accidents and casual misuse, but it does nothing against someone with direct database access.
Layer 2: Database or storage enforcement
This is where you block updates and deletes in the engine itself, or write to storage with retention locks. Engineers writing on append-only audit logs as a security primitive argue that integrity has to be enforced at the infrastructure level, because application-level safeguards fail when credentials are compromised or someone reaches the database directly. Use separate credentials for the log writer and for anyone who administers the database, so no single account can both write and rewrite.
Layer 3: Hash chains and Merkle trees
A hash chain links each record to the one before it: each entry includes a hash of the previous entry, so changing one record breaks every hash after it. It is simple and effective, but proving that a single event is in the log can require replaying a long stretch of it.
Merkle trees fix that. Research on history trees showed that Merkle structures give proofs that events remain present and that successive versions of the log are consistent, and that auditors can verify those proofs. In the same study, for a log of 80 million events, a randomly chosen event needed a proof of about 3 KB, against an 800 MB trace for a classic hash chain. Another widely read write-up on transparent logs explains that these proofs grow only logarithmically with log size, and can show both that a record exists and that an earlier log is a prefix of a later one.
That second property matters most. It means a verifier who saw the log yesterday can confirm today’s log extends it without rewriting history.
Layer 4: An external anchor
Hashes inside the same system an attacker controls can be recomputed. An attacker who can rewrite the entire log can also rewrite every hash. The fix is to publish the current root hash somewhere the attacker cannot reach: a separate account, a different cloud provider, a write-once ledger, or a party that signs and timestamps it. According to the Quipu-Log chapter, a full rewrite is detected when the external anchor is checked.
Anchor on a schedule. A root per source per minute is a common pattern, and the interval sets how much activity an attacker could hide before the next anchor.
Layer 5: Signatures and access control
NIST’s long-standing guidance on audit trails recommends strong access controls, digital signatures and write-once devices to protect audit-trail integrity. The document is from 1997, but the three controls still map neatly onto modern equivalents: IAM policies, signed log batches and object-lock storage.
What to record
A perfectly protected log of the wrong data is useless. The Canadian Centre for Cyber Security’s guidance on audit and accountability says to capture the event type, time, location, source, outcome and associated identities. Depending on the system, add source and destination addresses, user or process identifiers, success or failure indicators and file names. The same guidance says to limit personal information to what is needed.
A workable minimum record looks like this:
| Field | Why an investigator needs it |
|---|---|
| Event type | Separates logins from configuration changes from data exports |
| Timestamp (UTC, from a trusted clock) | Orders events and supports timelines |
| Source (host, service, IP) | Shows where the action originated |
| Actor identity | Ties the action to a person, service account or process |
| Target object | Shows what was touched |
| Outcome | Success or failure, which reveals probing and brute force |
| Log sequence number or hash reference | Lets you detect gaps and reordering |
If your product makes automated decisions, the logging requirements widen. Our guide to AI audit trails and what to log covers model versions, inputs and decisions.
Types of audit trails
NIST distinguishes event-oriented logs and keystroke monitoring, and it describes system-level, application-level and user audit trails in the same bulletin. System-level trails show logins and resource use, application-level trails show what happened inside the software, and user trails show an individual’s actions. Integrity protection should cover all of them, since an attacker will edit whichever trail tells the story.
Limits you should plan for
Honest design starts with the failure cases.
Compromised credentials. If an attacker steals the key that signs your anchor, they can forge anchors. Keep signing keys in a hardware security module or managed key service, separate from the systems being logged, and rotate them with a documented process.
Privileged administrators. A root user on the log host can often alter storage underneath your application. Separation of duties helps: the people who run the servers should not hold the keys or accounts that control the anchor.
Nobody checks. The research is direct that tampering is only detected when integrity is verified. Automate verification and alert on failures. A famous example is the DigiNotar certificate authority, where evidence of compromise was found through a routine daily check.
Logs that never arrive. A hash chain protects what was written. It cannot prove an attacker did not stop the agent from sending events in the first place. Hash events at the first hop where they enter your pipeline, and monitor for silent sources.
Key loss. If you lose the keys needed to verify, you lose the proof. Back up verification material and test recovery.
Performance, storage and privacy costs
Tamper evidence is not free, but the cost is manageable. In the 2009 history-tree study, signed logging exceeded 100,000 messages per second, against 400,000 unsigned. Storing record hashes added about 12% and tree hashes about 25% for 256-byte records. The prototype processed an 80-million-event syslog trace at 1,750 events per second, or 10,500 events per second with signature work offloaded. Hardware has moved on since 2009, so treat these as a guide to relative overhead, then benchmark your own pipeline.
Signing in batches rather than per event is the usual way to recover throughput. For privacy, the same research notes that selective proofs can show one record is genuine without revealing unrelated records. That helps when an auditor needs to verify a single transaction and should not see your customers’ other data. Encrypting sensitive fields before they enter the ledger gives you the same benefit for hashes you must retain after the underlying data is deleted.
Why trustworthy records matter after an incident
When a system is compromised, the first thing a skilled intruder tries is to clean up the record. Investigators then depend on whatever evidence survived: detection data, recordings and event histories that can be shown to be intact. The same principle applies well beyond IT, for example in detection and recording in surveillance systems, where an event record is only worth as much as the confidence that nobody altered it.
For a security vendor, this has a commercial edge. A customer’s legal team, insurer or regulator will ask whether your logs would stand up as evidence. A clear answer, with a verification procedure to show, shortens the sale. Our comparison of EDR and XDR makes a related point: ask for test evidence before you buy, and expect your own buyers to do the same.
A practical rollout in six steps
- Define the threat model. Decide whether you are defending against outside attackers, insiders, or both, and write down what the design does not cover.
- Hash at the point of entry. Compute the event hash where the event first enters your pipeline, not after it has passed through systems an attacker might control.
- Enforce append-only in the store. Use database triggers or object-lock retention, with separate credentials for writers and administrators.
- Build the tree and publish roots. Aggregate hashes into a Merkle tree and write the root to an external ledger on a fixed schedule.
- Verify on a schedule. Check the archive against the anchors daily, and alert on any mismatch or missing interval.
- Rehearse the audit. Have someone outside the engineering team run a verification using only the documented procedure and public proofs.
Our perspective
In our work with cybersecurity and AI startups, the same pattern keeps showing up: the product is strong, but the evidence behind it is not. A founder says the platform detects an intrusion, and the buyer asks how anyone could prove it later. If the logs can be edited by an administrator, the honest answer is that nobody can.
We believe forensic readiness should be designed in from the first release, not bolted on when the first enterprise questionnaire arrives. That means treating log integrity as a product feature with its own threat model, its own verification procedure and its own plain-language explanation for buyers and investors.
This is why Cybertech Acceleration focuses exclusively on digital forensics. We help founders add judicial-grade evidence capabilities and translate them into a business story: what it proves, who needs that proof, and why it closes deals. Tamper-evident logging is one of the clearest examples, because it is technical enough to be credible and simple enough to explain in one sentence.
Thiago Vieira
Turn log integrity into a market advantage
If you build security or AI products and want forensic-grade evidence to be part of what you sell, that is what our accelerator is for. We work with founders on the forensic component of the product, on the commercial narrative around it, and on structured market entry with warm introductions. Learn more about Cybertech Acceleration.
Founders planning to enter the US from abroad can also look at our Soft Landing program, and those interested in the Texas market can see the Cybertech Texas Mission.
FAQ
Is tamper-proof logging actually possible?
Not with software alone. Research on the subject shows that even a well-designed tamper-evident log cannot prevent a malicious logger from altering or destroying records. The realistic goal is to make tampering detectable and to make hiding it very hard, using append-only storage, hashing and an external anchor.
Is blockchain a good way to make logs tamper-proof?
It can serve as the external anchor, since a public ledger is outside your control. You rarely need to store the logs themselves there. Writing a Merkle root to a ledger on a schedule gives you most of the benefit with far less cost and no exposure of log content.
What should be logged in an audit log?
At minimum, the event type, time, location, source, outcome and the identities involved. The Canadian Centre for Cyber Security also lists addresses, user or process identifiers, success or failure and file names, and advises keeping personal information to what is necessary.
What is the difference between append-only and immutable logs?
Append-only describes behavior: new entries are allowed, edits and deletes are not. Immutable usually describes the storage guarantee, such as write-once media or retention locks. Use both, and add hashing and anchoring so that a bypass of either control still shows up on verification.
Sources
- Merkle tree and an external anchor
- cannot stop a malicious logger from destroying or altering records
- PostgreSQL trigger can enforce this at the database engine level
- append-only audit logs as a security primitive
- transparent logs
- strong access controls, digital signatures and write-once devices
- audit and accountability
- a routine daily check
- detection and recording in surveillance systems