Microsoft Admin Portals vs Graph API: Why Your Conditional Access Policy Has a Blind Spot
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The 'Microsoft Admin Portals' Conditional Access target gives security teams a convenient shorthand that implies comprehensive coverage of administrative access. The reality is narrower: it covers only browser-based access to the specific portal web applications. Any automation, scripting, or API-direct access to the same administrative capabilities authenticates against Microsoft Graph or Azure Resource Manager directly -- and those are separate application targets in Conditional Access. Attackers who steal admin credentials immediately pivot to API-based access because it bypasses browser-based CA controls and leaves fewer browser-side forensic traces.
What Microsoft Admin Portals Actually Covers
Microsoft documents the 'Microsoft Admin Portals' grouping as covering these specific applications: Microsoft Entra admin center (entra.microsoft.com), Microsoft 365 admin center (admin.microsoft.com), Azure portal (portal.azure.com), Exchange admin center (admin.exchange.microsoft.com), Microsoft Purview compliance portal (compliance.microsoft.com), Microsoft Defender portal (security.microsoft.com), Microsoft Intune admin center (intune.microsoft.com), and Power Platform admin center. The list is updated periodically -- check the Microsoft documentation for the current membership. What is not included: Microsoft Graph API (00000003-0000-0000-c000-000000000000), Azure Resource Manager / Windows Azure Service Management API (797f4846-ba00-4fd7-ba43-dac1f8f63013), Exchange Online PowerShell (fb78d390-0c51-40cd-8e17-fdbfab77341b), Azure Active Directory PowerShell (1b730954-1685-4b74-9bfd-dac224a7b894). Any CA policy targeting only 'Microsoft Admin Portals' leaves these critical API endpoints without the same protection.
Build a Comprehensive Admin Access CA Policy
A properly scoped CA policy for privileged admin access should target both the portal grouping and the individual API endpoints. Create one policy (or two linked policies for organizational clarity) with the following target applications: Microsoft Admin Portals (the existing grouping), Microsoft Graph API (app ID 00000003-0000-0000-c000-000000000000), Windows Azure Service Management API / Azure Resource Manager (app ID 797f4846-ba00-4fd7-ba43-dac1f8f63013), Exchange Online PowerShell (app ID fb78d390-0c51-40cd-8e17-fdbfab77341b), Microsoft Azure Active Directory PowerShell (app ID 1b730954-1685-4b74-9bfd-dac224a7b894). Apply the same controls to all: require phishing-resistant MFA (or at minimum, require MFA + compliant device for organizations not yet on phishing-resistant auth). Assign the policy to all privileged admin role holders and the privileged admin security group. Test in Report-Only mode for one week before enabling -- legitimate admin scripts and automation using these endpoints will appear in the CA log during the test, allowing you to identify service principals or automation accounts that need exemptions.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Graph API Operations That Bypass Portal-Only CA Policies
Concrete examples of high-impact operations that bypass a portal-only CA policy: User enumeration: Get-MgUser -All (reads all user objects via Graph API). Group manipulation: New-MgGroupMember / Remove-MgGroupMember (modifies group membership). Role assignment: New-MgDirectoryRoleMember (assigns directory roles -- critical for privilege escalation). Application credential manipulation: Add-MgServicePrincipalPassword (adds a secret to a service principal -- see the SP hidden credentials post). Conditional Access policy modification: Update-MgIdentityConditionalAccessPolicy (an attacker can disable CA policies via API -- bypassing the portal-only policy to disable the policy itself). Exchange mail access: Get-MgUserMailFolder, Get-MgUserMessage (reads email via Graph API, not Exchange admin center). These operations are all available to anyone with the appropriate directory role who can authenticate to Microsoft Graph -- even if a portal-only CA policy prevents them from logging into entra.microsoft.com.
Impact on Automation and Service Accounts
Adding Microsoft Graph and Azure Resource Manager to a CA policy affects service principals and automation accounts as well as human admins. Service principals are excluded from user-targeted CA policies (they authenticate via client credentials, not interactive flows), so the impact is primarily on: automation scripts run by humans (Azure Automation runbooks triggered by a person, PowerShell run interactively by an admin). The CA policy change may break interactive automation that uses an admin's credentials rather than a service principal. Before enabling, audit all automation that uses interactive OAuth (not client credential) flows against Microsoft Graph or Azure RM. Identify automation that should be migrated to use a service principal (with Conditional Access for workload identities applied separately). Human admins using PowerShell with interactive authentication (Az module, Microsoft.Graph module) will be prompted to satisfy the CA requirements at sign-in -- the first MFA prompt when starting a PowerShell session will cover the full session via the PRT or token lifetime.
Verify Coverage with the CA What-If Tool
Use the Entra ID Conditional Access What-If tool to verify your policies cover all access paths. In the Entra admin center: Security > Conditional Access > What If. Set: User = a specific privileged admin account. Cloud apps = Microsoft Graph (manually enter the app ID or name). IP address = an unusual IP address (e.g., 1.2.3.4, outside corporate range). Click What If. The result shows which CA policies would apply to this scenario. If the only policy that fires is one targeting 'Microsoft Admin Portals' -- and it fires for Graph too -- double-check by opening the policy definition and confirming Microsoft Graph is in the target apps list. If no policy covers Graph API access, the gap is confirmed. Repeat for Azure Resource Manager and Exchange Online PowerShell. Document the What-If results before and after applying the remediation to prove the gap was closed.
The bottom line
The 'Microsoft Admin Portals' Conditional Access target is a portal-browser shortcut, not a full coverage of administrative access. Add Microsoft Graph API and Azure Resource Manager explicitly to your admin access CA policy to close the API gap. Use the CA What-If tool to verify coverage for each administrative application endpoint. Any attacker who steals admin credentials will immediately try API access precisely because portal-only CA policies leave it uncontrolled.
Frequently asked questions
Does adding Microsoft Graph to the CA policy block all application access or just interactive admin access?
CA policies targeting Microsoft Graph apply to interactive OAuth flows where a user authenticates. Service principals (applications using client credentials) are not subject to user-targeted CA policies. Adding Microsoft Graph to the admin CA policy blocks human users from getting interactive Graph tokens that do not satisfy the CA requirements. It does not affect service principal client credential flows, which must be governed separately via Conditional Access for Workload Identities. Background sync processes, integration connectors, and automation using service principals are not affected.
If I add Microsoft Graph to the CA policy, does it affect all users accessing Microsoft Graph or only admins?
It depends on the user assignment in the CA policy. If the policy is assigned to a specific admin group (as it should be for a privileged access policy), only members of that group are affected by the Graph API requirement. Standard users also access Microsoft Graph (for Teams, OneDrive, Outlook via modern apps) but those are governed by separate CA policies. The admin-targeted Graph policy only fires for admin account sign-ins to Microsoft Graph -- standard users are not impacted. Verify the user scope in your CA policy before adding Graph to avoid unintended broad application.
What is the Windows Azure Service Management API and why is it important to include?
The Windows Azure Service Management API (also referred to as Azure Resource Manager in some contexts, app ID 797f4846-ba00-4fd7-ba43-dac1f8f63013) is the authentication endpoint for Azure subscription management operations performed via the Azure PowerShell (Az module) and Azure CLI. When an admin runs az login or Connect-AzAccount, they authenticate to this endpoint. Including it in the CA policy ensures that Azure subscription management via CLI and PowerShell requires the same strong authentication as the Azure portal. Without it, an attacker with stolen credentials can manage Azure resources via CLI even if the Azure portal is protected by a strong CA policy.
Can I use named locations to restrict API access to corporate IP ranges instead of requiring phishing-resistant MFA?
Named location restrictions (block API access from outside corporate IP ranges) provide meaningful protection and can be appropriate for some organizations. However, they have limitations: corporate IP ranges change, VPNs can be compromised, and split-tunnel VPN configurations may not route API traffic through corporate IPs. Phishing-resistant MFA provides stronger assurance because it is hardware-bound and cannot be replayed regardless of network location. For highest-privilege accounts, use both: require phishing-resistant MFA AND restrict to named corporate locations. For broader admin populations, phishing-resistant MFA alone is the recommended baseline.
How do I verify that my Conditional Access admin policy actually covers API access and not just portal access?
Use the Conditional Access What-If tool in the Entra admin center (Protection > Conditional Access > Policies > What If): set the user to an admin account, set the cloud app to Microsoft Graph, set the sign-in context to a non-compliant device or risky IP. The tool shows which policies apply and their effect. Additionally, test in practice: have an admin use the Microsoft Graph Explorer (graph.microsoft.com) with API permission enabled -- if the CA policy fires, Graph Explorer requests require MFA. For API-level testing without a browser, use a PowerShell token acquisition attempt via MSAL from a test machine: Invoke-MgGraphRequest and observe if MFA is triggered. If Graph Explorer or the PowerShell call proceed without MFA, the policy is not covering Graph API access.
What are the most common Conditional Access policy gaps that allow attackers to bypass MFA requirements for Microsoft admin portals?
The most commonly exploited CA gaps for admin portal bypass: targeting 'Microsoft Admin Portals' as the cloud app while not including the Microsoft Graph API separately -- Graph API calls from automation tools (Azure PowerShell, Azure CLI, custom scripts) authenticate independently and may not trigger the admin portal policy. Excluding 'Service accounts' or 'Break glass accounts' from MFA policies using exclusion groups, then an attacker adding their compromised account to that exclusion group (requires write access to the group, which Application Administrators or the group owner may have). Creating a CA policy that requires MFA but targeting 'Select cloud apps' with only the Exchange Online app ID, missing other admin portals. Sign-in frequency controls set to 'Every time' for admin portals but not enforcing re-authentication for token refreshes -- an attacker with a stolen refresh token can acquire new access tokens without triggering the sign-in frequency check. Verify coverage using the Entra ID CA policy report and Insights workbook: filter for sign-ins to admin portal app IDs that completed without MFA to find gaps.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.