Amazon Web Services

Everything DFNS does with AWS, from the KMS orchestration to Nitro Enclaves, MPC with a customer-held veto, CloudHSM as a hardware root of trust, and procurement through AWS Marketplace.

Chris Sutton
Chris Sutton
| 13 min read

This series covers the cloud environments DFNS supports, one in-depth article per cloud. Institutions run their most sensitive operations on DFNS, so it matters where we run ours. We are starting with Amazon Web Services because we started on AWS six years and zero breaches ago. It is still the largest cloud in the world, still the most trusted, and still where most of our customers already operate.

Why we are starting with AWS

Every institutional evaluation of digital asset infrastructure follows the same arc. It opens with chains and closes with clouds. The first questions are often about blockchain coverage: which networks, which tokens, which standards? The questions that decide the deal come later. Does this run inside our AWS account? Can our keys live in hardware we own? Does procurement go through a channel we already have? Can our auditors trace every signature to a control we can show them?

For a large share of the regulated institutions we work with, “our environment” means AWS. Their core systems, their data perimeters, their security tooling, and their committed cloud budgets already live there. It is our environment too. DFNS has run on AWS since day one. When these institutions adopt digital assets, they are not looking for a new island. They are looking for infrastructure that meets them where they already operate, on the terms their risk, compliance, and procurement teams have already approved.

This post covers everything DFNS does with AWS today. Three key models on one platform (TEE, MPC, and HSM). Enclave-isolated keys and a customer-held cryptographic veto on AWS Nitro Enclaves. A hardware root of trust in your own account through AWS CloudHSM. Procurement on your existing AWS bill through AWS Marketplace. And underneath it all, a trust model in which AWS is a surface DFNS runs on, never a dependency the security model needs.

What DFNS is

DFNS is the core banking platform for digital assets. Banks, fintechs, payment companies, exchanges, and corporates use it to run accounts and ledgering, the full transaction lifecycle, treasury, tokenization, interoperability with traditional rails, reconciliation and reporting, and the key management underneath it all, across more than 100 blockchains. More than 500 institutions run on DFNS, including IBM, Standard Chartered, Stripe, Circle, Broadridge, and Barclays. We secure over $200 billion in client assets, settle roughly 1% of global stablecoin volume, and have operated at 99.997% uptime since 2022 with zero breaches since 2020, under SOC 2 Type II and ISO 27001, 27017, and 27018 certifications audited by KPMG, with continuous third-party penetration testing and $15 million in annual insurance coverage.

Signing sits at the bottom of that stack, and we treat it that way. Signing is the floor, not the headline. What institutions buy is everything above it: the accounts, the lifecycle, the governance, and the evidence. The rest of this post is about how that floor, and the stack above it, meet AWS.

Three key models, and what AWS is never trusted with

Ask five vendors in this industry where the private key lives and you will get five incompatible answers. “Inside an enclave.” “Split across MPC nodes.” “Inside an HSM.” Each answer is defensible, each has a different trust anchor and different failure math. The real problem is that most platforms make the choice for you, then make their choice your architecture.

DFNS supports all three key models on one platform, and AWS serves every one of them:

  1. TEE. Keys are generated and used inside trusted execution environments. The key exists as a single object, but only inside an isolated boundary that nothing outside can read: not the host operating system, not a root user on the parent instance, not the cloud provider’s own operators. It never leaves. This is the model popularized by enclave-native key management platforms, and if it is the model you want, DFNS runs it. Its trust anchor is the enclave’s isolation and the attestation chain that proves what code is running inside.
  2. MPC. The default. Keys are generated through a distributed protocol as encrypted shares held in independent signer environments, and they stay that way for life. At no point in the lifecycle of a DFNS wallet, creation, signing, backup, recovery, or export, is the full private key assembled anywhere. Signing runs on KU25, the threshold ECDSA protocol our cryptography team designed with Jonathan Katz and published in IACR Communications in Cryptology. It produces signatures byte-for-byte indistinguishable from single-key signatures while requiring the cooperation of multiple independent signers. Compromise one machine, one process, or one administrator and you hold a fragment that signs nothing. Its trust anchor is mathematics, reinforced by hardware: DFNS’s MPC signer nodes themselves run inside enclaved environments, so even in the threshold model, every fragment sits behind isolation.
  3. HSM. Some regulators and some internal policies end the conversation at a hardware requirement: keys must live in certified, tamper-resistant hardware under the institution’s exclusive control. DFNS connects natively to certified HSMs through PKCS#11 and provides the orchestration, policy, and workflow layer above them. The key is a complete object in this model, but it is complete only inside hardware you own, and plaintext key material never leaves the module. Its trust anchor is FIPS-validated hardware and your exclusive administration of it.

Same API, same Policy Engine, same audit surface across all three. An institution can run the TEE model for one business line, MPC for another, and anchor a third in CloudHSM, matching the key model to the asset class and the regulator rather than to the vendor’s religion. Switching or mixing never costs a line of integration code. The key model becomes a risk decision, not a replatforming decision.

