Agent Foskett Academy • SOC Analyst Academy • Module 3 • Lesson 24 • Identity Incidents

Lesson 24 — Conditional Access Said Success — What Actually Happened?

The sign-in record showed Conditional Access: Success.

At first glance, that sounded reassuring. The policies worked. Access was granted. Nothing appeared to have failed.

But a successful Conditional Access result does not mean the sign-in was harmless. It means the applicable policy requirements were satisfied. The analyst still has to determine which policies applied, which controls were satisfied, whether exclusions existed and what the session did next.

Conditional Access success tells you the policy outcome. It does not tell you the security verdict.

Investigate the CA Result Back to SOC Analyst Academy

Agent Foskett SOC Analyst Academy investigating a Conditional Access success result

Success was not the whole story

The analyst must understand the policies evaluated, the controls satisfied, the conditions present and whether the resulting session behaved normally.

✓ Identify applied Conditional Access policies

✓ Review grant and session controls

✓ Check exclusions and policy scope

✓ Correlate the result with sign-in and session evidence

Case briefing

09:18 — SUCCESSFUL SIGN-IN USER s.bennett@contoso.com SOURCE Unfamiliar IP address DEVICE Unmanaged browser session APPLICATION Microsoft 365 CONDITIONAL ACCESS Success MFA Satisfied 09:26 — UNUSUAL FILE ACCESS 09:31 — OAUTH CONSENT EVENT THE EASY VERDICT "Conditional Access succeeded." THE SOC QUESTION "What exactly succeeded, and what did the session do afterwards?"

Investigation objective

Interpret the Conditional Access result in the context of the sign-in, applied policies, grant controls, exclusions, authentication method and subsequent activity.

Investigator's rule

Conditional Access is an access decision, not an incident verdict. A policy can succeed while an attacker still satisfies the required controls.

Stage 1 — understand what “success” means

Result	What it tells you	What it does not tell you
Success	Applicable Conditional Access requirements were satisfied.	That the person signing in was legitimate.
Failure	A required policy control was not satisfied.	That no other access path existed.
Not applied	No applicable policy affected that sign-in.	Why the user or app was outside scope.
Report-only	The policy evaluated without enforcement.	That the control actually blocked or required anything.

Success can still be suspicious

If an attacker possesses the password and can satisfy MFA, a Conditional Access policy requiring MFA may report success while the account is still compromised.

Policy outcome is only one layer

The analyst needs identity, device, source, application, authentication details and session behaviour alongside the Conditional Access status.

Stage 2 — inspect the sign-in with KQL

Start by collecting the Conditional Access status and surrounding sign-in fields for the user.

12345 678910 1112131415 161718

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(24h)
| where UserPrincipalName =~ TargetUser
| project TimeGenerated,
          UserPrincipalName,
          IPAddress,
          Location,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus,
          AuthenticationRequirement,
          AuthenticationDetails,
          DeviceDetail
| order by TimeGenerated desc

Check the device context

If the policy succeeded from an unmanaged device, determine whether device compliance was actually required or whether the sign-in fell outside that control.

Check the application

Conditional Access is scoped to applications and resources. The user may have satisfied one policy while another resource had different controls or no applicable policy.

Stage 3 — ask which policies actually applied

CONDITIONAL ACCESS = SUCCESS ↓ WHICH POLICIES APPLIED? ↓ WHAT CONDITIONS MATCHED? ↓ WHAT GRANT CONTROLS WERE REQUIRED? ↓ HOW WERE THEY SATISFIED? ↓ WERE ANY POLICIES NOT APPLIED? ↓ WERE EXCLUSIONS INVOLVED? ↓ WHAT SESSION CONTROLS WERE CREATED?

Do not read the summary field alone

The overall Conditional Access status is useful, but the policy-level details explain why access was allowed and which controls actually influenced the decision.

Exclusions can change everything

Break-glass accounts, trusted locations, service accounts or excluded groups can create legitimate exceptions — or unexpected gaps. Validate whether an exclusion was intentional.

Stage 4 — compare recent Conditional Access outcomes

Look for changes in the user's normal access pattern, including sign-ins where Conditional Access was not applied, failed or behaved differently.

12345 678910 111213

let TargetUser = "s.bennett@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ TargetUser
| summarize
    SignIns=count(),
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated)
    by ConditionalAccessStatus,
       AppDisplayName,
       ClientAppUsed,
       IPAddress
| order by LastSeen desc

Baseline the control path

If the user normally signs in through a managed device with one set of policies, a new successful path from an unmanaged client may deserve closer scrutiny.

Policy drift can become evidence

A newly excluded group, changed policy scope or disabled condition can explain why a suspicious sign-in succeeded when previous attempts did not.

Stage 5 — follow the successful session

