Require MFA for Azure Management: Cloud Control Plane Protection

The Azure portal, Azure CLI, Azure PowerShell, and related management APIs represent the control plane for your cloud infrastructure. From here, an attacker can create or delete resources, modify network security groups, access storage accounts, deploy compute, and — critically in Microsoft 365 environments — manipulate Entra ID configuration, federation settings, and tenant-level security controls.

Azure management access deserves its own Conditional Access policy rather than relying on a general MFA policy that covers all apps. This is because the risk profile is different: a successful sign-in here gives access to infrastructure-level controls, not just data. Requiring MFA specifically for Azure management ensures that even if an attacker has a valid credential, they cannot reach the control plane without a second authentication factor.

This is also a common Microsoft Secure Score recommendation and a baseline in the Microsoft Entra security defaults framework.

• Attacker with stolen admin credentials accesses the Azure portal without an MFA challenge and modifies tenant-level Entra ID configuration
• Federation settings changed or new federated domains added, creating a backdoor that bypasses all Entra ID credential validation
• Conditional Access policies weakened or disabled via the portal before detection
• New Global Admin accounts or service principals created for persistent access
• Azure resources spun up for cryptomining, data exfiltration, or command and control infrastructure on the tenant's subscription
• Audit logs disabled or modified, reducing forensic visibility into the breach

All accounts accessing Azure management should require MFA. The main considerations are:

• Automated pipelines and CI/CD systems that interact with Azure management APIs should use service principals with certificate-based authentication, not interactive user credentials — these can be excluded from the interactive MFA requirement
• Break-glass accounts that may need to access the Azure portal during an identity provider failure should be individually listed as exclusions with monitoring in place

There is no legitimate reason for a human administrator to access the Azure portal or management APIs without MFA. Automated service principals should use non-interactive authentication methods that don't rely on MFA exclusions.

• Check whether a Conditional Access policy specifically targeting the Microsoft Azure Management application (or "Windows Azure Service Management API") exists and is enforced
• Identify which accounts currently access the Azure portal interactively and confirm they all have MFA registered
• Review whether any service principals or automation accounts use interactive user authentication for Azure management — these should be migrated to app-only authentication
• Confirm break-glass account handling before enforcing — ensure emergency access accounts are documented and have compensating monitoring
• Deploy in report-only mode first to identify any sign-ins that would be blocked

1. Create a Conditional Access policy targeting the "Microsoft Azure Management" cloud app (or Windows Azure Service Management API)
2. Set the grant control to Require MFA or, preferably, Require authentication strength set to phishing-resistant MFA
3. Deploy in Report-only mode and review sign-in impact after 5–7 days
4. Migrate any interactive service account access to app-only certificate-based authentication before enforcing
5. Enforce the policy with documented break-glass exclusions only
6. Monitor for blocked sign-in attempts and confirm no automated pipelines were disrupted

Microsoft: Conditional Access for Azure management

Microsoft: Authentication strengths in Conditional Access

Microsoft: Best practices for Azure RBAC

After enforcing this control, review these related areas:

• Require MFA for Administrators — deploy alongside this policy; admin portal MFA and Azure management MFA are complementary controls
• Unprotected Admin Portals — ensure the Entra admin center, Exchange admin center, and M365 admin center have equivalent Conditional Access coverage
• New Federated Domain Added — one of the first things an attacker with Azure portal access will attempt; ensure this alert is monitored
• User Created and Made Admin — another high-priority alert to pair with this control; attackers with portal access often create backdoor admin accounts
• Break-Glass Accounts — review emergency access account configuration as part of this rollout