Edit

Essential Eight restrict administrative privileges

  • Article

This article details methods for achieving the Australian Cyber Security Centre (ACSC) Essential Eight Maturity Model for restricting administrative privileges using the Microsoft identity platform. The ACSC Maturity Model Guidelines for Restrict Administrative Privileges are found in the ACSC Essential Eight Maturity Model.

Why pursue the ACSC Essential Eight restricting administrative privileges guidelines?

The Australian Cyber Security Centre (ACSC) leads the Australian Government’s efforts to improve cyber security. The ACSC recommends all Australian organizations implement the Essential Eight mitigation strategies from the ACSC’s Strategies to Mitigate Cyber Security Incidents as a baseline. The baseline, known as the Essential Eight, are foundational cyber security measures that make it much harder for adversaries to compromise systems. The Essential Eight Maturity Levels allow organizations to assess the appropriateness of their cyber security measures against common threats in today’s interconnected ICT landscape.

A malicious actor’s goal is to gain access to privileged credentials, especially credentials with access to the enterprise control plane. Control plane access provides widespread access and control over high value assets within an enterprise ICT environment. Examples of control plane access include Global Administrator and equivalent privileges within Microsoft Entra ID and privileged access to enterprise virtualization infrastructure.

Restricting Privileged Access using a multi-layered approach increases the difficulty for an adversary to undertake malicious activities. Restricting Administrative Privileges is a highly effective control included in ACSC’s Strategies to Mitigate Cyber Security Incidents.

This table outlines the ISM controls related to Restrict Administrative Privileges.

ISM control Mar 2024 Maturity Level Control Measure
ISM-0445 1, 2, 3 Privileged users are assigned a dedicated privileged account to be used solely for duties requiring privileged access. Administrators should use separate accounts for privileged tasks and productivity work. Accounts with high level privileges in Microsoft Entra ID, Azure, and Microsoft 365 should be cloud-only accounts, not accounts synchronized from an on-premises Active Directory domain.
ISM-1175 1, 2, 3 Privileged accounts (excluding those explicitly authorized to access online services) are prevented from accessing the internet, email, and web services. Block the use of productivity tools like Office 365 email by removing Microsoft 365 licenses from privileged accounts. Privileged accounts should access cloud admin portals from a privileged access device. Controlling internet and email from privileged access devices can be performed using a host-based firewall, a cloud proxy, or by configuring the proxy settings on the device.
ISM-1507 1, 2, 3 Requests for privileged access to systems, applications, and data repositories are validated when first requested. An entitlement management process is in place for privileged access. Microsoft Entra Entitlement Management can be used to automate entitlement management processes.
ISM-1508 3 Privileged access to systems, applications, and data repositories is limited to only what is required for users and services to undertake their duties. Role-based access control is configured to limit access to authorized users. Microsoft Entra Privileged Identity Management (PIM) ensures just-in-time access, which is time-bound.
ISM-1509 2, 3 Privileged access events are centrally logged. Microsoft Entra audit logs and sign-in logs are sent to an Azure Log Analytics Workspace (LAW) for analysis.
ISM-1647 2, 3 Privileged access to systems, applications, and data repositories is disabled after 12 months unless revalidated. An entitlement management process is in place for privileged access. Microsoft Entra Entitlement Management can be used to automate entitlement management processes.
ISM-1648 2, 3 Privileged access to systems and applications is disabled after 45 days of inactivity. Use Microsoft Graph API to evaluate lastSignInDateTime and identify inactive privileged accounts.
ISM-1650 2, 3 Privileged account and group management events are centrally logged. Microsoft Entra audit logs and sign-in logs are sent to an Azure Log Analytics Workspace (LAW) for analysis.
ISM-1380 1, 2, 3 Privileged users use separate privileged and unprivileged operating environments. Using different physical workstations are the most secure approach to separating privileged and unprivileged operating environments for system administrators. Organizations that are unable to use separate physical workstations to separate privileged and unprivileged operating environments should take a risk-based approach and implement alternative controls according to a defense in depth security strategy.
ISM-1688 1, 2, 3 Unprivileged accounts cannot logon to privileged operating environments. Login restrictions and role-based access control is used to prevent unprivileged accounts from logging into privileged operating environments.
ISM-1689 1, 2, 3 Privileged accounts (excluding local administrator accounts) cannot logon to unprivileged operating environments. Login restrictions and role-based access control is used to prevent privileged accounts from logging into unprivileged operating environments.
ISM-1883 1, 2, 3 Privileged accounts explicitly authorized to access online services are strictly limited to only what is required for users and services to undertake their duties. Role-based access control is configured to limit access to authorized users. Microsoft Entra Privileged Identity Management (PIM) ensures just-in-time access, which is time bound.
ISM-1898 2, 3 Secure Admin Workstations are used in the performance of administrative activities. Privileged Access Workstation devices are managed using Microsoft Intune and secured using a combination of Defender for Endpoint, Windows Hello for Business and Microsoft Entra ID controls.

Restrict administrative privileges: Essential Eight requirements

Privileged access allows administrators to change the configuration of key applications and infrastructure such as identity services, business systems, networking devices, user workstations and user accounts. Privileged access or credentials are often referred to as the 'keys to the kingdom' as they provide the bearers with control over many different assets within a network.

The following categories of controls are required to achieve Essential Eight Maturity Level 3 for Restrict Administrative Privileges.

  • Identity governance: Identity governance is the process of validating user access requirements and removing access that is no longer required.
  • Least privilege: Least privilege is an approach to access control that limits access to systems, applications, and data repositories to only what is required for users and services to undertake their duties.
  • Account restrictions: Account restrictions reduce the exposure of privileged credentials to unprivileged environments.
  • Administrative devices: Administrative devices are secure operating environments used for performing administrative activities.
  • Logging and monitoring: Logging and monitoring of privileged activities enables detection of signs of compromise.

Identity governance

Identity Governance helps organizations achieve a balance between productivity and security. Identity lifecycle management is the foundation for Identity Governance, and effective governance at scale requires a modern identity lifecycle management infrastrastructure.

Entitlement management (ML1)

Essential Eight Maturity Level 1 requires that requests for privileged access to systems, applications and data repositories are validated when first requested. Validation of privileged access requests is part of the entitlement management process. Entitlement management is the process of administering user access to privileges to ensure that only authorized users have access to a set of resources. Key steps within the entitlement management process include access requests, access reviews, access provisioning and access expiration.

Microsoft Entra Entitlement Management automates the process of managing access to resources within Azure. Users can be delegated access using access packages, which are bundles of resources. An Access package in Microsoft Entra Entitlement Management can include security groups, Microsoft 365 groups and Teams, Microsoft Entra enterprise applications and SharePoint Online sites. Access packages include one or more policies. A policy defines the rules or guardrails for assignment to access package. Policies can be used to ensure that only appropriate users can request access, that approvers for access requests are assigned, and that access to resources is time-limited and will expire if not renewed.

Illustration describing the Microsoft Entra Entitlement Management Lifecycle.

For detailed information about entitlement management, see Microsoft Entra Entitlement Management.

Manage inactive users (ML2)

Essential Eight Maturity Level 2 requires that privileged access to systems and applications is automatically disabled after 45 days of inactivity. Inactive accounts are user or system accounts that are no longer required by your organization. Inactive accounts can usually be identified through sign-in logs, indicating that they haven't been used to sign in for an extended period of time. It's possible to use the last sign-in timestamp to detect inactive accounts.

The last sign-in provides potential insights into a user's continued need for access to resources. It can help with determining if group membership or app access is still needed or could be removed. For guest user management, you can understand if a guest account is still active within the tenant or should be cleaned up.

You detect inactive accounts by evaluating the lastSignInDateTime property exposed by the signInActivity resource type of the Microsoft Graph API. The lastSignInDateTime property shows the last time a user made a successful interactive sign-in to Microsoft Entra ID. Using this property, you can implement a solution for the following scenarios:

For detailed information about managing inactive users, see Manage inactive user accounts.

Least Privilege

Least privilege requires that access to systems and applications is limited to only what is required for users and systems to undertake their duties. Least privilege can be implemented using controls such as role-based access control (RBAC), privileged access management and just-in-time (JIT) access.

Separate accounts for administrators (ML1)

Essential Eight Maturity Level 1 requires that privileged users are assigned a dedicated privileged account to be used solely for duties requiring privileged access. Accounts with high level privileges in Microsoft Entra ID, Azure and Microsoft 365 should be cloud-only accounts, not accounts synchronized from an on-premises Active Directory domain. Administrative accounts should block the use of productivity tools like Office 365 email (remove license).

For detailed information about managing administrative access, see Securing privileged access for hybrid and cloud deployments.

Enforce conditional access for administrators (ML1)

Essential Eight Maturity Level 1 requires that privileged users use separate privileged and unprivileged operating environments. Privileged access to Azure and Microsoft 365 environments requires a higher security standard than the standard applied to regular users. Privileged access should be granted based on a combination of signals and security attributes to support a Zero Trust strategy. Compromise of an account with privileged access to Azure or Microsoft 365 can cause significant disruption to business processes. Conditional Access can reduce the risk of compromise by enforcing a certain standard of security hygiene before allowing access to Azure management tools.

It's recommended to implement the following controls for administrative access to the Azure portal and command line administration tools:

  • Require multi-factor authentication (MFA)
  • Block access attempts with a High Sign-in risk level from Microsoft Identity Protection
  • Block access attempts with a High User Risk level from Microsoft Identity Protection
  • Require access from a Microsoft Entra joined device, which meets Intune compliance requirements for device health, update status and system security status

For detailed information about enforcement of Conditional Access for Administrators, see the following articles:

Managing local administrator accounts (ML2)

Essential Eight Maturity Level 2 requires credentials for break glass accounts, local administrator accounts and service accounts to be long, unique, unpredictable and managed. Active local Administrator accounts on Windows workstations are often used by attackers to laterally traverse a Windows environment. For this reason, the following controls are recommended for local Administrator accounts on domain-joined systems:

Active Directory joined systems

Microsoft’s Local Administrator Password Solution (LAPS) provides a solution to the issue of using a common local account with an identical password on every computer. LAPS resolves this issue by setting a different, rotated random password for the local administrator account on every computer in the domain. Passwords are stored in Active Directory and protected by restrictive Access Control Lists. The local administrator password can only be retrieved or reset by eligible users.

For detailed information about managing local administrator accounts on Active Directory joined systems, see the following articles:

Microsoft Entra joined systems

When you join a Windows device to Microsoft Entra ID using a Microsoft Entra join, Microsoft Entra ID adds the following security principles to the local Administrators group on the device:

  • The Microsoft Entra Global Administrator role
  • The Azure AD Joined Device Local Administrator role
  • The user performing the Microsoft Entra join

You can customize the membership of the local Administrators group to satisfy your business requirements. It's recommended to limit local administrator access to workstations and require PIM approval for the use of the Azure AD Joined Device Local Administrator role.

In the Azure portal, you can manage the Device Administrator role from Device settings.

  1. Sign-in to the Azure portal as a Global Administrator.
  2. Browse to Microsoft Entra ID > Devices > Device settings.
  3. Select Manage Additional local administrators on all Microsoft Entra joined devices.
  4. Select Add assignments then choose the other administrators you want to add and select Add.

To modify the Device Administrator role, configure Additional local administrators on all Microsoft Entra joined devices.

For detailed information about managing local administrators on Microsoft Entra joined systems, see the following articles:

Managing service accounts (ML2)

A common challenge for developers is the management of secrets, credentials, certificates, and keys used to secure communication between services. Essential Eight Maturity Level 2 requires credentials for service accounts to be long, unique, unpredictable, and managed.

Active Directory joined systems

Group managed service accounts (gMSAs) are domain accounts to help secure services. gMSAs can run on one server, or in a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, account password management is handled by the Windows operating system (OS).

gMSAs are an identity solution with greater security that help reduce administrative overhead:

  • Set strong passwords: 240 byte, randomly generated passwords: the complexity and length of gMSA passwords minimizes the likelihood of compromise by brute force or dictionary attacks.
  • Cycle passwords regularly: password management goes to the Windows OS, which changes the password every 30 days. Service and domain administrators don't need to schedule password changes, or manage service outages.
  • Support deployment to server farms: deploy gMSAs to multiple servers to support load balanced solutions where multiple hosts run the same service.
  • Support simplified service principal name (SPN) management - set up an SPN with PowerShell, when you create an account.

Microsoft Entra joined systems

Managed identities provide an automatically managed identity in Microsoft Entra ID for applications to use when connecting to resources that support Microsoft Entra authentication. Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials.

There are two types of managed identities:

  • System-assigned. A service principal is automatically created in Microsoft Entra ID for the resource identity. The service principal is tied to the lifecycle of that Azure resource. When the Azure resource is deleted, Azure automatically deletes the associated service principal.
  • User-assigned. A service principal is manually created in Microsoft Entra ID for the resource identity. The service principal is managed separately from the resources that use it.

Just-in-time access to systems and applications (ML3)

Avoid assigning permanent standing access for any accounts that are members of highly privileged roles in Azure or Microsoft 365. Attackers frequently target accounts with permanent privileges to maintain persistence in enterprise environments and cause widespread damage to systems. Temporary privileges force attackers to either wait for a user to elevate their privileges or to initiate privilege elevation. Initiating a privilege elevation activity increases an attacker's chance of being detected and removed before they're able to inflict damage.

Grant privileges only as required using the following methods:

  • Just-in-Time access: Configure Microsoft Entra Privileged Identity Management (PIM) to require an approval workflow to obtain privileges for access to privileged roles. At a minimum, elevation should be required for the following privileged Microsoft Entra roles: Global Administrator, Privileged Authentication Administrator, Privileged Role Administrator, Conditional Access Administrator and Intune Administrator. At a minimum, elevation should be required for the following privileged Azure RBAC roles: Owner and Contributor.
  • Break glass accounts: Emergency access accounts are limited to emergency or "break glass" scenarios where normal administrative accounts can't be used. For example, all administrators being locked out of a Microsoft Entra tenant. Ensure that you set a strong password and only use emergency access accounts during emergencies. Create cloud-only accounts using the *.onmicrosoft.com domain for emergency access accounts and configure monitoring to alert on sign-ins.

Access reviews (ML3)

Essential Eight Maturity Level 3 requires that privileged access to systems and applications is limited to only what is required for users and services to undertake their duties. The need for privileged access to Azure resources and Microsoft Entra roles changes over time. To reduce the risk associated with stale role assignments, you should regularly review access. Microsoft Entra access reviews enable organizations to efficiently manage RBAC group memberships, access to enterprise applications, and Microsoft Entra role assignments. User access can be reviewed regularly to make sure only the right people continue to have access.

Microsoft Entra access reviews enable use cases such as:

  • Identifying excessive access rights
  • Identifying when a group is used for a new purpose
  • As people move teams or leave the company, removing unnecessary access
  • Enabling proactive engagement with resource owners to ensure they regularly review who has access to their resources.

Depending on the type of access requiring review, access reviews need to be created in different areas of the Azure portal. The following table shows the specific tools for creating access reviews:

Access rights of users Reviewers can be Review created in Reviewer experience
Security group members
Office group members		 Specified reviewers
Group owners
Self-review		 Access reviews
Microsoft Entra groups		 Access panel
Assigned to a connected app Specified reviewers
Self-review		 Access reviews
Microsoft Entra Enterprise Apps (in preview)		 Access panel
Microsoft Entra role Specified reviewers
Self-review		 Privileged Identity Management (PIM) Azure portal
Azure resource role Specified reviewers
Self-review		 Privileged Identity Management (PIM) Azure portal
Access package assignments Specified reviewers
Group members
Self-review		 Entitlement management Access panel

For detailed information about Microsoft Entra access reviews, see the following articles:

Account restrictions

Account security is a critical component of securing privileged access. End-to-end Zero Trust security requires establishing that the account being used in the session is actually under the control of the human owner and not an attacker impersonating them.

Login restrictions (ML1)

Users, services, or application accounts with administrative privileges in Windows Active Directory (AD) domains pose a high risk to enterprise security. These accounts are often targeted by attackers because they provide widespread access to servers, databases, and applications. When administrators login to systems with a lower security profile, privileged credentials are stored in memory and can be extracted using credential theft tools (for example, Mimikatz).

Essential Eight Maturity Level 1 requires that privileged accounts (excluding local administrator accounts) can't logon to unprivileged operating environments. The Microsoft Tiered Administration Model applies login restrictions to domain-joined devices to prevent exposure of privileged credentials on devices with a lower security profile. Admins with administrator access to the Active Directory domain are separated from administrators with control over workstations and enterprise applications. Logon restrictions should be enforced to ensure that highly privileged accounts can't login to less secure resources. For example:

  • Members of the Active Directory Enterprise and Domain Admins groups can't log on to business application servers and user workstations.
  • Members of the Microsoft Entra Global Admins role can't log on to Microsoft Entra joined workstations.

Logon restrictions can be enforced with Group Policy User Rights Assignments or Microsoft Intune Policies. It's recommended to configure the following policies on enterprise servers and user workstations to prevent privileged accounts from exposing credentials to a less trusted system:

  • Deny access to this computer from the network
  • Deny logon as a batch job
  • Deny logon as a service
  • Deny logon locally
  • Deny logon through Terminal Services

Restrict access to the internet, email and web services (ML1)

Essential Eight Maturity Level 1 requires that privileged accounts (excluding accounts that are explicitly authorized to access online services) are prevented from accessing the internet, email and web services. Administrative accounts should block the use of productivity tools like Office 365 email (remove license). Administrative accounts should access cloud admin portals from a privileged access device. Privileged access devices should deny all websites and use an allowlist to enable access to cloud admin portals. Controlling internet and email from privileged access devices can be performed using a host-based firewall, a cloud proxy, or by configuring the proxy settings on the device.

Microsoft Entra joined devices

Create a Microsoft Intune Configuration Profile to configure the network proxy on devices used for privileged administration. Privileged Access devices used to administer Azure and Microsoft 365 cloud services should use the proxy exemptions from the following table.

Section Name Config
Basics Name PAW-Intune-Configuration-Proxy-Device-Restrictions
Basics Platform Windows 10 and later
Basics Profile type Device restrictions
Configuration Use manual proxy server Allow
Configuration Address 127.0.0.2
Configuration Port 8080
Configuration Proxy exceptions account.live.com;*.msft.net; *.msauth.net;*.msauthimages.net;*.msftauthimages.net;*.msftauth.net;*.azure.com;*.azure.net;*.azureedge.net;*.azurewebsites.net;*.microsoft.com;microsoft.com;*.windowsupdate.com;*.microsoftonline.com;*.microsoftonline.cn;*.microsoftonline-p.net;*.microsoftonline-p.com;*.windows.net;*.windows.com;*.windowsazure.com;*.windowsazure.cn;*.azure.cn;*.loganalytics.io;*.applicationinsights.io;*.vsassets.io;*.azure-automation.net;*.azure-api.net;*.azure-devices.net;*.visualstudio.com;portal.office.com;config.office.com;*.aspnetcdn.com;*.sharepointonline.com;*.msecnd.net;*.msocdn.com;*.webtrends.com;*.aka.ms;*.digicert.com;*.phonefactor.net;*.nuget.org;*.cloudapp.net;*.trafficmanager.net;login.live.com;clientconfig.passport.net;*.wns.windows.com;*.s-microsoft.com;www.msftconnecttest.com;graph.windows.net;*.manage.microsoft.com;*.aadcdn.microsoftonline-p.com;*.azureafd.net;*.azuredatalakestore.net;*.windows-int.net;*.msocdn.com;*.msecnd.net;*.onestore.ms;*.aspnetcdn.com;*.office.net;*.officeapps.live.com;aka.ms;*.powershellgallery.com;*.azure-apim.net;spoprod-a.akamaihd.net;*.hip.live.com

Administrative Devices

System administrators should use separate devices for managing privileged and unprivileged operating environments. Administrative activities should follow the clean source principle for all devices involved in the administration process.

Separate privileged and unprivileged operating environments (ML1)

Essential Eight Maturity Level 1 requires that privileged users use separate privileged and unprivileged operating environments. Using different physical workstations is the most secure approach to separating privileged and unprivileged operating environments for system administrators. While security assurances may be enhanced in the session, they'll always be limited by the strength of the assurance in the originating device. An attacker with control of a privileged access device can impersonate users or steal user credentials for future impersonation. This risk undermines other assurances on the account, intermediaries like jump servers, and on the resources themselves.

Organizations which are unable to use separate physical workstations to separate privileged and unprivileged operating environments should take a risk-based approach and implement alternative controls according to a defence in depth security strategy. Microsoft recommends mapping user roles and assets to a sensitivity level to evaluate the level of assurance required to protect privileged operating environments.

For detailed information about privileged access sensitivity levels, see Privileged Access Security Levels

Secure Admin Workstations (ML3)

Essential Eight Maturity Level 3 requires that Secure Admin Workstations are used to perform administrative activities. Secure Admin Workstations (SAWs) are an effective control against the exposure of sensitive credentials on less secure devices. Logging onto or running services on a less secure device with a privileged account increases risk of credential theft and privilege escalation attacks. Privileged credentials should only be exposed to a SAW keyboard and should be denied from logging on to less secure devices. SAWs provide a secure platform for managing on-premises, Azure, Microsoft 365 and third-party cloud services. SAW devices are managed using Microsoft Intune and secured using a combination of Defender for Endpoint, Windows Hello for Business and Microsoft Entra ID controls.

The following diagram illustrates the high-level architecture, including the various technology components that should be configured to implement the overall solution and SAW framework:

Illustration describing the Microsoft Secure Admin Workstation solution.

For detailed information about Secure Admin Workstations, see the following articles:

Secure intermediaries and jump servers (ML2)

Security of intermediary services is a critical component of securing privileged access. Intermediaries are used to facilitate the administrator’s session or connection to a remote system or application. Examples of intermediaries include virtual private networks (VPNs), jump servers, virtual desktop infrastructure (including Windows 365 and Azure Virtual Desktop), and application publishing through access proxies. Attackers often target intermediaries to escalate privileges using credentials stored on them, get network remote access to corporate networks, or exploit trust in the privileged access device.

Different intermediary types perform unique functions so they each require a different security approach. Attackers are easily able to target systems with a larger attack surface. The following list includes options available for privileged access intermediaries:

  • Native cloud services such as Microsoft Entra Privileged Identity Management (PIM), Azure Bastion, and Microsoft Entra application proxy offer a limited attack surface to attackers. While they're exposed to the public internet, customers (and attackers) have no access to the underlying infrastructure. The underlying infrastructure for SaaS and PaaS services is maintained and monitored by the cloud provider. This smaller attack surface limits the available options to attackers vs. classic on-premises applications and appliances that must be configured, patched, and monitored by IT personnel.
  • Virtual Private Networks (VPNs), Remote Desktops and Jump Servers provide a significant attacker opportunity as these services require ongoing patching, hardening and maintenance to maintain a resilient security posture. While a jump server may only have a few network ports exposed, attackers only need access to one unpatched service to perform an attack.
  • Third-party Privileged Identity Management (PIM) and Privileged Access Management (PAM) services are frequently hosted on-premises or as a VM on Infrastructure as a Service (IaaS) and are typically only available to intranet hosts. While not directly internet-exposed, a single compromised credential may allow attackers to access the service over VPN or another remote access medium.

For detailed information about Privileged Access Intermediaries, see Secure Intermediaries.

Logging and monitoring

Logging privileged access events (ML2)

Logging of sign-ins and activities performed by privileged accounts is essential to detect abnormal behavior within enterprise environments. Microsoft Entra audit logs and Sign-in Logs provide valuable insight into privileged access to applications and services.

Microsoft Entra sign-in logs provide insight into sign-in patterns, sign-in frequency and status of sign-in activities. The sign-in activity report is available in all editions of Microsoft Entra ID. Organizations with a Microsoft Entra ID P1 or P2 license can access the sign-in activity report through the Microsoft Graph API.

Microsoft Entra activity logs include audit logs for every logged event in Microsoft Entra ID. Changes to applications, groups, users, and licenses are all captured in the Microsoft Entra audit logs. By default, Microsoft Entra ID retains sign-in and audit logs for a maximum of seven days. Microsoft Entra ID retains logs for a maximum of 30 days if a Microsoft Entra ID P1 or P2 license is present in the tenant. Microsoft Entra audit logs and Sign-in Logs should be forwarded to an Azure Log Analytics Workspace (LAW) for centralized collection and correlation.

For detailed information about centralized logging, see the following articles:

Monitoring event logs for signs of compromise (ML3)

Essential Eight Maturity Level 3 requires that event logs are monitored for signs of compromise and actioned when any signs of compromise are detected. Monitoring privileged activity is important to detect system compromise early and contain the scope of malicious activity.

Monitoring privileged access events

Monitor all privileged account sign-in activity by using the Microsoft Entra sign-in logs as the data source. Monitor for the following events:

