Microsoft Entra security operations for user accounts

User identity is one of the most important aspects of protecting your organization and data. This article provides guidance for monitoring account creation, deletion, and account usage. The first portion covers how to monitor for unusual account creation and deletion. The second portion covers how to monitor for unusual account usage.

If you have not yet read the Microsoft Entra security operations overview, we recommend you do so before proceeding.

This article covers general user accounts. For privileged accounts, see Security operations – privileged accounts.

Define a baseline

To discover anomalous behavior, you first must define what normal and expected behavior is. Defining what expected behavior for your organization is, helps you determine when unexpected behavior occurs. The definition also helps to reduce the noise level of false positives when monitoring and alerting.

Once you define what you expect, you perform baseline monitoring to validate your expectations. With that information, you can monitor the logs for anything that falls outside of tolerances you define.

Use the Microsoft Entra audit logs, Microsoft Entra sign-in logs, and directory attributes as your data sources for accounts created outside of normal processes. The following are suggestions to help you think about and define what normal is for your organization.

  • Users account creation – evaluate the following:

    • Strategy and principles for tools and processes used for creating and managing user accounts. For example, are there standard attributes, formats that are applied to user account attributes.

    • Approved sources for account creation. For example, originating in Active Directory (AD), Microsoft Entra ID or HR systems like Workday.

    • Alert strategy for accounts created outside of approved sources. Is there a controlled list of organizations your organization collaborates with?

    • Provisioning of guest accounts and alert parameters for accounts created outside of entitlement management or other normal processes.

    • Strategy and alert parameters for accounts created, modified, or disabled by an account that isn't an approved user administrator.

    • Monitoring and alert strategy for accounts missing standard attributes, such as employee ID or not following organizational naming conventions.

    • Strategy, principles, and process for account deletion and retention.

  • On-premises user accounts – evaluate the following for accounts synced with Microsoft Entra Connect:

    • The forests, domains, and organizational units (OUs) in scope for synchronization. Who are the approved administrators who can change these settings and how often is the scope checked?

    • The types of accounts that are synchronized. For example, user accounts and or service accounts.

    • The process for creating privileged on-premises accounts and how the synchronization of this type of account is controlled.

    • The process for creating on-premises user accounts and how the synchronization of this type of account is managed.

For more information for securing and monitoring on-premises accounts, see Protecting Microsoft 365 from on-premises attacks.

  • Cloud user accounts – evaluate the following:

    • The process to provision and manage cloud accounts directly in Microsoft Entra ID.

    • The process to determine the types of users provisioned as Microsoft Entra cloud accounts. For example, do you only allow privileged accounts or do you also allow user accounts?

    • The process to create and maintain a list of trusted individuals and or processes expected to create and manage cloud user accounts.

    • The process to create and maintained an alert strategy for non-approved cloud-based accounts.

Where to look

The log files you use for investigation and monitoring are:

From the Azure portal, you can view the Microsoft Entra audit logs and download as comma separated value (CSV) or JavaScript Object Notation (JSON) files. The Azure portal has several ways to integrate Microsoft Entra logs with other tools that allow for greater automation of monitoring and alerting:

  • Microsoft Sentinel – enables intelligent security analytics at the enterprise level by providing security information and event management (SIEM) capabilities.

  • Sigma rules - Sigma is an evolving open standard for writing rules and templates that automated management tools can use to parse log files. Where Sigma templates exist for our recommended search criteria, we've added a link to the Sigma repo. The Sigma templates aren't written, tested, and managed by Microsoft. Rather, the repo and templates are created and collected by the worldwide IT security community.

  • Azure Monitor – enables automated monitoring and alerting of various conditions. Can create or use workbooks to combine data from different sources.

  • Azure Event Hubs integrated with a SIEM - Microsoft Entra logs can be integrated to other SIEMs such as Splunk, ArcSight, QRadar and Sumo Logic via the Azure Event Hubs integration.

  • Microsoft Defender for Cloud Apps – enables you to discover and manage apps, govern across apps and resources, and check your cloud apps' compliance.

  • Securing workload identities with Microsoft Entra ID Protection - Used to detect risk on workload identities across sign-in behavior and offline indicators of compromise.

Much of what you will monitor and alert on are the effects of your Conditional Access policies. You can use the Conditional Access insights and reporting workbook to examine the effects of one or more Conditional Access policies on your sign-ins, and the results of policies, including device state. This workbook enables you to view a summary, and identify the effects over a specific time period. You can also use the workbook to investigate the sign-ins of a specific user.

The remainder of this article describes what we recommend you monitor and alert on, and is organized by the type of threat. Where there are specific pre-built solutions we link to them or provide samples following the table. Otherwise, you can build alerts using the preceding tools.

Account creation

Anomalous account creation can indicate a security issue. Short lived accounts, accounts not following naming standards, and accounts created outside of normal processes should be investigated.

Short-lived accounts

Account creation and deletion outside of normal identity management processes should be monitored in Microsoft Entra ID. Short-lived accounts are accounts created and deleted in a short time span. This type of account creation and quick deletion could mean a bad actor is trying to avoid detection by creating accounts, using them, and then deleting the account.

Short-lived account patterns might indicate non-approved people or processes might have the right to create and delete accounts that fall outside of established processes and policies. This type of behavior removes visible markers from the directory.

If the data trail for account creation and deletion is not discovered quickly, the information required to investigate an incident may no longer exist. For example, accounts might be deleted and then purged from the recycle bin. Audit logs are retained for 30 days. However, you can export your logs to Azure Monitor or a security information and event management (SIEM) solution for longer term retention.

What to monitor Risk Level Where Filter/sub-filter Notes
Account creation and deletion events within a close time frame. High Microsoft Entra audit logs Activity: Add user
Status = success
-and-
Activity: Delete user
Status = success
Search for user principal name (UPN) events. Look for accounts created and then deleted in under 24 hours.
Microsoft Sentinel template
Accounts created and deleted by non-approved users or processes. Medium Microsoft Entra audit logs Initiated by (actor) – USER PRINCIPAL NAME
-and-
Activity: Add user
Status = success
and-or
Activity: Delete user
Status = success
If the actors are non-approved users, configure to send an alert.
Microsoft Sentinel template
Accounts from non-approved sources. Medium Microsoft Entra audit logs Activity: Add user
Status = success
Target(s) = USER PRINCIPAL NAME
If the entry isn't from an approved domain or is a known blocked domain, configure to send an alert.
Microsoft Sentinel template
Accounts assigned to a privileged role. High Microsoft Entra audit logs Activity: Add user
Status = success
-and-
Activity: Delete user
Status = success
-and-
Activity: Add member to role
Status = success
If the account is assigned to a Microsoft Entra role, Azure role, or privileged group membership, alert and prioritize the investigation.
Microsoft Sentinel template
Sigma rules

Both privileged and non-privileged accounts should be monitored and alerted. However, since privileged accounts have administrative permissions, they should have higher priority in your monitor, alert, and respond processes.

Accounts not following naming policies

User accounts not following naming policies might have been created outside of organizational policies.

A best practice is to have a naming policy for user objects. Having a naming policy makes management easier and helps provide consistency. The policy can also help discover when users have been created outside of approved processes. A bad actor might not be aware of your naming standards and might make it easier to detect an account provisioned outside of your organizational processes.

Organizations tend to have specific formats and attributes that are used for creating user and or privileged accounts. For example:

  • Admin account UPN = ADM_firstname.lastname@tenant.onmicrosoft.com

  • User account UPN = Firstname.Lastname@contoso.com

Frequently, user accounts have an attribute that identifies a real user. For example, EMPID = XXXNNN. Use the following suggestions to help define normal for your organization, and when defining a baseline for log entries when accounts don't follow your naming convention:

  • Accounts that don't follow the naming convention. For example, nnnnnnn@contoso.com versus firstname.lastname@contoso.com.

  • Accounts that don't have the standard attributes populated or aren't in the correct format. For example, not having a valid employee ID.

What to monitor Risk Level Where Filter/sub-filter Notes
User accounts that don't have expected attributes defined. Low Microsoft Entra audit logs Activity: Add user
Status = success
Look for accounts with your standard attributes either null or in the wrong format. For example, EmployeeID
Microsoft Sentinel template
User accounts created using incorrect naming format. Low Microsoft Entra audit logs Activity: Add user
Status = success
Look for accounts with a UPN that does not follow your naming policy.
Microsoft Sentinel template
Privileged accounts that don't follow naming policy. High Azure Subscription List Azure role assignments using the Azure portal - Azure RBAC List role assignments for subscriptions and alert where sign-in name does not match your organizations format. For example, ADM_ as a prefix.
Privileged accounts that don't follow naming policy. High Microsoft Entra directory List Microsoft Entra role assignments List roles assignments for Microsoft Entra roles alert where UPN doesn't match your organizations format. For example, ADM_ as a prefix.

For more information on parsing, see:

Accounts created outside normal processes

Having standard processes to create users and privileged accounts is important so that you can securely control the lifecycle of identities. If users are provisioned and deprovisioned outside of established processes, it can introduce security risks. Operating outside of established processes can also introduce identity management problems. Potential risks include:

  • User and privileged accounts might not be governed to adhere to organizational policies. This can lead to a wider attack surface on accounts that aren't managed correctly.

  • It becomes harder to detect when bad actors create accounts for malicious purposes. By having valid accounts created outside of established procedures, it becomes harder to detect when accounts are created, or permissions modified for malicious purposes.

We recommend that user and privileged accounts only be created following your organization policies. For example, an account should be created with the correct naming standards, organizational information and under scope of the appropriate identity governance. Organizations should have rigorous controls for who has the rights to create, manage, and delete identities. Roles to create these accounts should be tightly managed and the rights only available after following an established workflow to approve and obtain these permissions.

What to monitor Risk Level Where Filter/sub-filter Notes
User accounts created or deleted by non-approved users or processes. Medium Microsoft Entra audit logs Activity: Add user
Status = success
and-or-
Activity: Delete user
Status = success
-and-
Initiated by (actor) = USER PRINCIPAL NAME
Alert on accounts created by non-approved users or processes. Prioritize accounts created with heightened privileges.
Microsoft Sentinel template
User accounts created or deleted from non-approved sources. Medium Microsoft Entra audit logs Activity: Add user
Status = success
-or-
Activity: Delete user
Status = success
-and-
Target(s) = USER PRINCIPAL NAME
Alert when the domain is non-approved or known blocked domain.

Unusual sign-ins

Seeing failures for user authentication is normal. But seeing patterns or blocks of failures can be an indicator that something is happening with a user's Identity. For example, during Password spray or Brute Force attacks, or when a user account is compromised. It's critical that you monitor and alert when patterns emerge. This helps ensure you can protect the user and your organization's data.

Success appears to say all is well. But it can mean that a bad actor has successfully accessed a service. Monitoring successful logins helps you detect user accounts that are gaining access but aren't user accounts that should have access. User authentication successes are normal entries in Microsoft Entra sign-in logs. We recommend you monitor and alert to detect when patterns emerge. This helps ensure you can protect user accounts and your organization's data.

As you design and operationalize a log monitoring and alerting strategy, consider the tools available to you through the Azure portal. Microsoft Entra ID Protection enables you to automate the detection, protection, and remediation of identity-based risks. ID Protection uses intelligence-fed machine learning and heuristic systems to detect risk and assign a risk score for users and sign-ins. Customers can configure policies based on a risk level for when to allow or deny access or allow the user to securely self-remediate from a risk. The following ID Protection risk detections inform risk levels today:

What to monitor Risk Level Where Filter/sub-filter Notes
Leaked credentials user risk detection High Microsoft Entra risk detection logs UX: Leaked credentials

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Microsoft Entra Threat Intelligence user risk detection High Microsoft Entra risk detection logs UX: Microsoft Entra threat intelligence

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Anonymous IP address sign-in risk detection Varies Microsoft Entra risk detection logs UX: Anonymous IP address

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Atypical travel sign-in risk detection Varies Microsoft Entra risk detection logs UX: Atypical travel

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Anomalous Token Varies Microsoft Entra risk detection logs UX: Anomalous Token

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Malware linked IP address sign-in risk detection Varies Microsoft Entra risk detection logs UX: Malware linked IP address

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Suspicious browser sign-in risk detection Varies Microsoft Entra risk detection logs UX: Suspicious browser

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Unfamiliar sign-in properties sign-in risk detection Varies Microsoft Entra risk detection logs UX: Unfamiliar sign-in properties

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Malicious IP address sign-in risk detection Varies Microsoft Entra risk detection logs UX: Malicious IP address

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Suspicious inbox manipulation rules sign-in risk detection Varies Microsoft Entra risk detection logs UX: Suspicious inbox manipulation rules

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Password Spray sign-in risk detection High Microsoft Entra risk detection logs UX: Password spray

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Impossible travel sign-in risk detection Varies Microsoft Entra risk detection logs UX: Impossible travel

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
New country/region sign-in risk detection Varies Microsoft Entra risk detection logs UX: New country/region

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Activity from anonymous IP address sign-in risk detection Varies Microsoft Entra risk detection logs UX: Activity from Anonymous IP address

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Suspicious inbox forwarding sign-in risk detection Varies Microsoft Entra risk detection logs UX: Suspicious inbox forwarding

API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules
Microsoft Entra threat intelligence sign-in risk detection High Microsoft Entra risk detection logs UX: Microsoft Entra threat intelligence
API: See riskDetection resource type - Microsoft Graph
See What is risk? Microsoft Entra ID Protection
Sigma rules

For more information, visit What is ID Protection.

What to look for

Configure monitoring on the data within the Microsoft Entra sign-in logs to ensure that alerting occurs and adheres to your organization's security policies. Some examples of this are:

  • Failed Authentications: As humans we all get our passwords wrong from time to time. However, many failed authentications can indicate that a bad actor is trying to obtain access. Attacks differ in ferocity but can range from a few attempts per hour to a much higher rate. For example, Password Spray normally preys on easier passwords against many accounts, while Brute Force attempts many passwords against targeted accounts.

  • Interrupted Authentications: An Interrupt in Microsoft Entra ID represents an injection of a process to satisfy authentication, such as when enforcing a control in a Conditional Access policy. This is a normal event and can happen when applications aren't configured correctly. But when you see many interrupts for a user account it could indicate something is happening with that account.

    • For example, if you filtered on a user in Sign-in logs and see a large volume of sign in status = Interrupted and Conditional Access = Failure. Digging deeper it may show in authentication details that the password is correct, but that strong authentication is required. This could mean the user isn't completing multi-factor authentication (MFA) which could indicate the user's password is compromised and the bad actor is unable to fulfill MFA.
  • Smart lock-out: Microsoft Entra ID provides a smart lock-out service which introduces the concept of familiar and non-familiar locations to the authentication process. A user account visiting a familiar location might authenticate successfully while a bad actor unfamiliar with the same location is blocked after several attempts. Look for accounts that have been locked out and investigate further.

  • IP changes: It is normal to see users originating from different IP addresses. However, Zero Trust states never trust and always verify. Seeing a large volume of IP addresses and failed sign-ins can be an indicator of intrusion. Look for a pattern of many failed authentications taking place from multiple IP addresses. Note, virtual private network (VPN) connections can cause false positives. Regardless of the challenges, we recommend you monitor for IP address changes and if possible, use Microsoft Entra ID Protection to automatically detect and mitigate these risks.

  • Locations: Generally, you expect a user account to be in the same geographical location. You also expect sign-ins from locations where you have employees or business relations. When the user account comes from a different international location in less time than it would take to travel there, it can indicate the user account is being abused. Note, VPNs can cause false positives, we recommend you monitor for user accounts signing in from geographically distant locations and if possible, use Microsoft Entra ID Protection to automatically detect and mitigate these risks.

For this risk area, we recommend you monitor standard user accounts and privileged accounts but prioritize investigations of privileged accounts. Privileged accounts are the most important accounts in any Microsoft Entra tenant. For specific guidance for privileged accounts, see Security operations – privileged accounts.

How to detect

You use Microsoft Entra ID Protection and the Microsoft Entra sign-in logs to help discover threats indicated by unusual sign-in characteristics. For more information, see the article What is ID Protection. You can also replicate the data to Azure Monitor or a SIEM for monitoring and alerting purposes. To define normal for your environment and to set a baseline, determine:

  • the parameters you consider normal for your user base.

  • the average number of tries of a password over a time before the user calls the service desk or performs a self-service password reset.

  • how many failed attempts you want to allow before alerting, and if it will be different for user accounts and privileged accounts.

  • how many MFA attempts you want to allow before alerting, and if it will be different for user accounts and privileged accounts.

  • if legacy authentication is enabled and your roadmap for discontinuing usage.

  • the known egress IP addresses are for your organization.

  • the countries/regions your users operate from.

  • whether there are groups of users that remain stationary within a network location or country/region.

  • Identify any other indicators for unusual sign-ins that are specific to your organization. For example days or times of the week or year that your organization doesn't operate.

After you scope what normal is for the accounts in your environment, consider the following list to help determine scenarios you want to monitor and alert on, and to fine-tune your alerting.

  • Do you need to monitor and alert if Microsoft Entra ID Protection is configured?

  • Are there stricter conditions applied to privileged accounts that you can use to monitor and alert on? For example, requiring privileged accounts only be used from trusted IP addresses.

  • Are the baselines you set too aggressive? Having too many alerts might result in alerts being ignored or missed.

Configure ID Protection to help ensure protection is in place that supports your security baseline policies. For example, blocking users if risk = high. This risk level indicates with a high degree of confidence that a user account is compromised. For more information on setting up sign in risk policies and user risk policies, visit ID Protection policies.

The following are listed in order of importance based on the effect and severity of the entries.

Monitoring external user sign ins

What to monitor Risk Level Where Filter/sub-filter Notes
Users authenticating to other Microsoft Entra tenants. Low Microsoft Entra sign-in log Status = success
Resource tenantID != Home Tenant ID
Detects when a user 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
Microsoft Sentinel template
Sigma rules
User state changed from Guest to Member Medium Microsoft Entra audit logs Activity: Update user
Category: UserManagement
UserType changed from Guest to Member
Monitor and alert on change of user type from Guest to Member. Was this expected?
Microsoft Sentinel template
Sigma rules
Guest users invited to tenant by non-approved inviters Medium Microsoft Entra audit logs Activity: Invite external user
Category: UserManagement
Initiated by (actor): User Principal Name
Monitor and alert on non-approved actors inviting external users.
Microsoft Sentinel template
Sigma rules

Monitoring for failed unusual sign ins

What to monitor Risk Level Where Filter/sub-filter Notes
Failed sign-in attempts. Medium - if Isolated Incident
High - if many accounts are experiencing the same pattern or a VIP.
Microsoft Entra sign-in log Status = failed
-and-
Sign-in error code 50126 -
Error validating credentials due to invalid username or password.
Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.
Microsoft Sentinel template
Sigma rules
Smart lock-out events. Medium - if Isolated Incident
High - if many accounts are experiencing the same pattern or a VIP.
Microsoft Entra sign-in log Status = failed
-and-
Sign-in error code = 50053 – IdsLocked
Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.
Microsoft Sentinel template
Sigma rules
Interrupts Medium - if Isolated Incident
High - if many accounts are experiencing the same pattern or a VIP.
Microsoft Entra sign-in log 500121, Authentication failed during strong authentication request.
-or-
50097, Device authentication is required or 50074, Strong Authentication is required.
-or-
50155, DeviceAuthenticationFailed
-or-
50158, ExternalSecurityChallenge - External security challenge wasn't satisfied
-or-
53003 and Failure reason = blocked by Conditional Access
Monitor and alert on interrupts.
Define a baseline threshold, and then monitor and adjust to suit your organizational behaviors and limit false alerts from being generated.
Microsoft Sentinel template
Sigma rules

The following are listed in order of importance based on the effect and severity of the entries.

