Entra ID Monitoring: MFA, SSO, Conditional Access, and User Management Guide 2026
Why Entra ID Monitoring Problems Keep Happening
I've seen this exact scenario play out on dozens of enterprise tenants: an IT admin gets a call that a user can't sign in. They dig into the portal, can't find the relevant log, and end up spending two hours hunting for data that should have taken two minutes to find. If you're here, you've probably lived that story yourself.
Entra ID Monitoring , Microsoft's identity monitoring and health system inside Microsoft Entra ID, is one of the most powerful tools in the Microsoft cloud stack. But it's also one of the most misconfigured. The root problem isn't that the feature is broken. It's that the admin center spreads the relevant controls across multiple blades, the default log retention is only 30 days, and critical diagnostic settings are left unconfigured out of the box.
Here's what's actually going on under the hood. Microsoft Entra ID generates three distinct types of activity logs: audit logs, sign-in logs, and provisioning logs. Each answers a different class of question. Audit logs tell you the history of every task performed in your tenant, who granted admin group access, what changes were made to an app registration, which policies were modified. Sign-in logs capture every authentication attempt across your users and client applications, which is where your MFA failures, SSO errors, and Conditional Access blocks land. Provisioning logs track the automated user lifecycle, who got created in ServiceNow, who was removed from Adobe, what happened to those Workday accounts flowing into Active Directory.
When Entra ID Monitoring isn't working properly, the symptoms are usually one of these: you can't see sign-in logs older than a few days, Conditional Access failure reasons are missing from the sign-in record, you're getting no alerts on risky sign-ins, or the provisioning logs for a third-party app are blank. None of these states generate a clear error message. Microsoft just quietly doesn't show you data it was never configured to collect or route.
The frustrating part, and I know this is frustrating, especially when a security incident is actively unfolding, is that by the time you realize the logs are missing, you may have already lost the data. The 30-day default retention window means if you haven't set up a diagnostic settings route to Azure Monitor, a storage account, or an event hub, that data is just gone after a month.
The other common culprit is permissions. Reading sign-in logs requires at minimum the Reports Reader, Security Reader, Security Administrator, or Global Administrator role. A lot of junior admins assigned to investigate a sign-in issue simply don't have one of those roles, and the portal returns a blank screen rather than an access denied error.
This guide walks you through every layer of Entra ID Monitoring setup and troubleshooting, from getting your first sign-in log loaded, to routing data to Azure Monitor, to interpreting Conditional Access failure codes in real time. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before diving into full diagnostic settings configuration, check the two things that fix about 70% of Entra ID Monitoring problems in under five minutes.
First: confirm your role assignment. Go to the Microsoft Entra admin center and navigate to Identity > Users > [your account] > Assigned roles. You need at least Reports Reader to see sign-in and audit logs. If your account doesn't have this role, have a Global Administrator assign it, then sign out and back in.
Second: check the date range filter. This sounds absurdly simple, but I've watched experienced engineers spend twenty minutes thinking logs are missing when the date picker was just defaulted to "Last 24 hours" and the event they needed happened three days ago. In the Entra admin center, go to Identity > Monitoring & health > Sign-in logs. Look at the filter bar at the top of the log table. Click the Date filter and change it to Last 7 days or Last 30 days. Hit Apply. Nine times out of ten the event you're looking for appears immediately.
If neither of those quick checks resolves your issue, you're likely dealing with one of three deeper problems: diagnostic settings aren't configured (meaning logs aren't being routed anywhere beyond the default 30-day in-portal view), the log category you need wasn't enabled when your workspace was set up, or you're looking for provisioning log data that was never generated because the provisioning job itself failed silently.
For MFA-specific failures, the fastest diagnostic path is the Authentication methods activity report under Identity > Monitoring & health > Usage & insights. This report breaks down MFA success and failure by method, Authenticator app, SMS, phone call, hardware token, and shows you exactly where the breakdown is happening without requiring you to filter through thousands of raw sign-in log entries.
For Conditional Access blocks, open a specific sign-in log entry and click the Conditional Access tab inside that entry. Each policy that evaluated against that sign-in shows its result: Success, Failure, or Not Applied. The failure reason is spelled out in plain text, "Device is not compliant," "MFA required but not satisfied," "Location not permitted", which saves you from having to decode error codes manually.
Getting to the right log type is the foundation of everything else. In the Microsoft Entra admin center at entra.microsoft.com, expand the left navigation to Identity > Monitoring & health. You'll see four primary options: Audit logs, Sign-in logs, Provisioning logs, and Usage & insights.
Use Audit logs when your question is about configuration changes, who granted access to an admin group, who modified an app registration, which Conditional Access policy was changed and when. The audit log captures every task performed in your tenant with a timestamp, the actor who performed it, the target resource, and the operation type. Filter by Activity using the dropdown to scope to a specific action category like "User management" or "Application management."
Use Sign-in logs when your question is about authentication, a specific user can't sign in, MFA is prompting unexpectedly, SSO is redirecting incorrectly, or you need to understand the sign-in pattern of a specific account. The sign-in logs have sub-tabs at the top: User sign-ins (interactive), User sign-ins (non-interactive), Service principal sign-ins, and Managed identity sign-ins. Non-interactive sign-ins, often invisible to the end user, are where token refresh failures and app-to-app auth problems hide.
Use Provisioning logs when you've connected a third-party HR or SaaS app (Workday, ServiceNow, Adobe, SAP SuccessFactors) to Entra ID for automated user lifecycle management and need to verify what the provisioning engine did. Filter by Status (Success / Failure / Skipped) and by the Action (Create / Update / Delete / Disable) to narrow down quickly.
Once you've loaded the right log type, use the Add filters button to add targeted columns: User (UPN or display name), Application, Status (Success/Failure/Interrupted), IP address, or Location. If a specific sign-in failure is reported by a user, the fastest filter combination is User + Date + Status:Failure. The matching entries usually appear within seconds.
If you see the table populated, you're in good shape. If it's blank after applying a filter and reasonable date range, move to Step 2, you likely have a permissions or diagnostic settings gap.
The default in-portal log retention in Entra ID is 30 days for sign-in logs and audit logs. For most security and compliance scenarios, that's nowhere near enough. Configuring diagnostic settings is how you route log data to a long-term destination before it expires.
Navigate to Identity > Monitoring & health > Diagnostic settings. Click + Add diagnostic setting. Give it a descriptive name like EntraLogs-AzureMonitor-Prod.
Under Category groups, check the log categories you want to capture. For full Entra ID Monitoring coverage, select all of: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, ManagedIdentitySignInLogs, and ProvisioningLogs. Don't skip the non-interactive and service principal categories, that's exactly where app authentication failures and token expiry issues show up.
Under Destination details, choose one or more of the following:
- Send to Log Analytics workspace, best option for querying with KQL and building Azure Monitor Workbooks
- Archive to a storage account, best for long-term compliance archival at low cost
- Stream to an event hub, required for routing to third-party SIEM tools like Splunk, Sentinel, or QRadar
If you're using Microsoft Sentinel, select Stream to an event hub and configure the Sentinel data connector on the Sentinel side to consume from that hub. The Microsoft Entra data connector in Sentinel can also be configured to pull logs directly from the API if you prefer that approach over event hub streaming.
Click Save. Diagnostic settings take effect within about 15 minutes. After that window, new log events start flowing to your chosen destination. Note: this setting does not backfill historical data. Only events generated after the diagnostic setting is saved will appear in your destination.
# Verify diagnostic settings are active via Azure CLI
az monitor diagnostic-settings list \
--resource /tenants/{tenantId}/providers/microsoft.aadiam \
--resource-type Microsoft.Aad/IamOnce configured, you should see data flowing into your Log Analytics workspace within 15–30 minutes. Run a quick test KQL query like SigninLogs | take 10 in the Log Analytics workspace to confirm ingestion is working.
This is where most of the real investigative work happens. When a user reports they're being blocked by MFA or Conditional Access, the sign-in logs tell you exactly what happened, you just need to know where to look.
Go to Identity > Monitoring & health > Sign-in logs > User sign-ins (interactive). Filter by the user's UPN and set the date range to cover when the failure occurred. Find the failed sign-in entry, it'll show a red Failure status badge.
Click the entry to open the detail pane. Work through these tabs in order:
Basic info tab: Confirms the user, app, client app type (browser vs. modern auth client), IP, location, and timestamp. Check the Sign-in error code field. Common codes you'll encounter:
AADSTS50076, MFA required by policy, user didn't complete itAADSTS50158, External security challenge not satisfied (often third-party MFA)AADSTS53003, Access blocked by Conditional Access policyAADSTS70011, Invalid scope, the requested scope is not valid for this applicationAADSTS90072, User account doesn't exist in this tenant (common with guest account SSO failures)
Conditional Access tab: Lists every CA policy that evaluated against this sign-in. Each shows: the policy name, whether it applied, and the result. If a policy shows Failure, expand it to see the specific grant control that wasn't met, Require MFA, Require compliant device, Require hybrid Azure AD joined device, etc.
If you see Report-only in the policy result, that policy is in test mode, it evaluated but didn't actually block anything. This is expected if the policy is being piloted before enforcement.
Authentication details tab: Shows each step of the authentication sequence and whether it succeeded. This is where you see exactly which MFA method was attempted (Microsoft Authenticator push, TOTP, SMS, etc.) and whether the user completed it, timed out, or denied the request. If a user says "I never got the push notification," the authentication details will show whether the Authenticator request was even sent.
// KQL, Find all Conditional Access failures in the last 7 days
SigninLogs
| where TimeGenerated > ago(7d)
| where ConditionalAccessStatus == "failure"
| project TimeGenerated, UserPrincipalName, AppDisplayName,
ConditionalAccessStatus, ResultDescription,
IPAddress, Location
| order by TimeGenerated descIf the KQL query above returns results in your Log Analytics workspace, your diagnostic settings are working correctly and you have full visibility into CA failures across the tenant.
The audit log is your paper trail for every administrative action taken in the tenant. When someone shows up in an admin group they shouldn't be in, or an app starts misbehaving after a configuration change, this is where the answer lives.
Go to Identity > Monitoring & health > Audit logs. The key filters here are:
- Date range, set to cover the window when the change could have happened
- Category, use "UserManagement" for role and group changes, "ApplicationManagement" for app registration changes, "Policy" for Conditional Access policy changes
- Activity, use the search box to type the specific operation, e.g., "Add member to role" or "Update application"
- Initiated by (actor), filter by the account you suspect made the change
- Target, filter by the specific user, group, or app that was changed
Every audit log entry shows you four critical pieces: the Activity (what operation ran), the Initiated by (who or what ran it, this could be a user, a service principal, or a Microsoft internal service), the Target(s) (what was affected), and the Modified properties section inside the entry detail which shows the before and after values for any changed attribute.
One scenario I see constantly: someone escalates that a user was added to the Global Administrator role without going through proper change control. In the audit log, filter Category: RoleManagement, Activity: Add member to role, then click into the matching entry. The Modified properties section shows the role that was assigned and the exact UPN of the account that performed the assignment. You have your answer in under a minute.
For app changes, filter Category: ApplicationManagement and look for activities like Update application, Add owner to application, or Add credentials to application (this last one is important, new client secrets or certificates added to an app registration is a significant security signal).
# Pull audit logs via Microsoft Graph, all role assignment changes in last 48 hours
GET https://graph.microsoft.com/v1.0/auditLogs/directoryAudits
?$filter=activityDateTime ge 2026-04-19T00:00:00Z
and category eq 'RoleManagement'
and activityDisplayName eq 'Add member to role'
&$orderby=activityDateTime desc
&$top=50If you need audit log data older than 30 days and haven't set up diagnostic settings yet, the data is unfortunately gone from the in-portal view. This is exactly why setting up a Log Analytics workspace or storage account destination (Step 2) matters so much, do it before you need it.
Beyond the raw logs, Entra ID Monitoring includes a proactive recommendations engine that analyzes your tenant configuration daily and flags gaps against Microsoft security best practices. I've found this feature catches misconfigurations that IT teams don't even know to look for.
Navigate to Identity > Overview > Recommendations. Microsoft Entra ID runs a daily analysis of your tenant configuration and surfaces actionable items ranked by impact. Each recommendation includes a description of the issue, a summary of why it matters, a step-by-step action plan, and, critically, a list of impacted resources so you know exactly which accounts, apps, or policies the recommendation applies to.
Common recommendations you'll see in most tenants include:
- Enable MFA for all users, lists every account that doesn't have an MFA method registered
- Remove unused credentials from applications, flags app registrations with expired or orphaned client secrets
- Convert per-user MFA to Conditional Access MFA, older tenants that enabled MFA at the per-user level (in the legacy MFA portal) should move to CA-based MFA for better control
- Migrate to Microsoft Authenticator from SMS, surfaces users still relying on SMS-based MFA
- Review and clean inactive user accounts, accounts that haven't signed in for 90+ days
For Identity Secure Score (now surfaced inside Entra Recommendations), you'll see a numeric score out of 100 that reflects your tenant's overall security posture. Each improvement action shows the point value you'd gain by completing it, useful for prioritizing where to spend your time.
Microsoft Entra Health (separate from recommendations) provides global SLA attainment data and health signals for key scenarios like MFA, password reset, and device registration. Go to Identity > Monitoring & health > Microsoft Entra Health to see whether service-level issues on Microsoft's side are contributing to authentication failures you're investigating.
# Pull recommendations via Microsoft Graph
GET https://graph.microsoft.com/beta/directory/recommendations
?$filter=status eq 'active'
&$orderby=priority ascWork through active recommendations systematically, start with the highest-priority ones, use the provided action plan, and mark each as Completed or Dismissed with reason so your recommendation list stays actionable rather than cluttered.
Advanced Troubleshooting
When the standard log views don't give you enough data, usually in enterprise or domain-joined scenarios, here's where to go deeper.
Analyzing logs in Azure Monitor with KQL: Once your diagnostic settings are routing data to a Log Analytics workspace, you can run KQL queries that go far beyond what the in-portal filters support. The tables you'll use most are SigninLogs, AuditLogs, and AADProvisioningLogs. Here are three queries I run regularly:
// Top 20 sign-in failure reasons in the last 30 days
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType != 0
| summarize FailureCount = count() by ResultDescription
| top 20 by FailureCount desc
// Detect sign-ins from unusual countries, alert candidates
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize SignInCount = count() by UserPrincipalName,
CountryOrRegion = tostring(LocationDetails.countryOrRegion)
| where CountryOrRegion !in ("United States", "United Kingdom", "Canada")
| order by SignInCount desc
// Service principal sign-ins, new apps authenticating in last 24h
AADServicePrincipalSignInLogs
| where TimeGenerated > ago(1d)
| summarize FirstSeen = min(TimeGenerated) by ServicePrincipalName, AppId
| where FirstSeen > ago(1d)
| order by FirstSeen descInactive user account management: For Microsoft 365 and Azure environments with hundreds or thousands of accounts, the Inactive users workbook under Identity > Monitoring & health > Workbooks is invaluable. It surfaces accounts that haven't had a successful interactive sign-in in 30, 60, or 90+ days. These stale accounts are a primary attack vector, they often retain licenses and permissions long after an employee leaves. The workbook pulls directly from the sign-in logs, so it requires at least some log retention beyond the default 30 days to be accurate.
SSO and application sign-in failures via the Enterprise Apps blade: For SSO-specific failures with a federated app (SAML, OIDC, or OAuth2), navigate to Identity > Applications > Enterprise applications > [your app] > Sign-in logs. This scoped view shows only authentication attempts for that specific app, which cuts through the noise in tenants with hundreds of applications. The Sign-in diagnostic feature (accessible via the Diagnose & solve problems blade on the Enterprise app) walks you through a guided troubleshooting wizard for common SSO failures without requiring you to interpret raw log data manually.
Entra ID Connect sync errors (hybrid environments): In hybrid environments where on-premises Active Directory syncs to Entra ID via Microsoft Entra Connect, provisioning failures sometimes appear in the Entra Provisioning logs rather than the on-premises sync client logs. If you're seeing users who exist on-prem but don't appear in Entra ID, or attribute values aren't syncing correctly, check the Provisioning logs filtered to Source: Microsoft Entra Connect and look for entries with Status: Failure. The error detail includes both the Entra-side error code and the AD attribute that caused the rejection.
Streaming to external SIEM (Splunk, QRadar, Elastic): Configure an Azure Event Hub namespace in the same region as your Entra tenant. In diagnostic settings, route all log categories to the event hub. In your SIEM, install the Microsoft Entra ID data connector (most major SIEMs have a pre-built one). The event hub delivers logs with sub-minute latency in most configurations, significantly faster than the Azure Monitor ingestion path, which can have 5–15 minute delays.
If you're seeing blank sign-in logs even after verifying role assignments, diagnostic settings, and date range filters, and your tenant is less than 30 days old or recently had a major configuration change, there may be a backend provisioning issue with your log pipeline. Escalate to Microsoft Support with your tenant ID and the specific log category that's missing. Also escalate if you're seeing latency beyond 48 hours in log delivery to your Log Analytics workspace, or if Microsoft Entra Health shows degraded service signals that have persisted longer than 4 hours without a posted resolution.
Prevention & Best Practices
Most Entra ID Monitoring gaps I encounter are preventable. The organizations that avoid these problems aren't doing anything exotic, they've just set up the basics correctly and checked them on a regular schedule.
The single highest-impact thing you can do is configure diagnostic settings on day one of your tenant. Before you onboard any users, before you configure any Conditional Access policies, route your logs to a Log Analytics workspace. The cost of log ingestion in Azure Monitor is minimal compared to the cost of a security incident you can't investigate because the log data expired. A workspace in the same Azure region as your Entra tenant costs roughly $2–4 per GB ingested depending on your region and commitment tier.
Review your Entra ID Recommendations on a monthly cadence at minimum. Microsoft adds new recommendations as new security best practices emerge, checking once a quarter means you're always running 3 months behind on known risk signals in your tenant. Book 30 minutes on your calendar each month and work through any new active recommendations.
For MFA specifically, audit MFA registration coverage regularly using the Authentication methods > Registration and reset report under Identity > Monitoring & health > Usage & insights. This report shows you what percentage of your users have registered each MFA method, which users have zero MFA methods (highest risk), and which users are still on legacy SMS-only authentication. Target 100% Authenticator app registration for privileged accounts, no exceptions.
Set up Microsoft Entra workbooks for your most common monitoring scenarios. The built-in workbooks cover sign-in analysis, MFA gaps, Conditional Access insights, and risky user trends. These are parameterized dashboards you can share with your security team so they don't need direct Entra admin access to monitor identity health signals.
- Configure diagnostic settings to Log Analytics before onboarding users, retroactive log recovery is impossible once 30 days passes.
- Create a dedicated Reports Reader role assignment for your security operations team so they can investigate sign-in issues without needing Global Admin access.
- Enable Conditional Access: Sign-in risk policy at minimum, this automatically blocks high-risk sign-ins (Entra ID Identity Protection flags stolen credentials and impossible travel) with zero manual log review required.
- Schedule a monthly review of inactive user accounts using the Inactive Users workbook, accounts unused for 90+ days should be disabled pending HR confirmation, not deleted outright.
Frequently Asked Questions
What is Entra ID Monitoring and what does it actually cover?
Entra ID Monitoring is the identity monitoring and health system built into Microsoft Entra ID. It covers three core activity log types, audit logs (every configuration change in your tenant), sign-in logs (every authentication attempt by users and apps), and provisioning logs (automated user lifecycle events with connected SaaS apps). On top of those raw logs, it includes reports like Usage & Insights, proactive Recommendations that analyze your tenant configuration daily, customizable Workbooks for visual analysis, and the Microsoft Entra Health dashboard that tracks service-level health signals. Together, these give you a full picture of what's happening with identity in your environment, from individual sign-in failures to tenant-wide security posture.
How do I find out who gave someone access to an admin group in my tenant?
Go to Identity > Monitoring & health > Audit logs. Set the Category filter to RoleManagement or GroupManagement depending on whether the access was via a role or a group membership, then filter the Activity to "Add member to role" or "Add member to group." Set the Target filter to the user who was added. The matching entry will show the exact UPN and display name of the actor who performed the assignment, along with the timestamp and the specific role or group that was changed. Expand the entry and check Modified Properties to see the exact before/after values for complete certainty.
What's the sign-in pattern of a specific user, and how do I see it over time?
In Identity > Monitoring & health > Sign-in logs, filter by the user's UPN and extend the date range to the maximum 30-day window available in the portal. Sort by time to see their authentication sequence, which apps they access, from which IPs and locations, and whether MFA was completed each time. For a visual time-series view of sign-in frequency and patterns, use the Sign-ins workbook under Monitoring & health > Workbooks. For patterns beyond 30 days, you need Log Analytics with diagnostic settings configured, the KQL query SigninLogs | where UserPrincipalName == "user@domain.com" | summarize count() by bin(TimeGenerated, 1d) gives you a daily sign-in count over any historical window.
How do I check what users were provisioned or removed in a connected SaaS app like ServiceNow or Adobe?
Go to Identity > Monitoring & health > Provisioning logs. Filter by the Application dropdown to select ServiceNow, Adobe, or whichever app you're investigating. Set the Action filter to the operation you're verifying, Create, Update, Delete, or Disable. Set Status to Success if you want to confirm completed operations, or Failure if you're investigating why a user wasn't provisioned or removed correctly. Each log entry shows the source identity (from your HR system or Entra ID), the target identity in the SaaS app, the exact operation, and a reason code if it failed. Common failure reason codes include AzureActiveDirectoryForbidden (permissions gap in the app connector), InvalidAnchor (matching attribute mismatch), and EntryAlreadyExists (the user already exists in the target app).
What are Entra ID Recommendations and should I be acting on them?
Entra ID Recommendations are the result of a daily automated analysis that Microsoft runs against your tenant configuration, comparing it to security best practices and flagging gaps. Yes, you should absolutely act on them, especially anything flagged as high priority. Each recommendation includes an exact step-by-step action plan and a list of the specific resources (users, apps, policies) affected, so there's no guesswork about what to change. They now incorporate Identity Secure Score recommendations too, which means acting on them directly improves your measurable security posture score. Treat the Recommendations blade as your monthly security checklist rather than a one-time setup page.
Why are my Entra ID sign-in logs only showing 30 days of data, how do I keep them longer?
The default in-portal log retention for Entra ID sign-in and audit logs is 30 days, and there's no way to extend it within the Entra portal itself. To keep logs longer, you must configure diagnostic settings to route the logs to an external destination. Your options are: a Log Analytics workspace (best for querying and analysis, configurable retention up to 730 days), an Azure Storage Account (cheapest for pure archival, supports retention policies for compliance), or an Azure Event Hub (for real-time streaming to a SIEM). Navigate to Identity > Monitoring & health > Diagnostic settings, click Add, select all log categories, choose your destination, and save. Only events generated after that moment will be retained beyond 30 days, there's no way to backfill historical data that has already expired.