Conditional Access Policy
A Conditional Access policy is Microsoft Entra ID’s gate at sign-in: an if-then rule that decides whether a sign-in is allowed, blocked, or asked to prove more before it’s trusted. This category holds the fourteen policies Octiga can deploy and keep in place, from enforcing MFA and blocking legacy authentication to restricting admin portal access and responding to risky sign-ins.
Why it matters
Most breached tenants weren’t forced open; they were left open. A password on its own protects very little: credentials get phished, reused from other breaches or brute-forced, and then whatever that account can reach is exposed. A tenant with no Conditional Access policies accepts any sign-in with a valid password, from any device, location or client, including protocols that predate MFA. For an MSP, this is the highest-leverage category to get right early: a handful of these baselines close most of the routes a compromised password would otherwise take.
How Microsoft evaluates it
Each baseline in this category is one Conditional Access policy in Microsoft Entra ID: an if-then statement of assignments (who, and which app or resource) and access controls (grant, block, or require a session control), evaluated every time someone signs in. Conditions such as device platform, network location, client app type and sign-in risk are combined with AND, so every configured condition has to be met for the policy to apply. Evaluation runs in two phases. Session details are gathered first; then a block control stops the sign-in outright, or the user is prompted, in order, to satisfy the remaining grant controls (MFA, then a compliant device, then a hybrid-joined device). When several policies apply to one sign-in, all of them have to be satisfied. (Microsoft Learn: What is Conditional Access?, Build a Conditional Access policy)
What end users experience
Users notice this category more than any other. Enforcing MFA adds a prompt (an Authenticator approval or a code) the first time a session needs it. Blocking legacy authentication prompts no one: whatever still used it, usually an old mail client, stops working with no explanation shown. Requiring a compliant device blocks sign-in from anything Intune hasn’t approved and points the user to the Company Portal. Restricting the Azure or Microsoft admin portals affects only the few people who hold an admin role. Risk-based policies are the least predictable: a sign-in Microsoft judges unusual can require MFA or a password change on the spot, even from someone who’s done nothing wrong. A policy set to report-only changes nothing users see; it collects evidence without acting on it.
| Baseline | Scope | Licence |
|---|---|---|
| Application Enforced Restrictions For Unmanaged Devices. | Tenant | Entra ID P1 or P2 |
| Block Legacy Authentication | Tenant | Entra ID P1 or P2 |
| Block Unknown Or Unsupported Device Access | Tenant | Entra ID P1 or P2 |
| Enforce MFA | Tenant | Entra ID P1 or P2 |
| Legacy Auth Conditional Access Policy - DEPRECATED NAME | Tenant | Entra ID P1 or P2 |
| MFA Conditional Access Policy - DEPRECATED | Tenant | Entra ID P1 or P2 |
| No persistent Browser Sessions | Tenant | Entra ID P1 or P2 |
| Octiga Generic Conditional Access Policy | Tenant | Entra ID P1 or P2 |
| Require Approved Client Apps | Tenant | Entra ID P1 or P2 |
| Require Compliant Or Hybrid Azure AD Joined Device. | Tenant | Entra ID P1 or P2 |
| Restrict Access To Azure Portal | Tenant | Entra ID P1 or P2 |
| Restrict Access To Microsoft Admin Portal | Tenant | Entra ID P1 or P2 |
| Securing Security Info Registration | Tenant | Entra ID P1 or P2 |
| Sign-In Risk-Based Multifactor Authentication. | Tenant | Entra ID P1 or P2 |