How to Audit and Monitor Users in Azure AD (Microsoft Entra ID) to Reduce Security Risk: The Complete Guide

Quick summary: auditing and monitoring users in Azure AD / Entra ID in 11 points

1. Define objective and scope: which risks to reduce (phishing, brute force, token theft, excessive privilege, forgotten guests).
2. Choose signals and sources: audit logs, sign-in logs (interactive and non-interactive), app/service logs, and Identity Protection signals.
3. Set retention: how long to keep logs and where (portal vs Log Analytics/Storage) so incidents can be investigated weeks later.
4. Baselining: define what “normal” looks like (countries, apps, schedules, devices, roles) so anomalies stand out.
5. Prioritize alerts: mass sign-in failures, unusual MFA, MFA disabled, role assignments, suspicious app creation.
6. Block legacy authentication: identify and eliminate POP/IMAP/SMTP AUTH and other patterns that drastically increase risk.
7. Monitor Conditional Access properly: report-only to test, logs to understand impact, fine-tune to avoid gaps or lockouts.
8. Keep privileges under control: PIM, just-in-time activation, role auditing, alerts for critical changes.
9. Guest governance: invitation control, cleanup, periodic access reviews, and collaboration expiration.
10. Centralize and correlate: Log Analytics/Sentinel for detection, KQL for investigation, playbooks for response.
11. Continuous operations: daily/weekly/monthly routines with clear owners (IT, security, business) and evidence.

Take a breath before the details: the goal is not to stockpile logs, but to turn them into signals and decisions. This guide focuses on how to do that in a practical, maintainable way.

Introduction: why audit and monitor users in Azure AD (Microsoft Entra ID)

Identity is the most repeated entry point in modern incidents: if an account falls, an attacker doesn’t need to “break” a server; they just sign in as if they were a real person. That’s why auditing and monitoring users in Azure AD (now Microsoft Entra ID) isn’t a luxury—it’s the foundation for detecting anomalous access, reducing response time, and preserving evidence when it’s time to explain what happened.

Auditing isn’t only about “having logs.” It’s about answering, quickly, the questions that always appear during an incident: Who signed in? From where? With which application? Which policies applied? Were MFA methods or roles changed? What changed in the tenant? and for how long was it exposed?

This guide takes a practical approach: what to look at, how to interpret it, how to centralize it, and how to turn it into an operable system that the team can run (without heroes or improvised reviews).

Intro recap: monitoring identities means turning “isolated events” into investigable, actionable signals. The sections below make this practical in Entra ID.

1. Risk model: what to prevent and which signals help

Before configuring alerts, it helps to define a simple risk model. No complex theoretical framework is needed—just identify the scenarios that can cause the most damage and the signals that reveal them.

1.1 Common identity risk scenarios

• Credential theft (phishing): the user types their password into a fake site or approves an illegitimate MFA prompt.
• Brute-force / password spray attacks: many attempts against many accounts, often using a small set of common passwords.
• Access from unexpected locations or devices: unusual countries, suspicious ASNs, unregistered devices.
• Persistence: the attacker creates an app, grants permissions, adds an MFA method, creates rules, or plants backdoors.
• Privilege escalation: role assignments, admin activations, changes to security policies.
• Guest risk: external access that persists for months without review, guests with higher permissions than expected.

1.2 Signals worth turning into “alerts” (not just logs)

With these signals, the project stops being “let’s review users” and becomes “let’s detect specific high-impact patterns.” That difference is what makes the system maintainable.

Section 1 recap: defining risks and signals prevents “monitor everything” chaos. The rest of the guide turns signals into logs, alerts, and routines.

2. Readiness: roles, log access, retention, and evidence

Two problems appear in almost every organization: (1) not everyone can access logs when an incident happens and (2) when it’s time to investigate, the data is gone (or incomplete). This section lays the groundwork.

2.1 Minimum roles and separation of duties

It’s recommended that log access doesn’t depend solely on Global Administrator. A realistic approach is role-based access by function: log readers, security admins, SIEM operators, etc. Also, privileged access should be temporary (PIM) and auditable.

2.2 Retention: the part everyone misses “later”

In the portal, logs look “recent,” but incidents are often investigated late: after a vendor notice, a suspicious transaction, or a leak. That’s why it’s worth deciding upfront:

• Which log types must be kept longer (sign-ins, audit, risk, role changes, app consent).
• Which platform retains them (Log Analytics, Storage, SIEM) and at what cost.
• How evidence is accessed (KQL, dashboards, exports, audit processes).

2.3 Separate “identity activity” from “Microsoft 365 auditing”

Entra ID provides identity logs (sign-ins and directory changes). But many organizations also need auditing of actions inside Microsoft 365 (for example, document activity, Teams activity, etc.). It’s important not to mix them up: identity auditing and Microsoft 365 activity auditing complement each other, but they are not the same thing.

Section 2 recap: without retention and clear roles, monitoring fails when it matters most. Next are the two pillars: audit logs and sign-in logs.

3. Audit Logs in Entra ID: what they record and how to use them well

Audit logs record changes: what is created, modified, or deleted in the directory and related objects (users, groups, apps, licenses, roles, configurations). They answer: “Who changed what, and when?”

3.1 What to look for in auditing (high-impact examples)

• User creation / deletion and re-enabling disabled accounts.
• Authentication method changes (MFA registration/updates) and password resets.
• Role assignments (direct or via PIM) and privilege changes.
• Application creation, consent grants, and permission changes.
• Policy changes (Conditional Access, security, identity configuration).

3.2 How to read an audit event without getting lost

To make audit logs useful, it helps to train a consistent reading pattern:

1. Actor: who performed the change (user, service, app, automation).
2. Target: which object was affected (user/group/app/policy).
3. Operation: what action occurred (Add, Update, Delete, Assign, Consent).
4. Result: success/failure and error details.
5. Context: IP, location, app used, correlation with sign-ins and tickets.

3.3 A realistic pattern to investigate “persistence”

In identity incidents, persistence often shows up as “small” but critical changes: a new app consent, an MFA method change, a role assignment, or a rule created via automation. A structured investigation typically follows this order:

1. Confirm the suspicious sign-in (sign-in logs).
2. Review audit logs to see what changed after that access.
3. Search for equivalent changes in similar accounts (same pattern, same IP, same app).
4. Revoke sessions / tokens, revert changes, and document evidence.

Section 3 recap: audit logs explain changes. Next is understanding sign-ins, because that’s where the access enabling those changes becomes visible.

4. Sign-in Logs in Azure AD / Entra ID: sign-in types and practical interpretation

Sign-in logs explain access: authentication attempts and outcomes. They’re the foundation for detecting brute force, unusual locations, device changes, suspicious applications, and systematic failures. They also help understand which security policies were evaluated (Conditional Access, MFA, risk, etc.).

4.1 Sign-in types (more important than it sounds)

Not every sign-in is “a user typing a password.” Entra ID has multiple sign-in types, and understanding them avoids false positives or blind spots:

• Interactive user sign-ins: visible user sign-in flows (portal, app, Office, etc.).
• Non-interactive user sign-ins: activity where the user doesn’t “see” a login (token renewals, background processes, apps acting on behalf of the user).
• Service principal sign-ins: application authentications (app identity), keys/certificates, automations.
• Managed identity sign-ins: Azure managed identities (workloads) accessing resources without traditional credentials.

4.2 Fields worth “mastering” in a sign-in record

• User / Identity: who signed in (UPN, object ID, type: member, guest, workload).
• Application: what app was accessed (Microsoft 365, Azure portal, third-party app, internal app).
• Client app / Authentication protocol: browser, mobile/desktop, legacy, etc.
• Device: registered, compliant, join type, OS, browser.
• Location / IP: country, approximate city, ASN (when correlated in a SIEM).
• Conditional Access: policies evaluated, whether MFA was required, whether access was blocked and why.
• Risk: associated risk signals (when available) and correlation with Identity Protection.

4.3 Practical reading: five questions that speed up any investigation

1. Is it isolated or repeated? Is it a one-off event or a series (many accounts / many IPs)?
2. Does it match normal behavior? location, time, device, and typical apps for that user.
3. What failed exactly? credentials, MFA, Conditional Access, device state, session, blocked user.
4. Which policies were involved? Conditional Access in enforced mode or report-only, requirements and results.
5. What happened next? audit trail: account changes, roles, MFA methods, apps, permissions.

Section 4 recap: sign-in logs explain access and context. Next is a classic and highly cost-effective risk reduction: eliminating legacy authentication.

5. Detect and block legacy authentication (legacy auth) to reduce risk

Legacy authentication (older protocols and patterns without modern MFA) still appears in many environments due to historic compatibility. The issue is that, from a risk perspective, it’s often a preferred entry point for automated attacks.

5.1 How to detect legacy auth using sign-in logs

A practical detection approach is typically two steps:

1. Identify which accounts and apps use it (users, IPs, client apps, frequency).
2. Determine whether it’s truly needed (a real legacy app, printer/MFP, old integration, or just a configuration kept by inertia).

5.2 Blocking with Conditional Access (no improvisation)

Blocking is typically implemented with a dedicated policy. The key is to do it with control:

• Start in report-only mode if there’s uncertainty, to measure impact before enforcing.
• Exclude emergency (break-glass) accounts with compensating controls, and ensure they’re properly protected.
• Confirm dependencies in printers, integrations, or old apps and plan replacements.

Section 5 recap: blocking legacy auth removes a large chunk of risk. Next is leveraging risk signals and detections (Identity Protection).

6. Microsoft Entra ID Protection: risk, detections, and response to compromised accounts

Microsoft Entra ID Protection adds a key layer: risk signals and detections to identify suspicious activity before it turns into a larger intrusion. The practical value shows up when those signals are connected to decisions: require MFA, block, force reset, or trigger an investigation process.

6.1 What ID Protection monitors

• Risky users: users with elevated risk based on signals and detections.
• Risky sign-ins: sign-ins deemed risky (behavior, location, patterns, etc.).
• Detections: events explaining why risk is assigned (anomalies, leaked credentials, etc.).

6.2 Practical response: a realistic action flow

When a user becomes risky or a risky sign-in occurs, a consistent flow helps:

1. Fast triage: confirm whether the event matches user context (travel, corporate VPN, device change).
2. Correlation: review sign-ins near the time window, target apps, locations, and previous failures.
3. Containment: revoke sessions, force password reset, require strong MFA, or temporarily block.
4. Reversal: remove illegitimate MFA methods, revoke suspicious consents, review roles.
5. Closure: document evidence, adjust policies, and create a preventive alert if the pattern repeats.

6.3 Avoid the classic mistake: “many signals, little action”

ID Protection can generate valuable information, but without a process to prioritize, investigate, and act, it becomes just another dashboard. A practical way to avoid that is to define:

• Which threshold opens a ticket/incident (high risk, repeated risky sign-ins, specific detections).
• Which actions are authorized (block, reset, session revocation, role review).
• How to confirm with the user (and through which channel, assuming email/Teams may be compromised).

Section 6 recap: ID Protection provides risk signals; real value comes from connecting those signals to Conditional Access and a response procedure.

7. Monitor Conditional Access: impact, report-only, and low-friction troubleshooting

Conditional Access is one of the most powerful controls to reduce risk, but also one of the most likely to generate incidents if deployed without visibility. That’s why monitoring its impact is almost as important as designing the policy.

7.1 Report-only: test without blocking

Report-only mode lets administrators simulate the outcome of many policies without enforcing them, recording what would have happened in the sign-in logs. It’s a practical way to prevent a security change from unexpectedly blocking a critical business area.

7.2 What to review in sign-in logs when there are issues

