In most small Microsoft 365 tenants, the Global Administrator account is also somebody’s mailbox. It reads email. It opens attachments. It browses the web at lunchtime. It is signed in on a laptop that goes home in a bag.
That single arrangement undoes more security than any missing product. An attacker who phishes that person does not get a foothold, they get the tenant: every mailbox, every file, the ability to create accounts, disable logging and grant themselves whatever else they want. No lateral movement required, because there is nowhere left to move to.
Separate identities, not separate hats
The rule is simple and it is the one that matters: the account you administer with is not the account you work in.
That means a distinct account, with its own credentials, no mailbox in normal use, no browsing, no third-party application consents, and no licence assigned unless a specific tool demands one. It is used to perform administrative tasks and then signed out of.
The objection is always convenience, and it is a fair one: switching accounts is friction. The answer is that the friction is the point; it is also smaller than it sounds once separate browser profiles or a dedicated administrative session are set up. Weighed against the alternative, which is a single phishing email reaching the account that owns everything, it is not a close decision.
This is also a Cyber Essentials requirement rather than best practice advice. Administrative accounts must be separate from accounts used for day to day work, and must not be used for email or web browsing. An assessment will ask, and the honest answer in many organisations is currently no.
Least privilege, in a place that makes it easy
Entra ID has a long list of built-in roles precisely so that Global Administrator is not the answer to every request. Someone who resets passwords needs a role that resets passwords. Someone who manages Teams needs the Teams role. Someone who reads reports needs a reader role.
Common requests and the role that actually covers them:
| Somebody needs to | Role that covers it |
|---|---|
| Reset user passwords | Password Administrator, or Helpdesk Administrator |
| Manage users and licences | User Administrator |
| Manage Teams, or SharePoint, or Exchange | The service-specific administrator role for that workload |
| Read reports and sign-in logs | Reports Reader, or Security Reader |
| Investigate security alerts | Security Reader, escalating to Security Operator |
| Manage devices in Intune | Intune Administrator |
| Everything, forever, because it was quicker | Global Administrator, which is how you ended up here |
Practical guidance that survives contact with a small organisation:
- Count your Global Administrators. Microsoft's guidance is to keep the number small, and most small tenants should be in low single figures. If you have more than a handful, some of them are there because it was quicker at the time.
- Assign the narrowest role that does the job. The role list exists to be used; picking Global Administrator because you are not sure which role applies is how the count grows.
- Remove the ones nobody uses. The consultant who set the tenant up. The former employee's account that was never disabled. The provider's engineer who left the company two years ago.
- Check the guest accounts. External accounts with administrative roles are a genuine and regularly overlooked finding.
- Review service accounts and application permissions. Applications granted broad access to mail or files are administrative access by another name, and they never appear on a list of administrators.
Emergency access accounts
Every organisation that tightens administrative access eventually meets the same question: what happens when the control locks you out of your own tenant?
The answer is emergency access accounts, sometimes called break-glass accounts. Two of them, cloud-only, not tied to any individual, excluded from the Conditional Access policies that could block them, with long unique credentials stored somewhere physically secure and not inside the tenant they exist to unlock.
Three things make them useful rather than decorative. Exclude them deliberately from the policies you are about to enforce, before you enforce them. Alert on their use, so that any sign-in generates a notification somebody actually receives. And test them, on a schedule, because an untested emergency account is an assumption rather than a control.
Create the emergency access accounts and test them first. Then create separate administrative identities and move roles onto them. Then apply Conditional Access to administrative roles, in report only mode, and watch for a week. Then enforce. Doing it in any other order is how organisations lock themselves out of their own tenant on a Friday afternoon.
Protecting the accounts once they exist
Separation buys you nothing if the administrative account is protected the same way the ordinary one was.
Hardware-bound authentication, and specifically a security key. Administrative accounts should not be protected by codes that can be intercepted, relayed by a proxy, or approved by a tired person at eight in the morning. That much is settled. What to replace them with, for privileged accounts, is worth being more careful about than most guidance is.
My preference for a Global Administrator account is a FIDO2 hardware security key, a YubiKey or equivalent. The private key is generated on the device, cannot be exported from it, and is not synchronised anywhere. Compromising it requires physical possession of a specific object rather than compromise of a machine, an account, or a vendor’s cloud.
Software-backed passkeys are a different proposition, and the industry has been noticeably keener on them than the evidence yet justifies. Where a passkey is stored by the operating system or a synchronising provider, its security is bounded by the security of that store and of whatever recovery mechanism exists for it. There is active research and a growing body of tooling around extracting credentials from Windows devices, and the honest position today is that the jury is still out. For ordinary user accounts, passkeys are a substantial improvement on what they replace and I would encourage them. For the account that owns your tenant, I would rather the key lived on a piece of hardware in a drawer.
Two practical points follow. Register at least two keys per administrative account, because a single hardware token is a single point of failure and the recovery path for a lost one is exactly the weakness you were trying to remove. And know the direction of travel regardless: Microsoft makes passkeys the default sign-in from 1 September 2026 and retires telephony-based authentication on 1 February 2027, which we covered in the passkeys readiness guide. Phone codes are ending whether or not you have decided what replaces them.
Conditional Access targeted at administrative roles. Require compliant or managed devices for administrative sign-in. Block legacy authentication outright. Consider restricting where administrative sessions can begin from. Our Conditional Access guide covers the wider policy set.
No standing access where it can be avoided. Privileged Identity Management, available with Entra ID Plan 2, allows roles to be activated for a period rather than held permanently. It is not included in Business Premium, and for organisations without it the equivalent discipline is manual: fewer permanent administrators, reviewed more often.
Logging that someone reads. Sign-in logs, audit logs and alerts on privileged role assignment. The value is not in collecting them, it is in noticing when a new Global Administrator appears at three in the morning.
The review nobody does
Administrative access accumulates. Somebody needs a role for a project, gets it, and the project ends. A provider is granted access during a migration and it is never withdrawn. Somebody changes job internally and keeps everything they had before.
None of this is negligence, it is entropy, and the only answer is a scheduled review. Quarterly is a reasonable rhythm for a small organisation: list every account holding an administrative role, confirm each one still needs it, remove the rest, and record that you did it. That record is also useful evidence when a customer questionnaire or a certification assessment asks how you manage privileged access.
What good looks like, concretely
For a small organisation with Business Premium, a defensible position looks roughly like this:
- Two or three Global Administrators, no more, each with a separate administrative account holding no mailbox and no routine use.
- Two emergency access accounts, cloud-only, excluded from Conditional Access, credentials in a safe, sign-in alerting configured, tested every six months.
- Every administrative account authenticating with a FIDO2 hardware security key, with a second key registered as backup.
- Conditional Access requiring compliant or managed devices for administrative sign-in, legacy authentication blocked tenant-wide.
- Everyone else on the narrowest role that does their job, with guest accounts and application permissions reviewed alongside human ones.
- A quarterly review, recorded, of who holds what.
None of that requires a licence upgrade, a project, or a consultant. It requires an afternoon and the decision to stop postponing it.
Where this meets certification
Cyber Essentials asks directly about separate administrative accounts, about multi-factor authentication on cloud services, and about removing access no longer required. IASME Cyber Assurance goes further and examines how access is governed rather than simply whether it is configured.
If you would rather find out what your tenant currently looks like before a questionnaire does, an independent Microsoft 365 Security review covers administrative accounts, Conditional Access, guest access and application permissions. Get in touch or call 01722 445972.