Etminan's core is free, open, 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.
Status. The 0.9.0 features below (starting with SIEM output) are in development and not yet published — this page describes what is arriving, so you can plan for it. In-development and planned items are labelled as such; don't read them as already shipped.
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.
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, baseline approve / reject / exclude, TLS and attestation-key rotation, and operator-key registry changes — so integrity events land in the same pipeline your analysts already watch, without polling an API or parsing prose.
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);
unset — or unrecognized — means nothing is emitted. Best-effort by design: a broken or
unreachable syslog target never breaks a verification run.
The actions that change what a host is trusted to look like — approving a new baseline, rejecting drift — can be made to require more than one authorized operator's signature (an N-of-M scheme), with distinct roles (viewer, reviewer, approver, admin) and every action bound to a named identity in the hash-chained audit trail. This meets the four-eyes and separation-of-duties expectations common under ISO 27001, SOX, and internal-audit regimes — the audit log answers which person, not just which key.
It builds directly on the operator-key authorization registry that shipped in 0.8.0 (authorized signers, split into admin and operational roles, with signed rotation and revocation).
Off by default. Until you enable a multi-signature policy, the existing single-approver workflow is completely unchanged.
The enterprise story isn't all forward-looking — two capabilities aimed squarely at regulated, high-assurance deployments shipped in 0.8.0, and dual control (above) builds directly on the first of them:
etminanoperator-key init it stays in legacy
accountability-only mode, so existing deployments are unchanged.
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.