How to Investigate Suspicious MFA Activity

A user says they received an MFA prompt they did not expect.

A few minutes later, you find a successful sign-in for the same account.

At that point, the useful question is not simply "Did MFA pass?"

You need to answer a more important set of questions:

This guide walks through that investigation from start to finish using Microsoft Entra logs.

Step 1: Open the Sign-In Logs First

In the Microsoft Entra admin center, go to:

Entra ID → Monitoring & health → Sign-in logs

Start with these filters:

Do not filter only for successful events. The failures before a successful sign-in often explain what actually happened.

For each suspicious event, record these fields:

Microsoft documents these values in the sign-in log activity details and the Azure Monitor SigninLogs table reference.

Figure 1 — Microsoft Entra interactive sign-in logs showing failed, interrupted, and successful authentication attempts for the test account from the same source IP.

Step 2: Open the Interrupted Event and Read Authentication Details

Now open the interrupted sign-in that occurred immediately after the first failures.

Go to Authentication Details.

This section is important because an interrupted sign-in can still tell you whether the primary credential was correct.

Microsoft Entra can satisfy an MFA requirement using authentication context from an existing token. The Authentication Details view can also show whether the sign-in used a fresh method such as Microsoft Authenticator, SMS, or another method, whether a token claim satisfied the requirement, or whether only the password step completed.

For the suspicious event, capture:

In this lab scenario, assume the suspicious event shows:

That tells us the primary credential was valid, even though the sign-in did not complete at that moment.

Now compare that with the events immediately before it.

Suppose you find:

This sequence is much more important than the single successful row.

The same IP, repeated failures, interrupted flows, later successful sign-ins, and activity in My Signins and Azure Portal fit a suspicious authentication sequence. It still does not prove compromise, but it gives you a concrete hypothesis to test.

Figure 2 — Authentication Details for the test account showing successful primary authentication with the correct password.

Step 3: Correlate the Event Instead of Reading Rows in Isolation

A portal view is useful for the first pass. If your Entra logs are sent to Log Analytics or Microsoft Sentinel, query the same window so you can compare events quickly.

Start with the affected user:

The goal is to build one ordered view of the authentication activity.

Then take the CorrelationId from the suspicious event and search for other events that share it:

Do not assume every event around the same time will share one correlation ID. Use it as one linkage point, then compare time, user, IP, application, session, and request identifiers as well.

Step 4: Compare the Suspicious Sign-In With the User's Normal Activity

Now widen the window.

Look at the user's previous successful sign-ins, not just the incident period.

A useful comparison window might be the previous 7 to 30 days, depending on how frequently the account signs in.

Compare the suspicious event with the baseline:

In this scenario, assume the previous two weeks show:

None of those differences proves compromise alone.

Together with the correct-password evidence, interrupted flows, later successful sign-ins, and security-info activity, they increase confidence that the sign-in needs escalation.

Check the IP Across the Tenant

Do not stop at the user.

Search the same IP across other identities:

If the IP attempted to authenticate to many accounts in a short period, you may be looking at a broader credential attack rather than one isolated user.

You can also list the raw events:

In the next screenshot, the same source IP appears across multiple test identities and applications, including Azure Portal and My Signins. In production, this is where you separate a shared legitimate network from a broader authentication attack.

Figure 3 — Microsoft Entra sign-in activity filtered to the test user, showing the authentication sequence in chronological order.

Figure 4 — Sign-in activity filtered by source IP. Searching the same IP across the tenant helps determine whether suspicious authentication activity is isolated to one account or appears across multiple identities.

Step 5: Check Whether the Account Added or Changed an Authentication Method

If an attacker gained access, they may try to create persistence.

Open:

Entra ID → Monitoring & health → Audit logs

Filter around the same time window and look for authentication-method activity such as:

Microsoft maintains these operation names in the Entra audit activity reference.

Be careful with time zones. The sign-in screenshots in this lab are shown in UTC, while the audit log screenshot is shown in local time. On September 17, 2026, 5:19 PM local time in the screenshot corresponds to 16:19 UTC.

If your audit logs are in Log Analytics, use a query like this:

Assume our lab investigation finds:

At this point, the investigation changes significantly.

A sequence of suspicious sign-ins followed by new authentication information is a strong persistence indicator.

Do not immediately delete the method before you record the evidence.

Capture:

The audit log also shows why context is important, an admin-registered phone method can appear in the same time period as user-registered security information. Record the initiator and method type before deciding which entries are legitimate recovery activity and which entries may be attacker persistence.

Then compare the user's currently registered methods with what they actually recognize.

For a direct inventory, Microsoft Graph can retrieve a user's registered authentication methods:

Use the least-privileged permissions appropriate for your investigation process.

Figure 5 — Microsoft Entra audit logs showing the registration of new security information, including a Microsoft Authenticator method, for the test account.

Step 6: Check What Happened After the Suspicious Sign-In

Successful authentication is not the end of the incident.

Now move forward in time.

Ask what resources the account accessed after the suspicious sign-in.

Start by querying the user's successful sign-ins after the event:

Look for applications or resources the user does not normally access.

If the account reached Exchange Online, SharePoint, Teams, Azure management, an administrative portal, or another sensitive workload, continue the investigation in that workload's audit logs.

The exact post-authentication checks depend on what the account can access.

For example, in an Exchange investigation you would want to know whether the attacker created or changed inbox rules, accessed messages, or performed other mailbox actions. In an administrative account investigation, you would review directory changes, role changes, application changes, and privileged operations.

The important point is to follow the access.

Do not close the investigation because the initial sign-in event itself has been explained.

Step 7: Ask the User Questions That Can Confirm or Break the Hypothesis

Contact the user through a trusted channel.

Do not rely on email or Teams if you think the account itself may be compromised.

Avoid asking only:

"Did you approve an MFA prompt?"

Ask questions tied to the evidence:

This makes the user's answer useful to the investigation.

In this case, assume the user confirms:

You now have user confirmation that supports the technical evidence.

Step 8: Decide Whether You Have Enough Evidence to Contain

Do not wait for every possible log source when the evidence already indicates active compromise.

Contain immediately when you have combinations such as:

A single unfamiliar location is not enough.

A location estimate can be wrong because of VPNs, mobile networks, proxies, and cloud services.

Step 9: Contain the Account

Once you confirm compromise, move from investigation to containment.

Microsoft's emergency access guidance and risk remediation guidance document several administrative actions for compromised identities. The exact order depends on your environment, but a practical response is:

In the Entra admin center, authentication administrators can manage actions such as password reset, requiring MFA re-registration, and revoking sessions from the user's authentication methods page.

Be careful with Require re-register MFA. Microsoft documents that this action removes several existing MFA methods, including Microsoft Authenticator registrations, phone numbers, and software OATH tokens. Use it deliberately as part of recovery, not as an exploratory step.

Step 10: Rebuild the Final Timeline

At the end of the investigation, you should be able to explain the incident chronologically.

For our lab scenario, the final timeline is:

That timeline is the output of the investigation.

Not the MFA alert.

What Should Go Into the Incident Record

Before you close the case, preserve enough evidence that another analyst can reproduce your conclusion.

Record:

If your conclusion is "benign", document why.

If your conclusion is "compromised", document which evidence crossed the threshold.

To understand the attack techniques behind suspicious MFA activity, read our guide to MFA bypass.