When a critical sign-in fails, is it a forgotten password or a botched MFA prompt? Understanding Entra audit logs is the only way to move beyond guesswork and secure your identity perimeter effectively.
Locating MFA Events in Microsoft Entra
Microsoft records MFA activity across two primary areas within the Entra admin centre. To access these, your account must be assigned at least the Reports Reader, Security Reader, or Global Reader role. These permissions allow you to view and download the telemetry necessary for security monitoring.
Sign-In Logs
Found under the Monitoring & health section of the Entra ID menu, sign-in logs focus on the authentication attempt itself. This is where you verify if a user was prompted for MFA and whether they successfully completed the challenge. These logs are essential for identifying patterns of failed access or suspicious sign-in locations.
Audit Logs
Audit logs track changes to the environment rather than individual sign-in attempts. For IT teams troubleshooting MFA for teams, this is where you can see when a user registered new security information, deleted a verification method, or changed their default sign-in factor. This trail ensures that every modification to a user’s security profile is documented.
Interpreting MFA Authentication Details
The most granular data lives within the Authentication Details tab of a specific sign-in event. You should not rely solely on the "authenticationRequirement" field, as it may report "single factor" if a previous MFA claim was satisfied during a persistent session. To get an accurate picture, you must examine the specific indicators within the event record.
- MFA Result: This confirms whether the challenge succeeded, failed, or was actively denied by the user on their device.
- Authentication Method: This field shows the specific factor used, such as a Microsoft Authenticator push notification, an OATH hardware token, or an SMS code.
- Error Code 500121: This is a common signal that the user did not complete the MFA prompt. In many cases, this occurs because the user has not finished their initial security info setup.
- Status Filtering: When investigating issues, filter by Status = Failure and Authentication requirement = Multifactor authentication to isolate blocked sign-ins.
For teams involved in shared account MFA management, these logs are vital for identifying which authentication methods are currently active across administrative logins and ensuring no unauthorised methods have been added.
Automating Log Analysis with Microsoft Graph
For larger environments, manual filtering in the portal is often inefficient. You can query MFA data programmatically via the Microsoft Graph API to extract authentication patterns into external SIEM tools. Accessing these logs via the API requires a Microsoft Entra ID P1 or P2 licence.
To build custom weekly security reports or automate monitoring, your application requires the "AuditLog.Read.All" permission. Using PowerShell cmdlets like Get-MgAuditLogSignIn allows you to filter by the creation date and time, enabling your team to identify trends in MFA usage or spikes in registration activity across the entire tenant.
Retention and Compliance Requirements
By default, Entra ID retains logs for only 7 days on Free tiers and 30 days for P1 or P2 licences. For many MFA compliance frameworks, such as SOC 2 or PCI DSS v4.0, these windows are insufficient. You must maintain a long-term audit trail to demonstrate control over administrative access.
To maintain an extended history, you must configure Diagnostic Settings to export logs to an external location. This ensures you can meet retention requirements and conduct forensic investigations months after an event occurs.
- Log Analytics Workspace: Best for active querying, creating dashboards, and setting up automated security alerts.
- Azure Storage Account: The most cost-effective option for long-term archival and meeting multi-year compliance mandates.
- Event Hub: Ideal for real-time streaming to third-party security platforms and external SOC providers.
Closing the Visibility Gap
Standard Entra logs tell you if a code worked, but they cannot tell you who viewed a shared TOTP secret if it is stored on a personal device or an unencrypted spreadsheet. This lack of accountability is a significant hurdle for SaaS MFA management in collaborative environments. When an MFA secret is tied to a single engineer's smartphone, it creates a single point of failure and obscures the audit trail.
By moving to a centralised MFA vault, you gain an additional layer of telemetry that Microsoft alone cannot provide. Every time a team member views, copies, or modifies a TOTP seed, a timestamped log is generated with the user's identity. This allows IT teams to correlate an Entra sign-in event with a specific person’s access to the MFA code, closing the loop on administrative accountability.
Relying on individual devices for corporate authentication secrets prevents the centralised visibility required for a robust Zero Trust MFA strategy. By combining Entra’s sign-in logs with granular access logging, you ensure every administrative action is accounted for and every secret is protected. Start your 14-day free trial of Gatera today to move your authentication secrets off personal phones and into a secure, audit-ready vault.