Trust nothing, verify everything.

This page sets out how we define it, the principles we follow, how we live them, and where we are taking them next.

Open letter

To the people evaluating us.

Most security pages tell you what a company does. We want this one to show you how we think.

DFNS secures onchain operations for 400+ institutions, such as banks, custodians, fintechs, trading firms, asset managers, and payment companies. They are trusted by their customers and answerable to their regulators. The chain of trust is long. At the end of it is often someone who has never heard of DFNS, and never will. Their funds still depend on us.

A platform that carries that weight cannot run on assumption. It has to verify every request, every signature, every employee, every deployment, every line of code, and every claim we make on a page like this.

The question behind every security review is simple: who do we have to trust, and what happens if they are wrong?

For most blockchain infrastructure, the honest answer includes vendors. Our goal is to make the answer as close to no one as possible. Even if DFNS is compromised, the system should hold.

That work is not finished. Where our practice does not yet match the principle, we say so here.

Clarisse Hagège Chief Executive Officer, DFNS

Co-signed by the DFNS security team. Last reviewed June 1, 2026.

Definitions

Zero trust, defined.

Zero Trust.

/ˈzɪr.oʊ ˈtrʌst/ noun

1
A security model that eliminates implicit trust in any user, device, network, or system component, regardless of location or prior authentication.
- Every access request is treated as if it originated from an untrusted network.
- Every action is independently verified against current policy.
- Trust is never inherited; it is re-established on every operation.

Source

The canonical reference is NIST Special Publication 800-207, Zero Trust Architecture (August 2020), which formalizes the model around three tenets:

(a)

Verify explicitly.

Authenticate and authorize based on all data, like identity, device, location, workload, anomalies.
(b)

Use least-privilege access.

Limit user, service, and system access to the minimum scope required, for the minimum time required.
(c)

Assume breach.

Operate as if compromise already occurred. JIT access, encrypt it all, verify continuously, log everything.

What Zero Trust is not.

Most vendors sell one control and call it an architecture. It’s not. Each component matters. None is enough alone. Zero trust means treating every layer as fallible, then designing the system so one failure cannot become an asset loss.

Zero trust is not MPC alone.

MPC distributes key shares. It does not prove the user is legitimate, the transaction is safe, or the policy state is intact.
Zero trust is not a TEE.

A TEE protects code and data inside an enclave. It does not make inputs, policies, or customer verification trustworthy by itself.
Zero trust is not an HSM.

An HSM protects keys. It is not a governance layer, a policy engine, or an end-to-end verification model.
Zero trust is not a smart contract.

Smart contracts enforce onchain rules. They do not solve offchain authentication, internal controls, or supply-chain risk.
Zero trust is not a certification.

SOC 2, ISO 27001, and audits are necessary evidence. They are a baseline, not a security model.

Risk model

Start with what can go wrong

Before adding controls, define what can fail, who can be compromised, and what the system must still protect.

01
External attackers.

Criminal groups and nation states with deep resources, persistent campaigns, and supply chain reach into DFNS and its dependencies.
02
Compromised employees.

A DFNS engineer acting alone cannot move client funds, exfiltrate keys, or ship code to production. The architecture assumes the insider.
03
Stolen credentials.

An API key, passkey, or admin session may be stolen. One credential must never be enough to drain a wallet.
04
Compromised infrastructure.

Clouds, hardware, and networks are not fully trusted. Key material is distributed so no single environment ever yields a usable key.
05
Malicious or buggy code.

Including ours. Every production change passes review and reproducible build verification.
06
Captured key shares.

One stolen share still cannot sign. Periodic refresh gives any capture a short useful life.
07
Tampered governance.

Key safety is not enough. Every piece of data must be protected. Governance state can only change through intent the customer can verify.
08
The future.

Today’s cryptography may fall to future advances, including quantum. Post quantum migration is built in, not bolted on.

Threats outside the model

Worth naming clearly:

Cryptanalytic breaks

