Security
Built to be audited.
Thoma is designed for shops whose IT teams have to defend a CMMC review or a 21 CFR Part 11 inspection. That means every security boundary is enforced server-side, every change writes a tamper-evident audit row, and every customer can read the source code that does the enforcing.
Differentiator
You can read every line of our source code.
Thoma is shipped source-available, not closed-source. Pattern-wise this follows companies like Sentry, MongoDB, and Cal.com: customers can read every line of the codebase for security audit purposes — including the auth code, the license-check code, the encryption-at-rest paths, and the multi-tenant isolation boundary.
For shops doing a CMMC vendor security assessment or a NIST 800-171 §3.12 review, this turns a multi-week exercise into a day. Your IT team doesn't have to take our word for the security claims on this page — they can verify them in source.
What you can do: read, audit, patch for internal use, run security analysis tools against the codebase. What the license restricts: redistribution, modification for competing use, running without a paid license. IP protection comes from license terms, not from obfuscation.
The full license is published on the Terms of use page. Source access is gated by a light-touch mutual NDA, currently handled through a short NDA-review path (online DocuSign signing is in preparation). Request source access →
Security feature inventory
Categorized for an IT-procurement reviewer. Each item is implemented today and verifiable in source. The security-critical paths — authorization, identity-token parsing, and integrity verification — are continuously property/fuzz-tested and failure-mode tested. Long-form evidence with NIST 800-171 + CMMC L2 mappings lives in the Security & Compliance white paper.
Identity + authentication
Passwords hashed with PBKDF2-HMAC-SHA256 (FIPS-approved)
User passwords are stored as PBKDF2-HMAC-SHA256 hashes at 600,000 iterations (OWASP 2023 recommendation, FIPS 140-2/3 approved). Legacy bcrypt hashes from pre-2026-05-11 verify transparently and migrate to PBKDF2 on next login. Plaintext passwords never touch disk. No password ever leaves your server.
MFA (TOTP) with encrypted secrets at rest
TOTP MFA is available on every tier with per-user enrollment and admin-issued recovery codes, and can be enforced org-wide — required by default on the Enterprise tier, and configurable per org on any tier. When enforcement is on, an un-enrolled user can't get a working session: login hands them a scoped enrollment token and nothing else until they set up MFA. Thoma's enforcement covers password / built-in / LDAP logins; SSO (OIDC/SAML) logins inherit MFA from your identity provider. So the CMMC IA-2 / NIST 800-171 3.5.3 requirement can be met through Thoma's own enforcement, through your MFA-enforcing IdP, or through MFA on the access path (workstation/network). When an encryption key is configured, shared TOTP secrets are AES-256-GCM-encrypted before being written to the database — so even a stolen DB dump can't replay codes without the key.
Account lockout + last-code replay defense
Configurable lockout after N failed attempts. The most-recently-redeemed TOTP code is recorded so the same code can't be replayed inside its 30-second window.
Optional AD / SSO (Enterprise)
Enterprise customers can plug Thoma into Active Directory (LDAP bind), OIDC (Okta, Azure AD, Auth0, etc), or SAML 2.0 (any standards-compliant IdP) so users don't manage a separate set of credentials. For Active Directory, SAML, and OIDC, group-to-role mappings sync on every login.
Authorization
Role-based, server-enforced
Write endpoints are gated by server-side permission checks. Tampering with the frontend doesn't grant write access — the server resolves your role and permissions from the database on every request and enforces them, regardless of what the client sends.
Per-category permission matrices
Document categories carry their own permission rules — viewers, editors, approvers, status-transition rights all configurable per category. A user can be a Documents editor and a Changes viewer in the same install.
Status-transition checks
Releasing or rejecting a document is itself a permission. The check runs on /api/data POST against the OLD blob's category rules so a malicious payload can't grant itself the transition (21 CFR Part 11 §11.10(g) authority check).
Audit trail
Append-only audit log
Every write, status change, login, MFA event, admin action, and document/CUI access writes a row to the audit log. Rows are append-only — any update or deletion breaks the hash chain and is flagged on the next verification; only a configurable retention job prunes old rows.
Hash-chained for tamper detection (CMMC AU-9)
Each row's hash includes the previous row's hash, so changing or deleting a single row breaks the chain. An admin panel runs chain-integrity verification on demand, and a scheduler runs it nightly.
Filesystem attestation mirror for defense-in-depth
When the operator configures a filesystem mirror directory, each integrity scan writes its verification result — the chain-head hash and break count — to an append-only directory outside the database. If an attacker compromises Postgres but not the host filesystem, the independent chain-head attestation still reveals whether the audit chain was altered. (Enabled by default on the managed cloud deployment; opt-in on-prem.)
Electronic-signature ceremony with locked records
21 CFR Part 11 §11.50 / §11.70 — signed records carry the signer's identity, timestamp, and the meaning of the signature, written into a separate signature chain that is itself hash-linked.
SIEM-ready event stream (webhook + syslog + OCSF)
Auth events, chain-integrity alerts, AD-driven offboarding, and failed-login + account-lockout signals fan out to your SIEM via webhook (Splunk HEC / Datadog / custom JSON) and/or syslog UDP (CEF or RFC 5424). OCSF v1.3.0 webhook output for normalization-aware SIEMs (Splunk-OCSF, AWS Security Lake, Sentinel). Copy-paste detection-rule templates available — see /security/siem-detection-rules.
Data at rest
Customer-controlled hardware
Thoma runs on your server. Database files, the document vault, and the audit log live on disks you control — encrypt the disk with BitLocker / LUKS / your tool of choice and we're protected at rest by your usual storage policy.
Append-only file vault with versioning
Document binaries are written to a vault under a unique per-file identifier, with a SHA-256 integrity checksum verified on read. Edits create new versions; previous versions are retained. The vault is the single source of truth and never silently overwrites.
Document vault encrypted at rest (AES-256-GCM)
Document binaries in the vault are encrypted with AES-256-GCM — a unique per-file data-encryption key, each wrapped by a per-deployment key-encryption key held in your KMS or environment, never in the database. A stolen disk or database dump yields ciphertext, independent of whole-disk encryption. Encryption is fail-closed: a missing key refuses new writes rather than silently storing plaintext.
Encrypted secrets (TOTP, backup keys)
Sensitive at-rest values that aren't user-controlled can be encrypted at the application layer with keys held outside the DB: TOTP secrets via AES-256-GCM when a TOTP encryption key is configured, and database backups via AES-256-CBC with PBKDF2 key derivation when a backup encryption key is configured.
Data in transit
TLS-only by default
The installer wires up TLS termination from day one. HTTP-only deployment is supported for air-gapped intranets where TLS is handled upstream, but the default is HTTPS with HSTS.
Strict CORS + security headers
CORS allowlist locked to your configured origin. Standard hardening headers (CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy) are set by the server.
No third-party data sharing
Customer data never leaves your server — except the optional AI Assistant, which is per-org opt-in and disabled by default. See the AI Assistant carve-out below.
Deployment
Native Windows install on your hardware
Single installer, portable Postgres bundled, runs as a Windows service. No SaaS account, no cloud-vendor lock-in. Your data lives where you put it.
Offline operation (air-gapped, Professional and Enterprise)
Every install tolerates up to 72 hours offline via a signed-license grace cache, so a transient internet outage never interrupts work. Professional and Enterprise licenses can additionally be issued for full air-gapped operation: a long-lived signed activation key with no mandatory heartbeat, for DoD-contractor and restricted-internet shops. The license still expires at the end of its term — offline means no phone-home until renewal, not a license that never checks. You won't need to step up to the compliance tier just to run offline.
Pre-update backup automation
Updates take a snapshot of the database and configuration before applying, and a bundled one-command script rolls that snapshot back if an update goes wrong. The document vault can optionally be folded into the same pre-update snapshot for fully turnkey rollback; by default it stays in your separate file-level vault backups, since it can be large.
AI Assistant carve-out
The single exception to "no third-party data sharing"
Thoma's optional AI Assistant feature sends queries plus a recent-context snapshot to Anthropic's Claude API when a user asks it a question. This is the only place customer data leaves your server, and it is gated behind multiple safeguards:
- Off by default. Per-org admin must explicitly enable it via a privacy disclosure modal.
- Unavailable on Enterprise tier. CMMC Level 2 environments can't enable it at all — third-party LLMs are incompatible with CUI handling restrictions.
- Anthropic's commercial API terms apply — under Anthropic's published commercial terms, prompts/outputs are not used to train models and are not retained beyond the limited period needed to operate the service and meet legal/safety obligations. (Per Anthropic's terms as published; confirm the current version with Anthropic.)
- Per-user + per-org quotas with a global vendor kill switch (`THOMA_AI_GLOBAL_DISABLE`).
- Every chat persists server-side in your per-organization chat history for admin review.
Full details: /ai-chat/.
Compliance posture
CMMC Level 2 ready (Enterprise)
The Enterprise tier ships with the controls a CMMC L2 assessment looks for: org-wide multi-factor authentication (required by default on Enterprise — enforced by Thoma for password/LDAP logins, by your IdP for SSO), AD/SSO support, append-only audit log with chain integrity verification, full air-gapped deployment (offline license activation, no mandatory heartbeat), and the AI-Assistant carve-out. SOC 2 Type II is on the launch roadmap.
21 CFR Part 11 fit
§11.10 controls (validated systems, audit trails, authority checks, electronic signatures): the audit-log + signature-ceremony + status-transition-permission stack maps cleanly. The standard configuration is designed to support a Part 11 inspection.
NIST 800-171 mapping
Per-control mapping for the AC, AU, IA, SC, and SI families is included in the Security & Compliance white paper. Source- available means a vendor security assessment (3.12 family) can be done with the actual code in front of the reviewer.
Vulnerability response
Reports go to [email protected]. We aim to acknowledge reports promptly and to assess and remediate high-severity issues as quickly as practicable, prioritizing them ahead of routine work. Customers get advance notice of the patch window via email.
Backup + recovery
Pre-update snapshots are automatic. Full DB + vault backup is one command. Restoration is one command. Backup encryption keys are managed by your IT team — we never hold them.
Supply-chain transparency
The product's dependencies are lockfile-pinned. Its CI blocks known high-severity vulnerable dependencies (npm audit gate) and scans every product change for committed secrets (gitleaks). A CycloneDX SBOM is available on request for any release.
Multi-tenant isolation
Self-hosted Thoma is single-tenant by definition (you run it on your server). The public demo and any future managed-hosting option enforce per-org boundaries at the API layer with server-side org-id checks on every request.
Reference
Security & Compliance white paper
The white paper is the long-form companion to this page: per-control NIST 800-171 mapping, threat model, key-management diagram, the full audit-chain verification algorithm, and the assessment-ready posture statement IT teams hand to their auditors.
The white paper is complete (v1.0). We share it with serious prospects under NDA — request a copy by emailing [email protected].
Ready to put it in front of your IT team?
Trial installations include the full security feature surface (excluding the Enterprise-only compliance package). IT can run their review on the actual install, against the actual source code, before anyone signs anything.