Etminan makes a handful of deliberate bets: a hardware chip instead of a file on disk, a second device that does the judging, and a hard rule that nothing in the system approves itself. None of this needs a TPM or Linux internals background to follow — here's the reasoning, in plain terms. For the deeper component-level breakdown, see Architecture & design.
Most host-integrity tools work the same way: keep a record of what every important file should look like, then periodically compare it against reality. The weak point is where that record lives — usually a file on the same machine it's protecting. Anyone who gets full control of that machine (root) can, in principle, edit both the thing being checked and the record of what it used to look like, at the same time. The check still runs; it just checks against a story the attacker gets to rewrite.
A TPM is a small, separate chip most modern servers already have, built specifically so that its record of "what has run on this machine" can't be rewritten after the fact — not even by someone with full root access to the operating system itself. Etminan uses it as the anchor for exactly that reason: it moves the one thing an attacker most wants to forge outside the reach of the access level they're trying to get.
In one line: a checksum file asks "does this still match?" using a record the attacker can potentially edit; a TPM asks the same question using a record they can't.
Most integrity tools work on a schedule — say, once an hour — because that's how often a full scan is affordable to run. That leaves a window: a file changed and changed back, or simply never re-read, can slip by unnoticed until the next scan. Etminan runs its scheduled check on that same kind of cadence, but also reacts the moment a watched file is written, rather than waiting for the next round. Every check — scheduled or immediate — still anchors back to the same hardware-backed record, so reacting faster never means trusting less.
The machine being watched is never the one that decides whether it's telling the truth. Etminan splits the system in two: an agent on each monitored host that only takes measurements, and a separate verifier device that does all the judging — comparing what it's told against an approved baseline and deciding whether to raise an alarm. Even in the worst case, a monitored host with its root account fully compromised, the attacker doesn't get a vote on whether their own tampering gets reported. That decision was never theirs to make.
Etminan can automatically match a detected change against, say, an approved ticket in your change-management system, and it will show that match to whoever reviews the finding. What it deliberately never does is treat that match as approval on its own. A person still makes the actual call, every time a real, unexplained change shows up. The automation's job is to save that person the busywork of digging up context by hand — not to make the decision for them.
The same rule applies everywhere a bit of automatic context could tempt a shortcut: which package a changed file belongs to, who owned it, when it last changed. All of that is shown to help a human decide faster — none of it is ever allowed to decide on its own.
Every time someone approves a change, rejects one, or grants an exception, that action is signed by the person who made it and added to a record built so that editing or deleting an entry later breaks the whole trail, not just that one entry. The point isn't just catching outside attackers — it's giving the people who operate Etminan an honest record of their own decisions that nobody, including an insider with database access, can quietly rewrite after the fact.
Ticket-system lookups, Slack/PagerDuty alerts, and anything else Etminan talks to are built as separate, explicitly approved add-ons — never code baked directly into the core program. That keeps the security-critical part of Etminan small enough to actually review from top to bottom, and it means plugging in your own ticketing system or alert channel never requires touching, or trusting, that core. Each add-on is checked and verified before it's allowed to run at all — nothing gets picked up automatically just because it exists on disk.
A page like this is only honest if it says where the guarantees stop. These are the real limits, not softened for a broader audience.
Without a full hardware certificate chain from the manufacturer, enrolling a new host the first time still relies on a person confirming "yes, this is the machine I think it is." Everything afterward builds on that one moment being done carefully.
Someone with physical access to the hardware itself — desoldering the chip, tampering with firmware before the operating system even starts — is outside what this defends against. This protects against remote and software-level compromise, not a hands-on attacker in the room.
It holds the approved baselines and the record of every decision. Protecting it matters as much as protecting the hosts it watches — Etminan makes tampering with its own records detectable, but a fully compromised verifier is a risk that needs its own separate attention, not something this system claims to erase on its own.
etminan