# Security model

Executive summary
**Ripple Custody is built on a zero-trust security model with three pillars: key management, secure communication, and data integrity.**

- **Your keys stay yours**: Private keys never leave your KMS—whether that's an HSM (Hardware Security Module) or an MPC (Multi-Party Computation) cluster. The platform requests signatures without ever seeing the keys themselves.
- **No single point of compromise**: Even if an attacker breaches the database, API, or network, they cannot steal funds or forge transactions.
- **Auditable by design**: Every state change is signed, timestamped, and stored in a tamper-evident structure.
- **Resilient to attacks**: Multiple layers prevent man-in-the-middle, replay, and database tampering attacks.


Prerequisites
Before reading this page, you should understand:

- [System architecture](/products/custody/v1.36/overview/architecture) - Overview of Ripple Custody components
- [Governance model](/products/custody/v1.36/overview/governance-model) - How domains, policies, intents, and approvals control operations


Why this matters
Security is the foundation of digital asset custody. Your clients trust you with their assets, and regulators require you to demonstrate robust controls. The zero-trust architecture means you can prove to auditors that no single compromised component can result in asset loss.

**For architects and operators**: Understand how the three security pillars work together. Key management protects signing, secure communication protects data in transit, and data integrity protects data at rest. All three must be properly configured for the security model to hold.

The *zero-trust model* assumes a hostile network and does not implicitly trust any single component — not even the database. Security is achieved through cryptographic verification, strict component isolation, and explicit, auditable governance.

## The three pillars of security


```mermaid
flowchart LR
    subgraph Pillars["Security Pillars"]
        direction TB
        KM["Key Management"]
        SC["Secure Communication"]
        DI["Data Integrity"]
    end

    KM --> |"Keys never exposed"| Trust["Zero Trust<br/>Architecture"]
    SC --> |"All traffic verified"| Trust
    DI --> |"State is auditable"| Trust
```

### 1. Secure key management

The platform's golden rule is that **private keys are never exposed**. The vault component acts as a secure gateway to your client-managed _key management system (KMS). The platform performs signing operations without ever seeing the keys.

| Method | Description |
|  --- | --- |
| **HSM (Hardware Security Module)** | A tamper-proof physical device that stores the complete private key and performs all cryptographic operations internally. |
| **MPC (Multi-Party Computation)** | A cryptographic protocol where the private key is split into multiple "shards" held by different parties. No single, complete key ever exists in one place. |


For detailed information on key management options and configuration, see [Key management](/products/custody/v1.36/overview/security/cryptographic-trust-model).

### 2. Secure communication between components

The platform assumes all internal network traffic is insecure. Every connection is cryptographically secured through multiple layers:

| Layer | Purpose |
|  --- | --- |
| **TLS and PKI** | All network traffic is encrypted. You provide certificates from your internal PKI (public key infrastructure). |
| **JWTs** | All API requests authenticated using JSON Web Tokens from the platform's OIDC server. |
| **mTLS** | Critical internal components (notary, vault) use mutual TLS (Transport Layer Security) — both sides verify each other. |
| **Application signing** | Messages between notary and vault are signed at the application layer. |


For detailed information on authentication, network security, and the security lifecycle, see [Secure communication](/products/custody/v1.36/overview/security/secure-communication).

### 3. Verifiable state & governance

You cannot trust a system if you cannot verify its state. The platform uses blockchain-inspired cryptographic structures:

| Mechanism | Purpose |
|  --- | --- |
| **Merkle tree** | All trusted entities organized in a tamper-evident hash tree. Any modification invalidates the signed root. |
| **Anti-rewind file (ARF)** | Prevents replay attacks by tracking the most current state version. |
| **Entity signatures** | Every trusted entity is individually signed by the notary. You can [verify these signatures](/products/custody/v1.36/overview/security/data-integrity-and-audit-trail#verifying-custody-signatures) independently. |


For detailed information on data integrity, trusted entities, and the system update flow, see [Data integrity and governance](/products/custody/v1.36/overview/security/data-integrity-and-audit-trail).

## Next steps

| Topic | Description |
|  --- | --- |
| [Key management](/products/custody/v1.36/overview/security/cryptographic-trust-model) | Deep dive into HSM vs MPC options and key lifecycle |
| [Secure communication](/products/custody/v1.36/overview/security/secure-communication) | TLS, JWT, mTLS, and application-layer signing |
| [Data integrity](/products/custody/v1.36/overview/security/data-integrity-and-audit-trail) | Merkle trees, anti-rewind files, and signature verification |
| [Authentication](/products/custody/v1.36/identity-and-access/authentication/overview) | How users authenticate and sign requests |