What Is a Break-Glass Account? Emergency IdP Admin Access

A break-glass account is a highly privileged administrator login that you keep outside your normal sign-in path, so you can still get into your identity provider when SSO, MFA or the other admins are unavailable. You do not use it day to day. You seal it away, monitor it closely, and open it only when everything else has failed, the same way you would break the glass on a fire alarm.

The idea is simple, but the details matter, because the account is both your best recovery tool and an attractive target. This post covers what a break-glass account is, when you need one, how to set it up well, and how the same pattern looks on Keycloak.

What is a break-glass account?

A break-glass account (Microsoft calls them “emergency access accounts”) is an administrator identity that does not depend on the systems most likely to fail. It is not federated to another identity provider, it does not rely on a conditional policy that could itself be misconfigured, and its credential does not live in the same place your team normally signs in.

Microsoft’s guidance in Manage emergency access accounts in Microsoft Entra ID (Microsoft Learn) describes exactly this shape: at least two cloud-only accounts with permanent top-level admin rights, kept separate from the accounts people use every day, and monitored so that any sign-in is noticed. The same pattern applies to any identity provider, whether it is Entra ID, Okta, Auth0 or Keycloak.

When do you need a break-glass account?

You need one any time the people who administer your identity provider could lose access through no fault of their own. The common situations are:

• An identity provider outage. If the system that issues your admin logins is down, the admins cannot sign in to fix it, even though the problem may be in their own configuration.
• A federation misconfiguration. If you federate admin access to another provider and someone breaks that trust, every federated admin is locked out at once.
• An MFA provider failure. If the second factor is a push service or SMS gateway that is down, admins who are fully authenticated on the first factor still cannot get in.
• A locked-out or departed admin. If the only person who held the top-level role is unreachable, you need a documented way back in.
• Incident recovery. After a suspected compromise you may deliberately disable normal admin sign-in while you investigate, and you still need a clean way to work.

Compliance frameworks may expect the plan as well. A SOC 2 or ISO 27001 reviewer may ask how you recover administrative access, so a written procedure is useful evidence even if you never use it.

What makes a good break-glass account?

The best practices are consistent across vendors, and they follow from one principle: the account should work when the normal path does not, while being much harder to abuse than a normal admin account.

1. Keep at least two accounts. One account is a single point of failure, since a lost or locked credential leaves you with nothing. Two accounts, stored in different places, gives you a fallback.
2. Give them a phishing-resistant credential. A hardware security key (FIDO2/passkey) kept offline is a better choice than a password alone or an SMS code. Microsoft recommends a passkey (FIDO2), or certificate-based authentication if you already run a public key infrastructure, and a method different from the one your normal admins use. Its guidance also says to validate the accounts regularly, at least every 90 days.
3. Make the account independent of what can fail. Do not federate it, do not tie it to a conditional policy that depends on the failing system, and do not make it depend on the same MFA service everyone else uses.
4. Alert on every sign-in. A break-glass account should be silent almost all the time, so any use should page someone.
5. Test it on a schedule. A check every quarter (Microsoft’s guidance says at least every 90 days) that the credential still works, the alert fires, and the procedure is readable is enough. If you never test it, you may only find out it is broken during an incident.
6. Write the procedure down. Record who may open it, how that is approved, where the credential is stored, how the use is logged, and how it is closed and rotated afterwards.
7. Review who can reach it. Treat access to the sealed credential like any other privileged access, and include it in your periodic user access review.

There is one design tension worth naming. The account has to be easy enough to use under pressure, yet hard enough that an attacker cannot use it quietly. The answer is usually a strong offline credential combined with loud monitoring, rather than weakening the credential to make it convenient.

Should a break-glass account have MFA?

Yes, in most setups it should, but the factor you pick matters. A hardware security key stored offline gives you strong authentication without depending on a push service or phone number that might be the thing that is down. What you want to avoid is a factor that shares a failure mode with your normal admins, such as the same SMS provider or the same authenticator app backend.

If your policy forces you to exempt the account from some controls, keep the exemption as narrow as possible and compensate with monitoring and an offline credential. Because the account holds the highest privileges, it is an attractive target, which is why alerting matters as much as the credential itself.

How do you set up break-glass access in Keycloak?

