Lesson 25 — Microsoft Entra Monitoring Alerts
Microsoft Entra logs contain the evidence needed to identify risky sign-ins, privilege changes, application failures and suspicious workload identity activity.
Azure Monitor log search alert rules turn that evidence into proactive monitoring. A KQL query evaluates the incoming data, an alert condition determines when the rule fires and an action group delivers the notification or automation response.
This lesson explains alert architecture, KQL design, thresholds, evaluation frequency, action groups, alert processing rules, testing, tuning and practical Microsoft Entra monitoring scenarios.
What you will learn
This lesson explains how Microsoft Entra telemetry becomes proactive monitoring through KQL alert rules, Azure Monitor and action groups.
Learning objectives
After completing this lesson, you should be able to design and operate Microsoft Entra monitoring alerts.
- Explain the Azure Monitor alert architecture.
- Create KQL queries suitable for alerting.
- Configure log search alert rules.
- Use thresholds, time windows and evaluation frequency correctly.
- Configure action groups and notifications.
- Test, tune and document identity alerts.
- Distinguish alerting from dashboards and investigation.
The problem this solves
Logs are valuable only when someone reviews them in time.
Monitoring alerts identify important identity conditions automatically and notify responders before suspicious activity is buried beneath routine events.
Microsoft Entra alert architecture
Prerequisites
- Microsoft Entra logs routed to a Log Analytics workspace.
- Permission to query the workspace.
- Permission to create or modify alert rules.
- An Azure Monitor action group.
- A tested KQL query that returns the intended evidence.
Where alerts are created
In the Azure portal, open Monitor → Alerts and select Create → Alert rule.
The Log Analytics workspace is normally selected as the rule scope for Microsoft Entra log search alerts.
Core alert components
| Component | Purpose | Microsoft Entra example |
|---|---|---|
| Scope | The Azure resource monitored by the rule. | Log Analytics workspace receiving Entra logs. |
| Signal | The data source and alert type. | Custom log search. |
| Query | The KQL logic that identifies relevant events. | High-risk sign-ins in SigninLogs. |
| Measurement | The value used to compare against the threshold. | Number of matching rows. |
| Threshold | The point at which the alert fires. | Greater than zero events. |
| Evaluation | How often and over what time range the query runs. | Evaluate every five minutes over the last ten minutes. |
| Action group | Notification or automation target. | Email the SOC and invoke a Logic App. |
Start with the investigation question
Do not begin with the notification method.
First define the exact condition that deserves operational attention, such as a break-glass account sign-in, a new privileged role assignment or repeated application failures.
Build the query in Log Analytics
Develop and validate the KQL query before creating the alert rule.
Confirm that it finds true historical examples and excludes routine activity.
Alert query design
| Design principle | Why it matters | Better practice |
|---|---|---|
| Filter early | Large queries may be slower and more expensive. | Limit time, users, applications and result types near the start. |
| Return stable fields | Schema changes can break alert logic. | Use documented fields and test after platform changes. |
| Avoid unnecessary columns | Large result payloads add noise. | Project only evidence required for response. |
| Use explicit conditions | Ambiguous text searches generate false positives. | Use exact operation names, IDs or risk values where possible. |
| Preserve identifiers | Responders need event correlation. | Include timestamps, users, IP addresses and correlation IDs. |
Measurement and threshold
A common log alert measures the number of rows returned by the query.
For high-impact conditions, the threshold may be greater than zero. For noisy conditions, a higher count or grouped threshold is usually more useful.
Evaluation frequency
The evaluation frequency controls how often Azure Monitor runs the rule.
Faster evaluation improves detection speed but may increase alert activity and monitoring cost.
Lookback window
The lookback window defines how much data each evaluation examines.
It should normally be longer than the evaluation interval so delayed ingestion does not create blind spots.
Overlapping evaluations
Overlapping windows can detect the same event more than once.
Use alert state, suppression, splitting and query logic carefully to prevent repeated notifications for one incident.
Example 1 — Emergency access account sign-in
This condition normally deserves immediate investigation because emergency access accounts should rarely be used.
Suggested rule settings
- Measurement: Number of results.
- Operator: Greater than.
- Threshold: 0.
- Evaluation: Every 5 minutes.
- Lookback: 10 minutes.
- Severity: High.
Response evidence
Include the account, application, IP address, result, timestamp and correlation ID in the alert context.
Document the approved use and emergency access owner.
Example 2 — Repeated failed sign-ins
This query identifies users with repeated failures during the evaluation window. The threshold should be tuned to the organisation's normal authentication behaviour.
Why not alert on every failure?
Single sign-in failures are common and often harmless.
Alerting on every failure creates fatigue and hides genuinely suspicious patterns.
Improve the detection
Exclude known test accounts, trusted automation and understood legacy applications only when the exclusion is documented and reviewed.
Consider grouping by source IP, application and result code.
Example 3 — High-risk sign-in
Risk alert context
A high-risk result does not automatically prove compromise.
Responders should review Identity Protection detections, Conditional Access results, device evidence and post-authentication activity.
Built-in notifications
Microsoft Entra ID Protection also provides automated risk notification emails.
Use Azure Monitor alerts when custom KQL logic, routing or automation is required.
Example 4 — Privileged role assignment
Operation names can vary by activity and platform behaviour. Validate the exact values found in your tenant before enabling the alert.
Permanent vs eligible access
Privileged Identity Management may create different audit events for eligible assignments, active assignments and activations.
Build separate logic when the response priority differs.
Expected administration
Not every role assignment is malicious.
Correlate the event with change records, approvers, PIM justification and the identity that initiated the action.
Example 5 — Conditional Access policy change
Why this matters
A disabled, excluded or weakened Conditional Access policy can affect the entire tenant.
High-impact policy changes should be reviewed against approved change activity.
Tune the query
Review actual AuditLogs values in the tenant and narrow the query to create, update and delete operations that matter.
A broad text match is useful during discovery but should be refined for production.
Example 6 — Service principal failures
Workload identity importance
Service principals and managed identities may access important resources without an interactive user.
Monitoring must include workload identities as well as human sign-ins.
Common causes
- Expired client secret.
- Invalid certificate.
- Removed permission.
- Incorrect resource or tenant.
- Application deployment error.
- Abusive credential use.
Action groups
An action group defines what happens when the rule fires.
| Action | Typical use | Operational consideration |
|---|---|---|
| Notify administrators or the SOC. | Use monitored shared mailboxes, not one individual. | |
| SMS or voice | Urgent high-severity escalation. | Reserve for conditions that require immediate action. |
| Push notification | Notify Azure mobile application users. | Confirm the responder group is maintained. |
| Webhook | Send the alert to an external system. | Protect endpoints and validate payload handling. |
| Logic App | Automate enrichment, ticketing or response. | Use managed identity and least privilege. |
| ITSM integration | Create incidents in a service platform. | Avoid duplicate tickets from repeated evaluations. |
Action group design
Separate high-severity security alerts from routine operational notifications.
Use clear names, documented owners and tested destinations.
Test notifications
Use the action group test function and a controlled alert condition.
Confirm delivery, message formatting, escalation and after-hours ownership.
Alert processing rules
Alert processing rules can add action groups or suppress notifications under defined conditions.
They are useful for planned maintenance, temporary routing changes and centralised action management.
Suppression is not deletion
Suppressing notifications does not make the underlying security condition safe.
Maintenance windows and exceptions must be narrow, approved and time-limited.
Alert state and duplicate control
| Approach | Benefit | Risk |
|---|---|---|
| Stateless alert | Each evaluation can create a notification. | Repeated alerts may create noise. |
| Stateful alert | The alert remains active until the condition clears. | Short events may not behave as expected if poorly configured. |
| Split by dimensions | Creates separate alert instances per user, app or source. | Large numbers of dimensions can create alert storms. |
| Query suppression logic | Excludes recently processed or approved activity. | Complex logic can hide real events. |
Severity
Severity should reflect impact and response urgency rather than query complexity.
- Sev 0 — Critical, immediate response.
- Sev 1 — High priority.
- Sev 2 — Warning.
- Sev 3 — Informational.
- Sev 4 — Verbose or low priority.
Alert naming
Use names that state the resource, condition and scope.
Example: Entra ID — Emergency Access Account Sign-in — Production Tenant.
Agent Foskett investigation: “The alert fired 63 times overnight”
Alert validation
- Run the query against known historical events.
- Generate a controlled test event where safe.
- Confirm the rule fires at the expected time.
- Confirm notification delivery.
- Verify the alert contains useful evidence.
- Measure false positives and missed scenarios.
Operational ownership
- Who receives the alert?
- Who investigates it?
- What is the expected response time?
- What evidence must be collected?
- When is escalation required?
- Who approves tuning or suppression?
Common mistakes
| Mistake | Impact | Better practice |
|---|---|---|
| Creating the rule before testing the KQL | False alerts or missed events. | Validate against real historical data first. |
| Alerting on every failed sign-in | Severe alert fatigue. | Detect meaningful patterns and thresholds. |
| Using a very long lookback window | Repeated matches and slower queries. | Match the window to ingestion and response requirements. |
| Not monitoring action group delivery | Alerts fire but nobody receives them. | Test destinations and ownership regularly. |
| Ignoring workload identities | Application compromise or outages remain hidden. | Monitor service principals and managed identities. |
| Suppressing noisy alerts indefinitely | Real activity may be ignored. | Tune the detection and time-limit exceptions. |
| Providing no response guidance | Analysts waste time deciding what to do. | Attach a clear investigation runbook. |
Alert review checklist
- Is the monitored condition important?
- Does the query return the correct evidence?
- Are threshold and evaluation settings justified?
- Can the same event generate duplicates?
- Does the action group reach an owned destination?
- Is severity correct?
- Is a response runbook available?
- Has the alert been tested recently?
Security best practices
- Use least privilege for alert rule management.
- Protect webhook and automation credentials.
- Use managed identities for Logic Apps where possible.
- Monitor changes to alert rules and action groups.
- Review exclusions and suppression regularly.
- Track alert quality and response outcomes.
- Keep emergency access alerts highly visible.
Key takeaways
- Microsoft Entra monitoring alerts use exported logs, Log Analytics, KQL and Azure Monitor.
- A log search alert rule evaluates a query and creates an alert when its condition is met.
- Action groups deliver email, SMS, webhook, automation and ITSM responses.
- Evaluation frequency and lookback windows must account for ingestion delay and duplicate detection.
- High-value alerts include emergency access use, privileged changes, risky sign-ins and workload identity failures.
- Not every failed sign-in deserves an alert.
- Queries should preserve timestamps, identities, IP addresses and correlation IDs.
- Alert processing rules can route or suppress notifications but must be controlled carefully.
- Testing, tuning, ownership and response runbooks are essential parts of alert engineering.
Related Agent Foskett resources
Continue learning
Microsoft Entra Monitoring Alerts with Azure Monitor and KQL
Microsoft Entra monitoring alerts use Log Analytics, KQL log search alert rules, Azure Monitor action groups and alert processing rules to detect and respond to important identity conditions.
Microsoft Entra Academy Lesson 25 — Monitoring Alerts
This Agent Foskett lesson explains emergency access alerts, risky sign-in monitoring, privileged role changes, Conditional Access policy changes, workload identity failures, action groups, thresholds, evaluation windows, testing and alert tuning.