• Policy details: which policies evaluated and their outcomes (grant, block, require MFA, device compliance).
• Failure reason: why it failed (MFA, non-compliant device, out-of-scope user, unexpected app).
• Client app: whether access comes from an old client or a legacy protocol.
• Location: policies by country, named locations, or false positives caused by VPN.

7.3 Insights & Reporting: from “cases” to a global view

In organizations with mature Conditional Access, insights help identify trends: which policies block the most, where friction is high, and which changes to prioritize. This is especially helpful when hardening access in phases.

Section 7 recap: Conditional Access is governed through visibility. With report-only and log analysis, friction drops and security improves without blocking the business.

8. Privileges and roles: auditing admins, PIM, and critical changes

In identity security, the rule is simple: the more privilege, the more control and evidence. A compromised admin or an illegitimate role assignment can have immediate, broad impact. That’s why auditing roles and privileges must be a top priority.

8.1 Recommended controls for admin accounts

• Account separation: standard user account and administrative account (depending on the organization’s model).
• Strong MFA: phishing-resistant where possible.
• Dedicated Conditional Access: require compliant device, controlled location, or an extra security step.
• No permanent privilege: use PIM for time-bound, justified activation.

8.2 What to monitor in PIM (beyond “it’s enabled”)

PIM reduces exposure, but usage monitoring is what matters:

• Out-of-hours activations or unclear justifications.
• New eligible assignments to sensitive roles.
• PIM configuration changes (approval requirements, duration, MFA).
• Critical roles assigned directly (should be exceptional).

Section 8 recap: privileges require “extra” control: PIM, auditing, and alerts. After admins, the next frequent focus is the guest ecosystem.

9. Guest users (B2B) in Azure AD / Entra ID: control, reviews, and cleanup

Guest users tend to grow silently: projects, vendors, consultants, customers. Over time they become a risk if there is no expiration, access review, and cleanup. A serious user auditing system includes guests from day one.

9.1 Signals worth monitoring for guests

• Guests with access to sensitive sites or applications.
• Guests who haven’t signed in for months but still have permissions.
• Unusual spikes or bulk invitations (visible in audit logs).
• Role changes or membership in critical groups (should be rare).

9.2 Access Reviews: the tool that brings the most “order”

Access reviews establish a routine: every X weeks or months, owners review who should continue to have access. It’s especially useful for guests and groups that grant access to critical resources.

9.3 Best practices that prevent recurring issues

• Assign a business owner for each external collaboration (project/customer/vendor).
• Avoid “sharing inward” internal resources not designed for externals; create dedicated spaces.
• Expiration and cleanup when the project ends (or when the guest is no longer used).

Section 9 recap: guests aren’t “a detail”—they are identities with access. Access Reviews plus periodic cleanup turns diffuse risk into a controlled process.

10. Centralizing Entra ID logs: Log Analytics, Event Hub, Storage, and correlation

When deeper incident investigation (or compliance evidence) is required, portal-only logs are rarely enough. Centralizing logs provides longer retention, powerful searches (KQL), correlation, and smarter alerts.

10.1 Common options (and when to choose each)

• Log Analytics: analysis and investigation (KQL), workbooks, alerts, Sentinel integration.
• Event Hub: near-real-time streaming into external SIEMs or platforms.
• Storage account: long-term archiving and cost-effective retention for audits.

10.2 Which logs to export at a minimum

A reasonable baseline usually includes:

• Sign-in logs (including non-interactive and, where relevant, service principals).
• Audit logs (changes to users, roles, apps, policies).
• Risk events / Identity Protection (if licensed and used as a security signal).

10.3 First use cases in Log Analytics (to deliver value fast)

If logs are centralized but nobody uses them, it becomes pure cost. Start with concrete use cases:

• Top users with sign-in failures in the last 24 hours.
• New countries/locations per user (last 7 days).
• Apps with spikes in access or unusual failures.
• Critical audit events (roles, MFA, apps, consents).

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize Failed=count(), Apps=dcount(AppDisplayName), IPs=dcount(IPAddress) by UserPrincipalName
| order by Failed desc
| take 20

