Service Principal as a 'Plan B' emergency access break-glass account

The verdict from the Entra community...

In the world of Microsoft Entra ID management, few topics generate as much passionate debate as emergency access strategies.

Recently, I posed this question in a poll on LinkedIn and X:

What do you think of using Apps (Service Principals) as a 'Plan B' emergency access account?

Here’s the combined results from the 817 votes.

This split reflects the nuanced nature of the topic, with no clear consensus. In this blog post, I’ll break down the approach of assigning a Global Administrator (GA) role to an SP for emergency access, analyze the pros and cons based on community feedback, and share my personal take on the matter.

Why emergency access accounts?

Getting locked out of your Entra tenant is the stuff of nightmares for any IT administrator or security professional. Whether it's a misconfigured Conditional Access policy, a lost or broken multi-factor authentication device, or an expired credential, the inability to access your critical cloud environment can bring operations to a grinding halt.

Microsoft’s recommendation has been to set up a "break-glass" or "emergency access" user account. These highly privileged accounts are kept under strict control, excluded from standard Conditional Access policies and secured with robust methods like FIDO2 keys stored securely offsite. Their usage is heavily monitored and alerts are triggered immediately upon sign-in.

But in the evolving landscape of cloud identity, a new idea has surfaced, sparking considerable debate: What about using an Application (specifically, a Service Principal) with Global Administrator permissions as an emergency access mechanism?

This approach hinges on the fact that Service Principals authenticate differently than users, often using certificates or secrets, which bypasses user-focused Conditional Access policies. The idea is to create a Service Principal, grant it the Global Administrator Entra role, and secure its credentials (ideally a certificate on a hardware security module like a YubiKey) and monitor its activity rigorously.

The earliest reference for this approach that I’ve seen is this reddit post from 2023 ‘Using Service principal as Azure AD Break glass access’. At that time I dismissed the idea, but lately I’ve seen quite a few posts on various forums where admins had locked themselves out of their tenant and it got me thinking about using SPs.

So that’s where the poll came in → "What do you think of using Apps (Service Principals) as a 'Plan B' emergency access account?" The results, based on 817 votes, were quite telling:

• Yes: 165 (20.2%)

• No: 327 (40.0%)

• Maybe: 325 (39.8%)

The poll results clearly indicate a significant level of hesitation or outright opposition to this approach. The combined "No" and "Maybe" votes represent nearly 80% of the responses, suggesting that while there's some interest or recognition of potential edge cases ("Maybe"), the majority are either against it or highly skeptical.

Let's delve into the lively discussion that followed to understand the reasoning behind these votes.

Analysis of Community Responses: The Pros and Cons Unpacked

The comments on both platforms provided invaluable context to the poll numbers, highlighting strong opinions and practical experiences.

Arguments Against (The "No" Votes and Skeptical "Maybe"s):

The most prevalent concerns centered around security risks and complexity:

1. Lack of MFA: A major drawback repeatedly cited is that Service Principals cannot natively perform multi-factor authentication in the same way a user account does. While certificate-based authentication is strong, it's seen by many as not a direct equivalent to user+MFA, leaving a perceived gap.

2. Credential Management Hell: The security of a Service Principal relies entirely on the security of its credentials (secrets or certificates). Many respondents expressed concern that organizations already struggle with managing user credentials and application secrets. Adding a highly privileged SP with poorly managed credentials (e.g., secrets stored insecurely, certificates expiring or on insecure devices) introduces a significant attack vector. Mathias Dumont and Alexander specifically highlighted this risk.

3. Privilege Escalation Path: Granting a Service Principal Global Administrator is immensely powerful. Several folks, including Jordan Pitcairn, Stian Andresen Strysse, and Graham Gold, pointed out that the App Administrator and Cloud Application Administrator roles have the power to manage credentials for Service Principals. If these admin roles are not tightly controlled (e.g., via PIM), an attacker compromising one of these roles could potentially create new credentials for the break-glass SP and gain GA access without needing to compromise the original secured credential. Graham Gold explicitly stated, "App Administrator = Tier 0... If not gated with PIM and approvals, you’re handing out a backdoor to GA."

