When businesses set up Microsoft 365, one of the most common shortcuts taken during the process is assigning global admin rights to whoever set it up, usually the owner or a senior manager, and leaving it tied to their everyday work account. The same account they use to send emails, book meetings, and receive phishing attempts.
It feels logical at the time. One account, less to remember, easier to manage. But it is one of the most significant security risks in any Microsoft 365 environment, and it is completely avoidable.
This post covers why your M365 admin account should be completely separate from your day-to-day work account, what a proper setup looks like, and why every Microsoft 365 tenant should have a break glass account with a very specific configuration.
Why Your Work Account Should Never Have Global Admin
Your work account is your most exposed account in the entire organisation. It sends and receives email. It clicks on links. It gets targeted by phishing campaigns. It gets entered into websites, webinars, and third-party tools. Every time you use that account, you are increasing its exposure.
Now imagine that account also has global administrator rights over your entire Microsoft 365 environment. That means whoever controls that account controls your email, your Teams, your SharePoint, your user accounts, your security settings, your billing. Everything.
If a phishing attack succeeds against your work account and you are also a global admin, the attacker does not just read your emails. They can create new admin accounts, disable security policies, extract data from every mailbox in the organisation, and lock you out entirely. This is not a theoretical scenario. It is how a significant number of Microsoft 365 compromises actually play out.
The entire point of a separate admin account is that it is never used for anything other than administration. It does not send or receive email. It does not browse the web. It does not get entered into forms. Its only job is to make changes to the Microsoft 365 environment when required, and then it gets logged out of.
What a Proper Admin Account Looks Like
A proper Microsoft 365 admin account has a few key characteristics.
It uses a different username to your work account. Typically something like admin@yourcompany.com or firstname.admin@yourcompany.com. It is immediately obvious from the username that this is an administrative account, not a working one.
It has no mailbox attached to it. Admin accounts do not need to send or receive email. Attaching a mailbox to an admin account just creates additional exposure. If Microsoft needs to send licence or billing notifications, those can go to a distribution group monitored by the right people.
It is protected by MFA. Every admin account should require multi-factor authentication every single time it is used, without exception. There should be no trusted devices, no remembered sessions, no exceptions for being on the office network. Admin sign-ins should always prompt for MFA.
It is only used for administration. The person who holds the admin account should sign in, make the changes they need to make, and sign out. They should not keep an admin session open in a browser tab while they work through the rest of their day. The admin account should feel like picking up a set of master keys: you use them when you need them, and you put them back when you are done.
It has its own Conditional Access policies. Microsoft Entra ID allows you to apply different Conditional Access rules to admin accounts. These should be stricter than the rules applied to standard user accounts: sign-in frequency enforced, location restrictions considered, session limits applied.
The Separation Works Both Ways
It is worth being explicit about this: the separation should be complete. Your standard work account should have no admin rights whatsoever. Your admin account should not be your primary working identity.
This means if you are used to jumping in and out of admin settings during your working day while using your standard account, that has to change. Administration becomes a deliberate act that requires you to switch accounts, authenticate fully, do the work, and sign out. That friction is the point. It means administration is never accidental, never casual, and never something an attacker can access just by compromising your everyday account.
Many IT professionals push back on this at first because it feels like extra work. It is, slightly. But compared to rebuilding a compromised Microsoft 365 tenant, the extra few seconds to sign in with the admin account is not a meaningful burden.
What is a Break Glass Account
A break glass account is an emergency access account that exists for one specific purpose: to allow you to get back into your Microsoft 365 tenant if your normal admin accounts are inaccessible.
Scenarios where this matters more than you might think include: your MFA app stops working, your authenticator device is lost or damaged, your identity provider has an outage, your normal admin account gets locked out, or a Conditional Access policy is misconfigured and blocks all admin sign-ins. Without a break glass account, any of these situations can lock you out of your own tenant completely.
Microsoft’s own guidance recommends that every organisation maintains at least two break glass accounts for exactly this reason.
How to Configure a Break Glass Account Properly
The break glass account has a very specific configuration that makes it different from a standard admin account.
It uses a physical MFA token, not a cloud-based authenticator. NIST guidelines are clear that even emergency accounts should not be exempt from multi-factor authentication. The correct approach is to use a hardware security key such as a YubiKey as the MFA factor for the break glass account. Unlike a phone-based authenticator app, a YubiKey works independently of any cloud service, mobile network, or device. It does not rely on the same MFA infrastructure that may have caused the emergency in the first place. The physical key is stored in the same secure vault as the written credentials, so whoever retrieves the password also retrieves the key. Both are needed to authenticate, which means the account remains properly protected even while being accessible in a genuine emergency.
It has an extremely long, complex password. Because MFA is excluded, the password becomes the only authentication factor. That means it needs to be genuinely secure. The recommendation is a minimum of 16 characters, but in practice many organisations use passwords of 30 to 50 characters or more. A randomly generated string of uppercase and lowercase letters, numbers, and symbols. Something that cannot be guessed, cannot be brute-forced in any realistic timeframe, and is not based on any pattern.
The password is stored securely offline. It should not be stored in a password manager that lives in your tenant or is connected to your Microsoft 365 environment. If the tenant has a problem, you need the password to be accessible independently of it. Common approaches include printing it and storing it in a physical safe, splitting it into two halves held by two different people, or storing it in an offline vault. The key principle is that the password must be retrievable even if your entire IT environment is unavailable.
It uses the .onmicrosoft.com domain. Your break glass account should use your tenant’s default .onmicrosoft.com address rather than your custom domain. This is because if there is an issue with your custom domain configuration, the .onmicrosoft.com address will still resolve. Your custom domain is a dependency you do not want in an emergency.
It is a cloud-only account. Break glass accounts should not be synchronised from your on-premises Active Directory. If your AD sync has a problem or your on-premises environment is unavailable, a cloud-only account will still work.
It is permanently excluded from all Conditional Access policies. Every Conditional Access policy you create should have the break glass account listed as an explicit exclusion. This includes MFA policies, compliant device policies, location-based policies, and sign-in frequency policies. The account needs to be able to sign in regardless of what any policy says.
It should never be used for routine administration. The break glass account is not a shortcut for when you cannot be bothered to sign in with your normal admin account. It exists solely for genuine emergencies. Using it for routine tasks defeats its purpose and increases the risk of the credentials becoming known.
Thanks to Dee at AsYouNeed for the discussion around the NIST guidance on this point and for making sure we got it right.
Monitoring the Break Glass Account
Because the break glass account has no MFA and a very powerful set of rights, any sign-in to it should immediately trigger an alert.
In Microsoft Entra ID you can set up diagnostic settings or alert rules that fire the moment the break glass account signs in. The alert should go to multiple people, including people outside the IT team where possible, so that any unexpected use of the account is noticed immediately.
The logic is straightforward: if the break glass account is being used when there is no emergency, something is wrong. Either someone has obtained the credentials and is using them without authorisation, or someone in the team has started using the account for routine work, which needs to be corrected.
Testing the Break Glass Account
A break glass account that has never been tested is a break glass account you cannot rely on. Most organisations set one up and then leave it untouched for months or years, at which point no one is certain the password recorded in the safe is still correct, whether the account might have been accidentally captured by a new Conditional Access policy, or whether anyone still knows where the password is stored.
The account should be tested regularly, typically every 90 days. Testing means signing in with the account, confirming access works, and signing out again. It does not mean making any changes to the tenant. Just confirming the account is accessible. That sign-in will also trigger your monitoring alert, which is a useful test of whether the alerting is still working correctly.
Putting It All Together
A well-configured Microsoft 365 admin setup looks like this:
Every person who needs administrative access has a dedicated admin account, separate from their working account, with no mailbox attached. Those admin accounts are covered by strict Conditional Access policies and require MFA every time they are used. They are only used when administration is actually required.
The tenant also has at least two break glass accounts. These accounts have global administrator rights, are excluded from Conditional Access policies that would otherwise block emergency sign-in (such as device compliance or location restrictions), use a physical hardware token such as a YubiKey as their MFA factor, use the .onmicrosoft.com domain, are cloud-only, and have very long randomly generated passwords stored securely offline alongside the physical MFA key in a locked vault. Any sign-in to either account triggers an immediate alert to the relevant people.
The working accounts used day to day have no admin rights at all.
Why This Matters for Smaller Businesses
Larger organisations often have dedicated IT security teams that enforce this kind of configuration. For smaller businesses with five to fifty users, it tends to get overlooked because the person who set up Microsoft 365 is also the person running the business, and adding administrative overhead feels like an unnecessary complication.
The reality is that attackers do not only target large organisations. Microsoft 365 tenants belonging to small businesses are targeted regularly, specifically because they tend to have weaker configurations. A compromised admin account in a small business can be just as damaging as in a large enterprise. The email, the data, the contacts, the communications: all of it is accessible to anyone who can sign in as a global admin.
Getting the admin account setup right costs very little in time or money. Recovering from a compromised tenant can cost a great deal of both.
If you are not sure whether your Microsoft 365 environment is configured correctly, this is one of the first things worth checking. And if you need a hand getting it set up properly, that is exactly what we are here for.
