Trust Center
Last updated: April 15, 2026 · Version 1.0
Mimir Labs builds enterprise data tools that manufacturers entrust with their operational reality. This page documents how we protect that trust in practice. We will not claim a certification we do not hold. Where we are working toward one, we say so and give a date. If a date slips, this page will say so.
At a Glance
| Framework | Status |
|---|---|
| CMMC Level 1 (FCI) | Self-attested, April 2026 |
| CMMC Level 2 (CUI) | Readiness assessment planned Q3 2026 |
| SOC 2 Type 1 | Audit planned Q4 2026 |
| SOC 2 Type 2 | Audit planned 2027, contingent on customer engagements |
| NIST 800-171 alignment | Operational today; formal documentation in progress |
| ISO 27001 | Not pursued at this stage |
CMMC Level 1 Self-Attestation
What this means
The Cybersecurity Maturity Model Certification (CMMC) program, administered by the U.S. Department of Defense, defines three maturity levels for contractors who handle federal information. Level 1 covers the Basic Safeguarding of Federal Contract Information and consists of 17 practices across 6 domains, derived from FAR 52.204-21. Level 1 permits self-attestation. Levels 2 and 3 require third-party assessment.
What we attest to
Mimir Labs LLC, as of the date at the top of this page, meets the 17 CMMC Level 1 practices for all systems that would process Federal Contract Information, applied across our product portfolio (Yggdrasil, Ratatosk, Ragnarok, Bifrost, Mimisbrunnr, Norn).
Practices and our approach
| Domain / Practice | How we meet it |
|---|---|
| AC.L1-3.1.1 — Limit system access to authorized users | Role-based access control on every product; JWT-based authentication; no shared credentials |
| AC.L1-3.1.2 — Limit system access to authorized transactions | Per-role permission grants enforced at the API layer; least-privilege default |
| AC.L1-3.1.20 — Verify and control connections to external systems | All external integrations require named, scoped credentials; no anonymous API access |
| AC.L1-3.1.22 — Control public information on systems | Public surfaces are explicitly separated from authenticated systems |
| IA.L1-3.5.1 — Identify users and devices | Per-user accounts; no role accounts; session tracking on every authenticated request |
| IA.L1-3.5.2 — Authenticate users and devices | PBKDF2 password hashing; TOTP multi-factor authentication available; JWT with 1-hour expiry |
| MP.L1-3.8.3 — Sanitize or destroy media before disposal | Storage is cloud-hosted; decommissioning follows provider-documented secure-deletion practice |
| PE.L1-3.10.1 — Limit physical access | Production runs on hardened Hetzner VPS infrastructure with provider-managed physical security |
| PE.L1-3.10.3 — Escort visitors and monitor activity | Not applicable; no Mimir Labs physical facility hosts production systems |
| PE.L1-3.10.4 — Maintain audit logs of physical access | Inherited from hosting provider |
| PE.L1-3.10.5 — Control and manage physical access devices | Inherited from hosting provider |
| SC.L1-3.13.1 — Monitor, control, and protect communications | TLS 1.2+ for all external traffic; HTTPS termination at Caddy; internal service authentication |
| SC.L1-3.13.5 — Subnetworks for publicly accessible components | Public and authenticated surfaces separated at the network layer |
| SI.L1-3.14.1 — Identify, report, and correct flaws | Documented vulnerability response; dependency scanning on every build |
| SI.L1-3.14.2 — Protection from malicious code | Server-side input validation; parameterized queries; Content Security Policy headers |
| SI.L1-3.14.4 — Update malicious code protection | Automated dependency updates; scheduled security patching windows |
| SI.L1-3.14.5 — Perform periodic scans | Scheduled vulnerability scans of production infrastructure |
The signed self-attestation document is available on request via the contact below.
How We Handle Your Data
Where it lives
Tenant business data is stored in a dedicated, isolated PostgreSQL database specific to your tenant, hosted on dedicated Hetzner VPS infrastructure. Data is not shared across tenants.
Who can access it
Mimir Labs personnel access to customer production data is restricted to named individuals with documented business need. Access is logged. We do not share, sell, or license customer data. We do not use customer data to train machine learning models.
How long we keep it
Customer data is retained for the duration of the customer relationship plus a documented offboarding window (typically 30 days, subject to contractual agreement). Upon offboarding, customer data is either returned in a portable format, deleted, or both, at customer discretion.
Data portability is a first-class commitment. All customer-owned data can be exported in machine-readable form (CSV, JSON, or Mimisbrunnr-mapped canonical format) at any time, not solely at offboarding.
Protection in transit and at rest
- In transit: TLS 1.2 or higher, modern cipher suites. HTTPS enforced across all application surfaces.
- At rest: Filesystem-level encryption on production storage.
- Passwords: PBKDF2 hashing with per-user salts. We cannot recover a lost password; we can reset it.
- Secrets: Application secrets stored in a dedicated secrets store, not in configuration files or version control.
Authentication and Access Control
- Per-user accounts only. We do not support shared credentials.
- TOTP-based multi-factor authentication is available to all users and strongly recommended.
- Session tokens (JWT) expire after 1 hour by default.
- Role-based access control is enforced at the API layer, not only the UI.
- Tenant administrators have full control over their user roster, role definitions, and permission assignments.
- Failed authentication attempts are logged. Repeated failures trigger account lockout.
Audit Trail
Every data modification, state transition, configuration change, and significant integration event is recorded in an immutable audit log. The log captures the actor, the time, the entity affected, the before-and-after values where applicable, and the source of the request (IP address, user agent, session ID).
Audit logs are retained for the duration of the customer relationship and are accessible to tenant administrators through the administrative interface. Historical audit records are not editable or deletable by any user, including Mimir Labs personnel, except as part of documented legal-compliance workflows.
Vulnerability Disclosure
If you believe you have discovered a security vulnerability in any Mimir Labs product, please report it responsibly to [email protected]. We commit to acknowledging reports within 2 business days and providing an initial assessment within 10 business days.
We do not currently operate a paid bug-bounty program. We will publicly acknowledge researchers who report valid vulnerabilities (with their consent) once a fix is in place. We ask that reporters not publicly disclose vulnerabilities until we have had reasonable time to remediate, and that reports not include access to data belonging to customers other than the reporter’s own.
Subprocessors
We use the following third-party services in the operation of our products:
| Subprocessor | Purpose | Location |
|---|---|---|
| Hetzner | Production VPS infrastructure | Germany / United States (per deployment region) |
| Cloudflare | DNS, DDoS protection, CDN | Global |
| SendGrid | Transactional email delivery | United States |
| Square | Payment processing | United States |
| BoldSign | Electronic contract signing | United States |
| Google Analytics | Anonymized website analytics | Global |
| GitHub | Source code and build infrastructure | United States |
We will update this list if we add or change subprocessors. Material changes will be communicated to active customers.
Business Continuity
- Backups: Automated daily backups of all production databases, retained 30 days, encrypted in transit and at rest.
- Recovery Time Objective: 24 hours for a full production recovery from last good backup.
- Recovery Point Objective: 24 hours of data loss in the worst case.
- Geographic redundancy: Backup artifacts are replicated across regions. Application-layer geographic redundancy is planned for 2027.
- Incident response: Documented incident response process with named on-call responsibilities. Incident post-mortems are published to active customers within 10 business days of a material incident.
What We Do Not Do
We believe the absence of certain practices is part of a trust posture:
- We do not sell, license, or share customer data with third parties.
- We do not use customer data to train AI or machine learning models, our own or anyone else’s.
- We do not add undocumented subprocessors.
- We do not enforce data lock-in: customer data is exportable in the Mimisbrunnr canonical format at any time.
- We do not permit end-user extensibility of the canonical data model.
- Reference calls and case-study participation are voluntary. We do not require customers to serve as public references as a condition of engagement.
Contact
For security questions, compliance documentation requests, or to request the signed CMMC Level 1 self-attestation document: [email protected]
For general inquiries: [email protected]