Emergency Access: Controlling Without Blocking Operations

Cybersecurity · 2 min

Emergency accounts help recover services, but they can also create serious risks. Learn how to govern *break-glass* access with control and traceability.

Emergency Access: Controlling Without Blocking Operations

TL;DR

Emergency access should be an exception, not an operational shortcut.
Break-glass accounts need an owner, scope, authentication, and logging.
Risk increases when privileged accounts become permanent and poorly monitored.
Periodic testing helps confirm that access works when needed.
Post-use review is as important as initial authorization.

The right question is not whether emergency access should exist

In enterprise environments, there are scenarios where normal access can fail: identity provider unavailability, misconfiguration, loss of connectivity, security incident, or a critical integration failure. In these moments, an emergency account, often referred to as break-glass, can allow for recovery of control. The relevant question is not whether these accounts should exist, but how to prevent them from becoming a permanent, poorly monitored, privileged backdoor outside normal governance processes.

The risk lies in privilege without context

An emergency account typically concentrates high permissions and authentication mechanisms independent of usual workflows. This is useful when the identity system is unavailable but also creates exposure if the account is shared, reused, or forgotten. Management should start by defining purpose, technical scope, covered systems, custodians, and conditions of use. This discipline complements identity risk detection practices, such as those discussed in [ITDR e riscos de identidade](/pt/blog/itdr-detetar-riscos-de-identidade-antes-do-incidente).

Separate routine access from exceptional access

The most common mistake is using emergency accounts for frequent administrative tasks. When this happens, the distinction between normal operation and exception ceases to exist. A good practice is to keep everyday access subject to roles, approval, strong authentication, and traceability, reserving the break-glass mechanism for documented situations. In modern access architectures, this separation must coexist with [Zero Trust e ZTNA](/pt/solucoes/zero-trust-ztna) principles, without assuming that an emergency justifies an absence of control.

Define custody, authentication, and logging

Every emergency account must have a functional and technical owner. Credentials should be stored in a controlled manner, with limited access and a documented access process. Emergency accounts should use strong authentication mechanisms appropriate for the contingency scenario, avoiding dependencies that might impede access during a failure. Automatic alerts and detailed logging of their use should also exist. If the account needs to bypass specific dependencies, this exception must be explicit and justified. Integration with [gestão de infraestrutura](/pt/servicos/gestao-infraestrutura) practices helps maintain inventory, responsibilities, and procedures aligned.

Test without trivializing

An account that is never tested can fail precisely when it is needed. But tests that are too frequent or poorly framed can normalize the use of elevated privileges. The balance lies in periodic exercises, with a defined window, prior approval, clear objectives, and validation of evidence. Testing should confirm that the credential is accessible, that access works, that alerts are triggered, and that activity is logged. If any of these points fail, the process needs correction before it can be considered reliable.

Review after each use

The post-use moment is critical. It must be confirmed who accessed, why, for how long, what changes were made, and if credentials need rotation. When use occurred during an incident, the review should link to response procedures and their respective [runbooks operacionais](/pt/blog/runbooks-automatizacao-resposta-incidentes). The goal is not to bureaucratize recovery, but to ensure that the exception was necessary, proportional, and auditable. Well-governed emergency access reduces improvisation without eliminating responsibility.