Conditional Access polices

For Microsoft 365 scenarios, Microsoft’s recommended patterns for risk-based policies differ from the configurations described.

1. Session controls

For risk-based Conditional Access policies (sign-in risk and user risk), Microsoft guidance in the provided context applies these session controls:

• Sign-in risk policy for MFA:
  • Under Session → Sign-in frequency → Every time.
  • This forces re-evaluation and MFA on each risky sign-in.
  • Steps are shown in the “Enable sign-in risk policy for MFA” guidance.
• User risk policy for password change:
  • Under Session, Sign-in frequency – Every time is automatically applied and is mandatory.

So, for M365 access when using risk-based policies:

• If the policy is granting access with MFA (or risk remediation), configure Sign-in frequency = Every time.
• If the policy is blocking access, additional session controls are not required; the block itself is sufficient. Session controls mainly affect how often tokens are re-evaluated, not the block decision.

2. Recommended grant controls vs. current configuration

The current policies are configured to Block on High risk. The Microsoft guidance in the context recommends:

• Sign-in risk policy:
  • Assignments: All users (excluding break-glass accounts), All resources.
  • Condition: Sign-in risk = High and Medium.
  • Grant: Grant access + Require authentication strength with Multifactor authentication.
  • Session: Sign-in frequency = Every time.
  • Start in Report-only, then move to On after review.
• User risk policy:
  • Assignments: All users (excluding break-glass accounts), All resources.
  • Condition: User risk = High.
  • Grant: Grant access + Require risk remediation (this enforces password change; authentication strength is automatically selected).
  • Session: Sign-in frequency – Every time is automatically applied and mandatory.
  • Start in Report-only, then move to On after review.

Compared to this guidance:

• Using Block for High sign-in risk and High user risk is more aggressive than the documented recommendations, which focus on MFA for sign-in risk and password change for user risk.
• For most M365 scenarios, the recommended pattern is:
  • Sign-in risk → require MFA every time for High/Medium.
  • User risk → require password change (risk remediation) for High.

3. Validation of other policy settings

Based on the context:

• Assignments:
  • All users is correct, but emergency access/break-glass accounts should be excluded.
• Target resources:
  • All resources (formerly ‘All cloud apps’) is correct for tenant-wide protection.
• Conditions:
  • Sign-in risk policy: Configure = Yes, risk levels High and Medium are recommended.
  • User risk policy: Configure = Yes, user risk level High is recommended.
• Enable policy:
  • Start with Report-only and later switch to On after reviewing impact.

These align with the documented steps, except for the choice of Block vs. Grant access with MFA / risk remediation.

4. Evaluation of risk with federated authentication via Okta

The context describes how to configure risk-based Conditional Access policies but does not provide details about risk evaluation behavior when authentication is federated through Okta. There is no explicit statement in the provided material confirming or denying correct sign-in risk or user risk evaluation in a federated/Okta SSO scenario.

Because this behavior is not covered in the context, no statement can be made here about whether sign-in risk and user risk will be evaluated correctly when using Okta federation.

References:

• Require multifactor authentication for elevated sign-in risk
• Configure and enable risk policies
• Tutorial: Use risk detections for user sign-ins to trigger Microsoft Entra multifactor authentication or password changes
• Require a compliant device, Microsoft Entra hybrid joined device, or multifactor authentication for all users
• Plan a Conditional Access deployment