After a breach, the logs are the first thing an intruder rewrites.

When something goes wrong, everyone turns to the logs: your own investigators, the authority you report to, a cyber insurer assessing the claim, a customer who asks what happened to their data. An intruder knows this, and editing or deleting the lines that show what they did is often the first thing they do. A log you can still edit is your word about what happened, not evidence of it.

logseal seals your logs as they are written, segment by segment, into the evidence log. Each segment is archived on your own storage, and only a salted fingerprint of its record reaches us. Later, anyone can check offline that every sealed segment is exactly what was written, and that none has gone missing.

What it proves

No sealed segment was changed: Each segment’s SHA-256 is inside a record sent to the log as soon as the segment closes and the log can be reached. Change one line afterwards and the segment no longer gives the sealed digest.
None went missing: Segments are numbered and each record names the one before it, so a removed, inserted or renumbered segment shows. logseal verify lists exactly which.
When, independently of you: The log’s signed heads are timestamped by two independent authorities (not qualified under eIDAS) and anchored in Bitcoin, so a segment is shown to have existed no later than a time nobody can move.
What you reported, and when: Seal each early warning, notification and report as you send it, and the copy you hold is shown to be the one you sent, when you say you sent it.
Checkable without us: The open-source verifiers check a record’s proof offline, and logseal verify checks the archive against your own journal. Nobody has to trust you, or us.

What it cannot do

It does not detect anything: It is not an intrusion detection system or a SIEM. It keeps the evidence of an incident; it does not spot one.
It cannot say who did it: It does not identify an attacker or decide who was responsible. Investigators reach those conclusions from the logs; the seal makes sure those logs can be trusted.
It cannot protect lines written after a takeover: Once an intruder controls the machine that writes a log, what that machine writes from then on can be forged at the source. What the seal protects is everything sealed before. Run logseal on a log collector the watched systems cannot reach, not on each of them.
It does not make anyone compliant: NIS2 and the GDPR ask for incident handling, reports and documentation. Sealing shows when a record existed; whether the record is enough is yours to judge. What each article asks

How it runs

logseal is part of the drop-in recorder kit (Apache-2.0, no dependencies). It reads lines on standard input, so it takes anything that can print a log: journalctl, tail -F, a syslog relay, an export of cloud audit logs.

journalctl -f -o short-iso | riskrouter-logseal --source auth-server --archive /var/lib/logseal \
    --lines 1000 --seconds 60 --format syslog

riskrouter-logseal verify --archive /var/lib/logseal --journal evidence-journal.jsonl
# auth-server: 412 of 412 sealed segments intact, 412 recorded in the log

A segment: Closes after a number of lines or seconds, whichever comes first. It is written once to the archive, synced, and never overwritten; only then is its record sealed.
The record: A security.log-segment record of the NIS2 and data-breach pack: the source, the segment’s number, its time span, its line count and its SHA-256. The record and its salt stay in your journal; the log lines never leave your storage.
A restart: Carries on the same numbered chain from the last archived segment.
An outage: Records wait in your journal and are sent when the log answers again; nothing is lost, and nothing is marked recorded before the log has answered.

The same pack records each stage of an incident, and each report or notification you send. Download: logseal.mjs, with the recorder it uses, from the recorder kit. Recording needs a key; a sandbox key is free, with no form and no contract.

Who it is for

Organisations under NIS2, which must handle incidents and report significant ones within 24 hours, 72 hours and a month; every controller under the GDPR, which must document each personal-data breach; and anyone who will one day have to show a cyber insurer, an authority or a court what their logs said before an incident. Financial entities report ICT incidents under DORA, whose pack covers them.