| PA-1 |
nan |
Separate and limit highly privileged/administrative users |
Parent |
Secure access |
A maximum of 3 owners should be designated for your subscription |
Identify all high business impact accounts and limit the number of privileged administrative accounts across control plane, management plane, and data workload plane to minimize attack surface and blast radius from compromised credentials. |
Unauthorized access from over-privileged accountsAdversaries exploit highly privileged accounts with excessive permissions to gain unauthorized access to critical cloud resources, such as management consoles, APIs, or sensitive data stores. |
Initial Access (TA0001)Valid Accounts: Cloud Accounts (T1078.004): Compromising highly privileged accounts to authenticate to cloud consoles or APIs, accessing critical resources using stolen admin credentials. Privilege Escalation (TA0004)Abuse Elevation Control Mechanism: Cloud Infrastructure (T1548.005): Exploiting unscoped privileged accounts to escalate access by modifying IAM policies, gaining tenant-wide control. Persistence (TA0003)Account Manipulation: Additional Cloud Roles (T1098.001): Altering privileged accounts to add persistent roles, maintaining long-term access to cloud resources. |
Challenge:A financial services organization discovered excessive privileged access across both identity and resource layers: 47 Global Administrator accounts inMicrosoft Entra ID(most unused for over six months) and 89 users with Owner role at subscription scope in Azure, creating massive attack surface and violating least privilege principles. |
Must have |
AC-2(1), AC-2(7), AC-5, AC-6(1), AC-6(5) |
, 7.2.4, 8.2.2 |
, 6.7, 6.8 |
PR.AC-4, PR.AA-1 |
A.5.15, A.5.18, A.8.2 |
CC6.1, CC6.2 |
|
|
|
|
|
Blocked accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with owner permissions on Azure resources should be removed |
|
Without separation, a single compromised admin account can provide attackers with unrestricted access to modify IAM policies, deploy malicious workloads, or exfiltrate data across an entire tenant.Privilege escalation via compromised administrative credentialsAttackers leverage compromised privileged credentials to escalate access, gaining control over cloud tenants or critical infrastructure. |
|
Solution: Audit and reduce Entra privileged roles:Conducted comprehensive audit of all Global Administrator and Privileged Role Administrator assignments, identifying business justification for each account and reducing from 47 to 8 Global Administrators aligned with operational needs.Implement role-specific assignments in Entra:Transitioned users from Global Administrator to specific roles (User Administrator, Security Administrator, Compliance Administrator) based on actual job functions, using Microsoft Entra built-in roles to enforce granular permissions.Reduce Azure subscription-scope assignments:Audited all Owner and Contributor role assignments atAzure role-based access control (RBAC)level, reducing subscription-scope Owner assignments from 89 to 12 by scoping roles to specific resource groups based on team responsibilities.Implement resource group scoping:Transitioned development teams from subscription-level Contributor to resource group-level Contributor or specific built-in roles (Virtual Machine Contributor, Storage Account Contributor) matching actual needs.Establish unified governance:Created approval workflow requiring executive and security team sign-off for new privileged role assignments at both Entra and Azure resource levels, with quarterly access reviews and automated alerts for assignments exceeding approved scopes. |
|
|
|
|
|
|
|
|
|
|
|
|
There should be more than one owner assigned to your subscription |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In environments where administrative accounts are not isolated, a stolen credential can be used to manipulate role assignments, create new privileged accounts, or disable security controls, enabling tenant-wide compromise.Persistent access from stale or unmonitored privileged accountsAdversaries exploit stale or unmonitored privileged accounts to maintain persistent access, evading detection after initial compromise. |
|
Outcome:Organization dramatically reduced privileged account attack surface across identity and resource layers, eliminated stale administrative access, and established sustainable governance preventing privilege creep at both tenant and subscription levels. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Admin accounts that remain active after role changes or project completion provide attackers with long-term access to invoke APIs or modify r |
|
|
|
|
|
|
|
|
|
| PA-1 |
PA-1.1 |
Restrict and limit highly privileged/administrative users in Microsoft Entra |
Child |
Secure access |
A maximum of 3 owners should be designated for your subscription |
Identify all high business impact accounts and limit the number of privileged administrative accounts across control plane, management plane, and data workload plane to minimize attack surface and blast radius from compromised credentials. |
nan |
nan |
Restricting highly privileged administrative accounts prevents unauthorized tenant-wide access and limits blast radius from compromised credentials. Organizations with excessive global administrators face increased risk of breaches where attackers can manipulate IAM policies, deploy malicious workloads, or exfiltrate data across all resources. Limiting these accounts to only essential personnel enforces least privilege and reduces attack surface. Implement the following restrictions for cloud identity administrative roles: Identify critical built-in rolesThe mostcritical built-in rolesin Microsoft Entra ID are Global Administrator and Privileged Role Administrator, as users assigned to these roles can delegate administrator roles and directly or indirectly read and modify every resource in your cloud environment.Evaluate custom role permissionsReview custom roles in your identity management system for privileged permissions thatneed to be governedbased on your business needs, applying the same restrictions as built-in privileged roles.Extend restrictions beyond cloud identity systemsRestrict privileged accounts in on-premises identity systems, security tools, and system management tools with administrative access to business-critical assets (such as Active Directory Domain Controllers, security monitoring systems, and configuration management tools), as compromise of these management systems enables attackers to weaponize them for lateral movement to cloud resources. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Blocked accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There should be more than one owner assigned to your subscription |
|
|
|
|
|
|
|
|
|
|
|
| PA-1 |
PA-1.2 |
Restrict and limit highly privileged/administrative users at Azure resource level |
Child |
Secure access |
A maximum of 3 owners should be designated for your subscription |
Identify all high business impact accounts and limit the number of privileged administrative accounts across control plane, management plane, and data workload plane to minimize attack surface and blast radius from compromised credentials. |
nan |
nan |
Limiting privileged roles at the resource level prevents unauthorized access to cloud resources and enforces least privilege across subscriptions and resource groups. Excessive Owner or Contributor assignments at subscription scope enable attackers to manipulate resources, modify security controls, or escalate privileges after initial compromise. Restricting these assignments reduces blast radius and ensures administrative access aligns with operational responsibilities. Apply the following restrictions for cloud resource-level administrative roles: Restrict critical built-in resource rolesAzure hasbuilt-in rolesthat grant extensive permissions (Owner grants full access including role assignment; Contributor grants full resource management; User Access Administrator enables user access management), requiring the same restrictions as tenant-level privileged roles.Govern custom resource rolesReview and restrict custom roles at the resource level with privileged permissions assigned from business needs, ensuring they don't inadvertently grant excessive access through permission combinations.Control billing and subscription management rolesFor customers with Enterprise Agreement, restrict Azure Cost Management and Billing administrative roles (Account Owner, Enterprise Administrator, Department Administrator) as they can directly or indirectly manage subscriptions, create/delete subscriptions, and manage other administrators. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Blocked accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There should be more than one owner assigned to your subscription |
|
|
|
|
|
|
|
|
|
|
|
| PA-2 |
nan |
Avoid standing access for user accounts and permissions |
Parent |
Secure access |
Management ports of virtual machines should be protected with just-in-time network access control |
Implement just-in-time privileged access mechanisms to assign temporary, time-bound permissions instead of persistent standing privileges, preventing malicious or unauthorized users from exploiting always-on administrative access after compromised credentials or insider actions. |
Unauthorized access from persistent privileged accountsStanding high-privilege roles enable adversaries to misuse compromised credentials for unauthorized access to cloud resources, such as invoking APIs to exfiltrate data or deploy malicious workloads, exploiting always-on permissions without temporal restrictions.Privilege escalation via compromised credentialsCompromised accounts with persistent elevated roles allow attackers to escalate privileges by modifying IAM policies, such as assigning tenant-wide administrative roles, exploiting the absence of time-limited access to gain control over subscriptions or resources.Prolonged exposure from stale accessUnrevoked roles after task completion create extended exposure windows, allowing adversaries to exploit stale credentials for unauthorized access, such as extracting data from storage accounts, due to forgotten or unmanaged permissions. |
Initial Access (TA0001)Valid Accounts: Cloud Accounts (T1078.004): Compromising accounts with standing high-privilege roles to authenticate to cloud management consoles or APIs, using persistent credentials to access resources without time-bound restrictions. Privilege Escalation (TA0004)Abuse Elevation Control Mechanism: Cloud Infrastructure (T1548.005): Exploiting persistent privileged roles to escalate access by modifying IAM policies, leveraging always-on permissions to gain unauthorized control over subscriptions. Persistence (TA0003)Account Manipulation: Additional Cloud Roles (T1098.001): Modifying role assignments to maintain persistent access by adding high-privilege roles to compromised accounts, exploiting lack of time-limited access. |
ChallengeA global retail company had 156 users with standing Owner and Contributor roles at subscription scope, creating persistent high-privilege access that remained active 24/7 despite infrequent administrative needs. Solution Implement PIM for Azure resourcesConverted all standing Owner and Contributor role assignments to eligible roles in PIM, requiring users to activate roles only when performing administrative tasks with 4-hour time-bound activation.Configure approval workflowsEstablished multi-stage approval for Owner role activation requiring resource owner and security team approval, with automated MFA enforcement and justification requirements for all privileged access requests.Enable JIT VM accessDeployed Azure Bastion with Defender for Cloud JIT controls restricting RDP/SSH access to production virtual machines, allowing access only through approved time-bound requests eliminating persistent management port exposure. OutcomeOrganization eliminated persistent privileged access, substantially reduced attack surface from standing administrative permissions, and established automated expiration preventing forgotten elevated access. |
Must have |
AC-2(1), AC-5, AC-6(2), AC-6(5), AC-16 |
, 7.2.5, 8.2.8 |
, 6.8 |
PR.AC-4, PR.AA-1 |
A.5.15, A.5.18, A.8.2 |
CC6.1, CC6.3 |
| PA-2 |
PA-2.1 |
Use just in time (JIT) control for Azure resource access |
Child |
Secure access |
Management ports of virtual machines should be protected with just-in-time network access control |
Implement just-in-time privileged access mechanisms to assign temporary, time-bound permissions instead of persistent standing privileges, preventing malicious or unauthorized users from exploiting always-on administrative access after compromised credentials or insider actions. |
nan |
nan |
Just-in-time privileged access prevents persistent administrative permissions that enable unauthorized access after credential compromise. Organizations with standing privileged roles face extended exposure windows where attackers can exploit always-on permissions for data exfiltration, privilege escalation, or lateral movement without time constraints. Implementing JIT access ensures permissions automatically expire, limiting blast radius and reducing attack surface. Enable just-in-time access through the following approach: Deploy Privileged Identity ManagementEnable just-in-time (JIT) privileged access to Azure resources and Microsoft Entra ID usingMicrosoft Entra Privileged Identity Management (PIM), where users receive temporary permissions to perform privileged tasks that automatically expire, preventing unauthorized access after permissions expire and generating security alerts for suspicious activity.Configure eligible role assignmentsAdmins assign eligible roles to users or groups via PIM, specifying who can request privileged roles and defining activation requirements including approval workflows, MFA requirements, and time-bound durations (typically 1-8 hours).Establish activation workflowsUsers request role activation through the Azure portal or PIM API when privileged access is needed, providing justification and time window, with approvers reviewing requests based on policies and either granting or denying access, while PIM logs all actions for audit purposes.Im |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| PA-3 |
nan |
Manage lifecycle of identities and entitlements |
Parent |
Secure access |
No Azure Policy available |
Use automated processes or technical controls to manage the complete identity and access lifecycle including request, review, approval, provisioning, and deprovisioning, ensuring permissions remain aligned with business needs and are revoked when no longer required. |
Unauthorized access due to excessive permissionsIdentities granted more access rights than required, violating least privilege and increasing the attack surface.Stale or orphaned access from unmanaged accountsPermissions retained after they are no longer needed or accounts left active after user departure, enabling potential exploitation.Insider threats from misconfigured or unmonitored accessAuthorized users misusing permissions due to misconfigured policies or lack of oversight, including bypassing approval processes.Non-compliance with regulatory standardsFailure to enforce least privilege, access auditing, or timely deprovisioning, risking violations of standards like GDPR, HIPAA, SOC 2, or ISO 27001.Human error in access managementManual processes leading to incorrect permission grants, overlooked deprovisioning, or misconfigured approval chains.Lack of auditability and traceabilityAbsence of proper logging and documentation, hindering tracking of access requests, approvals, or provisioning, delaying breach detection. |
Initial Access (TA0001)exploiting valid accounts (T1078.004) by leveraging compromised or stale cloud credentials to authenticate to APIs or management consoles, enabling unauthorized access to cloud resources. Privilege Escalation (TA0004)abusing elevation control mechanisms (T1548.005) by exploiting misconfigured RBAC policies or excessive permissions to assign elevated roles from a resource group role. Persistence (TA0003)manipulating accounts (T1098.001) by modifying IAM policies or disabling MFA to embed persistent access, allowing adversaries to retain unauthorized control over cloud resources. Exfiltration (TA0010)accessing data from cloud storage (T1530) using over-privileged accounts to enumerate and retrieve sensitive data from storage buckets or databases. Defense Evasion (TA0005)impairing defenses (T1562.001) by disabling cloud audit logging or monitoring with high-privilege accounts, concealing malicious actions like resource modifications. |
ChallengeA multinational enterprise with 8,500 employees across 40 countries/regions struggled with manual access provisioning requiring 3-5 business days per request, creating operational delays and accumulating 450+ orphaned accounts from departed employees with active privileged access. Solution Implement entitlement managementDeployedMicrosoft Entra ID entitlement managementwith access packages for all Azure resource groups, establishing automated workflows for request, multi-stage approval, and time-bound access with automatic expiration.Configure lifecycle workflowsCreated automatedjoiner/mover/leaver workflowstriggering immediate provisioning for new employees, access updates for role changes, and instant deprovisioning upon termination with removal from all access packages and privileged groups.Deploy Permissions ManagementImplemented continuous monitoring detecting unused permissions across multi-cloud infrastructure, automatically right-sizing overprovisioned roles and generating alerts for privilege creep requiring review. OutcomeOrganization reduced access provisioning time from 3-5 days to under 2 hours, eliminated all orphaned accounts through automated deprovisioning, and achieved 100% access request auditability with complete approval trail documentation. |
Should have |
AC-2, AC-2(1), AC-2(3), AC-2(4), IA-4 |
, 7.2.4, 8.1.3, 8.1.4 |
, 5.2, 5.3, 6.1 |
PR.AA-3, PR.AC-1, PR.AC-4 |
A.5.15, A.5.16, A.5.17, A.5.18 |
CC6.1, CC6.2, CC6.3 |
| PA-3 |
PA-3.1 |
Manage lifecycle of identities and entitlements |
Child |
Secure access |
No Azure Policy available |
Use automated processes or technical controls to manage the complete identity and access lifecycle including request, review, approval, provisioning, and deprovisioning, ensuring permissions remain aligned with business needs and are revoked when no longer required. |
nan |
nan |
Automated identity lifecycle management prevents orphaned accounts, unrevoked permissions, and excessive access that persist after role changes or employee departures. Organizations relying on manual access management face delayed deprovisioning, inconsistent approval processes, and lack of auditability, creating security gaps where unauthorized users exploit stale credentials for data exfiltration or privilege escalation. Implementing automated workflows ensures access aligns with current business needs through consistent request, approval, provisioning, and expiration processes. Establish automated identity and access lifecycle management through the following approach: Plan access management objectives and scopeDefine access needs by identifying Azure resource groups requiring access management, including specific roles (e.g., Owner, Contributor) and user or workload identities, establishing boundaries for governance and approval workflows.Assign responsibilitiesDesignate Global Administrators, Identity Governance Administrators, or catalog owners to manageentitlement managementand access packages, delegating to resource owners or project managers who review and approve access requests for specific Azure resource groups.Set up entitlement management for access request workflowsCreate catalogs in Microsoft Entra admin center to organize related resources and access packages, adding specific Azure resource groups with their roles (e.g., Contributor, Reader) as catalog resour |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| PA-4 |
nan |
Review and reconcile user access regularly |
Parent |
Monitor and governance |
Blocked accounts with owner permissions on Azure resources should be removed |
Conduct periodic audits of privileged account entitlements to verify that access permissions are strictly aligned with authorized administrative functions, ensuring compliance with the principle of least privilege. |
Unauthorized access due to excessive permissionsIdentities granted more access rights than required, violating least privilege and increasing the attack surface.Stale or orphaned access from unmanaged accountsPermissions retained after they are no longer needed or accounts left active after user departure, enabling potential exploitation.Insider threats from misconfigured or unmonitored accessAuthorized users misusing permissions due to misconfigured policies or lack of oversight, including bypassing approval processes.Non-compliance with regulatory standardsFailure to enforce least privilege, access auditing, or timely deprovisioning, risking violations of standards like GDPR, HIPAA, SOC 2, or ISO 27001.Human error in access managementManual processes leading to incorrect permission grants, overlooked deprovisioning, or misconfigured approval chains.Lack of auditability and traceabilityAbsence of proper logging and documentation, hindering tracking of access requests, approvals, or provisioning, delaying breach detection. |
Initial Access (TA0001)exploiting valid accounts (T1078.004) by leveraging compromised or stale cloud credentials, such as over-privileged service accounts, to authenticate to APIs or management consoles, enabling unauthorized access to cloud resources without triggering alerts. Privilege Escalation (TA0004)abusing elevation control mechanisms (T1548.005) by exploiting misconfigured RBAC policies or excessive permissions to assign elevated roles, such as tenant-wide administrative access, from a resource group role. Persistence (TA0003)manipulating accounts (T1098.001) by modifying IAM policies or disabling MFA to embed persistent access, allowing adversaries to retain unauthorized control over cloud resources like storage or compute. Exfiltration (TA0010)accessing data from cloud storage (T1530) using over-privileged accounts to enumerate and retrieve sensitive data from storage buckets or databases, exploiting unrevoked or poorly validated permissions. Defense Evasion (TA0005)impairing defenses (T1562.001) by disabling cloud audit logging or monitoring with high-privilege accounts, concealing malicious actions like resource modifications or data access. |
ChallengeA technology company with 650 privileged accounts discovered during annual audit that 89 accounts (14%) had not been used in over 180 days, while 34 accounts retained elevated permissions despite users changing to non-administrative roles. Solution Implement quarterly access reviewsDeployedMicrosoft Entra PIM access reviewsfor all Azure subscriptions and Entra roles with quarterly recurring schedules, assigning resource owners as primary reviewers and security team as secondary reviewers for oversight.Enable automated detectionConfigured PIM alerts for excessive role assignments (>8 Global Administrators) and accounts unused for 90+ days, integrating withMicrosoft Sentinelfor real-time notifications to security operations center.Establish remediation workflowsCreated standardized response procedures requiring reviewers to provide justification for maintaining access or immediately revoking unnecessary permissions, with automatic escalation for overdue reviews to governance team. OutcomeOrganization identified and removed 89 stale accounts and right-sized 34 over-provisioned accounts, reduced Global Administrator count from 12 to 6, and achieved 100% quarterly review completion rate with documented justifications. |
Must have |
AC-2(3), AC-2(7), AC-6(7), IA-4 |
, 8.1.4, 8.2.6 |
, 5.4, 6.2 |
PR.AA-3, PR.AC-6, DE.CM-3 |
A.5.18, A.8.2, A.8.3 |
CC6.1, CC6.2, CC6.3 |
|
|
|
|
|
Blocked accounts with read and write permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with read permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with write permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
| PA-4 |
PA-4.1 |
Review and reconcile user access regularly |
Child |
Monitor and governance |
Blocked accounts with owner permissions on Azure resources should be removed |
Conduct periodic audits of privileged account entitlements to verify that access permissions are strictly aligned with authorized administrative functions, ensuring compliance with the principle of least privilege. |
nan |
nan |
Review all privileged accounts and access entitlements in Microsoft Azure, encompassing Azure tenants, Azure services, virtual machines (VMs)/Infrastructure as a Service (IaaS), CI/CD processes, and enterprise management and security tools. UseMicrosoft Entra ID access reviewsto evaluate Microsoft Entra roles, Azure resource access roles, group memberships, and access to enterprise applications. Microsoft Entra ID reporting provides logs to identify stale accounts or accounts unused for a specified period. Additionally, Microsoft Entra Privileged Identity Management (PIM) can be configured to send alerts when an excessive number of administrator accounts are created for a specific role and to detect administrator accounts that are stale or misconfigured. Plan the access review scope and objectivesIdentify which Azure resources (e.g., subscriptions, resource groups, VMs) and Microsoft Entra roles (e.g., Global Administrator, User Administrator) require review, establishing review frequency (e.g., monthly, quarterly) based on security requirements and regulatory needs. Assign review responsibilitiesDesignate resource owners, security teams, or role administrators to conduct reviews, ensuring reviewers have appropriate permissions in PIM. Set up access reviews in Microsoft Entra PIMCreate access reviews for Entra roles by selecting specific Microsoft Entra roles to review, specifying reviewers (individuals, group owners, or self-reviews), and setting review parameters including |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Blocked accounts with read and write permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with owner permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with read permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Guest accounts with write permissions on Azure resources should be removed |
|
|
|
|
|
|
|
|
|
|
|
| PA-5 |
nan |
Set up emergency access |
Parent |
Secure access |
No Azure Policy available |
Set up emergency access to ensure that you are not accidentally locked out of your critical cloud infrastructure in an emergency. Emergency access accounts should be rarely used and can be highly damaging if compromised, but their availability is critically important for scenarios when they are required. |
Administrative lockout from cloud tenant managementLoss of access to a cloud tenant when all privileged accounts are blocked by MFA failures, federation outages, or compromised/deleted accounts, preventing IAM policy updates or resource management.Unauthorized access to highly privileged accountsWeakly secured credentials or unrestricted access to emergency accounts enables adversaries to authenticate to cloud management consoles or APIs, facilitating privilege escalation or data exfiltration.Insider threats via misused emergency accessEmergency accounts bypassing standard controls are misused by authorized personnel for non-emergency tasks, risking credential exposure or unauthorized access.Lack of auditability for emergency accessInadequate logging or monitoring of emergency account activity prevents detection of unauthorized use, delaying incident response.Operational failure from untested emergency accountsUntested emergency accounts with outdated credentials or misconfigured IAM bindings fail during crises, preventing access restoration and exacerbating lockouts. |
Initial Access (TA0001) - Valid Accounts: Cloud Accounts (T1078.004)Leveraging compromised emergency access accounts with high privileges to authenticate to cloud management consoles or APIs, exploiting insecurely stored credentials. Privilege Escalation (TA0004) - Abuse Elevation Control Mechanism: Cloud Infrastructure (T1548.005)Over-privileged emergency accounts with excessive IAM roles are exploited to escalate access, allowing adversaries to modify policies or assign tenant-level administrative permissions. Persistence (TA0003) - Account Manipulation: Additional Cloud Credentials (T1098.001)Modifying emergency account configurations, such as adding persistent roles or disabling MFA, to maintain unauthorized access. Defense Evasion (TA0005) - Impair Defenses: Disable or Modify Cloud Logs (T1562.008)Using emergency accounts to disable audit logging or monitoring in cloud environments, concealing malicious actions. Credential Access (TA0006) - Steal Application Access Token (T1528)Stealing emergency account credentials stored insecurely to authenticate to cloud services. |
ChallengeA multinational financial services organization experienced a federation outage affecting their hybrid identity infrastructure, discovering they had no functioning emergency access path to Microsoft Entra ID. All 15 Global Administrators relied on federated authentication, leaving the organization completely locked out during the incident requiring Microsoft support escalation to regain access after 6 hours of downtime. Solution Create emergency access accountsProvisioned two cloud-only emergency access accounts (EmergencyAccess01@contoso.onmicrosoft.com, BreakGlass02@contoso.onmicrosoft.com) with permanent Global Administrator role assignments in Microsoft Entra ID, ensuring accounts were not federated or synchronized from on-premises Active Directory to eliminate dependency on federation infrastructure.Implement passwordless authentication with dual controlConfigured EmergencyAccess01 withFIDO2 passkey authenticationand BreakGlass02 withcertificate-based authenticationfor credential diversity, storing FIDO2 security keys in two separate fireproof safes at headquarters and disaster recovery site, while certificate private keys remained on hardware security modules accessible only to C-level executives with dual-person authorization requirements documented in emergency response procedures.Configure Conditional Access exclusions strategicallyCreated named location exclusion policy for EmergencyAccess01 exempting it from all Conditional Access policies including MFA requirements, while BreakGlass02 remained subject to phishing-resistant MFA requirements providing balanced security approach ensuring at least one account guaranteed access during any authentication service disruption.Deploy Azure Monitor alerting for emergency account activityConfiguredLog Analytics workspacewith custom alert rules querying SigninLogs for emergency account object IDs, triggering critical severity alerts (Sev 0) with immediate email and SMS notifications to security operations center, CISO, and IT director whenever emergency accounts authenticated, with alert query:SigninLogs | project UserId | where UserId == "00aa00aa-bb11-cc22-dd33-44ee44ee44ee" or UserId == "11bb11bb-cc22-dd33-ee44-55ff55ff55ff"evaluating every 5 minutes.Establish quarterly validation and testing proceduresCreated documented quarterly drill schedule requiring designated security team members to retrieve credentials from secure storage, authenticate using emergency accounts, perform test administrati |
Must have |
AC-2, CP-2, CP-9, IR-4, IA-4 |
, 8.6.1, 12.10.1 |
, 6.5, 17.9 |
PR.IP-10, RS.CO-3, RS.RP-1 |
A.5.24, A.5.29, A.17.1 |
CC6.1, CC7.4, CC9.1 |
| PA-5 |
PA-5.1 |
Setup emergency access |
Child |
Secure access |
No Azure Policy available |
Set up emergency access to ensure that you are not accidentally locked out of your critical cloud infrastructure in an emergency. Emergency access accounts should be rarely used and can be highly damaging if compromised, but their availability is critically important for scenarios when they are required. |
nan |
nan |
Emergency access accounts ("break-glass" accounts) prevent complete administrative lockout during MFA failures, federation outages, or compromised administrative accounts. Without these accounts, organizations risk losing tenant access when normal authentication paths fail. Implementing emergency access ensures business continuity while maintaining security through controlled credential management, monitoring, and testing. Establish emergency access accounts through the following structured approach: Create emergency access accountsConfigure at least two cloud-only accounts (not federated) with Global Administrator role in Microsoft Entra ID, using descriptive names (e.g., EmergencyAccess01, BreakGlass02) that clearly identify their purpose, ensuring accounts are not assigned to specific individuals and remain dedicated exclusively for emergency scenarios.Secure credentials with dual controlGenerate strong, randomly generated passwords of at least 32 characters configured to never expire, implementing dual control mechanisms by splitting credentials into multiple parts stored in separate secure physical locations (e.g., fireproof safes at different sites) accessible only to authorized C-level executives or security leadership, documenting retrieval procedures requiring multi-person approval.Configure Conditional Access exclusionsExclude at least one emergency account from allConditional Access policiesand MFA requirements to guarantee access during service disruptions, while |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| PA-6 |
nan |
Use privileged access solution |
Parent |
Secure access |
No Azure Policy available |
Secured, isolated privileged access solutions are critically important for the security of sensitive roles like administrator, developer, and critical service operator. |
Credential compromise via malware or phishing on administrative workstationsAttackers deploy keyloggers, phishing pages, or memory-scraping malware on unhardened workstations to capture privileged credentials, such as API tokens or passwords, enabling unauthorized access to cloud management consoles or APIs. |
Credential Access (TA0006)Stealing credentials (e.g., passwords, API tokens) from unhardened administrative workstations via keyloggers, phishing, or memory-scraping malware (T1552.001), using captured credentials to authenticate to cloud management consoles or APIs for unauthorized access. Privilege Escalation (TA0004)Exploiting local admin rights or unpatched vulnerabilities on non-PAW devices to escalate privileges (T1068), manipulating IAM roles or access tokens to gain tenant-wide administrative access, such as modifying cloud resource policies. Initial Access (TA0001)Targeting exposed RDP/SSH endpoints on cloud resources via brute force or session interception (T1133), using compromised admin sessions from unsecured remote connections to execute commands or access sensitive data. Persistence (TA0003)Establishing persistent access by deploying malware or backdoors on unhardened workstations (T1547.001), maintaining control over admin devices to repeatedly access cloud IAM configurations or deploy malicious workloads. Defense Evasion (TA0005)Disabling cloud logging or monitoring services via compromised admin accounts on non-PAW devices (T1562.008), concealing unauthorized IAM changes or resource manipulations by suppressing audit trails. |
ChallengeA healthcare organization discovered 23 administrators using personal laptops and standard corporate workstations with unrestricted local admin rights to manage production Azure resources containing protected health information (PHI), exposing privileged credentials to malware and phishing attacks without endpoint protection, application control, or activity monitoring, creating HIPAA compliance risks and enabling potential credential theft. Solution Deploy dedicated PAW infrastructureProvisioned 25 dedicated Windows 11 Enterprise devices as PAWs enrolled in Microsoft Intune with strict device compliance policies, applied Microsoft Defender for Endpoint security baseline removing all local administrator rights, enabled BitLocker full disk encryption with TPM protection, and configured Windows Defender Application Control (WDAC) whitelisting only approved administrative tools (Azure portal, PowerShell 7, Azure CLI, Visual Studio Code, Microsoft Remote Desktop) blocking all other application execution including Office productivity suites and web browsers except Edge in application guard mode.Implement comprehensive device hardeningConfigured Intune device configuration profiles enforcing security policies including mandatory 5-minute screen lock with Windows Hello authentication, blocked USB storage devices and external media, disabled camera and microphone access, prevented local credential caching, deployed Company Portal for managed app delivery restricting installations to approved administrative tools, and integrated Microsoft Defender for Cloud Apps blocking access to consumer cloud storage services (Dropbox, personal OneDrive, Gmail) through network traffic inspection.Enable advanced threat protectionIntegrated Microsoft Defender for Endpoint on all PAWs with attack surface reduction rules blocking Office macros, script-based threats, credential harvesting tools (Mimikatz), and suspicious process injections, configured endpoint detection and response (EDR) with automated investigation and remediation for high-severity threats, enabled tamper protection preventing security control disablement, and established security operations center (SOC) alerting with 15-minute response SLA for critical PAW security events.Enforce phishing-resistant authenticationCreated Microsoft Entra Conditional Access policies requiring FIDO2 security key authentication for all privileged accounts accessing Azure portal and Microsoft 365 from PAWs, implemented device c |
Must have |
AC-2, AC-3, AC-6, IA-2, IA-5, IA-8, SI-4 |
, 7.2.5, 8.2.8, 8.4.2 |
, 5.4, 6.3, 6.4 |
PR.AC-7, PR.PT-3, DE.CM-1 |
A.5.15, A.8.5, A.8.16 |
CC6.1, CC6.6, CC6.7 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For example, a phishing attack mimicking a cloud portal login page or a trojan on a non-PAW device can extract admin credentials, allowing adversaries to invoke API calls, modify IAM policies, or exfiltrate data.Privilege escalation through unsecured workstation configurationsAdversaries exploit local admin rights, unpatched vulnerabilities, or weak application controls on administrative workstations to escalate privileges, manipulating IAM roles or access tokens. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For instance, a workstation without AppLocker policies may allow malicious scripts to execute, enabling attackers to elevate from user-level to tenant-wide administrative access, compromising resources like virtual machines or storage.Unauthorized access via insecure remote connectivityAttackers target exposed RDP/SSH endpoints or unsecured protocols to intercept admin sessions or perform brute force attacks, gaining |
|
|
|
|
|
|
|
|
|
| PA-6 |
PA-6.1 |
Use privileged access solution |
Child |
Secure access |
No Azure Policy available |
Secured, isolated privileged access solutions are critically important for the security of sensitive roles like administrator, developer, and critical service operator. |
nan |
nan |
Privileged Access Workstations (PAWs) provide hardened, isolated environments preventing credential theft from malware, phishing, and unauthorized access on administrative devices. Without PAWs, administrators using standard workstations or personal devices expose privileged credentials to keyloggers, memory-scraping malware, and session hijacking, enabling attackers to compromise cloud tenants. Implementing PAWs with device hardening, strong authentication, and secure remote access ensures administrative operations remain protected from endpoint-based attacks. Deploy privileged access workstations through the following structured approach: Provision and configure hardened PAW devicesDeploy dedicated Windows devices as PAWs (physical workstations or Azure VMs) enrolling them inMicrosoft Intunefor centralized management, applyingMicrosoft Defender for Endpoint security baselinesremoving local administrator rights, enforcing device encryption withBitLocker, and configuringWindows Defender Application Control (WDAC)orAppLocker policiesrestricting application execution to approved administrative tools only (Azure portal, PowerShell, Azure CLI, Visual Studio Code). Implement device compliance and application controlConfigure Intune device configuration profiles enforcing security policies including disabled local admin accounts, mandatory screen lock after 5 minutes of inactivity, blocked removable storage devices, and restricted Microsoft Store installations, deployingCompany Por |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
| PA-7 |
nan |
Follow just enough administration (least privilege) principle |
Parent |
Secure access |
API Management subscriptions should not be scoped to all APIs |
Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments. |
Unauthorized access due to excessive permissionsAttackers exploit over-privileged accounts with permissions beyond what is required for their role, enabling unauthorized access to sensitive cloud resources such as storage accounts, virtual machines, or databases. |
Initial Access (TA0001)Valid Accounts: Cloud Accounts (T1078.004): Compromising over-privileged accounts with broad RBAC roles (e.g., Owner at subscription scope) to authenticate to cloud management consoles or APIs, enabling adversaries to access sensitive resources like storage accounts or virtual machines without detection. Privilege Escalation (TA0004)Abuse Elevation Control Mechanism: Cloud Infrastructure (T1548.005): Exploiting misconfigured RBAC roles with excessive permissions to escalate privileges, such as modifying IAM policies to assign tenant-wide administrative roles from a resource group scope, granting unauthorized control over cloud resources. Persistence (TA0003)Account Manipulation: Additional Cloud Roles (T1098.001): Modifying RBAC role assignments to add persistent high-privilege roles to compromised accounts, allowing adversaries to maintain access to cloud resources like databases or compute instances via unauthorized role bindings. Exfiltration (TA0010)Data from Cloud Storage (T1530): Accessing and extracting sensitive data from cloud storage using accounts with overly permissive RBAC roles, enabling adversaries to enumerate and download confidential files from storage buckets due to unscoped permissions. Defense Evasion (TA0005)Impair Defenses: Disable or Modify Cloud Logs (T1562.008): Using accounts with excessive RBAC permissions to disable audit logging or monitoring services, concealing malicious actions like resource modifications or IAM changes by s |
ChallengeA software company granted 145 developers Owner role at subscription scope for convenience, providing excessive permissions allowing database deletion, network security group modification, and IAM policy changes far beyond development needs. Solution Implement least privilege RBACAnalyzed actual permission requirements and reassigned developers to scoped custom roles limiting access to specific resource groups with granular permissions (read/write for App Services, read-only for Key Vault, no access to network or IAM resources).Deploy PIM for time-bound assignmentsConfigured Microsoft Entra PIM for elevated access needs requiring developers to activate Contributor role for 4-hour windows with justification and approval, replacing standing Owner assignments with on-demand access.Establish RBAC governanceCreated automated monthly reviews of all role assignments using PIM access reviews, requiring resource owners to justify continued access and automatically flagging role assignments broader than resource group scope for security team review. OutcomeOrganization reduced 145 standing Owner assignments to 0, limited developer access to 23 scoped resource groups with custom roles averaging 8 permissions vs previous 100+ Owner permissions, and prevented 3 accidental production deletions in first quarter through restricted access. |
Must have |
AC-2, AC-3, AC-5, AC-6, AC-6(1), AC-6(2) |
, 7.2.2, 7.2.3, 8.2.2 |
, 5.4, 6.1, 6.8 |
PR.AC-4, PR.AC-7, PR.AA-1 |
A.5.15, A.5.18, A.8.2, A.8.3 |
CC6.1, CC6.3, CC6.7 |
|
|
|
|
|
Audit usage of custom RBAC roles |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Key Vault should use RBAC permission model |
|
In cloud environments, excessive permissions often result from broad role assignments (e.g., granting Owner instead of Contributor at a subscription scope), allowing adversaries to perform actions like data exfiltration, resource deletion, or IAM policy modification. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Role-Based Access Control (RBAC) should be used on Kubernetes Services |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For instance, a user with unnecessary write access to a storage account can extract confidential data or deploy malicious content, amplifying the attack surface.Privilege escalation from misconfigured role assignmentsAdversaries leverage misconfigured or overly permissive role assignments to escalate privileges, gaining unauthorized control over cloud resources or entire tenants. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Without granular RBAC policies, a user with a seemingly low-privilege role (e.g., Reader at a resource group scope) might exploit inherited permissions or role misconfigurations to assign themselves higher privileges, such as Owner at a subscription level. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This can lead to tenant-wide |
|
|
|
|
|
|
|
|
|
| PA-7 |
PA-7.1 |
Use Azure RBAC to manage Azure resource access |
Child |
Secure access |
API Management subscriptions should not be scoped to all APIs |
Follow the just enough administration (least privilege) principle to manage permissions at fine-grained level. Use features such as role-based access control (RBAC) to manage resource access through role assignments. |
nan |
nan |
Use Azure role-based access control (Azure RBAC) to manage Azure resource access through role assignments. Through RBAC, you can assign roles to users, groups, service principals, and managed identities. There are pre-defined built-in roles for certain resources, and these roles can be inventoried or queried through tools such as Azure CLI, Azure PowerShell, and the Azure portal. The privileges you assign to resources through Azure RBAC should always be limited to what's required by the roles. Limited privileges will complement the just-in-time (JIT) approach of Microsoft Entra ID Privileged Identity Management (PIM), and those privileges should be reviewed periodically. If required, you can also use PIM to define a time-bound assignment, which is a condition in a role assignment where a user can only activate the role within the specified start and end dates. Note: Use Azure built-in roles to allocate permissions and only create custom roles when required. |
nan |
nan |
nan |
nan |
nan |
nan |
nan |
|
|
|
|
|
Audit usage of custom RBAC roles |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Azure Key Vault should use RBAC permission model |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Role-Based Access Control (RBAC) should be used on Kubernetes Services |
|
|
|
|
|
|
|
|
|
|
|
| PA-8 |
nan |
Determine access process for cloud provider support |
Parent |
Secure access |
No Azure Policy available |
Establish an approval process and access path for requesting and approving vendor support requests and temporary access to your data through a secure channel. |
Unauthorized data access via cloud provider supportRisk of cloud provider support personnel accessing customer data stores without explicit consent, potentially exploiting privileged credentials during diagnostic or maintenance operations.Insider threat exploitation through provider accessPotential for malicious or negligent cloud provider insiders to abuse privileged access, leading to data exfiltration or unauthorized modifications within customer tenants.Opaque access operations without visibilityLack of visibility into data access events, hindering traceability and accountability, which can erode trust and violate audit requirements.Excessive privilege escalationRisk of cloud provider support engineers obtaining overly broad access scopes, exceeding the least privilege principle and increasing the attack surface within cloud resources.Regulatory non-compliance with audit requirementsUncontrolled data access violating data protection frameworks (e.g., GDPR, HIPAA, CCPA), risking non-compliance penalties due to inadequate access governance.Data exposure during support operationsPotential for sensitive data leakage or mishandling during support activities, such as remote desktop s |
Valid Accounts (T1078.004)Exploitation of compromised or misused cloud account credentials, such as those of support personnel, to access customer data in cloud environments, bypassing standard authentication controls. Account Manipulation (T1098.001)Addition of unauthorized credentials, like keys or tokens, to cloud identity services or applications, enabling persistent access to customer resources during support operations. Brute Force (T1110)Repeated attempts to guess cloud account credentials, such as those used by support engineers, to gain unauthorized access to customer data during troubleshooting activities. Steal Application Access Token (T1528)Theft of access tokens used by support personnel to interact with customer cloud resources, facilitating unauthorized data access or lateral movement within the tenant. OS Credential Dumping (T1003.006)Extraction of credentials from cloud identity services by insiders with temporary elevated access, allowing synchronization of sensitive identity data for persistent access. |
ChallengeA financial services organization required explicit approval control for Microsoft support data access due to regulatory requirements but lacked visibility into support engineer access requests and approval workflows for compliance auditing. Solution Enable Customer LockboxActivatedCustomer Lockboxat tenant level for all subscriptions requiring Global Administrator approval, establishing documented approval process with designated Subscription Owners and Azure Customer Lockbox Approvers receiving automated email notifications for all data access requests.Configure approval workflowsEstablished 4-day review window for all Lockbox requests with mandatory approver justification documentation, configuring alternate email notifications for service principals and implementing escalation procedures for time-sensitive support scenarios.Implement monitoring and audit loggingIntegrated Customer Lockbox approval events withMicrosoft Sentinelgenerating real-time alerts for security team, enabling comprehensive audit trail of all support access requests, approval decisions, and access durations for regulatory reporting. OutcomeOrganization achieved 100% explicit approval for Microsoft support data access with average 2-hour approval latency, maintained complete audit trail of 47 Lockbox requests over 6 months for regulatory compliance, and denied 3 requests not meeting approval criteria demonstrating governance control. |
Must have |
AC-2, AC-3, AC-6(2), AU-6, CA-3 |
, 10.2.2, 12.8.2, 12.8.5 |
, 6.8, 8.2, 8.11 |
PR.AC-4, PR.PT-2, DE.AE-3 |
A.5.19, A.5.20, A.5.23, A.8.2 |
CC6.3, CC6.7, CC7.2 |
| PA-8 |
PA-8.1 |
Use Azure Customer Lockbox |
Child |
Secure access |
No Azure Policy available |
Establish an approval process and access path for requesting and approving vendor support requests and temporary access to your data through a secure channel. |
nan |
nan |
Customer Lockboxprovides explicit approval control for Microsoft support engineer data access, ensuring customers maintain governance over who accesses their cloud resources during troubleshooting. Without Lockbox, support engineers could access customer data without explicit consent, creating compliance risks and reducing visibility into vendor access activities. Implementing Lockbox ensures every support data access request requires customer approval, maintaining audit trails and regulatory compliance. Implement Customer Lockbox through the following process: Enable LockboxA Global Administrator enables Customer Lockbox at the tenant level via the Azure portal's Administration module, requiring an Azure support plan (Developer or higher) with all subscriptions and resources under the tenant covered.Initiate support requestUsers open support tickets in the Azure portal for workload issues, where Microsoft support engineers review tickets and determine if data access is needed beyond standard troubleshooting tools.Request elevated accessIf standard tools can't resolve the issue, engineers request elevated permission via Just-In-Time (JIT) access service, creating Lockbox requests for direct data access (e.g., virtual machine remote desktop) specifying purpose, duration, and resources.Notify designated approversDesignated approvers (Subscription Owners, Global Admins, or Azure Customer Lockbox Approvers) receive email notifications with request details and links to the Lockbox |
nan |
nan |
nan |
nan |
nan |
nan |
nan |