Locked out of your cloud environment because your ‘break-glass’ emergency access account failed? Learn why this common pitfall happens and discover three battle-tested methods to regain access, from the quick fix to the permanent solution.

So, Your ‘Break-Glass’ Account Shattered? Let’s Get You Back In.

I still get a cold sweat thinking about it. It was 3 AM, and PagerDuty was screaming about our primary billing database, `prod-billing-db-01`, being unreachable. Simple enough, I thought, I’ll just hop on and restart the instance. Except I couldn’t. My primary admin account was locked out. A new, overly aggressive MFA policy had been rolled out by the security team an hour earlier, and my session had just expired. “No problem,” I mumbled to myself, “that’s what the emergency account is for.” I logged in with `emergency-admin@techresolve.com`… and was met with the exact same MFA prompt, which, of course, wasn’t configured for this user. We were locked out. Completely. That feeling of digital helplessness as a critical system burns is something I wouldn’t wish on my worst enemy.

The ‘Why’: When Good Policies Go Bad

I see this question pop up all the time, and the root cause is almost always the same: a well-intentioned but overly broad security policy. In Azure, it’s a Conditional Access policy. In AWS, it’s an SCP or a wide-reaching IAM policy. The mistake is applying a rule to “All users”.

You think “All users” means all your regular employees. But the system interprets that literally. It means every single identity principal in the directory, including the service accounts, the guest users, and yes, your precious `break-glass` account that was supposed to be your skeleton key. The very tool designed to protect you has become the bars on your own jail cell. The policy that enforces MFA on everyone doesn’t know—or care—that `emergency-admin` is special. It just sees a user and applies the rule.

Getting Back In: Three Battle-Tested Methods

Okay, so you’re locked out. The house is on fire, and your keys are inside. Let’s get you back in the door and then build a better door.

Method 1: The Quick Fix (The Support Ticket)

This is the “I need to be in five minutes ago” solution. Your first and most immediate option is to contact your cloud provider’s support (Microsoft, AWS, Google) and declare a critical, production-down outage. You will need to prove your identity, which can be a process, but they have procedures for this.

What you’ll ask for is a temporary, emergency exclusion on the policy that’s locking you out. You’ll say something like, “Please add a temporary exclusion for the public IP address X.X.X.X to Azure Conditional Access policy ‘Global MFA Enforcement’.” They have the backend access to do this. Once they add the exclusion, you can log in from that IP without the policy applying, fix the root cause, and then have them remove the temporary rule.

Warning: This is a temporary patch, not a fix. It’s reactive and relies on a third party during a high-stress event. Use this to stop the bleeding, but immediately move on to Method 2 once the fire is out.

Method 2: The Permanent Fix (The Exclusion Group)

This is how you prevent this from ever happening again. The core principle is simple: never apply a policy to “All users.” Instead, you create a dedicated, non-privileged security group for your emergency access accounts. Let’s call it `sg-break-glass-admins`.

1. Create a security group in your directory (e.g., Azure AD, AWS IAM Identity Center) named `sg-break-glass-admins`.
2. Add your two (you have at least two, right?) emergency accounts to this group.
3. Modify every single one of your broad security policies. Change the assignment from “Apply to All users” to “Apply to All users, EXCEPT for members of `sg-break-glass-admins`.”

Here’s what a pseudo-policy might look like. Notice the `exclude` block:

{
  "policyName": "Global-MFA-Enforcement",
  "conditions": {
    "users": {
      "include": [ "All" ],
      "exclude": [ "group:sg-break-glass-admins" ]
    },
    "applications": {
      "include": [ "All" ]
    }
  },
  "grantControls": {
    "operator": "OR",
    "builtInControls": [ "mfa" ]
  }
}

Pro Tip: You MUST test this. We have a quarterly DR drill where part of the playbook is to confirm we can log in with our break-glass accounts and that they are correctly excluded from new policies. Don’t assume; verify.

Method 3: The ‘Nuclear’ Option (The Support-Only User)

What if you’re so locked out you can’t even file a high-priority support ticket? This is a terrifying scenario, but one a mature organization plans for. You create a separate, highly-isolated user account whose *only* permission is the ability to create and manage support tickets.

Let’s call this user `support-ticket-creator@techresolve.com`. This account has no admin rights. It can’t see your storage accounts, it can’t reboot `prod-db-01`, it can’t do anything but talk to the cloud provider.

This user account is ALSO added to your `sg-break-glass-admins` exclusion group. Its purpose is singular: if all other access methods fail, this user is your guaranteed line of communication to the people who can help you. It’s the red phone in the bunker.

Look, we all make mistakes. Cloud environments are complex beasts. The key isn’t to never fail; it’s to build resilient systems and processes that assume failure will happen. Don’t wait for that 3 AM call to discover your safety net has a hole in it. Go check your policies right now. Seriously.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions