# Global Administrator role activation triggers an approval workflow
Without approval workflows, threat actors who compromise Global Administrator credentials through phishing, credential stuffing, or other authentication…
Source: https://maester.dev/docs/tests/ZTA.21817
:::note[Maester checks this too]
[CIS.M365.5.3.4](/docs/tests/CIS.M365.5.3.4) (Ensure approval is required for Global Administrator role activation), [CISA.MS.AAD.7.6](/docs/tests/CISA.MS.AAD.7.6) (Activation of the Global Administrator role SHALL require approval.) check the same setting. Running both reports it twice.
:::
## Overview
Without approval workflows, threat actors who compromise Global Administrator credentials through phishing, credential stuffing, or other authentication bypass techniques can immediately activate the most privileged role in a tenant without any other verification or oversight. Privileged Identity Management (PIM) allows eligible role activations to become active within seconds, so compromised credentials can allow near-instant privilege escalation. Once activated, threat actors can use the Global Administrator role to use the following attack paths to gain persistent access to the tenant:
- Create new privileged accounts
- Modify Conditional Access policies to exclude those new accounts
- Establish alternate authentication methods such as certificate-based authentication or application registrations with high privileges
The Global Administrator role provides access to administrative features in Microsoft Entra ID and services that use Microsoft Entra identities, including Microsoft Defender XDR, Microsoft Purview, Exchange Online, and SharePoint Online. Without approval gates, threat actors can rapidly escalate to complete tenant takeover, exfiltrating sensitive data, compromising all user accounts, and establishing long-term backdoors through service principals or federation modifications that persist even after the initial compromise is detected.
## Remediation
- [Configure role settings to require approval for Global Administrator activation](https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
- [Set up approval workflow for privileged roles](https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-approval-workflow?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | High |
| Effort to fix | Medium |
| Impact on users | Low |
| Pillar | Identity |
| Category | Application management |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Privileged Identity Management |
| Area | Privileged access |
| ATT&CK | [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts, [T1548.005](/docs/tests?mitre=T1548.005) Temporary Elevated Cloud Access |
| Licence | P2 |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.