— Stronghold-KMS

Stronghold-KMS

Purpose-Built Key Management
for Authority Infrastructure

Stronghold-KMS governs authority keys for any regulated infrastructure — blockchain nodes, validators, PKI systems, and signing infrastructure. First deployed for Canton networks, built for any system that depends on authoritative key control.

Canton · Blockchain Validators · Certificate Authorities · Signing Infrastructure

Get Started

The Foundation of Network Trust

System-Level Keys

Wallet keys move assets. System-level keys protect the network itself. In Canton, security isn't just about asset custody — it's about trust in every node, every transaction, and every rule embedded in the system. System-level keys power encrypted state sharing, consensus, and operational logic. And these same patterns apply across any infrastructure where authority keys govern trust.

Namespace Key

Controls governance scope and participant identity within a Canton domain

Identity Key

Establishes node identity; enables authenticated participation in the network

Encryption Key

Protects state confidentiality and encrypted ledger sharing between participants

Signing Key

Authorizes and validates all transactions and operational commands

Admin Key

Controls configuration, upgrades, and emergency operations at the node level

Extensible Architecture

Built for Any Authority Key

Canton is the first deployment. Stronghold-KMS is designed around a principle, not a product: any system that depends on authority keys for its integrity deserves the same level of controlled custody.

Canton — First Deployment

One architecture. Any authority key system.

The same custody model that governs Canton node keys applies wherever authority keys underpin infrastructure trust. The key management problem is universal; only the key types change.

Stronghold-KMS separates the policy engine, the HSM integration layer, and the key lifecycle logic — so onboarding a new key type is a configuration exercise, not a re-architecture.

The key management problem is universal. Only the key types change.

Blockchain Validators

Validator signing keys, staking keys, and consensus participation keys for proof-of-stake and permissioned blockchain networks.

PKI & Certificate Authorities

Root CA and intermediate CA private keys — the most sensitive keys in any enterprise PKI, requiring strictly controlled access and lifecycle management.

Code Signing Infrastructure

Software release signing keys and firmware authentication keys where a single compromise can affect every user of a system at scale.

IoT Device Identity

Manufacturing root keys and device provisioning keys that establish trust anchors for large fleets of connected devices.

Network Authentication Systems

RADIUS, TACACS+, and DNSSEC signing keys that underpin the trust model of enterprise network access.

Secure Communications

End-to-end encryption master keys and session signing keys for classified and regulated communication systems.

Why It Matters

Infrastructure Trust Is Non-Negotiable

Authority key compromise doesn't trigger a fraud alert. It silently erodes the trust that makes regulated infrastructure function.

Security operations analyst monitoring infrastructure

Trust Foundation

Institutions rely on infrastructure trust — not just user endpoints. A Canton node, a validator, or a root CA is only as trustworthy as the keys that govern it.

System Fragility

One compromised system key can unravel an entire network. Unlike wallet keys, authority keys have no recovery path once trust is broken.

Controlled Continuity

Standardized key control ensures compliance, auditability, and continuity across operations, audits, and regulatory reviews.

Below the Application Layer

Authority key governance operates below the application layer — invisible to most monitoring, but foundational to the trust model of the entire system.

Traditional security protects keys. Modern systems must govern authority.

The Hidden Risk

Authority key compromises have a disproportionate impact on infrastructure trust — and they rarely announce themselves.

Case Study

GitHub Token Leak

An old token exposed 270GB of critical source code — including deployment scripts and infrastructure configs. An infrastructure credential, not a wallet key. System-level key governance would have scoped and rotated this credential automatically.

Purpose-Built Requirements

Why Authority Keys Need Purpose-Built Management

Authority key systems operate under a distinct trust model. Key management must align with participant topology, governance scope, and the operational realities of the system being protected.

Local Filesystems

Disk-based key storage lacks audit controls and exposes key material to misconfiguration, malware, and insider access without policy mediation.

Limited auditability. Compliance gaps.

Cloud KMS

Multi-tenant infrastructure introduces shared trust assumptions and jurisdictional considerations that may not align with sovereignty requirements for regulated infrastructure.

Shared tenancy. Jurisdictional considerations.

Standalone HSMs

HSM hardware provides strong key isolation, but authority key systems require dynamic lifecycle management — key rotation, participant onboarding, and governance updates that benefit from software-defined orchestration.

Strong isolation. Limited orchestration.

Designed for control, not convenience

Authority keys require a purpose-built system that governs key lifecycle end-to-end — issuance, use, rotation, and revocation — under enforced policy controls, with full auditability and zero trust assumptions.

Stronghold-KMS addresses all of the above.

Modern data center server infrastructure

Stronghold-KMS is not a tool, it is a control infrastructure.

Stronghold-KMS Capabilities

Built for Authority Keys. Built for Resilience.

Every capability is designed around the operational realities of authority key systems — governed key lifecycle, policy-mediated access, and sovereign custody.

True Cold Storage

Air-gapped key storage for the most sensitive cryptographic material. Keys that never touch a live network can never be exfiltrated from one.

Hardware-Enforced Key Isolation

Keys never leave secure HSM boundaries. Hardware Security Module integration for signing and operational continuity, with enforced policy controls on every key use event.

No Third-Party Dependencies

No cloud lock-in, no shared infrastructure, no external trust assumptions. Your keys remain under sovereign control at all times.

System-Native Integration

Designed from the ground up for each target system's trust model and topology — no retrofits, no shim layers. Canton-native first.

Continuous Updates

Key management policies remain aligned with system upgrades and evolving compliance requirements without operator disruption.

Zero-Trust by Design

Segregated access controls and policy enforcement mean even MPCH operators cannot access your keys. Custody belongs entirely to you.

Stronghold hardware · HSM integration

Architecture

Zero Trust In Action

Your keys. Your policies. Even MPCH has no access.

No direct key access for operators — all interactions are mediated by the policy engine, with no override path available to MPCH staff.

Permissioning governed by a configurable policy engine — define who can request, approve, and audit key operations across your organization.

Full visibility and auditability — every key lifecycle event is logged with tamper-evident records, ready for regulatory review.

End-to-end control with zero reliance on cloud services — operates in fully air-gapped or hybrid environments with no external connectivity required.

Stronghold HSM hardware · Air-gapped key store

Keys Ledger

Audit Logs

Get started

See How MPCH Secures Your Operations

Request a Demo