Friday Cyber Briefing • Microsoft Entra • Conditional Access • Identity Security
The Conditional Access Policy Existed... But It Wasn't Protecting Anything
The MFA policy was configured.
The risk controls were configured.
Device compliance and named locations were configured.
The dashboard looked healthy.
But the policy was still in Report-only mode.
Microsoft Entra was evaluating sign-ins and recording what would have happened, but it was not actually enforcing the access decision.
Conditional Access Investigation
The policy configuration looked complete. The sign-in logs revealed that the tenant was only simulating protection.
Confirm policy state
Review assignments and exclusions
Verify real enforcement in sign-in logs
Everything appeared to be configured
The tenant contained the controls an administrator would expect to see in a modern identity-security design.
MFA requirements existedSelected users and cloud applications were included in a policy requiring multifactor authentication.
Risk controls existedUser risk and sign-in risk conditions were present and appeared ready to respond to suspicious authentication.
Device checks existedGrant controls referenced compliant devices, approved applications and trusted access conditions.
The dashboard was telling the truth
The problem was not that Microsoft Entra had failed to evaluate the policy. It was doing exactly what Report-only mode was designed to do.
- 1
- 2
- 3
- 4
- 5
- 6
Policy state: Report-only Result: reportOnlySuccess Grant control: Require multifactor authentication Enforcement action: None
Report-only is simulation, not protection
Report-only mode lets administrators observe policy impact before enabling enforcement. It is a deployment tool, not a permanent security state.
The policy still evaluatesUsers, applications, locations, device state and risk conditions are processed during the sign-in.
The logs show predicted outcomesAdministrators can see whether the policy would have succeeded, failed or interrupted the sign-in.
The grant control is not appliedNo MFA challenge, compliant-device requirement or access block is enforced by that report-only policy.
The investigation timeline
A healthy-looking configuration became an enforcement investigation.
09:05 — Policy reviewMFA, risk, device and location settings appeared complete in the Conditional Access portal.
09:17 — Sign-in logs checkedThe Conditional Access tab showed report-only results instead of an applied access decision.
09:24 — Policy state confirmedThe control was configured correctly, but its state was still set to Report-only.
What the sign-in logs revealed
The Conditional Access details for a sign-in should be read policy by policy, not reduced to a single green or red status.
Policy name and stateConfirm whether each relevant policy is enabled, disabled or operating in Report-only mode.
Conditions matchedCheck the user, application, platform, device, location and risk conditions that brought the sign-in into scope.
Grant control resultDistinguish a real success or failure from a predicted report-only result.
Configured does not mean assigned
Even after switching a policy to On, protection still depends on who and what the policy actually targets.
User scopeIncluded groups, excluded accounts and directory roles can completely change the policy's real coverage.
Resource scopeA policy aimed at selected applications will not automatically protect every Microsoft 365 or Azure resource.
ExclusionsBreak-glass accounts are sensible exclusions, but broad exclusions can silently remove the users who need protection most.
How to move safely from Report-only to On
Conditional Access should be enabled deliberately, with evidence and rollback options rather than by guesswork.
Review report-only resultsIdentify users, applications and device scenarios that would fail before the policy is enforced.
Protect emergency accessMaintain tightly controlled break-glass accounts that are monitored and excluded only where necessary.
Enable in stagesStart with a pilot group, verify sign-in behaviour, then expand coverage while monitoring failures and support impact.
What administrators should verify
A Conditional Access review is not complete until policy intent, assignment and enforcement all agree.
Policy state is OnDo not assume a completed configuration wizard means the policy is actively protecting sign-ins.
Real users are in scopeTest representative users, groups, devices, applications and locations rather than relying on policy appearance.
Logs show enforcementLook for applied policy results and actual grant-control outcomes in Microsoft Entra sign-in logs.
Investigation lessons
Conditional Access can look mature while still providing no real control over authentication.
Configuration is not enforcementA policy can be perfectly designed and still provide no protection while disabled or left in Report-only mode.
Healthy dashboards need contextSuccessful report-only evaluations show policy logic, not successful protection of the tenant.
The sign-in logs are the evidenceThey show which policy matched, which control applied and whether the decision was real or simulated.
Related Agent Foskett investigations
Continue with identity, MFA, sign-in risk and Microsoft security investigations.
The Login Was Successful But The Risk Was HighInvestigate why a successful authentication can still carry strong identity-risk signals.
The MFA Method Was Added At 3:14AMTrace suspicious authentication-method registration and determine whether account control has changed.
The User Passed MFA But It Wasn't Really ThemUnderstand why an MFA success does not automatically prove a legitimate user controlled the session.
The MFA Prompt Looked NormalExamine the social-engineering and session context behind a seemingly routine approval request.
AuthenticationDetails ExplainedRead authentication evidence and understand what Microsoft identity telemetry is actually recording.
Agent Foskett AcademyBuild practical Microsoft security investigation skills through structured lessons and real telemetry.
Final thought
The policy existed. The logs were evaluating it. The tenant was still unprotected.
The design was not the problemThe users, conditions and grant controls had been configured as expected.
The logs exposed the gapReport-only results showed what would happen without pretending the controls had actually been applied.
Enforcement completed the controlConditional Access only became protection when the policy moved from simulation to a verified On state.
