MPCH promoted its Canton key-management white paper on October 29, 2026. Source: MPCH. Graphic: CantonNews.
MPCH has promoted a new white paper on Canton key management for major banks, outlining decisions institutions should make before putting a node—the software that connects the bank to Canton—into service. Shared on October 29, the paper focuses on who can authorise signing, how those rules are enforced and what evidence a bank can retain.
A signing key is a secret credential used to approve or authenticate actions. A key-management system, or KMS, stores and controls the use of those credentials. MPCH’s paper argues that safe storage alone is insufficient: banks also need enforceable approval rules, records of key use and a recovery plan.
Protecting identity and daily operations
Canton uses different keys for different jobs. The root namespace key anchors an identity and authorises which other keys can act for it. Operational keys handle routine network activity.
The distinction affects recovery. Canton’s validator security guide explains that a participant’s root namespace key cannot be rotated. Its key-management documentation describes isolating that key and using delegated authority for administrative work. Routine node-key rotation does not replace the namespace root key.
The paper recommends keeping the root key offline while making operational keys available inside hardware security modules: dedicated devices that protect cryptographic keys. Offline protection and continuous operation therefore serve different needs.
Different key roles require different protection and availability arrangements. Sources: MPCH’s white paper and Canton’s key-management guide. Graphic: CantonNews.
Who controls a signing request?
MPCH describes its existing Stronghold KMS service as separating signing authority from the bank’s Canton node. The node prepares and submits transactions; the service applies the bank’s configured approval rules before signing. The company says this prevents the node from bypassing those rules on its own.
That is a claim about how the service is designed, not a guarantee against every security failure. MPCH defines its role as key protection and signing-policy enforcement. It says it does not hold the bank’s assets, operate its wallets or settle transactions.
Three choices for where the keys live
The paper describes three deployment arrangements:
- Fully managed: MPCH operates both the online hardware environment and offline root-key storage.
- A bank-held offline copy: the managed service continues, while the bank also retains its own cold root-key copy.
- At the bank’s premises: MPCH equipment sits inside the bank’s facility and remains operated by MPCH.
The last option changes the equipment’s location, not who operates it. Across the models, the paper presents approval controls, audit records and recovery procedures as part of the decision.
Plan before switching systems
The timing follows the Canton Foundation’s warning to protect validator keys and patch software. That advisory addresses operators generally; MPCH’s paper presents a vendor’s approach for banks.
Implementation still depends on the deployment. Canton’s current validator guide covers external KMS configuration for Helm deployments and says Docker Compose deployments are unsupported. Helm and Docker Compose are different ways to deploy and manage the node software. For an existing non-KMS validator, it recommends creating a fresh KMS-enabled validator and transferring relevant assets, rather than simply changing a setting.
MPCH says it already manages Canton validator keys in production. The new paper does not name a new bank customer or announce a completed deployment.
Primary sources: MPCH white paper, its October 29 announcement and Canton validator security guide. Reporting cutoff: October 29, 2026 at 00:57 UTC.