4. Complexity and "Hackiness": Niclas Madsen strongly felt this is a "bad design and a 'hack'," adding unnecessary complexity that introduces risk. Jesper Joachim Raarup echoed this, arguing it adds another "angle of attack" and distracts from fundamental security hygiene. The KISS (Keep It Simple, Stupid) principle was invoked by Kévin KISOKA and Amanda Wuest.

5. Lack of Dedicated Controls: Jackson Sweeney and D Lind highlighted the lack of granular controls like Restricted Administrative Units (RAUs) for Service Principals, making it harder to isolate and protect them compared to privileged user accounts (though RAUs for users also have limitations).

6. Workload Identity CA Dependency: While Conditional Access policies for Workload Identities exist and were mentioned as a potential mitigation (Eric Mannon, Tom Camps, Michaelsoft Binbows), many organizations haven't implemented them, or they aren't as mature as user CA policies. Relying on this for the security of a break-glass SP is seen as risky if the organization's maturity isn't high enough (Graham Gold).

7. Doesn't Solve Core Problems: Some felt this approach doesn't address the root cause of lockouts (poor policy design) or the fundamental need for robust break-glass user accounts (Alexander, John Hoddinott).

Arguments For or Accepting in Specific Cases (The "Yes" Votes and Accepting "Maybe"s):

Despite the strong opposition, there were compelling arguments and scenarios where this approach was seen as viable or even necessary:

1. Bypassing Restrictive CA Policies: The most significant practical advantage mentioned by proponents like Stian Andresen Strysse, Gabe Delaney, and Roel van der Wegen is that a Service Principal can circumvent user-based Conditional Access policies that might block all user sign-ins, including traditional break-glass users (if they weren't properly excluded or if the exclusion failed). Gabe and Roel shared real-world experiences where they used application permissions to regain access to locked-out tenants.

2. MSPs and Scaling: Roel made a specific case for MSPs managing hundreds of tenants. Managing physical FIDO keys for break-glass users across numerous clients becomes logistically challenging. A multi-tenant application approach, with careful credential management and monitoring, could be a more scalable "Plan B" for MSPs, though this was debated due to supply chain risks (Jesper Joachim Raarup).

3. Requires a Robust Framework: Many "Maybe" votes and some "Yes" arguments (Gabe Delaney, Kirby Clements, Michael Cramer) stressed that this isn't something to be done lightly. It requires a dedicated framework including:

   • Strict credential management (HSM, certificates).

   • Comprehensive monitoring and alerting on any activity or modification of the SP or its credentials.

   • Clear boundaries on the SP's permissions (though for GA break-glass, this is inherently broad).

   • Protection against accidental modification.

4. Microsoft Should Build It: Michael Cramer proposed that Microsoft should create a built-in, purpose-designed recovery account feature in Entra ID, secured by design (e.g., mandatory multiple FIDO keys, automatic CA exclusion, special auditing), rather than leaving admins to implement potentially risky workarounds. Kirby Clements agreed, suggesting Microsoft could formalize this by restricting management of such SPs to only GAs or a new dedicated role.

5. Better Than Poor User Break-Glass: Some implied that a well-implemented SP break-glass could be more secure than traditional user break-glass accounts secured only with password managers or single, easily compromised MFA methods.

Conclusion from the Responses

Based on the poll results and the detailed comments, the community sentiment is clear: Using a Service Principal with Global Administrator rights as a general break-glass emergency access account is largely viewed with skepticism and concern (the combined 80% "No" and "Maybe" votes).

The primary reasons for this apprehension are the inherent security challenges of managing Service Principal credentials, the potential for privilege escalation through less-controlled App Admin roles, the lack of native user-like MFA, and the added complexity compared to traditional methods.

While there's recognition that this approach could be useful in specific, dire lockout scenarios (especially those caused by CA policies affecting users) or perhaps for specific operational models like MSPs, the consensus is that the security risks, if not mitigated by an exceptionally robust security framework, monitoring, and strict controls over App Admin roles, outweigh the potential benefits for most organizations. The "Maybe" votes indicate that for some, the idea isn't outright rejected but is contingent on significant safeguards and potentially official tooling or guidance from Microsoft.

Ultimately, the discussion highlights a perceived gap in current Entra ID capabilities for truly resilient emergency access that can bypass even fundamental policy misconfigurations, alongside a lack of organizational maturity in securing workload identities compared to user identities.

My Personal Opinion

(Please note: This is my personal opinion and does not represent the official stance of my employer, Microsoft.)

The poll responses definitely opened my eyes to new risks I hadn’t considered before as well as concrete examples of the usefulness when managing a large number of tenants like MSPs (or even an Enterprise with 100s of tenants).

I lean towards "Yes" for specific types of tenants, and this stance is based on a few key observations:

1. Increased Lockout Vectors: It's true that the ways to lock yourself out of a tenant have proliferated. Beyond losing a password/MFA, misconfigured Conditional Access policies (blocking all access), authentication strengths, or even Passkey profiles can render all user accounts inaccessible. The risk of an accidental, tenant-wide lockout seems higher than before.

2. Difficulty of Recovery: As this Reddit post illustrates, recovering access to a locked-out tenant via Microsoft Support is, by design, a difficult and time-consuming process. And it absolutely should be hard. Microsoft must rigorously verify identity before handing over control of a tenant to prevent threat actors from easily claiming ownership. However, for legitimate administrators facing a crisis, this process can be agonizingly slow (or impossible if you don’t have any form of mechanism to show concrete proof linking you to the tenant).

3. Tenant Type Matters:

   • Entra ID Free Tenants, M365 Dev tenants: (Yes) These tenants don’t have a clear way to prove ownership. No linked credit card etc. Although you can’t create new M365 Dev tenants (the free ones), for those who already own them they are indispensable and would be a huge loss if you lost access. Plus, today it’s almost impossible to recover them if you lock yourself out.

   • Customers with Enterprise Agreements and dedicated Microsoft account teams: These organizations have direct access to Microsoft support channels and resources that can potentially expedite recovery in extreme circumstances. The need for a self-service, potentially risky workaround is diminished (Maybe from me).

   • Production tenants where your CEO can call Satya on the phone: Do you even need break-glass accounts? 😂

Creating a Break-Glass Service Principal account

If I were to create a Service Principal for break-glass (for appropriate tenant types), here is how I would configure it:

• Create Emergency Access Service Principal: A dedicated app (jury is out on single tenant vs multi-tenant app).

  • Multi-tenant SPs cannot be blocked by Workload ID CA policies in other tenants (today).

  • Workload ID still requires a seperate license so not many tenants have this proactively. If you do have such a policy you will need to exclude this account from the workload ID CA policy.

• Grant Entra GA role: Why such a wide role? It’s hard to predict what can go wrong. The last thing you need is to do all the prep work but the account is not usable to help with tenant recovery.

• Secure Credentials with HSM Certificate: Crucially, use certificate-based authentication. Generate the certificate signing request (CSR) on a local Hardware Security Module (HSM), such as a YubiKey or a dedicated hardware appliance. The private key never leaves the HSM.

• Robust Monitoring: Implement immediate and high-priority alerting whenever this Service Principal signs in or is used. This requires integration with a SIEM like Microsoft Sentinel or a dedicated monitoring system. KQL queries watching Entra ID sign-in and audit logs would be essential. Alerts should go via multiple channels (email, SMS, SOC alert). A GitHub Action or similar automation could be used to trigger checks and alerts.

• Redundancy for Monitoring: Have a separate, independent system (perhaps a third-party monitoring tool outside of Entra ID control that the SP couldn't easily disable) that performs a "heartbeat" check to ensure your primary monitoring and alerting systems (like the GitHub Action) are still operational. If the heartbeat stops, it triggers an alert.

Someday I hope to build a PowerShell module or an app that makes it super easy to set this up correctly and manage it. 😉

References and further reading

• How to Configure an Emergency Access App in Entra ID - Lokesh

• M365 Breakglass Maturity Model - Graham Gold

• Attacker’s Breakdown: M365 Break Glass Maturity - Elli Shlomo