DFNS now supports AWS CloudHSM. 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. The DFNS platform above, accounts, transaction management, treasury, policy, and governance, is unchanged. AWS 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.
The choice institutions actually face
For many regulated institutions, the custody conversation ends at a hardware requirement: keys must live in certified, tamper-resistant hardware under the institution’s exclusive control. Historically that meant buying, racking, and operating physical HSM appliances, real security, real operational weight. Meanwhile, the rest of the institution’s stack has moved to the cloud, and the teams running it want infrastructure that provisions in hours, scales elastically, and lives where their compliance perimeter already is.
AWS CloudHSM is AWS’s answer to that tension, and now it is a first-class key backend on DFNS. CloudHSM provides single-tenant hardware security modules inside your own VPC, validated to FIPS 140 Level 3, with clustering, cross-AZ replication, and automated backups managed by AWS, while the keys themselves remain under your exclusive control. AWS operates the hardware; it cannot access your keys. That separation, AWS runs the boxes, you own the cryptography, is precisely the property a regulator wants to see.
How it works
The integration follows the same architecture as every DFNS HSM deployment.
Your keys, your hardware, your account. You run an AWS CloudHSM cluster in your own VPC. Wallet keys are generated inside the HSM and marked non-exportable: they never exist outside the hardware boundary, not on disk, not in memory outside the module, not at DFNS. Signing happens inside the HSM, where the keys live.
The DFNS driver, in your environment. The DFNS HSM driver deploys alongside your cluster and connects through PKCS#11, CloudHSM’s standard cryptographic interface and the same one DFNS uses across its HSM family. The driver is the only bridge between the DFNS platform and your hardware, and it runs where you control it.
The platform, unchanged above. Every capability of the core banking platform operates on top: wallets provisioned via API or dashboard, the full transaction lifecycle, treasury, webhooks, and audit trails. Critically, the Policy Engine enforces approval quorums, limits, allowlists, and roles before any signing request reaches the driver, so hardware custody and business-level governance compose rather than compete.
And a final checkpoint you control. Validation Gate, which we introduced for HSM-based deployments, runs inside the driver in your environment: a customer-controlled endpoint that every signing and key-export request must pass, returning approve or deny, with no API to disable it. Even in the extreme case where DFNS itself were compromised, the last word on whether your CloudHSM signs stays with you.
What it means
Hardware custody without the rack. FIPS 140 Level 3 validated key storage with none of the procurement, data-center, and lifecycle burden of physical appliances. Provision a cluster in your AWS account and be operational in days.
Residency and jurisdiction by construction. Your keys live in the AWS region you choose, inside your account and VPC, satisfying data-residency and jurisdictional-control requirements as an architectural fact rather than a contractual promise.
An auditor-ready answer. Single-tenant, certified hardware, exclusive customer control, policy enforcement below the API, and a complete audit trail: the custody chapter of your next regulatory review, largely pre-written.
Choice of root of trust, permanently. CloudHSM joins IBM, Thales, and Securosys in the DFNS BYOH family, alongside MPC and TEE-based models. The same platform and the same integration span all of them, so the decision of where your root of trust lives is yours, and reversible. That is the point of the model: no dependency on a single provider’s hardware, cloud, or enclave. Your architecture, your call, at every stage of your journey.
Getting started
AWS CloudHSM is available now as a key backend for hybrid and dedicated DFNS deployments. If you run on AWS and want hardware-grade custody inside your own perimeter, the path is short: talk to our team, connect your cluster, and operate.
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team about AWS CloudHSM: sales@dfns.co