Microsoft Entra ID • SigninLogs • Identity Protection

The Login Was Successful But The Risk Was High

The sign-in succeeded. The password was correct. MFA was satisfied. The user reached Microsoft 365.

On the surface, everything looked normal.

But Entra ID had already marked the sign-in as high risk. Successful did not mean safe.

Agent Foskett investigation into successful high-risk sign-ins in Microsoft Entra ID
Briefing summary

A Microsoft 365 login appeared legitimate because it succeeded, but Entra ID risk signals showed the session was not as safe as it looked.

Sign-in result was successful
Risk level was marked high
SigninLogs revealed the real concern

What happened

The login did not fail. That was exactly why it was easy to underestimate.
The credentials worked The account authenticated successfully. From a basic login report, the event looked clean.
The risk signal did not fit Entra ID marked the sign-in as high risk. That changed the investigation from authentication success to trust validation.
The session needed investigation The question was no longer whether the login succeeded. The question was whether the person behind it should be trusted.

The KQL that changed everything

The evidence lived in Microsoft Entra ID SigninLogs. The hunt started by finding successful sign-ins where the risk level was still medium or high.
successful-high-risk-signin-investigation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == 0
| where RiskLevelDuringSignIn in~ ("medium", "high")
| extend
                            User = tostring(UserPrincipalName),
                            App = tostring(AppDisplayName),
                            City = tostring(LocationDetails.city),
                            Country = tostring(LocationDetails.countryOrRegion)
| project TimeGenerated, User, App, IPAddress, City, Country, ConditionalAccessStatus, RiskLevelDuringSignIn, RiskState, RiskDetail
| order by TimeGenerated desc
What it revealed The account had successful sign-ins that still carried a medium or high risk signal. The portal result said success, but the risk fields told another story.
No failed login required Attackers do not always generate noisy failed attempts. Sometimes the suspicious event is the one that worked.
The pattern was there Risk level, location, IP address, application, Conditional Access result and user behaviour created the timeline that explained the concern.

Agent Foskett moment

Everyone saw the successful result. The risk field was the detail that mattered.
The sign-in succeeded That made it easy to dismiss. Successful events often receive less attention than failed attempts.
The risk stayed high High-risk authentication activity should not be treated as routine just because the login was allowed.

This is where strong identity and access governance matters.
The logs showed the difference ResultType showed success. RiskLevelDuringSignIn, RiskState and RiskDetail explained why the event still needed review.
What it was not It was not just another successful login. It was not proof the user was safe. It was not something to ignore because MFA passed.
What it actually was A successful authentication event with risk evidence attached. The account entered the environment, but the trust level was already questionable.
Why it matters Successful sign-ins often become the start of the incident timeline. If the risky login is missed, everything after it looks like normal user activity.

What most environments miss

Identity risk should be investigated as evidence, not treated as background noise.
Success is not the same as safe A correct password and approved MFA prompt do not automatically prove the activity belongs to the real user.
Risk fields need monitoring RiskLevelDuringSignIn, RiskState, RiskDetail and ConditionalAccessStatus should be part of routine identity hunting.
The missing skill The investigation is not just whether access was granted. It is whether the granted access should have been trusted.

Related investigations

The User Passed MFA But It Wasn't Really Them Valid authentication does not always mean legitimate access when sessions, tokens and trust are abused. Read more →
The MFA Prompt Looked Normal MFA prompts can look legitimate while hiding attacker pressure or suspicious sign-in behaviour. Read more →
The Conditional Access Policy Was In Report-Only Mode A policy that evaluates but does not enforce can leave risky sessions untouched. Read more →
The Login Came Through A Trusted Device A trusted or compliant device does not automatically mean the activity is safe. Read more →
KQL Threat Hunting Guide Build practical Microsoft Defender XDR and Sentinel investigations across identity, endpoint and cloud signals. Read more →
The login succeeded.
The risk told the real story.
Contact GEMXIT

Final thought

Identity security is not just about whether access was granted. It is about whether that access should be trusted.
At GEMXIT We help organisations investigate Microsoft Entra ID sign-ins, risky users, Conditional Access outcomes and identity compromise evidence across Microsoft 365 environments. If you want to understand how this applies to your environment, see our Cyber Security services.
Agent Foskett mindset Do not just ask whether the login succeeded. Ask where it came from, why it was risky, what Conditional Access did and what happened after the session was granted.

Identity risk is one of the clearest places where Microsoft telemetry can tell the story before the incident becomes obvious. Start with Identity and Access, strengthen Endpoint Security visibility, and build the investigation skill with the KQL Threat Hunting Guide.

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD

Microsoft Entra ID High Risk Sign-In Investigation

This Agent Foskett briefing explains how successful sign-ins can still indicate Microsoft 365 account compromise when Entra ID risk signals mark the authentication event as medium or high risk.

Detect Successful But Risky Sign-Ins Using KQL

Microsoft Entra ID SigninLogs can help defenders investigate successful authentication events, RiskLevelDuringSignIn, RiskState, RiskDetail, Conditional Access results, IP addresses and location evidence using KQL.

Why Successful Authentication Does Not Always Mean Safe Access

When a Microsoft 365 account signs in successfully, defenders should still review risk signals, MFA behaviour, Conditional Access outcomes, session activity, device context and post-login activity before assuming the access was legitimate.