Microsoft Entra Conditional Access: signals, controls, and 'if-then' access rules
Slide deck explaining Microsoft Entra Conditional Access: how signals (conditions) and controls (outcomes) work together in 'if-then' access policies to secure sign-ins based on context.
Microsoft Entra Conditional Access: signals, controls, and 'if-then' access rules
Introduction to Microsoft Entra Conditional Access: how signals, controls, and 'if-then' access rules work together to secure sign-ins.
Microsoft Entra Conditional Access: signals, controls, and 'if-then' access rules
Introduction to Microsoft Entra Conditional Access: how signals, controls, and 'if-then' access rules work together to secure sign-ins.
Microsoft Entra Conditional Access (CA)
Conditional Access applies 'if-then' rules to decide how sign-ins to apps/resources should proceed. Identity-driven policy engine (not a network tool). Uses sign-in context to decide access. Outcomes: allow, require extra steps, or block. Supports a Zero Trust approach.
Conditional Access = 'If → Then'
Signals define the 'if,' and controls define the 'then.' IF: conditions match (signals). THEN: enforce an access outcome (controls). Match higher risk → stronger requirements. Keeps low-risk sign-ins smoother.
Signals (the 'if' part)
Signals describe the sign-in context that policies evaluate. Who: user, group, role. What: cloud app / target resource. Where: locations, networks. How: browser vs client apps. Device context: platform plus managed/compliant state.
Common signals: location + client app
Location and client app type are simple signals that often drive practical policies. Location: trusted vs untrusted places. Network context can influence trust decisions. Client app: browser vs mobile/desktop clients. Combine signals to raise security when needed.
Device context (managed / compliant)
You can require stronger access conditions when the device isn't trusted. Device platform can be evaluated. Managed/compliant state can be used (with device management integration). Sensitive apps often require compliant devices. Alternative outcome: block access.
Risk signals (when available)
If risk detections exist, Conditional Access can react with stronger controls. Risk signals: sign-in risk, user risk. Requires risk detections to be available (e.g., Entra ID Protection). High risk → require MFA or block. Policies must be designed and enabled.
Controls (the 'then' part)
Controls define what happens after signals match. Grant controls: require MFA, require compliant device, block access. Session controls: limit actions during the session (scenario-dependent). Controls are outcomes, not signals. One policy can combine multiple controls.
What Conditional Access is NOT
Conditional Access is policy logic, not packet filtering or 'just MFA.' Not a network firewall (no packet inspection). Not the same as MFA (MFA is a control). Works at identity/access for apps/resources. Decides when to challenge, allow, or block.
Security defaults vs Conditional Access
Security defaults are baseline; Conditional Access is targeted and granular. Security defaults: quick baseline protections. Conditional Access: custom 'if-then' policies. Granularity: per app / per group / per condition. Not meant to be used together.
Recap and Pitfalls
Good policies pair the right signals with the right controls—and you test before rollout. Example rules: location → require MFA; non-compliant device → block. Risk-based rules require available detections. Pitfalls: 'MFA equals CA', 'CA equals firewall', 'automatic without setup'.