let lookback = 30d;
let recent = 2d;
let baseline =
  SigninLogs
  | where TimeGenerated between (ago(lookback) .. ago(recent))
  | summarize CountriesBaseline=make_set(LocationDetails.countryOrRegion) by UserPrincipalName;
SigninLogs
| where TimeGenerated > ago(recent)
| summarize CountriesRecent=make_set(LocationDetails.countryOrRegion) by UserPrincipalName
| join kind=leftouter baseline on UserPrincipalName
| extend NewCountries=set_difference(CountriesRecent, CountriesBaseline)
| where array_length(NewCountries) > 0
| project UserPrincipalName, NewCountries, CountriesRecent

Section 10 recap: centralizing logs enables retention and correlation. Next is turning that foundation into detection and response: Sentinel and automation.

11. Microsoft Sentinel for identities: detections, rules, and playbooks

Microsoft Sentinel goes beyond “logs”: it correlates events, triggers alerts, opens incidents, and automates response. If an organization already uses Sentinel (or plans to), Entra ID is often one of the most valuable sources for early detection.

11.1 Detection scenarios that are usually worth a rule

• Password spray / brute force: many failures across many accounts from one or a few IPs.
• Impossible or inconsistent activity: sudden shifts in country/device for sensitive accounts.
• Privilege escalation: role assignment, Conditional Access changes, MFA changes.
• App-based persistence: unusual consent or high permissions granted.
• Legacy auth reappearance: after blocking, any attempt should alert.

11.2 Response playbooks (what’s worth automating)

Not everything should be automated, but some responses save substantial time:

• Notify security/IT with full context (user, IP, app, country, policies applied).
• Temporarily block or require reset (if allowed and approved in the procedure).
• Revoke sessions and tokens (when compromise indicators are strong).
• Create a ticket, assign an owner, and attach an investigation checklist.

Section 11 recap: Sentinel turns logs into manageable incidents and automates steps. Next is how to present this in dashboards and reporting that the team actually uses.

12. Dashboards and reporting: workbooks and views that truly help

A useful dashboard isn’t the one with “lots of charts,” but the one that answers operational questions: what’s getting worse, where activity looks abnormal, which policies are blocking too much, and which accounts need review.

12.1 Recommended minimum dashboard (to start)

• Access health: failure rate, top apps with failures, top users with failures.
• Geography: new countries, unusual locations, sensitive accounts by country.
• Security: critical audit events (roles/MFA/apps), legacy auth attempts.
• Risk: risky users, risky sign-ins, weekly trends.

12.2 Monthly reporting for leadership / audit (without noise)

Monthly reporting works best when it avoids overly technical detail and focuses on:

• Number of identity incidents, severity, and trend.
• Mean time to detect/respond (MTTD/MTTR).
• Primary drivers: residual legacy auth, weak MFA, Conditional Access exceptions, high-permission apps.
• Actions taken: new policies, privilege reduction, guest cleanup, improved retention.

Section 12 recap: dashboards connect technical operations to decisions. Next are concrete routines so monitoring doesn’t depend on “whenever someone remembers.”

13. Continuous operations: daily, weekly, and monthly routines to reduce risk

Auditing works when it becomes routine. A simple model is often enough:

13.1 Daily review (10–20 minutes, focused)

• Critical alerts (roles, MFA, policies, spikes in failures).
• High-risk users or risky sign-ins (where applicable).
• Open incidents and containment status.

13.2 Weekly review (more analytical)

• Top failure patterns and root causes (apps, Conditional Access, devices, locations).
• Review of “sensitive” accounts (admins, finance, HR) and their activity.
• Review of new/inactive guests and out-of-policy access.

13.3 Monthly review (governance and continuous improvement)

