Skip to main content
Applies to:
Cockpit v2Layered architectureMulti-tenant

Cockpit v2 is built on a layered, domain-driven design with defense in depth: clients reach a secure edge, requests pass through an authentication-and-authorization pipeline, domain services carry the business logic, and key material is held in a protected custody layer. The diagram below shows the shape of the platform.

DuoKey Cockpit — Architecture

A layered, defense-in-depth platform: clients, a secure edge, policy-enforced services, and protected key custody.

1
Clients & protocols
Microsoft 365 / OfficeDKE
Devices & workloadsACMEESTSCEPCMP
KMIP clientsKMIP 2.x
Console & REST / SDK
HTTPS / TLS
2
Secure edge
TLS termination
Rate limiting
Security headers
CORS
3
API & policy layer
Request pipeline
AuthenticationTenant resolutionEntitlement checkAudit
Then
Permission check (RBAC + ABAC)
Request validation
REST API
4
Domain services
Keys
Vaults
PKI
DKE 365
Post-quantum
KMIP
Applications
Access policies
Admin · Tenant · Editions
5
Data & audit
Encrypted database
Cache
Tamper-evident audit
6
Key custody
Software / DuoKey MPC KMS
Securosys HSMFIPS L3
Sepior (Blockdaemon)MPC
Cloud KMS · PKCS#11 HSMs

How it is organized​

Responsibilities are separated into clear layers, and dependencies flow downward only — the API and application layer depends on the domain, and the domain is independent of how it is delivered or stored.

Secure edge

TLS termination, rate limiting, security headers and CORS protect the platform before any request is processed.

API & policy layer

Every request is authenticated, bound to its tenant, checked against the tenant's entitlements, permission-checked and validated before a handler runs.

Domain services

Keys, vaults, PKI, DKE, post-quantum, KMIP, applications and access policies — the business logic, kept independent of delivery and storage.

Data & key custody

An encrypted store with a tamper-evident audit trail, and key material held in software, MPC or HSM custody behind one uniform interface.

Request flow​

Every request travels the same path: it is authenticated (session token or passkey), resolved to its tenant, checked against the tenant's edition entitlements, and audited — then the handler performs a permission check and validates the request before delegating to a domain service. The service reads or writes the encrypted store and, when cryptography is involved, calls the key-custody layer. Private keys never leave their vault or HSM.

One custody interface

Domain services talk to a single, uniform custody interface, so the same code works whether a key lives in a software vault, an MPC key-management service or a Securosys HSM. See Vaults & HSM.

Multi-tenancy​

Cockpit v2 is multi-tenant by construction. Every record belongs to exactly one tenant, the tenant is derived from the caller's signed identity (never supplied by the client), and isolation is enforced automatically for every query rather than left to individual features. Within a tenant, organizational units provide a second layer of scoping for teams and departments, and editions gate which capabilities are available.

Performance figures are indicative

Any throughput, latency or capacity number quoted for Cockpit v2 is an indicative target, not a guaranteed figure. Validate against your own environment before relying on it for capacity planning.

Secure edgerate limit · CORSAuthenticateJWT · WebAuthnTenantfrom tokenEntitlementsedition gateAuditfail-closedHandlerpermission + validateDomain servicebusiness logic
Every request is secured at the edge, authenticated, bound to its tenant, checked against entitlements and audited — before the handler runs a permission check and validation.