> For the complete documentation index, see [llms.txt](https://help.enterprise.ledger.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.enterprise.ledger.com/help-center-v2/concepts/the-security-model.md).

# The security model

Ledger Enterprise assumes your browser can be compromised, and is built so that this is survivable.

## Three layers

**Your organization's keys never leave the secure hardware.** Private keys are generated and held inside a Hardware Security Module (HSM). They are never sent to your browser, never held in a user's session, and cannot be exported. Signing happens inside the hardware; only the signature comes out.

**Your governance is enforced by hardware, not software.** Approval Rules are not a browser check that a determined attacker could skip. They are enforced at the point of signing, within the HSM. An operation that does not satisfy its Rule does not get signed, whatever the browser was told.

**Users approve with their own key, not with your organization's keys.** The HSM cannot sign on their behalf, it needs approvals from the designated users who own their own keys. Where the user's key sits depends on how the Administrators created your user.

* It can be a person holding the key on a Personal Security Device (PSD), a Ledger device. The Ledger device has its own screen, and it displays what you approve. It reads the operation from the secure hardware, not from the page in front of the user.
* An Administrator can instead create an API user. An API user holds its key in your organization's systems. It approves over the API with that key. There is no second screen to check. Your own systems must provide that check instead.

## What the device protects you from

This section covers approval on a Ledger device. A user who approves without one has no second display, so these checks do not apply.

The threat is a compromised browser, or a compromised machine. It displays one operation and Requests another: a different recipient, a different amount, a different deposit address.

The device renders the operation from the secure hardware. A substitution therefore shows up as a **mismatch between the device and the browser**.

> **Important:** If the device and the browser disagree, stop. Reject on the device, do not retry, and contact support. A mismatch is not a display glitch.

The device display is the authoritative one in two places:

* **On a send**, the recipient and the amount shown on the device are the authoritative values.
* **On a receive**, the deposit address shown on the device is the authoritative one. See [**Receiving assets**](/help-center-v2/guides/transactions/receiving-assets.md).

## What it does not protect you from

Device confirmation covers the integrity of an operation. It does not cover the merit of one.

<table><thead><tr><th width="257.20703125">Not covered</th><th>Why</th></tr></thead><tbody><tr><td>A correct transfer to the wrong counterparty</td><td>The device confirms the address you chose, not that you chose well. Verify new counterparty addresses through a second channel and use Whitelists.</td></tr><tr><td>A whitelisted destination that turns out to be malicious</td><td>A Whitelist records that your governance permits a destination, not that the destination is safe</td></tr><tr><td>A smart contract that behaves unexpectedly</td><td>Approving an interaction authorizes the call, not its consequences</td></tr><tr><td>Social engineering that gets a genuine approval</td><td>If you are persuaded to approve a real transfer, every layer works exactly as designed</td></tr></tbody></table>

> **Important:** Approval steps distribute a decision across people. A single mistaken or coerced individual is then not sufficient to move value. A quorum of one places the whole decision with one person.

## Separation of duties

Administrators set the Rules. Operators create transactions. Neither can do the other's job, and the split is enforced by the platform.

A change to what an Account may do is itself an approved change. It appears in the Account's history. No individual can make it quietly.

## Related

* [**How governance works**](/help-center-v2/concepts/how-governance-works.md)
* [**Your security device**](/help-center-v2/start-here/get-started/your-device.md)
* [**Policies**](/help-center-v2/guides/governance/policies.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.enterprise.ledger.com/help-center-v2/concepts/the-security-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.