Custody Is a Process, Not a Product: Designing Aergo Key Management for UK Production Systems

Enterprise blockchain projects rarely fail because the ledger cannot store a record. They fail because a private key sits in the wrong place. On Aergo, as on any account-based network, the private key is the authority: it signs transactions, authorises contract administration and, in the case of block producers, supports the operation of the network itself. A pilot can tolerate a key on a developer laptop. A production system cannot.

The integration risk is often described as connectivity, identity or data modelling. In practice, the harder question is who can sign, under what conditions, and how the organisation proves it afterwards. This playbook is for UK teams moving from an Aergo proof of concept into a controlled production service. It does not recommend a single vendor. It sets out the decisions that should be taken before the first transaction is signed.

Begin with a key inventory, not a product shortlist

Before comparing hardware security modules or multi-party computation providers, list every key that the Aergo deployment will rely on. A typical enterprise deployment has at least four classes:

• Account keys that hold tokens or authorise contract calls.
• Administrative keys that upgrade contracts, change parameters or pause activity.
• Infrastructure keys used by nodes, block producers or bridge operators.
• Operational keys used by middleware, oracles and batch jobs.

Each class has a different blast radius. A compromised user key may affect one account. A compromised administrative key may affect every participant. Map each key to an owner, a signing authority, a transaction limit and a recovery route. Record the map in a document that the finance, operations and security teams can read. This inventory becomes the basis for custody design and the first artefact an auditor will request.

Aergo's account model is familiar to teams that have worked with Ethereum-style networks, but familiarity can breed carelessness. A private key is not a password that can be reset by an administrator. If it is lost, the account is lost. If it is copied, the copy is as powerful as the original. Treat every key as a bearer instrument.

Four custody models and the trade-offs UK teams face

Software keystores are the default in development. They are cheap and flexible, but they place the key on a general-purpose machine. For production, they are appropriate only for low-value, tightly scoped operational keys, and only when the host is hardened and monitored.

Cloud key management services offer managed HSMs and audit logs. They suit UK teams that already run in a regulated cloud environment, but data residency, sub-processor disclosure and exit plans need to be checked against the organisation's outsourcing policy. The NCSC cloud security principles remain a useful reference, even for private-sector teams.

On-premises HSMs provide strong isolation and a clear physical boundary. They are often chosen by organisations that need to demonstrate control to a regulator or a board. The trade-off is operational: firmware updates, backup ceremonies, availability and skilled staff. An HSM that is unavailable at the moment of settlement is a business continuity incident, not an IT inconvenience.

MPC and threshold signing distribute the key material across participants, so no single machine holds a complete key. This can reduce single points of failure and support dual control, but it introduces coordination complexity and a new vendor dependency. For Aergo deployments with multiple institutions, MPC can be attractive; for a single UK company with a small operations team, it may add more complexity than control.

The right answer is usually a tiered model. High-value administrative keys sit in an HSM or a threshold scheme. Routine operational keys sit in a managed service with tight permissions. Development keys never touch production accounts.

Separation of duties on the signing path

Separation of duties is easy to state and hard to implement. The person who requests a transaction should not be the person who approves it, and neither should be the only person who can sign it. On Aergo, this means designing the signing path so that a transaction moves through distinct roles:

• Requester: prepares the transaction and attaches the business context.
• Approver: checks the amount, counterparty and purpose against policy.
• Signer: operates the key material and has no discretionary authority.
• Auditor: reviews logs and evidence after the event.

For low-value transactions, some roles can be combined. For administrative changes, none should be. The signing path should be documented as a workflow, not left to a chat message. Where possible, enforce it in tooling: a transaction management system that records the request, the approval and the signature is more reliable than an email trail.

UK regulated firms should also check the FCA's operational resilience expectations and, where applicable, PRA outsourcing rules. These do not prescribe blockchain key management, but they do require firms to understand critical operations and third-party dependencies. A key management provider is a third party. Treat it as one.

Recovery is a rehearsal, not a document

Every key management plan includes a recovery section. Few teams test it. A recovery plan that has not been rehearsed is a hypothesis.

For Aergo account keys, recovery may mean restoring from an encrypted backup, reconstructing a threshold share or invoking a pre-agreed succession process. For administrative keys, it may mean a multi-person ceremony with witnesses. For infrastructure keys, it may mean rotating a node identity and updating peer configurations.

Run a tabletop exercise first, then a technical rehearsal in a non-production environment. Record the time to recover, the people involved and the evidence produced. Repeat annually or after a significant change. The rehearsal should involve the operations team that will be on call, not only the security architects who designed the scheme.

A useful test is the departure scenario. If the only person who knows how to operate the HSM leaves, can the organisation still sign? If the answer is no, the custody model is not production-ready.

Evidence that finance and operations will ask for

Aergo gives the organisation a transaction record. It does not, by itself, give the organisation proof that the transaction was authorised under policy. That evidence must be assembled around the ledger.

Expect requests for:

• A key inventory with owners and classification.
• A signing policy that maps transaction types to approval thresholds.
• Key ceremony records, including attendees and tamper-evident logs.
• Access reviews for the key management service or HSM.
• Certification evidence, such as FIPS 140-3 or Common Criteria, where claimed.
• Incident and recovery test reports.
• Change tickets for contract administration and key rotation.

Finance teams will also want to reconcile on-chain movements with internal records. Operations teams will want runbooks. Auditors will want to see that the evidence is complete, retained and retrievable. Aergo's transparency helps, but it is not a substitute for internal control documentation.

A UK checklist before production

Before go-live, confirm the following:

• Every production key has a named owner and a documented purpose.
• Administrative keys require at least two people to act.
• Key material is stored in a device or service with an appropriate assurance level.
• Backups are encrypted, tested and stored separately from the primary system.
• Recovery has been rehearsed within the last twelve months.
• Access to key management systems is logged and reviewed.
• The outsourcing and data residency position is documented.
• The signing workflow is enforced by tooling, not convention.
• The evidence pack can be produced without asking a developer to search a laptop.

None of this is unique to Aergo. That is the point. Enterprise blockchain inherits the operational disciplines of enterprise IT, and key management is where those disciplines meet the ledger. The teams that succeed are not the ones with the most elegant contract. They are the ones that can answer a simple question: who holds the keys, and how do you know?