> 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/administration/governance/workspace-settings.md). # Workspace settings Workspace-level settings on Ledger Enterprise: the Master Administrator quorum, API admin rules, the root Certificate Authority, and external signer keys. **Role: Master Administrators.** **Workspace** holds the settings that apply to the whole Workspace rather than to one Account. It has two tabs: **Governance** and **Certificates**. An on-premises Workspace also has a third tab, **External signers**. > **Note:** Single sign-on (SSO) has no setting on this page. Ledger support enables SSO for a Workspace. See [**Signing in and out**](/help-center-v2/start-here/get-started/signing-in.md). ## Governance ### The Master Administrator quorum **Master Administrators** approve Workspace governance changes. That covers creating Accounts, and managing users, groups, Policies and Whitelists. The tab shows the current quorum and the Master Administrators it applies to. A Workspace starts with 3 Master Administrators and a quorum of 2. [**Workspace onboarding**](/help-center-v2/administration/onboarding.md) sets them. **Update quorum** sets how many Master Administrator approvals a Workspace governance Request needs. The change is itself a Request. The dialog's final button is **Review**. * **Update quorum** is available only when the Workspace has at least 4 Master Administrators. * The quorum must be at least 2, and at most the number of Master Administrators minus 1. * The new quorum must be different from the current quorum. * You cannot change the quorum while another Workspace governance change is in progress. > **Note:** You cannot add or remove Master Administrators here. They are managed by activating and revoking Ledger device users. See [**Users**](/help-center-v2/administration/users.md). > **Important:** A quorum change is paused while an Administrator creation is in flight. That is a pending Administrator invitation, or a pending Request that creates an Administrator. The **Update quorum** dialog shows **Quorum change paused**, and its **Review** button is unavailable until the creation resolves. ### API admin rules **By default an API Administrator has no permissions.** The Rules in this section grant them. Each Rule defines its own sequential approval steps: * Step 1 lists the API Administrators who can submit the Request. It has no quorum. * Each later step lists the API Administrators who approve the Request, with a quorum. The quorum is from 1 to the number of API Administrators in the step. Only active API Administrators who are not suspended can be in a step. You cannot add a Master Administrator to a step. To set up a Rule, select **Configure**. To change it, select **Edit rule**. Each change is a Request that Master Administrators approve. You cannot change a Rule while another Workspace governance change is in progress. | Rule | What it grants | | ----------------------------- | ------------------------------------------------------------------------------------------------------------- | | Policy-based Account creation | API Administrators in the Rule can create Accounts from an existing Policy, once the Rule's approvals are met | A Rule that has not been set up shows as **Not configured**, and grants nothing. > **Note:** An API Administrator can only create an Account from a Policy that already exists. See [**Policies**](/help-center-v2/administration/governance/policies.md). ## Certificates This tab holds your Workspace's **root Certificate Authority (CA)**. ### Display the root CA **Display** shows the root CA value and its certificate chain. > **Warning:** The root CA is sensitive. Share it only where it is needed. ### Enable address verification for API users An API user has no device on which to check a deposit address. Reviewing the root CA is what lets an API user verify an address against the Workspace instead. This is a **one-time step**, and it needs a Ledger device: 1. Download the root CA. 2. Review its details on your device. The dialog shows the SHA-256 fingerprint to compare. 3. Complete the review on the device. Once it completes, the tab shows **Enabled** and confirms the root CA was retrieved from the Workspace HSM. You can review the certificate again at any time. ## External signers This tab lists the registered **external signer public keys** for an on-premises deployment. An on-premises Workspace registers its external signer during [**Workspace onboarding**](/help-center-v2/administration/onboarding.md#the-steps-of-an-on-premises-workspace). The first three Master Administrators approve it on their Ledger devices. The keys are secp256k1, in either form: * Compressed: `02` or `03`, followed by 64 hex characters. * Uncompressed: `04`, followed by 128 hex characters. **Rotate public keys** replaces the complete set in one governed Request. You cannot change one key on its own. Only a Master Administrator can create a rotation Request. Every Master Administrator must approve it, whatever the Workspace quorum is. The Request is rejected if: * No key is given. At least one is required. * Two keys in the set are the same. * The requested set matches the current set. * A rotation Request is already in progress. The Request detail shows the previous keys beside the requested keys, so Approvers can compare them. ## Related * [**Users**](/help-center-v2/administration/users.md) * [**Workspace onboarding**](/help-center-v2/administration/onboarding.md) * [**Policies**](/help-center-v2/administration/governance/policies.md) * [**How governance works**](/help-center-v2/concepts/how-governance-works.md) * [**The security model**](/help-center-v2/concepts/the-security-model.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/administration/governance/workspace-settings.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.