This post includes guidance on Use Cases and Considerations for break glass accounts. A later post will describe creating a break glass account in Entra ID (formerly Azure AD) with usage alerts configured elsewhere in Azure.
A break glass account (referred to as a BGA in this post, but sometimes referred to in any mix of emergency access account, break glass user, or similar terms) is an account configured with privileged access as part of a disaster recovery procedure. BGAs are exclusively for use when no method of normal privileged access is possible, either by being entirely unavailable or unavailable within other acceptable parameters (such as time-to-access).
Important
You may have full confidence that your organization and existing configurations are rock solid, but much like information security as a whole, BGAs are all about belief vs. reality. In the normal course of operations, no one would intentionally configure a system such that the only admins could be entirely unavailable or unable to gain access at any point. You may very well believe that your access policies are robust enough that no single misconfiguration could lock everyone out, that the chances of key team members’ vacation coinciding with a service issue are extraordinarily low, that maintenance windows for systems won’t overrun or overlap, or any number of things that would prevent a lockout scenario.
Keep in mind we live in a world full of imperfect configurations, imperfect memory, and imperfect people. We consistently work with (or entirely design) “temporary” fixes that sit untouched for years, antiquated but critical systems barely holding together, team members with occasional personal emergencies, natural disasters, and no shortage of daily responsibilities. With so much on the line, a BGA should certainly be considered as part of your regular disaster recovery planning.
Why use a break glass account?
A BGA is a privileged account by definition. The principle of least privilege is a well-established and effective standard to follow in most security postures, so why add another privileged account? Simply put, business or operations continuity, and in some true disaster scenarios, a nuanced form of security. Account recovery outside of simple password resets can be quite slow, especially those performed through a vendor support system. In a worst case, you may not be able to prove your identity to your support system, or a malicious actor will have gained access to another privileged user and locked out other known administrators. BGAs can be a very powerful alternative to overcoming these obstacles.
Consider the following use case scenarios across your services:
- All administrators are required to use MFA (multifactor authentication) in order to access a service, but the system or service for authentication using MFA is suffering an outage.
- In a similar configuration, the authentication service is available, but no MFA devices are available (cell provider change impacted SMS, a device is lost/stolen/suddenly misconfigured by mistake, etc.).
- An access policy is configured to protect administrator access, but a new change mistakenly locks out all administrators (or all users).
- An access policy is correctly configured to take into account certain criteria (such as the detected region of the source IP address), but a change by the authentication service provider OR a source IP address’s provider causes legitimate source IPs to be detected as being from outside that region, thus preventing access.
- A policy is configured to protect against brute-force attacks on authentication which properly triggers and locks the account, but the same brute-force attack was attempted against all administrator accounts where a slow or otherwise improper account recovery process is required.
With all these possibilities across several different services in a production environment, it may well be in your best interest to have a BGA plan with proper configuration, documentation, and security in place for using it.
Focus on the goal
A break glass plan is meant to enable a new vector for disaster recovery while maintaining security. If your plan does not accomplish that overall goal, it should not be implemented. Always keep that in mind throughout the design and implementation process.
You’re creating a backdoor. That comes with risks to mitigate. If a design is not worth it, don’t force it. Adjust your approach.
While BGAs can certainly save a team or entire organization from a disaster scenario, the very nature which allows that recovery also opens it up to potential abuse via misuse or malicious action. As with any decision affecting an organization’s security posture, exact measures will vary. There is no simple one-size-fits-all solution. Any acceptable BGA solution will be nuanced by necessity. All organizations’ requirements and systems are different, and what works and is appropriate for most organizations most of the time will NOT work for every organization all the time. Each plan must be tailored to maximize efficacy while balancing with other considerations.
Don’t get sucked into the idea that this is a simple task on a checklist to be completed in 15 minutes or you may well have been better off not implementing any BGAs. A poor BGA implementation can easily weaken your security posture while providing little benefit.
Systems and services to consider
Keep in mind not only your central user directory service (such as Active Directory and Entra ID), but all of your organization’s implemented services (e.g., switch & firewall access, card access, software subscription services, remote access services, antimalware services, etc.). For each service, evaluate whether a BGA may be necessary at all. Keep in mind you’re creating a backdoor, the risk that entails, and the factors in recovering access already in place (and those expected to be later). Make sure it’s worth it.
Design considerations
Here are some elements to consider in overall design:
- Used properly, these accounts will be set in place and go unused for sometimes years at a time. Given their use cases, it pays to be extremely thorough.
- BGAs should be tested on a schedule with urgent priority and without fail.
- Be sure to exempt them from potentially automated tasks, such as disabling users who have not logged in.
- Trigger alerts when a BGA is used or changed in any way, including password and permissions changes, via email, SMS, or other means as available and appropriate.
- When testing BGAs, be mindful of alert fatigue. It may be best to send alerts to only a subset of administrators designated for testing or to simply use different testing frequencies for different subsets of targeted users, (e.g., management or help desk receiving test alerts annually instead of monthly). Suppressing alerts entirely for testing is generally not recommended, as alerts should be tested for successful delivery as well. For example, an Outlook rule accidentally filtering alert emails to a folder should be caught during testing.
- Multiple BGAs for certain services with different levels of access may be appropriate.
- Exempt BGAs from certain access and authentication policies as needed. If using multiple BGAs, the accounts may be configured such that no single BGA will be exempt from all policies.
- Naming BGAs innocuous and/or misleading names can help to minimize suspicion of their level of access (e.g., “service station NE”, “kiosk 3”, “sprinkler system”, “lighting control”, etc.). Try to use names that are not expected to be used for other operations at a later point but would not stand out to an internal user casually finding it in a list.
- Just as with the details of the SOP for use, the use case for masked BGA names should never be shared with anyone but those who would conceivably be part of the SOP.
- If using BGAs with innocuous names in multiple services, do not re-use the same name across services. If discovered, this would be a clear indication of more going on with accounts with that name.
- If using names with numbers or locations, consider creating more accounts with surrounding convention to minimize suspicion. Using the previous examples, this may be achieved by creating “kiosk 1”, “kiosk 2”, and “kiosk 4” to mask use of “kiosk 3” or creating “service station W” alongside “service station NE”. These extra accounts may simply be disabled, heavily restricted, or both.
- Use long and randomized passwords to avoid successful brute-force attacks, but exclude similar characters. It can be dangerous to leave a lowercase ‘l’ and capital ‘I’ up to a guess in cases where the account will be locked out after too many authentication failures.
- Storing parts of passwords in different storage mediums and locations (e.g., different offices, digital, written, etc.) so that access must remain a team effort with acknowledgement from several team members, especially for your most privileged BGAs. This may also be an option to provide redundancy in the case that a particular part of the password would be inaccessible (secure storage service outage, natural disaster, degraded physical media, theft, etc.).
- If anything is physically written, ensure it is legible to everyone as best you can.
- Store documentation on SOP in alternate or multiple locations to ensure access if the primary documentation service or storage location is impacted.
Also keep in place an SOP for what to do after a BGA has been used. At a minimum, the password should be changed and updated in all storage locations. You may opt to create entirely new BGAs depending on your circumstances. Whether some of these actions should be completed even when testing will be highly specific to your organization, but generally, the convenience of maintaining an established name and consideration of the human factor results in a practice of doing so only for real uses and not during tests. If the BGA SOP fails, the fundamental reason for having a BGA has failed.
The nature of BGAs makes their configuration and use tricky at best. This must be tailored to your organization and service. It may also be worth reaching out to particular service vendors for best practices regarding BGAs for their services.
See also: