Security Overview
This page provides a summary of Atrium's security architecture, intended for IT security teams evaluating the platform or preparing for compliance audits.
Authentication
Atrium supports three authentication contexts, each using a different mechanism:
| Context | Mechanism | Token type | Lifetime |
|---|---|---|---|
| Users (dashboard) | OIDC (external IdP or built-in) | JWT access + opaque refresh | 15 min / 7 days |
| Kiosk devices | Device pairing (6-digit code) | JWT device token | 1 year |
| Atrium Agent | Mutual TLS (mTLS) | Client certificate | Configurable (default 1 year) |
Each token type has a restricted scope. The API gateway verifies the token_type claim on every request — a kiosk token cannot access admin endpoints, and a user token cannot impersonate an agent.
Password security
When using the built-in identity provider:
- Passwords are hashed with argon2id (current best practice).
- Minimum length: 10 characters. No complexity rules.
- Password hashes are stored in a dedicated
credentialstable, separate from user profiles. - Optional TOTP-based multi-factor authentication.
- No self-registration — all accounts are admin-created.
Data isolation
All tenant data is isolated via PostgreSQL Row-Level Security (RLS):
- Every table with tenant-scoped data carries a
tenant_idcolumn. - RLS policies are enforced at the database level — even if application code omits a
WHERE tenant_id = ...clause, the database prevents cross-tenant data access. - Application-layer enforcement (
withTenant()wrapper) provides defense-in-depth. - RLS enforcement is tested in the automated test suite.
In self-hosted mode, the deployment contains a single tenant, but tenant_id and RLS are still active — no code path divergence between deployment modes.
Encryption
| Data | At rest | In transit |
|---|---|---|
| Database | PostgreSQL volume encryption (host-level, depends on deployment) | N/A (local connection) |
| OAuth tokens (CRM, Calendar) | Encrypted in database | HTTPS to providers |
| Agent communication | N/A | WSS (WebSocket over TLS) with mTLS |
| User sessions | JWT (signed, not encrypted — contains no sensitive data) | HTTPS |
| Passwords | argon2id hash | HTTPS |
| QR tokens | Ed25519 signed JWT | HTTPS (in emails), scanned locally |
QR code security
Pre-registration QR codes are self-validating Ed25519 signed JWTs. Key properties:
- Single-use (consumed at check-in, server-side replay protection).
- Time-limited (expires at the visit's expected departure).
- Offline-validatable (kiosk verifies signature locally without contacting the server).
- Compact (Ed25519 signatures are 64 bytes — keeps QR codes scannable).
Session termination
WiFi session termination is best-effort. Atrium tracks results and surfaces failures. Credential revocation (RADIUS reject) is immediate and reliable. Active session teardown (CoA/DM) depends on firewall vendor compliance with RFC 5176.
Audit trail
All security-relevant events are logged: authentication attempts, data access, configuration changes, and visitor lifecycle events. See Audit Log.
GDPR compliance
- PII has configurable retention with automatic purging.
- Event payloads reference PII by ID, never by value.
- Visitor data deletion cascades to all associated data (signatures, PDFs, vouchers).
- Built-in GDPR Data Processing Notice template.
- Right to erasure supported via manual deletion.
- Data processing inventory available via audit log.
Network security
- All external communication uses TLS 1.2+.
- Agent-to-server communication uses mutual TLS (mTLS) — both sides verify certificates.
- No SSH-based deployment. Updates are pull-based (server pulls images from registry).
- Secrets are managed via SOPS/age encryption (in the repository) and environment variables (at runtime). No secrets in container images.