Across all three, the constant is what AWS is never trusted with. AWS can provide the enclave your key lives in, host the enclave your share lives in, or operate the CloudHSM hardware behind your cluster. In every case, AWS never sees plaintext key material, and AWS never holds the authority to sign. Authority lives in the Policy Engine, enforced below the API, and in credentials held by your people on their own devices. The cloud is a surface. It is not the security model.

AWS CloudHSM as a root of trust

DFNS supports AWS CloudHSM as a first-class key management backend. Institutions running on AWS can anchor their DFNS deployment in their own CloudHSM cluster: keys generated, held, and used for signing inside FIPS 140 Level 3 validated hardware, in their own AWS account, in the region of their choice. CloudHSM joins IBM, Thales, and Securosys in the family of hardware roots of trust DFNS connects to natively, and switching between them never costs a line of integration code.

CloudHSM provides single-tenant hardware security modules inside your own VPC, with clustering, cross-availability-zone replication, and automated backups operated by AWS while the keys remain under your exclusive control. That separation is the property regulators look for. AWS operates the hardware. It cannot access your keys.

The integration follows the same architecture as every DFNS HSM deployment, and four properties are worth understanding precisely.

  • Your hardware. You run the CloudHSM cluster in your own VPC. DFNS does not participate in the administration of your HSM. Provisioning, configuration, and master key management are handled exclusively by you, which means DFNS personnel have no path to your cryptographic keys.
  • Stateless keys. Wallet keys are generated inside the HSM, then wrapped under a master key that never leaves the hardware. What gets stored is ciphertext. At signing time, the DFNS driver retrieves the wrapped key and hands it to the HSM together with the payload. The HSM unwraps and signs entirely inside the module, then discards the plaintext. Plaintext key material exists in exactly one place, ever: inside the hardware boundary. Not on disk, not in driver memory, not at DFNS. The stateless design is also what lets a single cluster serve wallet counts far beyond the HSM’s internal storage, which matters when you provision a wallet per customer at fintech scale.
  • PKCS#11. The DFNS HSM driver deploys in your environment, alongside your cluster, and connects via PKCS#11, the same standard interface DFNS uses across its entire HSM family. The driver is the only bridge between DFNS and your hardware, and it runs where you control it.
  • Validation Gate. Inside the driver runs Validation Gate, a final checkpoint you control, with no API to disable it. Every signing request that reaches your hardware has already cleared the Policy Engine, and Validation Gate stands between the platform and the module one more time, in your environment, under your control. Even if DFNS itself were compromised, the last word on whether your HSM signs stays with you.

Above all of this, the platform is unchanged. Wallets are provisioned through the same APIs and UIs. The full transaction lifecycle, treasury, webhooks, and audit trails operate exactly as they do on every other backend. Hardware custody and business-level governance compose rather than compete.

AWS Nitro Enclaves in two ways

Nitro Enclaves are isolated compute environments carved out of EC2 instances, with no persistent storage, no interactive access, and no external networking. The only channel in or out is a local vsock connection to the parent instance, and even a user with root on the parent instance cannot read the enclave’s memory. Attestation proves, cryptographically, exactly what code is running inside. DFNS uses these properties in two distinct ways.

  1. The enclave as a vault: the TEE model. In the TEE model, the enclave is where the key lives. Wallet keys are generated inside the enclave, used inside it for every signature, and never exist outside its boundary in plaintext. Teams that want enclave-native key management, deliberately and as a design choice, get it on DFNS with the platform above unchanged: the same wallets and APIs, the same transaction lifecycle, the same Policy Engine clearing every request before it reaches the enclave, the same audit trail after it.
  2. The enclave as veto: hybrid MPC. The hybrid deployment model makes you a required participant in every signing ceremony. DFNS operates a portion of the MPC key shares in its infrastructure. You hold one or more shares in your own environment, inside a Signing Server that DFNS provides and you operate, and on AWS the natural home for that Signing Server is a Nitro Enclave in your own account. No transaction signs without your share. That is not a contractual promise. It is a mathematical property of the threshold protocol: a direct cryptographic veto over every movement of funds.

Walk through what an attacker actually gets in the hybrid pattern. Fully compromise your AWS account and the parent EC2 instance, and you hold nothing that signs. The share is sealed inside the enclave, and even the share is only a fragment. Hypothetically break the enclave’s isolation itself, a scenario that would be industry news far beyond digital assets, and you still hold a fragment that cannot produce a signature without the rest of the quorum, and cannot get past the Policy Engine that clears every request before signing begins. Compromise DFNS instead, and the same wall appears from the other side: DFNS cannot sign without your share. Neither party can move funds unilaterally. That is the point of the design.

The difference between the two patterns is worth stating plainly. In the first, the enclave protects the key. In the second, the enclave protects a share, and the cryptography protects the key. Isolation raises the cost of an attack. The threshold protocol caps its payoff. Some institutions want the first for its simplicity and its familiar failure math. Others want the second because it refuses to let any single environment matter that much. On DFNS, that is a configuration decision, not a vendor decision, and not a migration.

