Admin access is still the weak spot in a lot of Microsoft 365 and Azure environments. I regularly come across global admins who run the whole tenant from the same laptop they use for everything else, and sometimes from unmanaged or personal devices. The risk isn't hard to see. One compromised browser or stolen session is enough for privilege escalation, data theft or a full tenant compromise. So access to admin portals has to be locked down, and Conditional Access gives us the controls to set up proper guardrails.

Admin portals need more protection than regular sign-ins

Whoever holds a directory role holds the keys to your cloud environment. Attackers know that and look for any weakness in admin access, be it a weaker MFA method, an outdated device or a browser nobody has locked down. Many of the tenants I see require MFA broadly, but only a few insist on compliant, trusted devices for admin work. That is exactly where it counts. Microsoft's own guidance now says admin access should be gated by compliant devices and phishing-resistant authentication strengths. If you want to secure admin portals, treat that as the baseline.

The policy targets directory roles and all admin portals

Everything rests on one Conditional Access policy, set up like this:

  • Targets only users in directory roles (role scope, not regular users)
  • Applies to all major admin portals ("Microsoft Administrator Portals", plus "Windows Azure Service Management API" for Azure management)

With this scope, every privileged admin is covered, including people in Exchange or SharePoint admin roles. API and PowerShell access to the Azure portal falls under the policy as well. The details are in the Microsoft documentation.

Many tenant admins are surprised by how many accounts (service accounts included) suddenly land in scope once you target directory roles instead of user groups. Go through the list of apps the policy covers before you switch anything on, so you don't lock people out by accident.

The grant controls require a compliant device and phishing-resistant authentication

The grant controls do the actual enforcement. I require both of the following:

  1. The device is marked as compliant (Intune-managed, all compliance baselines passed)
  2. Authentication meets phishing-resistant authentication strength (FIDO2, certificate-based authentication, or passwordless Authenticator; I go into more detail in my post on authentication strengths for admins)

This raises the bar right away. Admin roles can only be used from properly managed, secured workstations, and weak MFA methods no longer get through. Report-only mode is a must for the rollout. I always start there, check the logs to see who would have been blocked, and only then turn on enforcement. That's how you catch the surprises and the misconfigured devices before they hurt. I wrote more about testing policies safely here: [/blog/conditional-access-report-only-what-if-testing].

Break-glass accounts must stay outside the policy

An admin policy without a break-glass account is incomplete. At least one emergency access account, preferably two, has to be excluded from every Conditional Access policy that could block admin access, and that applies above all to policies requiring device compliance or strong authentication. If you skip this and a policy change goes wrong, you can lock out every admin you have. I put all break-glass accounts into a dedicated group and add that group as an exclusion to every relevant policy, always. My post on break-glass accounts covers a practical setup and regular health checks.

Pro tip: Once a policy is active, test break-glass access at least once a month. I've seen tenants where nobody had tested the break-glass account, and it turned out to be locked out at the very moment it was needed.

A compliant device is only the starting point for a PAW

A lot of people assume a compliant device is automatically a Privileged Access Workstation (PAW). It isn't. Passing Intune compliance alone doesn't get you there. I keep finding admins who use their normal email and browsing laptop as an admin workstation, sometimes with browser plugins installed or personal OneDrive in use. A real PAW is a dedicated, hardened device with no personal use and strict application controls, ideally kept separate from everyday productivity work. You need Intune compliance, but it only covers part of the picture. For proper admin security, design your PAW policy so it enforces both technical and operational separation.

The diagram shows the Conditional Access flow for admin portals

Here is the access flow for admin portals protected by Conditional Access:

graph TD
    Admin["Admin (directory role)"] --> Device["Device (compliance checked)"]
    Device --> MFA["Phishing-resistant authentication"]
    MFA --> Portal["Admin portal (CA policy)"]
    BreakGlass["Break-glass account"] --> Portal
    Portal --> Access["Access granted"]

Figure: Access to admin portals requires a compliant device and phishing-resistant MFA; the break-glass account is excluded.

Only admins on compliant devices with the right authentication get through. The one exception is the break-glass account, which bypasses the policy for emergencies.

I now treat this setup as non-negotiable in every tenant

Whenever I take over a new tenant, admin portals get locked to trusted, managed workstations, and that's not up for discussion. Setting up Conditional Access with device compliance and phishing-resistant authentication strengths takes little time compared to cleaning up after a compromise. The harder parts are turning PAWs into separate devices instead of a profile on someone's main laptop, and keeping break-glass accounts tested and ready to use. If your admin portals aren't protected this way yet, keep an eye on Microsoft's current announcements. Things are changing quickly, and attackers aren't slowing down either.