What to monitor Risk level Where Notes
Sign-in failure, bad password threshold High Microsoft Entra sign-in log Define a baseline threshold and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.
Failure because of Conditional Access requirement High Microsoft Entra sign-in log This event can be an indication an attacker is trying to get into the account.
Privileged accounts that don't follow naming policy High Azure subscription List role assignments for subscriptions and alert where the sign-in name doesn't match your organization's format. An example is the use of ADM_ as a prefix.
Interrupt High, medium Microsoft Entra Sign-ins This event can be an indication an attacker has the password for the account but can't pass the multifactor authentication challenge.
Privileged accounts that don't follow naming policy High Microsoft Entra directory List role assignments for Microsoft Entra roles and alert where the UPN doesn't match your organization's format. An example is the use of ADM_ as a prefix.
Discover privileged accounts not registered for multifactor authentication High Microsoft Graph API Audit and investigate to determine if the event is intentional or an oversight.
Account lockout High Microsoft Entra sign-in log Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.
Account disabled or blocked for sign-ins Low Microsoft Entra sign-in log This event could indicate someone is trying to gain access to an account after they've left the organization. Although the account is blocked, it's still important to log and alert on this activity.
MFA fraud alert or block High Microsoft Entra sign-in log/Azure Log Analytics Privileged user has indicated they haven't instigated the multifactor authentication prompt, which could indicate an attacker has the password for the account.
MFA fraud alert or block High Microsoft Entra audit log log/Azure Log Analytics Privileged user has indicated they haven't instigated the multifactor authentication prompt, which could indicate an attacker has the password for the account.
Privileged account sign-ins outside of expected controls High Microsoft Entra sign-in log Monitor and alert on any entries that you've defined as unapproved.
Outside of normal sign-in times High Microsoft Entra sign-in log Monitor and alert if sign-ins occur outside of expected times. It's important to find the normal working pattern for each privileged account and to alert if there are unplanned changes outside of normal working times. Sign-ins outside of normal working hours could indicate compromise or possible insider threats.
Identity protection risk High Identity Protection logs This event indicates that an abnormality has been detected with the sign-in for the account and should be alerted on.
Password change High Microsoft Entra audit logs Alert on any admin account password changes, especially for global admins, user admins, subscription admins, and emergency access accounts. Write a query targeted at all privileged accounts.
Change in legacy authentication protocol High Microsoft Entra sign-in log Many attacks use legacy authentication, so if there's a change in auth protocol for the user, it could be an indication of an attack.
New device or location High Microsoft Entra sign-in log Most admin activity should be from privileged access devices, from a limited number of locations. For this reason, alert on new devices or locations.
Audit alert setting is changed High Microsoft Entra audit logs Changes to a core alert should be alerted if unexpected.
Administrators authenticating to other Microsoft Entra tenants Medium Microsoft Entra sign-in log When scoped to Privileged Users, this monitor detects when an administrator has successfully authenticated to another Microsoft Entra tenant with an identity in your organization's tenant. Alert if Resource TenantID isn't equal to Home Tenant ID
Admin User state changed from Guest to Member Medium Microsoft Entra audit logs Monitor and alert on change of user type from Guest to Member. Was this change expected?
Guest users invited to tenant by nonapproved inviters Medium Microsoft Entra audit logs Monitor and alert on nonapproved actors inviting guest users.

Monitoring privileged account management events

Investigate changes to privileged accounts' authentication rules and privileges, especially if the change provides greater privilege or the ability to perform tasks in Microsoft Entra ID.

What to monitor Risk level Where Notes
Privileged account creation Medium Microsoft Entra audit logs Monitor creation of any privileged accounts. Look for correlation that's of a short time span between creation and deletion of accounts.
Changes to authentication methods High Microsoft Entra audit logs This change could be an indication of an attacker adding an auth method to the account so they can have continued access.
Alert on changes to privileged account permissions High Microsoft Entra audit logs This alert is especially for accounts being assigned roles that aren't known or are outside of their normal responsibilities.
Unused privileged accounts Medium Microsoft Entra access reviews Perform a monthly review for inactive privileged user accounts.
Accounts exempt from Conditional Access High Azure Monitor Logs or Access Reviews Any account exempt from Conditional Access is most likely bypassing security controls and is more vulnerable to compromise. Break-glass accounts are exempt. See information on how to monitor break-glass accounts later in this article.
Addition of a Temporary Access Pass to a privileged account High Microsoft Entra audit logs Monitor and alert on a Temporary Access Pass being created for a privileged user.

For detailed information about monitoring privileged account activity, see Security operations for privileged accounts in Microsoft Entra ID.

Protect event logs from unauthorized modification and deletion (ML3)

Essential Eight Maturity Level 3 requires that event logs are protected from unauthorized modification and deletion. Protecting event logs from unauthorized modification and deletion ensures that logs can be used as a reliable source of evidence if the organization experiences a security incident. Within Azure, event logs from privileged access to applications and services should be centrally stored within a Log Analytics workspace.

Azure Monitor is an append-only data platform, but includes provisions to delete data for compliance purposes. Log Analytics workspaces that collect logs from privileged activities should be secured with role-based access controls and monitored for modify and delete activities.

Secondly, set a lock on the Log Analytics workspace to block all activities that could delete data: purge, table delete, and table- or workspace-level data retention changes.

To fully tamper-proof your event logs, configure automated exports of log data to an immutable storage solution such as Immutable Storage for Azure Blob Storage.

For detailed information about protecting event log integrity, see Azure Monitor Data Security.