Keycloak does not use the phrase “break-glass account,” but the pattern maps onto the administrators of the master realm, which can manage every other realm. The steps below are for a Keycloak cluster you run yourself on the current 26.x line. If you use managed Keycloak, see the next section.

• Use the master realm admin as the emergency path. Day-to-day admins should be named users with scoped roles, ideally delegated per realm. Keep a separate, strongly protected master admin account for emergencies. Our guide to securing your Keycloak master realm covers the hardening that account needs.
• Know the recovery command. Keycloak 26 can create a temporary admin user or service account with kc.sh bootstrap-admin, described in the Keycloak server guide under “Bootstrapping and recovering an admin account.” Every Keycloak node has to be stopped before you run it, so it is a last resort that costs downtime, and the temporary account must be deleted once permanent admin access is restored. It also needs access to the server itself, which is another reason to control who has that.
• Move the admin console off the public hostname. Serving it on a separate admin hostname and applying path-based IP restrictions means an attacker cannot even attempt a sign-in unless they are on an approved network. Plan for how your emergency path works from an allowed network, such as a VPN or a bastion host.
• Watch for brute-force lockout. Keycloak’s brute-force detection can temporarily lock an account after repeated failures. That protects you from guessing, but it also means someone could deliberately lock your emergency account while you are in the middle of an incident. Decide ahead of time how you will clear a lockout, and read our note on brute-force protection gaps.
• Send admin events to your monitoring. Turn on admin events and login events and forward them to your logging stack so any use of the account raises an alert. The Keycloak auditing and event logging guide walks through the setup.
• Keep the credential in a vault. Store it sealed, with a record of who opened it, and rotate it after each use. For keeping Keycloak’s own configuration secrets out of plaintext, see Keycloak secrets management with a vault.

If you want a wider checklist for the cluster as a whole, the Keycloak security audit and hardening checklist is a good companion.

What does break-glass access look like on managed Keycloak?

On a managed service the question changes, because you do not hold server access. On Skycloak, for example, we do not issue a separate Keycloak admin username and password for your cluster. People reach the Admin Console through Admin Console SSO with their Skycloak login, and if you need emergency direct access (while SSO is being reconfigured, say) you contact support to arrange it. So your break-glass question becomes who holds owner access to your Skycloak account, how that account is protected, and where any automation client secret for the cluster is stored. Apply the same practices to those: two owners, strong offline credentials, alerts and a written procedure.

A break-glass procedure you can copy

A short written procedure is more useful than an elaborate one nobody reads. This template fits on one page:

1. Trigger. State the conditions under which the account may be opened, for example “no named admin can sign in and the incident commander approves.”
2. Approval. Name who can approve and how, such as two people from a short list, with the approval recorded in the incident ticket.
3. Access. Say where the credential and hardware key are stored and who holds the physical key.
4. During use. Confirm that the sign-in alert fired, record the start time and the reason, and limit the work to restoring normal access.
5. Closing. Sign out, rotate the credential, return the key to storage, and note the end time.
6. Review. Within a few days, review the admin event log for everything done under the account and file the review with the incident record.

Frequently asked questions

How many break-glass accounts should I have?

At least two, stored separately, so that a lost key or a locked account does not leave you with no way in. Microsoft’s guidance for emergency access accounts uses the same minimum. More than a handful tends to create a monitoring and access-review burden without improving recovery.

How often should I test a break-glass account?

A quarterly test is a reasonable default. Confirm that the credential still works, that the sign-in alert fires, and that the procedure is current. Run the test after any change to your authentication setup, since changes to MFA or conditional policies are the usual reason a break-glass account silently stops working.

Is a break-glass account the same as a shared admin account?

No. A shared admin account is used routinely by several people and makes it hard to attribute actions to anyone. A break-glass account is used rarely, under an approval process, with every use logged and reviewed, and the credential is rotated afterwards.

Can a break-glass account be an attack target?

Yes. It holds the highest privileges and is deliberately outside many normal controls, so attackers value it. That is why the guidance combines a phishing-resistant offline credential with an alert on any sign-in, rather than relying on obscurity.

Do managed identity providers still need break-glass access?

Yes. A managed service takes the server operations off your plate, but you still decide who can administer your account and how you recover if those people are unavailable. Write the procedure whichever way you host.