External Signer

External Signers: Own a Smart Account with a KMS, HSM, or Hardware Wallet

For institutional and custody use cases, an in-memory EthECKey isn't acceptable — the signing key has to live in a cloud Key Management Service, a hardware security module, or a physical device, and must never be readable by the application process itself. IEthExternalSigner is Nethereum's seam for that: signing happens as a remote or hardware operation instead of an in-process ECDSA computation.

The account itself doesn't change. It is still a plain ECDSA-owned NethereumSmartAccount, installed with the same EcdsaValidatorModule used everywhere else in Account Abstraction. Only where the key lives and who computes the signature changes — the generic on-ramp doesn't care which IAccountSigningService you hand it, so wiring an external signer in is exactly the same shape as wiring a raw key, one level removed.

When to Use This

• User needs a smart account's signing key in a KMS/HSM, never in application memory
• User mentions AWS Key Management Service, Azure Key Vault, custody infrastructure
• User wants a Ledger or Trezor hardware wallet to control a smart account
• User is building institutional custody or compliance-driven signing
• User wants to plug in a custom/MPC signer without changing the rest of the AA stack

Packages

dotnet add package Nethereum.Web3
dotnet add package Nethereum.AccountAbstraction

Plus whichever signer package matches the backend:

Each derives from Nethereum.Signer.EthExternalSignerBase. You also need IAAClient registered (the standard AddNethereumAccountAbstraction setup) and the same NethereumAccountFactory + ECDSAValidator pair deployed on the target chain that any ECDSA-owned account uses — an external signer installs the identical validator, so there's nothing extra to deploy on-chain for it.

The Simple Way

Wrap any IEthExternalSigner in AccountSigningExternalService, then drive it through the same generic on-ramp as any other signer:

using Nethereum.Accounts.AccountMessageSigning;
using Nethereum.AccountAbstraction;
using Nethereum.AccountAbstraction.Client;
using Nethereum.AccountAbstraction.ERC7579.Modules;
using Nethereum.AccountAbstraction.Signing;
using Nethereum.Signer;

// externalSigner is any IEthExternalSigner - a KMS, HSM, or hardware-wallet signer whose private
// key never lives in this process.
IEthExternalSigner externalSigner = /* your KMS/HSM/hardware-wallet signer */;
var ownerAddress = await externalSigner.GetAddressAsync();

var signingService = new AccountSigningExternalService(externalSigner);
var validator = new EcdsaValidatorModule(deploymentAddresses.EcdsaValidatorAddress);
var initData = AccountInitDataBuilder.BuildEcdsa(deploymentAddresses.EcdsaValidatorAddress, ownerAddress);

var account = await aaClient.CreateAccountAsync(signingService, validator, initData);   // NethereumSmartAccount

myToken.UseAccountAbstraction(account, aaClient);
var receipt = (AATransactionReceipt)await myToken.TransferRequestAndWaitForReceiptAsync(recipient, amount);
Console.WriteLine($"UserOp success: {receipt.UserOpSuccess}, sender: {receipt.Sender}");

That's it — no code downstream of CreateAccountAsync knows or cares that the owner key lives in a KMS instead of memory. Every signature over a UserOperation hash is produced by a call out to externalSigner, never by an in-process private key.

Mental Model: Same ECDSA Account, Key Lives Elsewhere

An external-signer account is not a distinct account type — it's an ordinary ECDSA-owned NethereumSmartAccount with the same EcdsaValidatorModule and AccountInitDataBuilder.BuildEcdsa init data as a raw-key account. On-chain, the deployed ECDSAValidator reports the external signer's address as owner — indistinguishable from an account owned by an in-process key, because it's the same signature scheme (secp256k1/ECDSA) either way.

What changes is entirely client-side: AccountSigningExternalService wraps an IEthExternalSigner instead of an EthECKey, and its SignTypedDataV4/PersonalSign are delegated out to that signer — SignTypedDataJsonAsync for typed data, SignEthereumMessageAsync for personal-sign — as a KMS API call or HSM operation rather than an in-memory computation. Contrast this with a WebAuthn passkey (see the webauthn-passkeys skill): a passkey is a different signature scheme (P-256), whereas an external signer is still plain secp256k1 ECDSA — just computed somewhere else.