Azure identity and access management fails in a predictable way in UK businesses, and it is rarely because nobody thought about security. It fails because administrative access accumulates. An engineer is given Global Administrator to fix something urgent and keeps it. A supplier is granted Owner on a subscription for a migration that finished two years ago. A service principal created for a deployment script holds rights over everything in the tenant. Each grant was reasonable on the day it was made, none was ever removed, and the result is an estate where a single stolen credential opens almost everything.
This guide is about reducing that standing access without making the IT team’s job harder — because the most common way least-privilege projects fail is not resistance to security but approval friction so severe that people quietly go back to a shared admin account that always works. It covers why standing privilege is the attack surface rather than a convenience, the two separate permission systems in Microsoft’s cloud that are routinely confused, role design for Azure RBAC and Entra ID directory roles, just-in-time elevation with Privileged Identity Management, Conditional Access policies aimed specifically at administrators, the non-human identities most reviews forget, and how to design elevation so that it takes seconds rather than waiting for an approver who is on leave. The wider authentication picture — passkeys, phishing-resistant MFA and Conditional Access for all users — is covered in our guide to phishing-resistant MFA and passkeys.
How standing admin access becomes the attack surface
The useful mental shift is to stop thinking of an admin account as a person with extra rights and start thinking of it as a credential that, if obtained, grants those rights to whoever holds it. Seen that way, every hour an account holds Global Administrator while its owner is doing ordinary work — reading email, browsing, opening attachments — is an hour in which a phishing message or a compromised browser session could hand the tenant to someone else.
Three properties make standing privilege especially dangerous in Microsoft’s cloud. First, the blast radius is enormous: a Global Administrator can create accounts, reset any password, read any mailbox through delegated permissions, alter security settings, and in Azure can elevate themselves to manage every subscription. Second, attackers specifically hunt for these accounts, because compromising one is the shortest route from initial access to full control. Third, the privileges are invisible in daily use — nobody notices that the account they use for email can also delete the backup configuration, until somebody else uses it to do exactly that.
The remedy is not to remove administrators; the work still has to happen. It is to separate the holding of a privilege from the use of it. Administrators are made eligible for roles rather than permanently assigned them, activate a role when a task needs it, for a bounded period, with strong authentication and a recorded reason, and lose it automatically afterwards. The tenant then has very few accounts with standing high privilege at any moment, and a stolen credential from an ordinary working session grants ordinary rights.
That last point is the one that changes the risk most. Most compromises begin with something mundane — a phishing link, a token stolen from a browser, a reused password — and land in whatever session was active. If the session belonged to an administrator with standing Global Administrator, the attacker has the tenant. If it belonged to the same person working with no active elevation, the attacker has a mailbox and a problem.
Before designing anything, run one count: how many accounts currently hold Global Administrator permanently, and how many of those are also used for everyday email? Microsoft’s own guidance is to keep Global Administrators to a small handful, and the second number should be zero — administrative roles belong on separate accounts that do not receive mail or browse the web. In the UK tenants we review, both numbers are routinely higher than anyone expected, and the count alone is usually enough to get the project approved.
Admin access in UK Azure estates — the numbers
The figures below reflect what we find reviewing Microsoft cloud tenants for UK organisations of 20 to 500 staff, generally with Microsoft 365 in use and one or more Azure subscriptions.
The first figure matters because each additional permanent Global Administrator is an additional route to the whole tenant. Seven is a typical result of accumulation rather than design: the original installer, a couple of internal IT staff, two people at a previous managed service provider, a contractor from a project, and a director who asked for it once. Rarely does anyone need more than two or three, plus emergency access accounts.
The second figure is the most directly exploitable. An account that holds Global Administrator and also receives email is an account that phishing targets directly, with the highest possible payoff. Separating administrative identities from everyday ones is free, takes an afternoon, and removes the single most attractive target in the tenant.
The fourth figure is the one most reviews miss entirely, because it concerns identities that are not people. App registrations, service principals and automation accounts are routinely granted broad rights to make a deployment work and never revisited. They cannot be phished in the ordinary way, but their secrets and certificates can leak through code repositories, configuration files and old scripts, and a leaked secret for an identity with Owner on a subscription is equivalent to a stolen administrator password that never triggers an MFA prompt.
What reviews actually find
The chart below shows how often each finding appears in identity and access reviews of UK Microsoft cloud tenants. Most are accumulation rather than misconfiguration, which is why they are fixable without redesigning anything.
The fourth row is the one that should prompt immediate action because it is not a design question. Accounts belonging to people who have left, and supplier accounts from completed engagements, still holding administrative roles are pure exposure with no offsetting benefit. Nearly half of tenants have at least one. Removing them requires no new licences, no policy design and no change to how anyone works.
The emergency access row deserves comment because it cuts the other way. Tightening administrative access without working emergency accounts creates a different risk: a Conditional Access misconfiguration or an identity provider outage that locks every administrator out of the tenant. Emergency access accounts — at least two, cloud-only, protected with phishing-resistant authentication held physically secure, monitored for any use, and tested periodically — are the safety net that makes tightening everything else safe. Microsoft now requires MFA for sign-ins to its admin portals, so these accounts need a strong method such as a FIDO2 security key rather than being exempted from authentication entirely.
The final row reflects how quickly the threat has moved. Push notifications and one-time codes can be relayed by adversary-in-the-middle phishing kits that capture both password and session. For administrative accounts specifically, phishing-resistant methods — security keys, passkeys, certificate-based authentication — are the proportionate standard, and Conditional Access authentication strengths can require them for admin roles even where ordinary users remain on simpler methods.
What the controls cost in the UK
The capabilities in this guide depend on Microsoft licence tier, and the line that matters most is between plans that include Conditional Access and those that also include Privileged Identity Management. The figures below are indicative UK pricing at the time of writing, excluding VAT, alongside implementation effort. Microsoft adjusts prices and bundling, so confirm the current position against your own agreement.
| Item | Indicative UK cost | What it provides | Note |
|---|---|---|---|
| Entra ID P1, typically via Business Premium or E3 | Included in those plans | Conditional Access, authentication strengths, group-based access | Most UK SMEs on Business Premium already have this |
| Entra ID P2, via E5 or as an add-on | Around £6–8 per user per month as an add-on | Privileged Identity Management, access reviews, risk-based policies | Needed only for users who administer or are reviewed |
| FIDO2 security keys for admins | £25–60 per key | Phishing-resistant authentication for privileged accounts | Two per admin, one held as a spare |
| Initial review, role redesign and PIM rollout | £3,000–9,000 | Inventory, separation of admin accounts, eligible roles, policies | Scales with number of subscriptions and admins |
| Quarterly access reviews | £300–1,200 per quarter | Recertification of privileged and guest access | Largely automated once configured |
The second row is the one organisations most often over-buy. Privileged Identity Management needs P2 licensing for the people who use it — administrators eligible for roles, and those whose access is reviewed — not for every user in the business. A 150-person organisation with six administrators does not need P2 for 150 people, and pricing it that way is usually what makes the business case look unaffordable.
The first row is the one organisations most often under-use. Business Premium is very common in UK SMEs and includes Conditional Access, yet a large share of tenants on it run with Microsoft’s baseline security defaults or with a single all-users MFA policy and nothing aimed specifically at administrators. The capability is paid for and sitting idle.
Set against all of this, the cost of a compromised Global Administrator is not a line in a table: it is tenant-wide, includes the possibility of deleted backups and mailboxes, and frequently runs to the cost of full incident response and rebuild. The relevant comparison is a few hundred pounds a year in licensing for a handful of administrators against that.
Standing admin access against just-in-time elevation
The comparison below highlights just-in-time elevation. The qualification is that just-in-time done badly — every activation requiring an approver, durations too short to finish a task — is worse in practice than standing access, because it drives people back to shared accounts. The right column describes elevation designed for speed, which is what makes it sustainable.
Standing admin access
Roles permanently assigned
Just-in-time elevation
Eligible roles, activated when needed
The second row is the security case in one line. Most compromises land in whatever session the user had open, and with just-in-time elevation that session usually has no privileged role active. The attacker obtains a mailbox rather than a tenant, which turns a catastrophic incident into a serious but contained one.
The friction row is where implementations succeed or fail, and the next section is devoted to it. The honest version is that elevation adds a step to administrative work, and that step must be fast enough that nobody looks for a way around it. Organisations that require manager approval for every activation of every role typically find, within months, that someone has created a permanently privileged account “for emergencies” which has become the account everyone uses.
Where admin access design goes wrong
The grid below groups the recurring weaknesses. Badges reflect how much each widens the route from a single compromised credential to tenant-wide control.
The shared admin account row is rated high for two reasons that compound. Shared credentials cannot be tied to an individual, so the audit trail is worthless; and they almost always have MFA registered to one person’s phone or disabled entirely so that several people can use them. They are also the account people retreat to when elevation is too slow, which is why the friction design in the next section is a security control rather than a convenience.
Legacy authentication is rated high because it undermines everything else. Older protocols that do not support modern authentication cannot enforce MFA or Conditional Access, so an account protected by both can still be attacked through a legacy protocol if it remains enabled. Blocking legacy authentication tenant-wide is a standard Conditional Access policy and one of the highest-value single changes available.
On the middle card: role assignments to individuals rather than groups is the root of accumulation. When rights are granted to a person, they stay with the person through every role change. When they are granted to a group that represents a function, removing someone from the function removes the rights, and reviewing access means reviewing a handful of groups rather than hundreds of individual assignments.
Two permission systems, routinely confused
A great deal of muddle in Microsoft cloud access comes from not realising there are two separate role systems, governing different things, with different scopes and different role names.
Entra ID directory roles
These govern the identity platform and the Microsoft 365 services built on it: users, groups, licences, authentication settings, Exchange, SharePoint, Teams and so on. Global Administrator is the most powerful of them, and Microsoft provides many narrower roles — User Administrator, Helpdesk Administrator, Exchange Administrator, Security Reader, Billing Administrator and others — precisely so that most administrative tasks do not need Global Administrator at all. These roles are assigned at the tenant level, or scoped to administrative units in some cases.
Azure role-based access control
Azure RBAC governs Azure resources: subscriptions, resource groups, virtual machines, storage, networking, databases. Its built-in roles include Owner, Contributor, Reader and User Access Administrator, plus many service-specific roles. Assignments are made at a scope — management group, subscription, resource group or individual resource — and inherit downwards. Owner can do everything including granting access to others; Contributor can do everything except grant access; Reader can look.
Where they meet
The two systems are linked at one critical point. A Global Administrator can elevate their own access to manage all Azure subscriptions in the tenant, by granting themselves User Access Administrator at the root scope. That means Global Administrator is effectively also the master key to Azure, whether or not anyone has assigned Azure roles to the account. Any count of who can control your Azure estate that ignores Global Administrators is incomplete.
The practical consequences are twofold. First, review both systems: an organisation that has carefully restricted Azure RBAC but has seven Global Administrators has not restricted access to Azure. Second, match the role to the task in each system: the person who resets passwords needs Helpdesk Administrator, not Global Administrator, and the person who restarts a virtual machine needs a scoped role on that resource group, not Owner on the subscription.
Designing roles for least privilege without making work harder
Least privilege is easy to state and easy to make impractical. The design principles below keep it workable.
Assign to groups that represent functions
Create groups for the functions people perform — service desk, infrastructure engineering, security operations, finance and billing — and assign roles to those groups, ideally as eligible assignments in Privileged Identity Management. People join and leave groups as their jobs change; the roles follow automatically. Reviewing access then means reviewing a handful of group memberships, not hundreds of individual grants.
Scope Azure rights to resource groups, not subscriptions
Organise resources so that resource groups reflect ownership — a group per application or environment — and grant rights at that scope. A developer who maintains one application needs Contributor on its resource group, not on the subscription that also contains the finance database. This is considerably easier when resource organisation is designed early, which is part of the reason landing zone design matters; we cover that in our guide to Azure landing zones.
Prefer narrow built-in roles to Global Administrator and Owner
Before granting the most powerful role, check whether a narrower built-in role covers the task. Most routine Microsoft 365 administration is achievable with service-specific administrator roles, and most Azure operations with Contributor or service-specific roles at an appropriate scope. Custom roles are useful where built-ins do not fit, and should be built up from the actions actually needed rather than copied from Owner with a few things removed.
Separate admin accounts from everyday accounts
Administrators should hold privileged roles on a separate account that does not have a mailbox and is not used for browsing. This removes the account from the reach of most phishing and limits the damage of a compromised everyday session. It is free, takes an afternoon, and is the single highest-value change in this whole guide for most UK tenants.
None of these principles requires saying no to administrators. They require saying yes in a narrower, time-bound, recorded way, which is a far easier conversation with an IT team than a blanket restriction.
A programme to reduce standing access
The sequence below takes a typical UK tenant from accumulated standing access to just-in-time elevation over about eight weeks, ordered so that the safety net goes in before anything is tightened.
The first item is non-negotiable and the most frequently skipped. Every tightening step that follows carries a small risk of locking administrators out — a Conditional Access policy that excludes the wrong group, a PIM configuration error, an authentication method problem. Working emergency access accounts are what turn those mistakes into an inconvenience rather than a support case with Microsoft while the business waits.
Weeks two and three deliver most of the risk reduction before Privileged Identity Management is even switched on. Removing stale access, separating admin accounts and requiring phishing-resistant authentication for administrators is achievable on Business Premium licensing and closes the routes most commonly used in real incidents.
Just-in-time elevation without approval bottlenecks
Privileged Identity Management succeeds or fails on its configuration, and the failure mode is consistent: settings chosen for maximum control produce so much friction that administrators find a way round them. The principles below are what keep elevation fast enough that nobody needs a workaround.
Self-activation for most roles
For the majority of administrative roles, let eligible administrators activate the role themselves after satisfying MFA and recording a justification. The security benefit comes from the role being inactive by default, from strong authentication at activation, and from the audit trail — not from a second person clicking approve. Reserve mandatory approval for the very highest roles, typically Global Administrator and Privileged Role Administrator, where a second pair of eyes is worth the delay.
Durations matched to real work
An activation period of thirty minutes for a task that takes two hours means re-activating mid-task, which people experience as obstruction. Set durations by role according to the work it supports: an hour or two for routine service desk tasks, longer for a planned infrastructure change window. The aim is that one activation covers one piece of work.
No single approver
Where approval is required, assign several approvers so that elevation never waits for one person who is on leave, in a meeting or asleep. A process with one approver is a process with a single point of failure, and the response to that failure is usually a permanent assignment made “temporarily”.
A documented emergency route
Some situations genuinely need immediate high privilege outside normal process. The emergency access accounts serve this purpose, and their use should be rare, alerted, and reviewed afterwards. Having a sanctioned emergency route is what makes it reasonable to remove all the unsanctioned ones.
Pilot with the people who will use it
Run the configuration with the IT team for two weeks before enforcing it, and adjust durations and approval rules according to what actually caused friction. The people doing the work know which tasks happen at 6pm on a Friday and which roles they activate together; their input turns a policy that will be resented into one that will be used.
Measured outcome in well-configured tenants: routine activation takes well under a minute, administrators stop noticing it after the first fortnight, and the number of accounts holding standing high privilege falls to the emergency accounts alone.
Conditional Access aimed at administrators
Conditional Access policies for all users are covered in our guide to phishing-resistant MFA. The policies below are specific to privileged access and are worth configuring even where broader policies are already in place.
Require phishing-resistant authentication for admin roles. Using authentication strengths, require security keys, passkeys or certificate-based authentication whenever an account in a privileged role signs in, rather than accepting push notifications or one-time codes that can be relayed by phishing kits.
Block legacy authentication. Tenant-wide, because legacy protocols bypass MFA and Conditional Access entirely. This one policy closes a route that remains in use against UK organisations.
Require compliant or managed devices for admin sessions. Where device management is in place, require that privileged sessions come from managed, compliant devices. This substantially reduces the risk from a stolen session token used on an attacker’s machine.
Shorten admin session lifetimes. Sign-in frequency controls can require privileged users to reauthenticate more often than ordinary users, limiting how long a stolen session remains useful.
Treat Azure management as a distinct application. Policies can target the Azure management endpoints specifically, applying stronger requirements to anyone managing resources regardless of their directory role.
Each of these applies to privileged accounts, which are few, so the user impact is small. And each should be tested in report-only mode first and deployed with emergency access accounts appropriately handled, so that a policy error does not lock administrators out.
Benchmarks — admin access practice against what we find
The figures below show how often each practice is in place across UK organisations of 20 to 500 staff using Microsoft cloud services, at first review.
Adoption of privileged access controls in UK tenants
Eighty-eight per cent have MFA for administrators, which is the number most organisations report when asked about admin security. Twenty-seven per cent require a phishing-resistant method, and nineteen per cent use just-in-time elevation. The distance between those figures is the difference between administrators who are hard to phish with a password alone and administrators who are hard to compromise with the kits actually used against UK organisations.
The service principal figure at fourteen per cent is the one to act on after the human accounts are dealt with. These identities do not appear in most people’s mental model of who has access, rarely feature in reviews, and frequently hold rights that would never be granted to a person.
The number that defines your exposure
If one figure describes how exposed a tenant is to a single compromised credential, it is the proportion of privileged role assignments that are permanent rather than activated only when needed.
Eighty-one per cent permanent means that at almost any moment, nearly every administrator’s account is holding its full privileges — while reading email, joining calls, browsing and opening attachments. Every one of those activities is a route by which a session can be compromised, and with permanent assignment the compromised session carries everything.
Reducing the figure is the core of this guide. The target is not zero in every case — emergency accounts are permanent by design, and some low-privilege read roles may reasonably stay assigned — but for Global Administrator, Privileged Role Administrator, Owner on subscriptions and similar high-impact roles, the target is that nobody holds them permanently except the emergency accounts.
The figure is also a useful progress measure, because it is easy to calculate from the role assignment reports in Entra ID and Azure and it falls visibly as the programme proceeds. Reporting it monthly to whoever owns IT risk gives a single number that captures most of the work.
Non-human identities and supplier access
Two categories of access sit outside most people’s picture of who can administer the tenant, and both are frequently the most over-permissioned.
Service principals, app registrations and automation
Every application, script and integration that acts on Azure or Microsoft 365 does so through an identity — an app registration with a service principal, a managed identity, or an automation account. These are routinely granted broad rights during setup because that is the quickest way to make something work, and they are almost never revisited. A deployment pipeline with Owner on a subscription, an old reporting tool with read access to every mailbox, a backup product with directory-wide rights — each is an identity that cannot be phished but whose secret can leak.
Three controls address most of the risk. Prefer managed identities for Azure workloads, because they have no secret to leak — the platform handles the credential. Scope every non-human identity to the narrowest role and resource that the workload needs. And treat client secrets as short-lived: set expiry, rotate them, keep them in a key vault rather than in scripts or repositories, and alert on new credentials being added to existing app registrations, since adding a secret to a trusted application is a known technique for establishing persistence.
Managed service provider and supplier access
Many UK SMEs give their IT provider administrative access to the tenant, and historically that often meant standing Global Administrator for the provider’s staff. Microsoft’s partner model has moved towards granular delegated admin privileges, which allow a partner to be granted specific roles, for a defined period, rather than blanket rights. Supplier access should be reviewed on the same terms as internal access: which roles, for whom, for how long, and with what authentication.
As a managed service provider ourselves, we think it is worth saying plainly that supplier access deserves the same scrutiny as any other privileged access, including ours. A provider holding permanent Global Administrator across many customer tenants is an attractive target in its own right, and customers are entitled to ask what roles their provider holds, how those are protected, and whether they are time-bound. The right answer is narrow roles, phishing-resistant authentication, and just-in-time activation — the same standard this guide recommends for everyone else.
Guest accounts complete the picture. External collaborators invited into Teams or SharePoint occasionally end up with roles they should not hold, and guest accounts from finished projects persist indefinitely unless reviewed. Including guests in quarterly access reviews is the low-effort fix.
The 12-point admin access checklist
Items one to four are immediate and require no new licensing. Items five to nine implement least privilege and just-in-time elevation. Items ten to twelve keep it that way.
- Create two emergency access accounts and test them. Cloud-only, Global Administrator, protected by securely stored FIDO2 keys, monitored for any sign-in. Do this before tightening anything else.
- Remove roles from departed staff, finished suppliers and unused service principals. Immediate exposure reduction with no design work.
- Move admin roles to separate accounts with no mailbox. Remove the most attractive phishing target in the tenant. Free, and an afternoon’s work.
- Block legacy authentication tenant-wide. Legacy protocols bypass MFA and Conditional Access; closing them protects every other control.
- Require phishing-resistant authentication for privileged roles. Security keys, passkeys or certificates, enforced through Conditional Access authentication strengths.
- Reduce Global Administrators to a small handful. Use narrower built-in roles for routine work; most tasks do not need the master key.
- Convert permanent roles to eligible roles in Privileged Identity Management. Assigned to groups, self-activated with MFA and justification, approval only for the highest roles.
- Set activation durations to match real tasks, with several approvers where approval applies. Friction is the main reason just-in-time fails; design it out.
- Scope Azure rights to resource groups and replace broad service principal rights. Managed identities where possible, narrow roles elsewhere, secrets out of scripts and into a key vault.
- Alert on privileged role assignment, activation and emergency account use. Routed to someone who will see it promptly.
- Review supplier and partner access on the same terms as internal access. Which roles, for whom, for how long, protected how. Time-bound and narrow by default.
- Run quarterly access reviews of privileged roles and guests. The control that stops accumulation returning.
If only three items are completed, make them one, three and five. Emergency access accounts make every other change safe to attempt. Separating admin roles from everyday accounts removes the target most phishing aims at. And phishing-resistant authentication for privileged roles closes the route that adversary-in-the-middle kits use against ordinary MFA. All three are achievable on Business Premium without additional licensing and together address the majority of real-world admin compromises.
Admin access readiness — where most UK tenants sit
Combining the assessment areas gives an indication of how far a single compromised credential could reach. The gauge reflects a first review of a UK organisation of 20 to 500 staff with Microsoft 365 and at least one Azure subscription.
A score around thirty-four has a familiar composition. Basic MFA scores well because it has been pushed hard for years and Microsoft now enforces it for admin portals. Account hygiene scores poorly: too many Global Administrators, roles on everyday accounts, stale access from leavers and suppliers. Just-in-time elevation scores close to zero. Non-human identities score lowest because they are rarely examined at all.
The encouraging point is how much of the gap closes without spending anything. The first four checklist items, which typically move a tenant from the low thirties to the high fifties, require no licence beyond what most UK SMEs on Business Premium already hold. Privileged Identity Management needs P2 for the handful of administrators who use it, which is a modest cost for the largest single reduction in exposure available.
The caveat for very small organisations: a ten-person business with one administrator and no Azure subscriptions does not need the full apparatus. Separate admin account, phishing-resistant authentication, two emergency accounts and legacy authentication blocked will cover most of the risk, and Privileged Identity Management becomes worthwhile as the number of administrators and the complexity of the estate grow.
Common mistakes in Azure admin access
The errors below recur across UK tenants. Most are accumulation and convenience rather than misunderstanding.
- Holding admin roles on everyday accounts. Present in nearly two-thirds of tenants reviewed. The account that reads email should not be the account that can delete the tenant.
- Using Global Administrator for routine work. Most administrative tasks have a narrower built-in role. The master key should be rare and briefly held.
- Forgetting that Global Administrator controls Azure too. A Global Administrator can elevate to manage every subscription, so restricting Azure RBAC alone does not restrict access to Azure.
- Leaving former staff and suppliers in admin roles. Nearly half of tenants have at least one. Pure exposure, no benefit, and the fastest thing to fix.
- Tightening access without emergency accounts. A Conditional Access mistake or authentication outage then locks every administrator out. Build the safety net first.
- Requiring approval for every elevation. It creates a bottleneck that drives people back to shared or permanent accounts. Self-activation with MFA and justification for most roles; approval only for the highest.
- Setting activation durations too short. Re-activating mid-task feels like obstruction and invites workarounds. Match durations to the work.
- Ignoring service principals. Non-human identities with broad rights and long-lived secrets are frequently the most over-permissioned identities in the tenant.
- Leaving legacy authentication enabled. It bypasses MFA and Conditional Access, undermining every other control on the account.
- Treating supplier access as outside scope. Partner and provider roles deserve the same narrow, time-bound, strongly authenticated treatment as internal access.
Be wary of the “break-glass” account that is actually used. Emergency access accounts exist for genuine emergencies and should sign in almost never; any sign-in should raise an alert and a review. In many tenants an account originally created for emergencies has become the shared account the team uses when elevation is inconvenient, with credentials known to several people and MFA registered to one phone. That account combines the highest privilege with the weakest accountability, and it usually exists because the sanctioned elevation route was too slow. Fix the friction and then restore the emergency account to its proper purpose.
What this looks like in practice
A UK professional services firm with 110 staff ran Microsoft 365 Business Premium and two Azure subscriptions hosting a document management system and a reporting database. An internal IT manager and an external managed service provider shared administration. Nobody regarded access as a problem; MFA was enabled for everyone and there had never been an incident.
A review prompted by a cyber insurance renewal found nine permanent Global Administrators: the IT manager, two service desk staff, three people at the managed service provider, a former IT contractor whose engagement had ended eighteen months earlier, the finance director, and an account named admin@ shared by the service desk. Every one of them used push-notification MFA. Six of the nine were also everyday mail accounts. In Azure, a deployment service principal created during migration held Owner on both subscriptions, with a client secret that had never expired, stored in a script in a shared folder.
None of this had been chosen. Each grant had been made to solve a problem at the time and never revisited. The shared admin@ account existed because, according to the service desk, “it always works” — MFA on it was registered to the IT manager’s phone and he approved prompts when colleagues asked.
The remediation took about seven weeks. Two emergency access accounts were created with FIDO2 keys held in the office safe and tested. The contractor’s account was removed, the shared admin@ account disabled, and the finance director’s Global Administrator replaced with Billing Administrator, which covered what she actually did. Dedicated admin accounts were created for the remaining administrators, with security keys and a Conditional Access policy requiring phishing-resistant authentication for privileged roles. Entra ID P2 was added for the five administrators only, and all privileged roles converted to eligible assignments with self-activation for service desk roles and approval for Global Administrator from any of three approvers.
In Azure, the deployment service principal was replaced with a managed identity holding Contributor on the specific resource groups it deployed to, and the old secret revoked. The managed service provider’s access was moved to granular delegated roles appropriate to the work they performed, activated as needed.
The bit that changed my mind was the shared admin account. We all knew it existed and nobody thought of it as risky, because it was ours. When the review showed it could reset every password in the firm and that I was approving MFA prompts for it from my phone without really looking, it stopped feeling like a convenience. The new setup takes about thirty seconds to elevate and nobody has asked for the old account back.
Two points generalise. The first is that the most dangerous account in the tenant was the one created to work around friction, which is the pattern this guide keeps returning to: the shared account disappears only when sanctioned elevation is fast. The second is the service principal, which no one had considered an administrator at all and which held more Azure rights than any person in the firm.
At a glance — Azure identity and access management
| Question | Short answer |
|---|---|
| Why is standing admin access dangerous? | Any compromised session carries the full privilege. With just-in-time elevation, most sessions carry ordinary rights only. |
| Two role systems | Entra ID directory roles govern identity and Microsoft 365; Azure RBAC governs Azure resources at a scope |
| Where they meet | A Global Administrator can elevate to manage every Azure subscription — count them when assessing Azure access |
| How many Global Administrators? | A small handful plus emergency accounts. Median found in reviews is seven. |
| Separate admin accounts? | Yes. Privileged roles on accounts with no mailbox and no browsing; present in only about 36 per cent of tenants. |
| What authentication for admins? | Phishing-resistant: security keys, passkeys or certificates, enforced via Conditional Access authentication strengths |
| Emergency access accounts | At least two, cloud-only, FIDO2-protected, monitored, tested — created before tightening anything else |
| What licence does PIM need? | Entra ID P2 for administrators who use it, not the whole organisation. Conditional Access needs P1, included in Business Premium. |
| How to avoid approval bottlenecks | Self-activation with MFA and justification for most roles, approval only for the highest, several approvers, task-length durations |
| Azure RBAC scope | Resource group level where possible, assigned to groups rather than individuals |
| Non-human identities | Managed identities where possible, narrow roles, short-lived secrets in a key vault, alert on new credentials |
| Supplier access | Granular, time-bound delegated roles with strong authentication — reviewed like internal access |
| Legacy authentication | Block tenant-wide; it bypasses MFA and Conditional Access |
| Key progress metric | Share of privileged assignments that are permanent — typically 81 per cent, target near zero outside emergency accounts |
| Cheapest high-value changes | Emergency accounts, separate admin accounts, phishing-resistant MFA for admins — all achievable on Business Premium |
How Cloudswitched approaches admin access
Cloudswitched manages Microsoft 365 and Azure estates for UK organisations, and privileged access is one of the first things we review on any tenant we take on. In practice that means building and testing emergency access accounts before changing anything, inventorying both role systems including service principals and supplier access, removing what nobody needs, separating admin identities, enforcing phishing-resistant authentication for privileged roles, and implementing Privileged Identity Management with elevation designed to take seconds rather than waiting for an approver. We hold ourselves to the same standard: our own access to client tenants is narrow, time-bound and strongly authenticated, and clients are welcome to ask exactly what we hold.
Find out how far one stolen credential could reach
We count your standing admin access across Entra ID and Azure, remove what nobody needs, and implement just-in-time elevation that your IT team will actually use.
Talk to an Azure SpecialistFrequently Asked Questions
What is the difference between Entra ID roles and Azure RBAC?
They are separate permission systems governing different things. Entra ID directory roles — Global Administrator, User Administrator, Exchange Administrator and others — govern the identity platform and Microsoft 365 services. Azure RBAC roles — Owner, Contributor, Reader, User Access Administrator and service-specific roles — govern Azure resources and are assigned at a scope such as a subscription or resource group, inheriting downwards. They meet at one important point: a Global Administrator can elevate to manage every Azure subscription in the tenant, so any assessment of who controls Azure must include Global Administrators. Our guide to Microsoft Entra ID covers the identity platform more broadly.
How many Global Administrators should we have?
A small handful — typically two to four for day-to-day purposes, plus two emergency access accounts — and ideally none of them held permanently outside the emergency accounts. Microsoft’s own guidance is to keep the number low. In UK tenants we review the median is seven, usually through accumulation: installers, former contractors, provider staff and occasionally a director who asked once. Most routine work can be done with narrower built-in roles, which is the principle set out in our guide to least privilege access.
What is Privileged Identity Management?
It is the Entra ID capability for just-in-time privileged access. Instead of being permanently assigned a role, an administrator is made eligible for it and activates it when needed, for a bounded period, after satisfying MFA and recording a justification, optionally with approval. The role expires automatically afterwards. It also provides access reviews and an audit trail of who activated what, when and why. It requires Entra ID P2 licensing for the people who use it — administrators and those whose access is reviewed — not for every user.
Will just-in-time access slow our IT team down?
Only if it is configured for maximum control rather than for use. Self-activation with MFA and a justification takes well under a minute and covers most roles. Reserve approval for the very highest roles such as Global Administrator, assign several approvers so nobody waits for one person, and set activation durations that match real tasks so administrators are not re-activating mid-change. Piloting with the IT team for a fortnight before enforcement surfaces the friction points. Configured this way, administrators typically stop noticing it within weeks.
What are emergency access or break-glass accounts?
Accounts kept for situations where normal administrative access fails — a Conditional Access misconfiguration, an authentication outage, or a compromised admin account. Best practice is at least two, cloud-only, with Global Administrator, protected by phishing-resistant credentials such as FIDO2 keys held physically secure, monitored so any sign-in raises an alert, and tested periodically. Because Microsoft now requires MFA for admin portal sign-ins, they need a strong authentication method rather than an exemption. They should be created before any other tightening, because they make mistakes recoverable.
Do administrators need phishing-resistant MFA?
Yes, as the proportionate standard for privileged accounts. Push notifications and one-time codes can be captured and relayed by adversary-in-the-middle phishing kits that steal both password and session. Security keys, passkeys and certificate-based authentication resist that technique. Conditional Access authentication strengths can require a phishing-resistant method specifically for privileged roles while ordinary users remain on simpler methods, so the user impact falls only on the small number of administrators. Our guide to phishing-resistant MFA covers the options in detail.
Which Conditional Access policies matter most for admins?
Requiring phishing-resistant authentication for privileged roles; blocking legacy authentication tenant-wide because it bypasses MFA and Conditional Access; requiring compliant or managed devices for admin sessions where device management exists; shortening sign-in frequency for privileged users; and applying stronger requirements to Azure management endpoints. Each affects only a small number of accounts. Test in report-only mode first and ensure emergency access accounts are handled so that a policy error cannot lock everyone out.
What licences do we need?
Conditional Access requires Entra ID P1, which is included in Microsoft 365 Business Premium and E3 plans that many UK SMEs already hold. Privileged Identity Management and access reviews require Entra ID P2, included in E5 or available as an add-on, and only needed for the users who use those features. Much of the risk reduction — separate admin accounts, removing stale access, phishing-resistant authentication for admins, blocking legacy authentication — is achievable on P1. Confirm current licensing against your agreement, as Microsoft adjusts bundling.
How do we secure service principals and automation accounts?
Use managed identities for Azure workloads wherever possible, because they have no secret to leak. Grant every non-human identity the narrowest role on the narrowest scope its workload needs rather than Owner on a subscription. Set expiry on client secrets, rotate them, store them in a key vault rather than in scripts or repositories, and alert when new credentials are added to existing app registrations. Review service principal permissions at least annually; only about 14 per cent of tenants we review have done so in the past year.
Should our IT provider have Global Administrator?
Not permanently, and not by default. Microsoft’s partner model supports granular delegated admin privileges, allowing a provider to be granted specific roles for a defined period. A provider should hold the narrowest roles that cover the work they actually do, protected by phishing-resistant authentication and activated when needed. It is entirely reasonable to ask your provider what roles they hold in your tenant and how those are protected. A provider holding standing Global Administrator across many customers is an attractive target in its own right.
How does admin access relate to Cyber Essentials and cyber insurance?
Directly. Cyber Essentials includes user access control requirements, including limiting administrative privileges and requiring MFA for cloud services, and administrative accounts are a focus of the assessment. Cyber insurers increasingly ask specifically about MFA on administrative accounts and treat gaps as a reason to decline or load a quote. Being able to evidence separate admin accounts, phishing-resistant authentication and just-in-time elevation strengthens both, as covered in our guide to Cyber Essentials and insurance.
Where should we start if we can only do a little?
Three things, all achievable on Business Premium without new licences. Create and test two emergency access accounts so that further changes are safe. Move administrative roles to separate accounts with no mailbox, removing the most attractive phishing target in the tenant. And require phishing-resistant authentication for privileged roles through Conditional Access. Then remove roles from former staff and suppliers, which needs no design at all. Together these address most real-world admin compromises before Privileged Identity Management is even considered.
Related reading
More guidance on securing and governing UK business IT:
Least privilege that your IT team will actually use
Cloudswitched reduces standing admin access across Entra ID and Azure, enforces phishing-resistant authentication for privileged roles, and designs just-in-time elevation that takes seconds — so nobody needs a shared admin account again.
Talk to an Azure Specialist
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
