This page describes the protections that are always on, whatever you configure. It is meant for security reviews and questionnaires. The controls you set yourself are in the other pages of this section.
Isolation between organisations
Every customer is an organisation (a tenant). Separation is enforced at three levels:
| Level | How |
|---|---|
| Database | Every table that holds organisation data has row-level security. A database session is bound to one organisation and can only read and write that organisation’s rows, even if application code asked for more. |
| Application | Every request is resolved to one organisation and one membership. A member of one organisation has no rights in another, and the same person’s role is looked up per organisation. |
| Devices | A device belongs to one organisation. Its credential, topics and commands are bound to it; it never receives another device’s messages. |
Background jobs that work across organisations (retention, usage counting, billing) list organisations through one guarded path and then work inside each organisation’s own boundary.
Regions
Hermetry runs as separate deployments in the European Union, the United States and Türkiye. Your organisation’s data stays in its home region. The global directory that routes requests knows only which region and node an organisation lives on; it holds no name, address, owner or setting. Emergency access by Hermetry operators to a node needs two signatures, is time-limited, and is marked in your audit log. See Regions and data residency.
Secrets and keys
| Secret | How it is kept |
|---|---|
| Passwords | Hashed with a slow hash; never stored or shown in clear. |
| Device access tokens and MQTT passwords | Shown once when issued; only a hash is stored. |
| API keys | Shown once; only a hash is stored. |
| Secrets in settings (mail and SMS accounts, OAuth client secrets, endpoint passwords, SAML private keys) | Encrypted at rest; never shown again after saving and never written to logs. |
| Authenticator app secrets | Sealed under a key of their own per person. |
| Device certificate private keys | Never leave the device. Hermetry stores the certificate and its fingerprint. |
| Certificate authority keys | Root keys offline; online signing keys sealed and held by one isolated process. See The device certificate authority. |
Secrets never appear in exports, audit rows, webhooks or notification texts.
Least privilege for processes
Hermetry is split into processes, and each gets only what it needs:
- The device gateway, which terminates MQTT and device HTTP, connects to the database with its own login that can only call a few narrow functions. It holds no certificate authority key.
- The certificate signer is the only process that can unseal signing keys.
- The provisioning worker answers device provisioning requests without any signing key.
- Scripts in flows run in isolated sandboxes with time limits and no network, files or credentials.
A fault in one process therefore does not hand an attacker the keys of another.
Sessions
- A sign-in creates a session with short-lived access tokens that are rotated. A refresh token used twice ends all of that person’s sessions, because it means a token was copied.
- Sessions end after a period of inactivity and after an absolute lifetime.
- A role change, a suspension or a removal ends the person’s sessions in the organisation at once. A suspended organisation’s sessions and device connections end at once.
See Sessions, lockout and trusted devices.
Abuse protection
| Control | Effect |
|---|---|
| Rate limits | API routes, sign-in and devices have request limits; over them requests are refused (429) or device messages dropped. |
| Account lockout and CAPTCHA | Repeated failed sign-ins lock the account for a while. |
| Address bans | Addresses that keep failing across accounts are banned for a while. |
| The AI firewall | Watches security signals and opens incidents that explain what it saw. See The AI firewall. |
| Decoys | Fake keys, records and paths that nobody legitimate uses; touching one raises a critical signal. |
Outgoing connections
Webhooks, flow HTTP blocks and polled endpoints connect out from Hermetry. They refuse private, loopback and internal addresses after the name is resolved, so they cannot be used to reach Hermetry’s own network. A webhook can reach an internal target only through an explicit allow-list an administrator adds. See Webhooks and Connections and secrets.
Evidence
Sensitive actions are written to a hash-chained audit log that the application cannot edit. See What is audited.
What you are responsible for
- Who you make a member, and with which role.
- Second factors and single sign-on for your people.
- Device profiles: TLS, allowed networks, credentials.
- API keys: their permissions, networks and expiry.
- Your own copies of exported data.