> 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/security-good-practice.md). # Security good practice What Ledger Enterprise enforces for security, and the practices that Ledger recommends for roles, Ledger devices, recovery sheets, transactions and workstations. This page lists what the platform enforces, and the practices that Ledger recommends for the people, devices and computers around it. **Role:** every user. The sections on roles and workstations are for the people who set your organization's security procedures. The platform enforces governance in the Hardware Security Module (HSM), and approval on the Ledger device. See [**The security model**](/help-center-v2/concepts/the-security-model.md). The computers, networks and people around the platform are the responsibility of your organization. Ledger does not control them. ## What the platform enforces | Control | Where it is enforced | | -------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | A device ID belongs to one active user or one registration in progress at a time | **Create user** refuses a device ID that is already in use | | An Administrator cannot create a transaction, and an Operator cannot change a Rule | The role of each user | | Every change to governance is a Request that the quorum approves | The HSM, at the point of signing | | The details of an operation show on the Ledger device, read from the secure hardware | The Ledger device | | A Master Administrator can suspend an Operator or an API user at once, with no Request | **Users** | | A revocation needs an approved Request | **Users**, through a Request | The platform does not check who holds each Ledger device, or where the device and its recovery sheet are kept. It does not check which computer a user works on. The practices below cover these points. They are recommendations, not controls that the platform enforces. ## Roles * Give each role to a different person. One person does not hold two Ledger devices in the same Workspace. * Give the three Shared Owner roles to three different people. See [**Shared Owners**](/help-center-v2/administration/onboarding.md#shared-owners). * Do not give the Shared Owner role and the Administrator role to the same person. * Keep an accurate list of your users, their roles and their rights. Update it when a person changes role or leaves. * Make sure that only authorized users are created, and that only authorized users stay in the Workspace. * When a person leaves, a Master Administrator revokes their user. To block an Operator or an API user at once, a Master Administrator can suspend the user first. See [**Users**](/help-center-v2/administration/users.md). * Revoke a user whose Ledger device is lost, or no longer in use. * Use user names and Account names that contain no personal information, such as "Admin 1". Keep the link between a name and a person in your own records. ## Ledger devices and PINs * Do not share a Ledger device between users. Do not lend it. * When you do not use the Ledger device, keep it with you or in a locked safe. * Disconnect the Ledger device from the computer when you do not use the platform. * Use a PIN of 8 digits. * Do not use a PIN that is easy to find, such as 00000000, 12345678, a date of birth or a name. * Do not write down your PIN. Do not tell your PIN to any other person. * Do not let a person or a recording device see you enter your PIN. If you think that somebody saw it, change the PIN. * Check your recovery sheet at regular intervals. Do not leave it unattended. > **Warning:** Ledger never asks for your PIN or your recovery phrase, by email, phone or any other channel. Any such request is an attack, whatever it appears to come from. ## Recovery sheets by role A recovery sheet holds the 24-word recovery phrase of a device. Ledger Stax devices for Ledger Enterprise are attested for a Workspace. A user recovers their device by restoring the 24 words on a Ledger Stax attested for the same Workspace. See [**Your recovery sheet**](/help-center-v2/start-here/get-started/your-device.md#your-recovery-sheet). Every PSD user keeps their recovery sheet, Operators included. | Role | When the device is used | Storage of the device | Storage of the recovery sheet | | ----------------- | ---------------------------------------------------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Shared Owner** | At the onboarding ceremony, and to recover the master seed | Physical safes, in separate locations | Physical safes, in separate locations, that only the Shared Owner can reach. Give another trusted person access, for events such as a departure, an incapacity or a death | | **Administrator** | For governance changes, as needed | With the user, at home or at the office | A physical safe that only Administrators can reach within hours. Give another trusted person access, for events such as a departure, an incapacity or a death | | **Operator** | For transactions, often every day | With the user, at home or at the office | A physical safe that Administrators or other trusted persons can reach within hours. Operators do not have access to it | The master seed of a hosted Workspace needs the recovery phrases of all three Shared Owners. See [**Recovering the master seed**](/help-center-v2/administration/onboarding/master-seed-recovery.md). ## Transactions * Read the details on the Ledger device before you approve. The device display is the authoritative one. * If the details on the device and on the screen do not match, decline on the device. Then select **Reject** in the interface. Declining on the device does not reject a Request that you approve. See [**Declining on the Ledger device**](/help-center-v2/guides/requests.md#declining-on-the-ledger-device). * On a receive, make sure that the address in the interface is identical to the address on the Ledger device. * Before a high-value transfer, send a small amount first. Make sure that the recipient received it. * Do not hurry a transaction or the setup of a Ledger device. * Do not create or approve a transaction under pressure or duress. * Reconcile sent and received operations every day against your own records, to find differences between authorized and actual transfers. See [**Reports**](/help-center-v2/guides/reporting.md). ## Workstations and networks **Protect each computer that a user uses to access Ledger Enterprise:** * Use a network firewall for incoming traffic. * Use a local firewall on the computer, so that only authorized programs connect to the internet. * Install the security updates of the operating system, the browser and all other software. * Restrict outgoing traffic to business-critical websites, and to the websites that software updates need. * Use up-to-date antivirus and anti-malware software. * Remove the software and services that the computer does not need. * Lock the session with a strong password. Change the password at regular intervals. * Lock the computer when you leave it. * Keep the work area physically secure, and do not share it. Close and lock the doors and windows at the end of the working day. **When you use Ledger Enterprise:** * Use a secure and stable internet connection. Do not use an unsecured public network. * Reserve dedicated computers for Ledger Enterprise and for websites of the same criticality. * Restart the browser before and after each use of Ledger Enterprise. * Do not browse other websites at the same time. * Do not connect other USB devices at the same time. Connect only the Ledger device. * Do not allow remote control access to the computer at the same time. * Do not accept a pop-up that asks you to download and install software. ## Phishing and Ledger support * Treat with suspicion any email that appears to come from Ledger. * Do not open the links in such an email, even if the link looks legitimate. If a business need for the website is confirmed, type its address in the browser yourself. * Ledger support never asks you to create a transaction or to approve a Request. * Ledger support never asks for a private key. The private keys of your Accounts stay in the HSM, and nobody can export them. * Ledger support answers through the support portal. See [**Contacting Ledger support**](/help-center-v2/contacting-support.md). ## Related * [**Contacting Ledger support**](/help-center-v2/contacting-support.md) * [**The security model**](/help-center-v2/concepts/the-security-model.md) * [**Your security device**](/help-center-v2/start-here/get-started/your-device.md) * [**Workspace onboarding**](/help-center-v2/administration/onboarding.md) * [**Users**](/help-center-v2/administration/users.md) * [**Requests and approvals**](/help-center-v2/guides/requests.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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.enterprise.ledger.com/help-center-v2/concepts/security-good-practice.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.