If an audited primitive is broken, DFNS will migrate to a replacement protocol as fast as possible. We prepare for this through standards work, but we cannot preempt mathematics.
Customer side errors

If a customer application sends a valid request, DFNS will process it. Controls above DFNS remain the customer’s responsibility, which is why we provide the primitives to build them.

Principles

The rules we build by

A zero trust system is not one control. It’s a set of decisions repeated across product, infrastructure, operations, and company culture.
01
No standing trust

No permanent access to production, key material, or sensitive customer data. Every privilege is scoped, time bound, justified, and revocable.
02
Verify before every signature

Every transaction is checked on its own. Authentication, authorization, and policy are evaluated before each signature.
03
No single party holds enough

Keys, admin authority, code release, and sensitive access are distributed by design. No person, service, or system can compromise client assets alone.
04
Least privilege, everywhere

Every human, service, agent, and integration gets the minimum access required, for the minimum time required. The default is no.
05
Assume breach at every layer

Each layer is built as if the next one can fail. A stolen credential, key share, or cloud environment should not be enough.
06
Verifiable, not vouched

Security claims must be backed by evidence: audits, certifications, pentests, disclosures, and open source cryptography. “Trust us” is not a control.
07
The math, not the marketing

Where cryptographic guarantees exist, we use them. Where they do not, we say so. Security claims should survive inspection.

In action

How a transaction earns a signature

Nine steps. Nine verification points. From request to execution, every layer must prove the transaction is legitimate before assets move.

DFNS orchestration · untrusted

Intent created

The server constructs the intent. The UI cannot alter it.

Intent signed

Phishing

Hardware-bound WebAuthn. Unphishable. Cannot be replayed or exported.

Permissions checked

Privilege escalation

Every endpoint scoped. Programmable per customer.

Policy enforced

Governance attacks

Pre-execution evaluation. Fail-closed: unknown recipients are blocked.

Compliance cleared

Illicit flows

AML, sanctions, and Travel Rule. Fail-closed by default.

Customer perimeter mTLS · on-prem or sovereign · customer-controlled

State verified

Tampering

An independent signing key, on customer infrastructure, runs four checks:

State integrity: Merkle-proven
User + intent: Governed credential
Policy: Threshold met
Transaction: Byte-for-byte match

Signature produced

Inside the perimeter. Two tiers, one decision rule.

HSM cold signing: Air-gapped · on-premise · ~95% of assets
MPC ceremony: Distributed threshold · ~5% operational

Transaction validated

Transaction tampering

A final independent check before the signature is released.

Transaction broadcasted

A legitimate, user-signed, governed transaction.

The company runs on the same rules

No engineer has standing production access. Every privileged action is requested, approved, scoped, time bound, and logged. Critical operations require quorums. Code ships through 4- or 6-eye review, reproducible builds, secret rotation, managed device checks, and active vulnerability disclosure.

The customer perimeter stays yours

DFNS holds no custodial, banking, or financial services licenses by design. Custody, ownership, data, and regulatory responsibility stay with the customer. Wallets can be exported through a break glass path, so there is no architectural lock in. Support access is scoped, time bound, logged, and revocable.

Evidence

How we prove it

A zero trust posture is only as credible as the evidence behind it. The evidence must be independently verifiable.

Independent audits

SOC 2 Type II, ISO 27001, ISO 27017, and ISO 27018 are externally audited. CCSS, ISO 22301, ISAE 3000, and SOC 1 are in progress.
Independent cryptography

Our threshold cryptography is audited by external firms, including Kudelski Security. Findings and fixes are published when appropriate.
Independent pentesting

DFNS runs quarterly external penetration tests with providers including Halborn, Kudelski Security, and Borg Security.
Open source where it matters

Our core cryptography components are public on GitHub. We intend to expand the open source surface over time.
Public vulnerability disclosure

When we find meaningful vulnerabilities in our code, dependencies, or industry patterns, we publish them and document the fixes.
Standards contribution

DFNS contributes to NIST, W3C WebAuthn, the Linux Foundation Decentralized Trust, and the MPC Alliance.