ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Conditional Access • Microsoft Entra ID • Sign-In Logs • MFA • Device Context • KQL

The Conditional Access Result Said Success — But That Wasn't the Whole Story

The sign-in was successful.

Conditional Access also reported Success.

The obvious conclusion was that the security controls had worked and there was nothing more to investigate.

Agent Foskett looked at the same event and asked a different question.

What, exactly, had succeeded?

Discuss identity security Back to investigations
Agent Foskett investigating a successful Microsoft Entra Conditional Access result
Conditional Access Investigation

The result was accurate. The interpretation was incomplete.

Inspect which policies actually applied
Review authentication and device context
Correlate the sign-in with what happened next

The word “Success” ended the investigation too early

Conditional Access is designed to evaluate policy conditions and grant or session controls during sign-in. A successful result tells you the applicable requirements were satisfied. It does not independently prove that the user, device, token or subsequent session activity was benign.
The policy result was realThe Conditional Access engine evaluated the sign-in and the applicable requirements were satisfied.
The security question was largerThe analyst still needed to understand who authenticated, from what device, with which method and what activity followed.
Context changed the meaningA technically successful control decision can exist inside a suspicious or compromised identity timeline.

The first clue was not the result — it was the timeline

Agent Foskett placed the sign-in beside the surrounding identity events. The Conditional Access result remained Success, but the rest of the sequence raised questions the result alone could not answer.
investigation-timeline.txt
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
01:52  Successful sign-in
01:52  Conditional Access = Success
01:52  MFA requirement satisfied
02:03  New authentication method registered
02:31  Privileged role activated
02:36  Administrative changes begin

Start with the sign-in event

In Microsoft Sentinel or Log Analytics environments where Entra sign-in data is available in SigninLogs, begin with the event itself. Keep the first query broad enough to preserve Conditional Access, authentication, device and location context.
inspect-signin.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
  15. 15
  16. 16
  17. 17
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          IPAddress,
          ConditionalAccessStatus,
          AuthenticationRequirement,
          AuthenticationDetails,
          DeviceDetail,
          LocationDetails,
          AppliedConditionalAccessPolicies
| order by TimeGenerated asc

Inspect the policies that were evaluated

Do not stop at the overall status. Expand the applied policy data and look at each policy result. A policy can be successful because its required controls were satisfied, while other policies may have been not applied, excluded or operating in report-only mode.
expand-conditional-access-policies.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
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| extend Policies = todynamic(AppliedConditionalAccessPolicies)
| mv-expand Policy = Policies
| project TimeGenerated,
          AppDisplayName,
          ConditionalAccessStatus,
          PolicyName = tostring(Policy.displayName),
          PolicyResult = tostring(Policy.result)
| order by TimeGenerated asc

Now inspect how authentication was satisfied

A successful MFA requirement is evidence that an accepted authentication path completed. The next question is which authentication steps occurred and whether they fit the user's normal behaviour and the wider incident timeline.
authentication-context.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
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| project TimeGenerated,
          AuthenticationRequirement,
          AuthenticationDetails,
          AuthenticationProcessingDetails,
          IPAddress,
          AppDisplayName,
          ConditionalAccessStatus
| order by TimeGenerated asc

The device context deserved its own question

Conditional Access decisions can use device-related signals, but investigators should still inspect the device information recorded for the sign-in. A compliant or managed status is useful context; it is not a substitute for investigating whether the session itself was expected.
device-context.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
  15. 15
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| extend Device = todynamic(DeviceDetail)
| project TimeGenerated,
          IPAddress,
          DeviceId = tostring(Device.deviceId),
          OperatingSystem = tostring(Device.operatingSystem),
          Browser = tostring(Device.browser),
          IsCompliant = tostring(Device.isCompliant),
          IsManaged = tostring(Device.isManaged),
          TrustType = tostring(Device.trustType),
          ConditionalAccessStatus

Compare the event with the user's normal sign-in pattern

One successful sign-in can look ordinary in isolation. Grouping recent sign-ins by IP address, application and Conditional Access status can help reveal whether the event belongs to a familiar pattern or is an outlier that deserves further investigation.
signin-baseline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ "alex.morgan@contoso.com"
| summarize SignIns = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
    by IPAddress, AppDisplayName, ConditionalAccessStatus
