A Canton participant node does not have to hold its own private keys. It can delegate every signing and decryption operation to an external key management service, so key material never sits on the node host or in its database. Canton ships support for AWS KMS and GCP KMS. Azure was not on that list.

IntellectEU built the driver that closes the gap, then asked Halborn to review it. The report is public. Here is what it covered, what it found, and what changed.

Why key management decides where a Canton validator can run

A validator's keys are its identity on the Canton Network, which makes the question of where those keys live an architectural decision rather than an operational detail.

In external key mode the node stores only references to vault keys. Every signature over a topology transaction and every decryption of an incoming message happens inside the vault, on request, authenticated by a short-lived token. Private keys never cross the vault boundary.

A participant holds four keys: three EC P-256 keys for namespace, signing and sequencer authentication, plus one RSA-2048 key for encryption. The namespace key is the root of the node's identity, so rotating it changes the node's cryptographic ID and makes it unrecognisable to every counterparty. It must also carry no expiry date. An expired namespace key stops the node, and the identity cannot be recovered without re-onboarding from scratch.

What Azure offers, and what was missing

Azure has three key storage tiers, and they are not interchangeable.

Only Managed HSM runs symmetric operations natively inside the hardware boundary. On both Key Vault tiers the driver uses envelope encryption instead: an ephemeral local AES data key, wrapped by an RSA key that never leaves the vault. Managed HSM is required only where compliance mandates symmetric encryption inside that boundary.

Canton exposes a KMS Driver API so providers can be added without changes to Canton itself. And yet nobody has used it for Azure.

Who holds the keys

The architectural choice that matters most here is not the vault tier. It is whose account the keys sit in.

In the reference deployment, the customer-managed keys live in the client's own Azure tenant, separate from the account running the workload. The client gets an independent audit trail of every key operation and can revoke access unilaterally, without any access to the operator's infrastructure. The node can be operated without the operator ever being able to become the node.

Cross-tenant workload identity makes that work across an organisational boundary. The client creates a managed identity in their tenant, federates it to the operator's Kubernetes cluster, and grants it vault access. No shared secret is created, distributed or rotated anywhere, and a Private Endpoint keeps traffic off the public internet.

When the client's security team pre-creates the keys rather than letting Canton generate them on first boot, the node runs read-only - get, sign, decrypt. Nothing else.

Why an independent audit

A KMS driver runs in-process with the node, which gives it access to Canton's process memory. That is inherent to any in-process driver rather than a flaw in this one, and it is exactly why an external review is worth commissioning.

Halborn is a blockchain security firm whose engineers work in custody and secrets management alongside cloud and infrastructure penetration testing. Halborn assessed the architecture and trust model, the Key Vault integration, key generation and signing, the dependency chain, and readiness for open-source release, across advisory and assurance teams.

Most blockchain security work is contract-level. A custody review is a different exercise according to Justin Fang, DLT Enterprise Architect at Halborn:

"Custody and key management reviews cover both the system-level security of keys and operational risks."

Underneath that sit entropy on key generation, cosigner setup and rotation, decryption at signing time, transaction intent verification, HSM and TEE protection, key destruction, maker-checker controls against insider manipulation, endpoint security, and disaster recovery for keys. Almost none of it appears in a contract audit.

What the audit found

All six were addressed. The driver was assessed at v0.7.1 and the remediations shipped in v1.0.0. Halborn recommends a follow-up assessment within six months, or after any material change.

Key management is usually treated as a storage problem. Justin Fang's view is that it is considerably wider than that:

"Key management extends beyond 'did I generate my key with enough entropy' and 'my key is in a safe location'. Specific to Canton, custody concerns extend beyond transaction signing. They affect namespace identities, validator set up and slashing events ... and even implicate the ability of a party to monitor or decrypt on-chain activity in the case of key loss or attack. Additionally, as more enterprises utilize agentic workflows, novel attack vectors such as prompt injection introduce a new attack surface where AI agents and AI-generated code affect key material operations."

The namespace identity point is the same one that makes that key non-rotatable: lose it and the loss is not a signing outage, it is an identity that cannot be reconstructed. The agentic point is early but not hypothetical. Institutions are already pointing coding agents at Daml, and an agent able to alter key configuration is a key management surface whether anyone has classified it as one or not.

Access the full audit here.

What to ask before letting anyone run your validator

Jonathan Mayeur, Head of Product at CatalyX and IntellectEU, puts it in three questions:

"Where do the private keys physically live, and can you prove they never leave that boundary. What can the operator do with those keys that the client cannot see. And if the client wanted to revoke access tomorrow, could they do it themselves, without us. If those answers aren't clean, the operational convenience isn't worth it."

Those questions apply whether a validator is self-hosted, run on a generic node service, or operated under management. Self-hosting keeps every answer in-house, at the cost of building and staffing the operation. A generic provider may not be able to answer the third one at all.

CatalyX Blockchain Manager keeps all three answers with the client: keys in the client's vault, operations logged on the client's side, access revocable without a conversation.

Canton key rotation and Azure key rotation are different operations. Rotating a Canton key is a topology change made from the Canton console. Rotating an Azure key adds a new version in the vault. Keys the driver generates carry a pinned version in their identifier, so an Azure-side rotation creates a version the node never touches.

About IntellectEU and CatalyX

IntellectEU is a founding member of the Canton Foundation and operates a Super Validator on the network. CatalyX is its product suite for the infrastructure and operations layer of Canton: running the nodes, building and distributing the Daml applications, and tracking what the network costs and returns.

Canton is a public Layer 1 with configurable privacy. Whether an institution builds on it or connects to it, someone has to run the infrastructure underneath and operate it day after day.
That is the layer CatalyX by IntellectEU is built for.