CA SUCCESS ↓ ACCESS GRANTED ↓ WHAT DID THE SESSION DO? NORMAL ACTIVITY? ↓ Supports legitimate explanation OR UNUSUAL FILE ACCESS? NEW OAUTH CONSENT? MAILBOX RULE? PRIVILEGE CHANGE? NEW MFA METHOD? UNUSUAL CLOUD ACTIVITY? ↓ The CA result did not explain the incident

Controls can be satisfied by an attacker

If the attacker has the factors required by policy, successful enforcement does not make the session trustworthy. The investigation must move beyond the access decision.

Session controls matter too

Sign-in frequency, persistent browser sessions and other session controls can affect how long access continues after the initial decision. Review them when persistence or token abuse is suspected.

Stage 6 — test competing explanations

Hypothesis	Evidence to test
Legitimate user satisfied policy	Expected device, source, app, authentication method and normal follow-on activity.
Attacker satisfied MFA	Unfamiliar source, suspicious MFA history and abnormal post-sign-in activity.
Policy exclusion allowed access	Excluded group, trusted location, user exception or policy scope evidence.
Policy did not require expected control	Grant-control configuration, application scope and policy-level evaluation details.
Report-only policy created false confidence	Policy mode and whether enforcement actually occurred.

Stage 7 — make the SOC decision

CONDITIONAL ACCESS RESULT ↓ IDENTIFY POLICY OUTCOME ↓ REVIEW APPLIED POLICIES ↓ CHECK GRANT + SESSION CONTROLS ↓ VALIDATE EXCLUSIONS / SCOPE ↓ CORRELATE MFA + DEVICE + SOURCE ↓ FOLLOW SESSION ACTIVITY ↓ TEST LEGITIMATE EXPLANATIONS ↓ CLOSE / CONTINUE / ESCALATE / CONTAIN

Conditional Access tells you how access was evaluated. The incident verdict still comes from the complete identity timeline.

Write the investigation finding

IDENTITY TRIAGE FINDING A successful Microsoft Entra sign-in occurred for s.bennett@contoso.com at 09:18. Conditional Access reported Success. The sign-in originated from an unfamiliar IP and an unmanaged browser session. The applicable policy requirements were satisfied, including MFA. However, the session was followed by unusual file access and an OAuth consent event. DECISION Escalate the identity incident. REASON The Conditional Access result confirms that policy requirements were satisfied, but it does not explain the suspicious source, device context or follow-on activity. The wider timeline remains inconsistent with the user's normal behaviour.

Lesson 24 key takeaways

Conditional Access success is an access-policy result, not proof of legitimate user activity.
Review which policies actually applied to the sign-in.
Understand which grant controls were required and how they were satisfied.
Check whether important policies were excluded, not applied or configured as report-only.
Device, application, source and authentication context remain essential evidence.
Use KQL to compare current and historical Conditional Access outcomes.
An attacker can satisfy Conditional Access if they possess the required factors.
Session controls can influence how long access persists after authentication.
Follow post-authentication activity before deciding whether the sign-in was benign.
Build the verdict from the complete identity timeline, not one policy status field.

Module 3 — Identity Incidents

Lesson 24 shows why a successful Conditional Access result must be interpreted in context. Next, Agent Foskett investigates a privileged role that became active overnight.

Next: Lesson 25 — The Privileged Role Became Active Overnight

Continue your SOC Analyst training

Module 3 focuses on identity incidents, authentication, MFA, privilege, sessions and application access.

SOC Analyst Academy KQL Academy Microsoft Sentinel Academy Defender for Endpoint Academy Microsoft Entra Security Academy Security Copilot Academy Agent Foskett Academy

🔎 SOC Analyst Academy — Module 3: Identity Incidents

Investigate suspicious authentication, Conditional Access outcomes and identity activity beyond the initial sign-in result.

← Previous lesson

Lesson 23 — A New MFA Method Appeared After the Sign-In Correlate authentication-method changes with identity activity.

✅ Current lesson

Lesson 24 — Conditional Access Said Success — What Actually Happened? Interpret Conditional Access in the wider sign-in story.

Next lesson

Lesson 25 — The Privileged Role Became Active Overnight Investigate unexpected privilege elevation.

How to investigate Conditional Access success in Microsoft Entra

Lesson 24 of the Agent Foskett SOC Analyst Academy teaches analysts how to interpret Conditional Access success, review applied policies, understand grant controls, validate exclusions and determine whether suspicious authentication still requires escalation.

KQL investigation of Conditional Access sign-in results

Learn how to use Microsoft Entra SigninLogs and KQL to review ConditionalAccessStatus, compare current and historical sign-in patterns and correlate policy outcomes with authentication, device, source and session evidence.