Etminan's core is free and self-hosted — and stays that way. On top of it, a growing set of capabilities targets larger organizations with a SOC, an auditor, and separation-of-duties requirements: native SIEM output, dual-control approvals, and compliance mapping. Every one of them is opt-in, and off by default — nothing here changes how an existing deployment behaves until you turn it on.
Off by default. Every capability on this page is disabled unless you explicitly configure it. A default install stays exactly as simple, and as auditable, as it is today — nothing here changes how an existing deployment behaves until you turn it on.
The Standard edition is free and complete on its own — full TPM-anchored attestation, the operator-approval workflow, the signed audit log, key governance, hardware provenance, and every integration. The Enterprise edition adds capabilities aimed at a SOC and separation-of-duties requirements. Enterprise is an add-on for larger, regulated deployments, not a gate on the core.
| Capability | Standard | Enterprise |
|---|---|---|
| TPM-anchored integrity attestation (agent + verifier) | ✓ | ✓ |
| Operator-approved baseline & drift detection | ✓ | ✓ |
| Hash-chained, signed audit log | ✓ | ✓ |
| Mutual TLS, certificate-pinned | ✓ | ✓ |
| RBAC identity registry — peer-UID auth, roles & scope, default-deny | ✓ | ✓ |
| Directory integration — a role from an Active Directory or LDAP group (off until a group is mapped; in Enterprise a mapping is a four-eyes change) | ✓ | ✓ |
Off-verifier evidence check — etminan-witness, its own package: no daemon, no database, no key, no TPM | ✓ | ✓ |
| Off-host audit anchor — the audit head leaves the machine that wrote it | — | ✓ |
| TOTP second factor — optional, per operator | ✓ | ✓ |
Local self-check — doctor, read-only, sends nothing anywhere | ✓ | ✓ |
| EK-certificate provenance (genuine-hardware assurance) | ✓ | ✓ |
| Measured boot — boot-chain attestation (PCR 0–9): firmware, bootloader, kernel & initramfs | — | ✓ |
| Notification channels (email, Slack, PagerDuty, webhook) | ✓ | ✓ |
| Change-source / ticket correlation | ✓ | ✓ |
| Package-manager correlation | ✓ | ✓ |
| Plugin API & certified catalog | ✓ | ✓ |
| Native SIEM output — CEF / LEEF over syslog | — | ✓ |
| SIEM output — JSON format — Elasticsearch, Loki, Vector | — | Planned |
| Dual control — four-eyes / M-of-N approval | — | ✓ |
| Air-gapped / offline operation — regulated & OT segments | — | ✓ |
| Advanced RBAC — custom roles & fine-grained scopes (base admin/operator/viewer is every edition) | — | Planned |
| Operator work queue — triage, acknowledge & resolve findings | Planned | Planned |
| Bidirectional ticketing — push findings out as tickets | Planned | Planned |
| Compliance control mapping — ISO 27001, NIS2, DORA, SOC 2, PCI-DSS (signed reports, under NDA) | — | ✓ |
| Automatic verifier failover — zero-touch HA (manual warm-standby is in every edition) | — | Per-deal |
| NIST 800-53 / 800-171 mapping — US frameworks, on request | — | Per-deal |
Everything in the Standard column is part of the free core. Shipping in Enterprise today: native SIEM output over syslog (CEF/LEEF), dual control, air-gapped operation, and the compliance control mapping. Still planned there: JSON SIEM output and advanced RBAC. Planned for both editions: the operator work queue, bidirectional ticketing, and measured-boot (boot-chain PCR 0–9) attestation. Automatic failover and NIST mapping are available per deal. None of them change how a default install behaves until you turn them on; several are described in more detail below.
For a SOC that already ingests syslog into Splunk, QRadar, Microsoft Sentinel, or Elastic. When enabled, Etminan emits one structured syslog event per finding and per signed operator action — enrollment, op approve / reject / exclude, TLS and attestation-key rotation, and identity-registry changes — so integrity events land in the same pipeline your analysts already watch, without polling an API or parsing prose.
Etminan speaks the SIEM-native formats directly — CEF for Splunk/ArcSight and LEEF for QRadar — so both ingest the events out of the box. Dedicated Splunk (CIM-normalised) and QRadar (offense) content — a Technology Add-on and a DSM — is on the way, with the field dictionary and mappings already written. † testing required
Events go to the local /dev/log socket by default (the host's
own syslog daemon forwards them onward), or straight to a remote collector over UDP via
ETMINAN_SIEM_SYSLOG_ADDR. Facility local0;
severities map cleanly (critical → err, warning → warning,
action → info). It is an addition to the existing
notification channels (email, Slack, PagerDuty, generic
webhook), not a replacement.
Off by default. The switch is
ETMINAN_SIEM_FORMAT=cef (or leef,
or json — a flat, newline-delimited schema for generic
structured-log ingesters such as Elasticsearch, Loki, or Vector);
unset — or unrecognized — means nothing is emitted. Best-effort by design: a broken or
unreachable syslog target never breaks a verification run.
SIEM output is configured entirely through the verifier's environment file — no rebuild, no code, no extra service. Add the switch (and, if you're not relaying through the host's own syslog daemon, a remote collector address) to the verifier's env file:
# Pick the wire format your SOC ingests: # cef → Splunk / ArcSight leef → QRadar json → generic (Elastic, Loki, Vector, …) ETMINAN_SIEM_FORMAT=cef # Optional: send straight to a remote collector over UDP. Omit this and events # go to the local /dev/log socket, where the host's own rsyslog/journald # forwards them onward — the usual setup when a log shipper is already running. ETMINAN_SIEM_SYSLOG_ADDR=siem.internal:514
The next scheduled run picks the change up automatically — the
service reads verifier.env each time
etminan-verifier.timer fires, so there is nothing to restart. To
see it emit immediately, run one cycle by hand:
etminansudo systemctl start etminan-verifier.service # or: etminan-verifier run
From then on, one event is emitted per finding and per signed operator action. A CEF finding
arrives looking like this (facility local0; severity maps
critical → err, warning → warning, action → info):
CEF:0|Etminan|etminan-verifier||pcr-mismatch|Host integrity finding|10|dst=web-01 cs1Label=kind cs1=pcr-mismatch msg=replayed PCR did not match the signed quote
Nothing sensitive is placed on the wire that isn't already in the finding itself — long signature/payload blobs from operator-action events are deliberately dropped, not forwarded. For the complete field dictionary, CEF/LEEF sample events, and Splunk CIM / QRadar QID mappings for the ingest side, see the SIEM integration guide.
† Generic CEF/LEEF ingestion works today. The certified Splunk Technology Add-on and QRadar DSM are validated against live Splunk and QRadar instances before release — until then, treat those as testing-required rather than certified.
The actions that change what a host is trusted to look like — approving a new baseline,
changing the identity registry, or creating a review-suppressing exclusion — can be
made to require more than one authorized operator (a configurable
N-of-M threshold). Each co-signer must be a distinct authenticated
operator identity — a second, different Unix UID the etminan-verifierd
daemon has independently authenticated and authorised — so one person cannot supply both
approvals. This meets the four-eyes and
separation-of-duties expectations common under ISO 27001, SOX, and internal-audit
regimes.
Honest limit: the control binds two distinct authenticated identities, not two distinct humans — give the co-approving accounts to different people. Each co-signer must independently satisfy the action's required role and scope under the daemon's default-deny matrix, and each decision is bound to its operator identity in the audit trail.
It builds directly on the RBAC identity registry that is part of every edition (authenticated operators mapped to a role and scope, default-deny, with the daemon holding the only signing key).
Off by default. Until you enable a multi-signature policy, the existing single-approver workflow is completely unchanged.
The enterprise story isn't all paywalled: two capabilities that matter most to regulated, high-assurance deployments are part of every edition, including Standard. Enterprise dual control (above) builds directly on the first of them:
etminan-verifierd daemon,
which authenticates each caller by kernel-supplied Unix UID (SO_PEERCRED)
and maps it, default-deny, to one role (admin / operator / viewer) and a host scope. The
daemon holds the single signing key and signs each authorised action on the operator's
behalf — operators hold no key at all. Every allow and deny lands on the audit chain. It
is the separation-of-duties foundation dual control is built on, and it is on by default:
the first admin is installed once, as root, with op bootstrap.
ETMINAN_AIRGAP=1 and the verifier refuses its own outbound
connections — the plugin-catalog fetch and remote SIEM syslog — while
in-enclave agent polling continues untouched. The refusal says which flag caused it and
which feature it turned off, rather than failing as a timeout. For classified networks
and OT/ICS segments where an outbound connection is not an option.
enroll --ek-roots <dir>): the host must present a
manufacturer EK certificate whose key matches its activated Endorsement Key and chains to
a root CA you provide — a genuine-hardware assurance layer on top of same-TPM residency,
for discrete TPMs where a software or emulated TPM must be ruled out. RSA CAs only;
without the flag, enrollment is unchanged.
Priorities shaped by real regulated deployments rather than guessed at. Listed honestly as what they are — in development or planned, not yet shipped:
None of this changes how Etminan behaves out of the box. Each capability stays disabled until you explicitly configure it, so a default install remains exactly as simple — and as auditable — as it is today. That's a deliberate rule, not an accident: a tool whose whole job is to detect unexpected change should never grow surprising new behavior of its own on an upgrade.
If you're evaluating Etminan for a SOC, a regulated industry, or an air-gapped site, tell us what you need — the SIEM format you ingest, your dual-control policy, the compliance framework you're audited against. It genuinely shapes what we build next, and it's the fastest way to get a feature you need onto the near-term list.
✉ Contact usReporting something security-sensitive? See the homepage Contact section for our PGP key fingerprint.