AWS Marketplace: procurement on the bill you already have

DFNS is available on AWS Marketplace. Banks, fintechs, payment companies, and enterprises can procure the core banking platform for digital assets the way they procure the rest of their cloud stack: through their AWS account, on their AWS bill, under terms their procurement team has already approved.

The slowest part of adopting new infrastructure at a regulated institution was never the integration. It was the paperwork. Vendor onboarding routinely takes months: security questionnaires, legal review, a new supplier record, a new payment flow. Marketplace collapses much of that.

  • One consolidated AWS invoice. No new supplier record, no new payment flow.
  • Purchases can typically count toward committed AWS spend, so DFNS runs on the budget you have already allocated.
  • Private Offers for enterprise terms, negotiated with us and transacted through AWS.
  • Self-serve tiers from $70 a month. Start today, grow into an enterprise agreement, and never change platforms.

One detail from the listing page itself. AWS Marketplace’s similar products module files DFNS next to Mambu, Finxact, and Thought Machine, the cloud-native core banking platforms. We did not choose that shelf. The category did.

Residency by construction

Every surface above shares one property: location is yours to decide. Your CloudHSM cluster runs in the AWS region you choose. Your Nitro Enclave runs in your account, in your region. Keys live where you put them, which turns data residency from a policy document into an architectural fact. For institutions answering to MiCA and DORA in Europe, the OCC and NYDFS in the United States, MAS in Singapore, VARA in the UAE, or the HKMA in Hong Kong, that is often the difference between a custody story that needs explaining and one that needs reading.

What to know before you architect

We would rather you learn these three things from us than from your architecture review.

  • Signature scheme coverage. CloudHSM support today covers ECDSA-based networks, which includes Ethereum and the EVM family where most institutional volume lives. EdDSA depends on the HSM’s operating mode, so wallets on Ed25519 networks such as Solana or Stellar typically run on the MPC model or a different hardware backend. Plan your chain mix against your key backend before you commit, and ask us to validate the pairing.
  • FIPS editions differ by hardware generation. AWS’s CloudHSM instance generations are validated under different editions of the FIPS 140 standard. Auditors care about the exact citation. Match it to the instance types you actually deploy, and we will help you document it.
  • Enclave trust anchors to AWS. Nitro attestation chains to Amazon’s root of trust, and in the TEE model, the enclave is what protects the key itself. For most institutions that is an acceptable and well-understood anchor. If your threat model cannot include a cloud provider as an isolation layer, run MPC with your share on your own hardware, or move the entire signing stack inside your perimeter with a full on-premise deployment. The integration code does not change across any of these choices.

Governance above the hardware

Everything above describes where keys live. It says nothing about who can use them, and that question decides more incidents than cryptography does. On DFNS, every request, whether it terminates in an MPC quorum, a Nitro Enclave, or a CloudHSM cluster, clears the Policy Engine first. The Policy Engine is enforced below the API, in the same layer that produces signatures, which means its rules cannot be bypassed by a stolen API key, a compromised application server, or an insider with dashboard access.

The controls read like your internal policy manual because they are meant to encode it. Approval quorums that adapt to amount, destination, and time of day. Address allowlists where adding an entry itself requires a quorum. Velocity limits that cap what any compromise can extract. Time locks on large movements. Transaction screening through Chainalysis, Elliptic, or Global Ledger before anything is signed, and Travel Rule exchange through Notabene where thresholds require it. Every action is cryptographically signed by the person or service account that performed it, with phishing-resistant passkey authentication for people, and the full audit trail exports into the SIEM and GRC systems your security team already runs.

What institutions run on this

  • A bank launching custody or buy, sell, and hold. Keys anchored in the bank’s own CloudHSM cluster. Products built on DFNS APIs inside the bank’s existing AWS perimeter. The custody chapter of the audit file largely writes itself: certified hardware, exclusive control, screened transactions, quorum approvals, exportable evidence.
  • A payment company settling stablecoins at volume. EVM flows signed against CloudHSM in the company’s own account, with a wallet per customer on the stateless key model. Webhook-driven reconciliation from the platform, and screening before signature so compliance is enforced rather than chased.
  • A corporate treasury that wants a veto, not a dashboard. A hybrid deployment with the corporate’s share inside a Nitro Enclave in its own AWS account. N of M approval across the CFO, treasurer, and risk officer. Nothing moves without the company’s own cryptographic participation, and the board can be told exactly that.
  • A team that wants the enclave model, deliberately. Some builders standardize on TEE key management: one key per wallet, isolated inside attested enclaves, familiar failure math, minimal protocol overhead. DFNS runs that model on Nitro Enclaves, under the same Policy Engine, screening, and audit trail as every other wallet on the platform, with MPC and CloudHSM one configuration away if requirements change.
  • An AWS-committed enterprise that needs procurement to move at engineering speed. A Private Offer through Marketplace, drawn against committed spend, on one consolidated invoice. The pilot starts this quarter instead of next year.

Getting started

Contact us