Tamper-Evident Logs
NIS2 requires essential and important entities to maintain tamper-evident security logs. A log stored in a system you control can be altered. A log sealed with an eIDAS-qualified timestamp — binding content, source, and time window together — cannot.
Works with any log source and any format. Submit the hash of your log batch; we anchor it with a qualified proof and return a VERIFIED / FAILED report your auditors can check without a TrustBeat account.
14-day free trial · no credit card required
When log integrity is the whole case
Three moments where a tamper-evident log record is the difference between compliance and exposure.
The incident is investigated
NIS2 Art. 23 requires reporting significant ICT incidents to the national authority within 24 hours. The investigators want the exact sequence of log entries from the 72 hours before the breach — unaltered, with a verifiable timestamp.
Each hourly log batch was anchored at rotation. The eIDAS proof shows the content and timestamp of every batch — investigators get the full sequence with no gaps they can question.
The log is challenged
A third party — insurer, counterparty, or regulator — claims your system behaved differently than your logs show. Since you control your own log storage, they argue you could have modified the files after the fact.
The log hash was anchored independently of your storage. Matching the current file hash against the sealed proof proves the log is unchanged — your word backed by cryptography.
The annual audit arrives
Your ISO 27001 or NIS2 audit requires evidence that security logs from 18 months ago haven't been tampered with since they were generated. A checksum stored alongside the log proves nothing — the checksum could have been recalculated after modification.
The auditor runs the VERIFIED / FAILED check against the independently-anchored proof. No TrustBeat account needed. No trust in your internal systems required.
How it works
Four steps from your log batch to a compliance-grade, independently verifiable seal.
Hash your log batch locally
Your log rotation script or pipeline computes the SHA-256 hash of the log file or batch at the point of rotation. Log content never leaves your infrastructure.
Works with any source and any format: filesystem logs, S3 objects, Kafka offsets, database audit tables, or application event streams.
Bind content, source, and time window
The log hash is combined with metadata — source identifier, tenant, and the time window the batch covers — using RFC 8785 JCS canonical JSON. This produces a single deterministic combined hash.
Canonical JSON ensures the same metadata always produces the same combined hash, regardless of key order. The binding is reproducible and independently verifiable.
eIDAS-qualified anchor every 10 minutes
The combined hash is batched into a Merkle tree and anchored with a qualified eIDAS timestamp from an EU Trusted List QTSP. Returns 202 Accepted instantly — your pipeline is never blocked.
The same 30-year LTV archive chain as Document Anchoring. The proof remains valid as cryptographic standards evolve.
VERIFIED / FAILED report for auditors
Retrieve a CryptoAgilityReport per submission: the verification outcome, hash algorithm details, TSA certificate chain, and the full Merkle proof path. Auditors can verify it offline.
If a hash algorithm used in the chain is later deprecated, the report flags it and the LTV re-stamp takes over automatically.
metadata = source · tenant · time_window
RFC 8785 (JCS) · RFC 3161 (TSA) · eIDAS Art. 41 · ETSI EN 319 102 LTV
Regulatory coverage
Log integrity requirements appear across multiple EU regulations. One anchoring pipeline covers them all.
| Regulation | Article | Covered |
|---|---|---|
| NIS2 | Art. 21 | |
| NIS2 | Art. 23 | |
| ZoKB | § 30b | |
| DORA | Art. 17 | |
| ISO 27001 | A.8.15 | |
| GDPR | Art. 5(2) |
Hash-agnostic — any log source, any format
Anchor a log batch in five lines
Drop one call into your log rotation script. NIS2 Art. 21 covered from the next batch.
$ npm install trustbeatimport { TrustBeatClient } from "trustbeat";
const tb = new TrustBeatClient("YOUR_API_KEY");
const { trackingId } = await tb.logs.anchor({
logHash: sha256(logFile), source: "app-server-01",
tenant: "acme", window: "2026-06-14T00:00Z/PT1H",
});
console.log(trackingId); // → 01JQ...Drop-in for any pipeline: The sha256(log_file) call runs in your infrastructure — log content never leaves your system. Integrate into logrotate, Fluentd postrotate hooks, S3 event triggers, or any CI/CD step that processes log archives.
Common questions
Does it work with our existing log pipeline?
Yes. You compute SHA-256 of your log batch in whatever step makes sense — logrotate postrotate hook, a Fluentd output plugin, an S3 Lambda trigger, or a nightly cron job — and submit only the hash. Log content is never sent to TrustBeat. If you already rotate logs hourly, one extra line anchors each rotation.
We have dozens of log sources. Do we need a separate integration for each?
No. Each submission includes a source field that identifies which system produced the log. You can run the same integration code for every source, varying only the source and tenant fields. All submissions appear in a single account with filtering by source.
What is ZoKB 2026, and does it apply to us?
ZoKB is the Czech national implementation of NIS2 (Zákon o kybernetické bezpečnosti), effective 2026. It applies to Czech essential and important entities — including operators of critical infrastructure, health, energy, transport, financial sector, and digital infrastructure. If your organisation falls under NIS2 in the Czech Republic, ZoKB applies.
What exactly is in the CryptoAgilityReport?
The report contains: the verification outcome (VERIFIED or FAILED), the hash algorithm used for the log hash and the combined hash, the TSA certificate subject and validity period, the Merkle proof path from your hash to the qualified root, and a flag if any algorithm in the chain is approaching deprecation. It is designed to be handed directly to an auditor.
Can we anchor logs retroactively from before we signed up?
No. An anchor submitted today proves the log existed in this form at today's time — it cannot be backdated. For historical logs you want to protect going forward, you can anchor the current state of the archive, which proves it has not changed since that anchor was created. Starting now is the right move for any NIS2 compliance timeline.
Připraveni ukotvit svůj první dokument?
Začněte zdarma. Bez kreditní karty. Prvních 100 hashů je na nás.
eIDAS Regulation (EU) No 910/2014 · Art. 41 legal presumption · EU Trusted List QTSP