• Access Reviews for critical groups/resources.
• Conditional Access policy review: exceptions, report-only, friction tuning.
• Review of high-permission apps and recent consents.
• Investigation drill: pick a real case and validate evidence coverage (retention, correlation, procedures).

Section 13 recap: sustainable monitoring relies on routines. Next are checklists and snippets to make implementation even more practical.

14. Operational checklists for auditing and monitoring users in Azure AD / Entra ID

14.1 Design checklist (before configuration)

• Define priority risks (credentials, privileges, apps, guests).
• Choose signals/alerts and thresholds (what opens an incident vs what’s informational).
• Define roles and owners (read, investigate, change, approve).
• Define retention and log destination (portal vs Log Analytics/Storage/SIEM).
• Plan for eliminating legacy auth and dependencies.

14.2 Deployment checklist (configuration)

• Enable and validate access to audit logs and sign-in logs.
• Configure export/ingestion to Log Analytics (if applicable) and validate tables.
• Configure baseline workbooks/dashboards and at least 5 investigation queries.
• Configure Conditional Access policies (including report-only testing) and validate outcomes in logs.
• Enable and configure PIM (if applicable) and role-change alerts.

14.3 Operations checklist (day-to-day)

• Daily review of critical alerts and risky users.
• Weekly review of patterns (failures, locations, apps) and cleanup of inactive guests.
• Monthly reviews (Access Reviews), high-permission apps, and investigation drills.
• Document policy changes and incident evidence for audit readiness.

Section 14 recap: checklists turn security into a repeatable process. Next are technical examples ready to adapt (KQL/PowerShell/Graph).

15. Useful queries and snippets for auditing and monitoring (KQL/PowerShell/Graph)

These examples are intended as starting points. In real environments, they should be adapted to organizational naming, locations, roles, and applications.

15.1 KQL — spikes of failures by IP (possible password spray)

SigninLogs
| where TimeGenerated > ago(6h)
| where ResultType != 0
| summarize Failed=count(), Users=dcount(UserPrincipalName) by IPAddress
| where Failed > 50 and Users > 10
| order by Failed desc

15.2 KQL — critical audit changes (roles, MFA, apps)

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Add member to role", "Add eligible member to role", "Update user", "Add app role assignment", "Consent")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources, Result

15.3 PowerShell / Graph — auditing ideas (conceptual)

For many teams, value comes from automating reports: users without MFA methods registered, inactive guests, disabled accounts with recent activity, etc. Depending on the organization’s stack, this is done with Microsoft Graph (SDK, REST) or operational scripts.

Section 15 recap: examples accelerate investigation and reporting, but real value comes when they’re integrated into routines and alerting.

16. Frequently asked questions (FAQ) about auditing and monitoring users in Azure AD / Entra ID

17. Official resources and recommended links

• Audit logs in Microsoft Entra ID
• Sign-in logs in Microsoft Entra ID (log types)
• Microsoft Entra ID Protection (overview)
• Conditional Access: report-only
• Conditional Access insights & reporting workbook
• Configure diagnostic settings for Entra logs
• Integrate Entra logs with Azure Monitor logs
• Send Microsoft Entra ID data to Microsoft Sentinel
• Microsoft Entra report data retention policies

Related MSAdvance services: Microsoft 365 Security, Microsoft Sentinel, Modern Workplace.

18. Conclusion: how to audit and monitor users in Azure AD / Entra ID without losing control

Auditing and monitoring users in Azure AD (Microsoft Entra ID) works when it rests on four pillars: clear signals (what to detect), available evidence (retention and centralization), well-tuned controls (Conditional Access, PIM, removal of legacy auth), and continuous operations (routines, reviews, reporting).

As next steps, the following approach tends to work well:

• Define 10 high-value alerts (roles, MFA, spikes in failures, app consents, legacy auth).
• Centralize logs in Log Analytics or a SIEM and validate the ability to investigate 30–90 days back (or whatever business requirements demand).
• Apply a phased plan: report-only → tuning → enforcement, avoiding mass changes without visibility.
• Establish guest governance and access reviews as routine.