> For the complete documentation index, see [llms.txt](https://docs.umh.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.umh.app/management-console/users-and-permissions/fallback-access.md). # Emergency Access Admins lose access. People leave, addresses get disabled, permissions get set wrong. Fallback access is what you arrange in advance so that a company is never locked out of its own instances. ## The break-glass account ### What is a break-glass account? A break-glass account is an account with full permissions that nobody uses for daily work. It exists for one purpose: when every regular admin is locked out, someone signs in with it, repairs the permissions or invites new admins, and signs out again. The name comes from the glass cover on a fire alarm: you break it only in an emergency. Because the account is used rarely, it is kept out of the normal flow of people joining and leaving, its credentials are stored in one controlled place, and its use is a deliberate, visible act rather than routine. If you already run break-glass accounts in other systems, the Management Console works the same way and you can skip to the practices below. ### The Account Owner is your break-glass account In the Management Console, the **Account Owner** is the account that created the company. It has Admin access everywhere in the company, and it cannot be transferred or demoted. That is deliberate: it guarantees one account always has full control, whatever happens to the others. Not every company has one. Ask your account executive if you are not sure whether yours does. The Account Owner cannot be recovered either, so decide before you register which account it will be, and treat it as a break-glass account from day one: * Use an address your organization owns and can keep, such as `ot-team@example.com`. Not the personal account of an employee who may leave. * Keep its credentials in your team's password manager rather than passing them around. * Switch on multi-factor authentication for it. * Do not work with it day to day. Invite ordinary admin accounts from it and use those. ## Reviewing it Check your fallback access when you review permissions. Two things drift: the address on the Account Owner stops being monitored. Decide each time whether the access should stay. --- # 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://docs.umh.app/management-console/users-and-permissions/fallback-access.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.