What to monitor Risk Level Where Filter/sub-filter Notes
Multi-factor authentication (MFA) fraud alerts. High Microsoft Entra sign-in log Status = failed
-and-
Details = MFA Denied
Monitor and alert on any entry.
Microsoft Sentinel template
Sigma rules
Failed authentications from countries/regions you don't operate out of. Medium Microsoft Entra sign-in log Location = <unapproved location> Monitor and alert on any entries.
Microsoft Sentinel template
Sigma rules
Failed authentications for legacy protocols or protocols that aren't used. Medium Microsoft Entra sign-in log Status = failure
-and-
Client app = Other Clients, POP, IMAP, MAPI, SMTP, ActiveSync
Monitor and alert on any entries.
Microsoft Sentinel template
Sigma rules
Failures blocked by Conditional Access. Medium Microsoft Entra sign-in log Error code = 53003
-and-
Failure reason = blocked by Conditional Access
Monitor and alert on any entries.
Microsoft Sentinel template
Sigma rules
Increased failed authentications of any type. Medium Microsoft Entra sign-in log Capture increases in failures across the board. That is, the failure total for today is >10% on the same day, the previous week. If you don't have a set threshold, monitor and alert if failures increase by 10% or greater.
Microsoft Sentinel template
Authentication occurring at times and days of the week when countries/regions don't conduct normal business operations. Low Microsoft Entra sign-in log Capture interactive authentication occurring outside of normal operating days\time.
Status = success
-and-
Location = <location>
-and-
Day\Time = <not normal working hours>
Monitor and alert on any entries.
Microsoft Sentinel template
Account disabled/blocked for sign-ins Low Microsoft Entra sign-in log Status = Failure
-and-
error code = 50057, The user account is disabled.
This could indicate someone is trying to gain access to an account once they have left an organization. Although the account is blocked, it is important to log and alert on this activity.
Microsoft Sentinel template
Sigma rules

Monitoring for successful unusual sign ins

What to monitor Risk Level Where Filter/sub-filter Notes
Authentications of privileged accounts outside of expected controls. High Microsoft Entra sign-in log Status = success
-and-
UserPricipalName = <Admin account>
-and-
Location = <unapproved location>
-and-
IP Address = <unapproved IP>
Device Info= <unapproved Browser, Operating System>
Monitor and alert on successful authentication for privileged accounts outside of expected controls. Three common controls are listed.
Microsoft Sentinel template
Sigma rules
When only single-factor authentication is required. Low Microsoft Entra sign-in log Status = success
Authentication requirement = Single-factor authentication
Monitor periodically and ensure expected behavior.
Sigma rules
Discover privileged accounts not registered for MFA. High Azure Graph API Query for IsMFARegistered eq false for administrator accounts.
List credentialUserRegistrationDetails - Microsoft Graph beta
Audit and investigate to determine if intentional or an oversight.
Successful authentications from countries/regions your organization doesn't operate out of. Medium Microsoft Entra sign-in log Status = success
Location = <unapproved country/region>
Monitor and alert on any entries not equal to the city names you provide.
Sigma rules
Successful authentication, session blocked by Conditional Access. Medium Microsoft Entra sign-in log Status = success
-and-
error code = 53003 – Failure reason, blocked by Conditional Access
Monitor and investigate when authentication is successful, but session is blocked by Conditional Access.
Microsoft Sentinel template
Sigma rules
Successful authentication after you have disabled legacy authentication. Medium Microsoft Entra sign-in log status = success
-and-
Client app = Other Clients, POP, IMAP, MAPI, SMTP, ActiveSync
If your organization has disabled legacy authentication, monitor and alert when successful legacy authentication has taken place.
Microsoft Sentinel template
Sigma rules

We recommend you periodically review authentications to medium business impact (MBI) and high business impact (HBI) applications where only single-factor authentication is required. For each, you want to determine if single-factor authentication was expected or not. In addition, review for successful authentication increases or at unexpected times, based on the location.

What to monitor Risk Level Where Filter/sub-filter Notes
Authentications to MBI and HBI application using single-factor authentication. Low Microsoft Entra sign-in log status = success
-and-
Application ID = <HBI app>
-and-
Authentication requirement = single-factor authentication.
Review and validate this configuration is intentional.
Sigma rules
Authentications at days and times of the week or year that countries/regions do not conduct normal business operations. Low Microsoft Entra sign-in log Capture interactive authentication occurring outside of normal operating days\time.
Status = success
Location = <location>
Date\Time = <not normal working hours>
Monitor and alert on authentications days and times of the week or year that countries/regions do not conduct normal business operations.
Sigma rules
Measurable increase of successful sign ins. Low Microsoft Entra sign-in log Capture increases in successful authentication across the board. That is, success totals for today are >10% on the same day, the previous week. If you don't have a set threshold, monitor and alert if successful authentications increase by 10% or greater.
Microsoft Sentinel template
Sigma rules

Next steps

See these security operations guide articles:

Microsoft Entra security operations overview

Security operations for consumer accounts

Security operations for privileged accounts

Security operations for Privileged Identity Management

Security operations for applications

Security operations for devices

Security operations for infrastructure