Security Overview

Where data is stored

IronKeep hosts all data in the United States, administered by US citizens, on FedRAMP Moderate (or higher) authorized cloud infrastructure.

All data is encrypted and stored across redundant databases and object storage with automatic failover.

Encryption

IronKeep uses three layers of encryption, all backed by FIPS 140-3 validated cryptographic modules. Each layer protects against different threat scenarios.

Layer 1: Storage encryption

All databases and object stores are encrypted at rest using dedicated per-tenant encryption keys. This protects against physical media theft and unauthorized infrastructure access.

Layer 2: Application-level envelope encryption

Sensitive fields and PII (email subjects, contact names, email addresses, calendar events) are encrypted at the application layer using AES-256-GCM before being written to the database. Each encryption operation uses a unique data key generated by a managed key service. Even with database access, encrypted fields are unreadable without the correct tenant key and encryption context.

Layer 3: Client-side encryption

The web application encrypts its local cache using a user-selected PIN. Key derivation uses PBKDF2 with 600,000 iterations (OWASP 2023 recommendation). Incorrect PIN attempts wipe the local cache.

Key management

Each tenant gets its own master encryption key managed by a dedicated key service with zero-operator access — even the underlying cloud provider cannot access key material. Keys rotate automatically on an annual schedule. The key hierarchy ensures that one tenant's keys can never decrypt another tenant's data. All key operations are audit-logged.

Operator access

Platform administrators can manage organizations, provision users, and configure infrastructure. They cannot:

Read tenant emails, contacts, or calendar data
Decrypt tenant encryption keys
Access plaintext user content
Generate search tokens for tenant data

This is enforced by encryption key policies with explicit deny rules on decrypt operations for admin roles. It is a technical control, not a policy promise.

Role model

Platform Admin: Creates and manages organizations and infrastructure. No access to tenant data.
Organization Admin: Manages users, DLP policies, and geo-fencing rules within their organization.
Compliance Officer: Can place legal holds and initiate eDiscovery exports. Read-only access to emails for compliance purposes.
User: Access to their own email, calendar, and contacts within their organization.

Tenant isolation

Tenant data is separated at every layer of the stack. This is not a single boundary — it is enforced redundantly across four systems.

Database queries: Every database query is scoped to the requesting tenant. Composite indexes prevent cross-tenant table scans.
Object storage: Stored objects are scoped by tenant. Storage policies enforce tenant-specific key usage.
Encryption context: All encrypt/decrypt calls include tenant-specific context. A key for Tenant A cannot decrypt data encrypted for Tenant B.
Authentication claims: The tenant identifier comes from the identity provider's JWT token, not from request parameters. It cannot be spoofed or overridden by the client.

Email security

Inbound

Incoming emails are validated for SPF, DKIM, and DMARC before acceptance. Accepted emails are stored encrypted, then processed through a serverless pipeline that includes virus scanning. Infected emails are moved to quarantine. Clean emails are parsed, encrypted, and stored in the mailbox database.

Outbound

Outbound emails are scanned for viruses and evaluated against organization-specific DLP (Data Loss Prevention) policies. DLP rules can block, quarantine, or flag emails based on keywords, recipient domains, file types, and regex patterns. Deny rules are always evaluated first. All DLP decisions are audit-logged.

Internal routing

Emails between users on the same platform are routed internally — they never leave the infrastructure. The system classifies recipients as internal or external and routes accordingly.

Backups & recovery

Database: Automated daily backups with point-in-time recovery. Multi-zone deployment with automatic failover.
Deleted data: User-deleted emails go to Trash with a configurable retention period before permanent deletion. Legal holds prevent permanent deletion of held records.
Backup encryption: All backups are encrypted with the same tenant encryption keys as the source data. Accessing a backup requires the same key permissions as accessing live data.

Compliance targets

IronKeep is designed to meet the following frameworks:

CMMC Level 2 — Access controls, audit logging, encryption, and incident response mapped to CMMC practices
NIST 800-171 — CUI handling controls including access control, configuration management, and audit accountability
DFARS 252.204-7012 — Adequate security for covered defense information
ITAR — US-person access controls and US-hosted infrastructure

Certification is in progress. The architecture is designed to produce audit evidence, not just pass a checklist.