| order by SignIns desc

Report-only results are evidence — not enforcement

Microsoft Entra evaluates report-only Conditional Access policies during sign-in and records the outcome, but those policies do not enforce their controls. That makes report-only data valuable for analysis, while also making it essential not to confuse an evaluated result with an enforced block or grant requirement.
Check policy stateDetermine whether the relevant policy was enabled, report-only, excluded or outside the scope of the sign-in.
Do not infer enforcementA report-only result shows what the policy would have done; it does not mean that policy controlled the live sign-in.
Preserve the full decision contextPolicy result, authentication details, device state, application, location and later activity belong in the same investigation.

The important distinction: control success versus identity trust

Conditional Access answers whether configured access requirements were met for a sign-in. The investigator's job is broader: determine whether the sign-in and the resulting session belong to the legitimate user and fit the expected business context.
Success can be technically correctThe control may have worked exactly as configured, which is why the result should be understood rather than dismissed.
Success is not the end of attributionAuthentication and policy evidence still need to be connected to the real user, device and session.
Follow what happened nextMailbox changes, MFA registration, privileged-role activation and cloud activity can transform an apparently normal sign-in into the first event in a compromise timeline.

Agent Foskett's investigation mindset

Do not argue with the control result. Understand what it proved — and then investigate everything it did not prove.
Ask which policies appliedThe overall status is a starting point. The individual policy evaluations explain why that status was reached.
Ask what satisfied the controlsReview MFA, device and authentication details instead of assuming success automatically means expected behaviour.
Ask what came after the sign-inIdentity investigations become defensible when the access decision is connected to the actions performed with the resulting session.

Investigation findings

The Conditional Access result was not wrong. The mistake was treating one successful control decision as a complete security verdict.
Conditional Access reported SuccessThe applicable requirements for the sign-in were satisfied.
The surrounding identity evidence was suspiciousAuthentication-method and privilege events changed the context in which the successful sign-in had to be interpreted.
The timeline provided the answerThe sign-in became meaningful only when Conditional Access, authentication, device and post-authentication events were investigated together.

Related Agent Foskett investigations

Continue with identity compromise, MFA, Conditional Access and privileged-access investigations.
The New MFA Method Was Registered 11 Minutes After The LoginCorrelate a successful sign-in with a suspicious authentication-method registration.
The Global Administrator Role Was Active for Only 17 MinutesReconstruct temporary privilege elevation during an identity compromise.
The Conditional Access Policy Was In Report-Only ModeUnderstand the difference between evaluating a policy and enforcing it.
The Login Was Successful — But The Risk Was HighInvestigate why a technically successful authentication can still deserve attention.
The User Passed MFA — But It Wasn't Really ThemExplore why MFA success is evidence, not automatic proof of user intent.
Agent Foskett AcademyBuild practical KQL and Microsoft security investigation skills through structured lessons.
Conditional Access said Success. The investigation still had questions.
Understand the decision, inspect the context and follow the session.
Visit the Agent Foskett Academy

Final thought

Security controls produce results. Investigators determine what those results mean when placed beside the rest of the evidence.
The result was not misleadingConditional Access reported the outcome of its policy evaluation for that sign-in.
The interpretation was too broadA successful access decision cannot answer every question about user intent, session legitimacy or later activity.
Trust the evidence, not a single labelThe strongest conclusion comes from the complete identity timeline.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Conditional Access Result Said Success — But That Wasn't the Whole Story

This Agent Foskett investigation explores why a Microsoft Entra Conditional Access Success result should be understood in context rather than treated as a complete security verdict. The investigation follows sign-in, authentication, device and post-authentication evidence across one identity timeline.

Microsoft Entra Conditional Access And Sign-In Log Investigation

The page demonstrates how investigators can inspect SigninLogs, ConditionalAccessStatus, AppliedConditionalAccessPolicies, AuthenticationDetails, DeviceDetail and related identity evidence to understand why a sign-in was allowed and whether the resulting session still deserves investigation.

KQL, Conditional Access, MFA And Identity Investigation

GEMXIT helps organisations investigate Microsoft Entra sign-ins, Conditional Access outcomes, MFA events, device context, privileged activity and identity compromise using practical KQL and evidence-driven Microsoft security investigation workflows.