Conditional Access: the policy set most tenants are missing

Conditional Access is the point where identity, device state and risk are turned into an access decision. It is also, in most tenants we assess, configured to a fraction of what the licence permits. The gaps are consistent enough that they are worth setting out directly.

Start with break-glass accounts

Before any policy is enforced, create at least two emergency access accounts, exclude them from every Conditional Access policy, give them long random passwords stored offline, and monitor them for sign-in activity. Every organisation that has locked itself out of its own tenant skipped this step.

These accounts should be cloud-only, should not be assigned to a person, and should be excluded explicitly rather than by relying on a group membership that a later policy might not evaluate.

The gaps we find most often

Legacy authentication is still permitted

Legacy authentication protocols do not support multi-factor authentication. While they remain reachable, MFA is advisory rather than enforced: an attacker with valid credentials simply chooses a protocol that never prompts. Blocking legacy authentication is the single highest-value policy in most tenants, and sign-in logs will tell you what still depends on it before you enforce.

MFA is required for administrators but not for everyone

Requiring MFA only for privileged roles assumes an attacker will target a privileged account first. In practice, initial access is usually a standard user mailbox, followed by internal phishing from a trusted address. Coverage should be universal, with documented exceptions rather than an unenforced default.

Device compliance is not a condition of access

If Intune evaluates compliance but no policy requires it, the compliance state is reporting rather than control. Requiring a compliant or hybrid-joined device for access to company resources is what makes device management a security control instead of an inventory.

No policy covers unmanaged devices

Access from an unmanaged browser is a legitimate requirement in many organisations. Left unaddressed, it defaults to full access. App-enforced restrictions allow browser access without download, which is usually the right compromise.

Sign-in and user risk are unused

Where the licence includes identity protection, risk-based policies act on signals no static rule can express: impossible travel, anonymised addresses, credentials seen in a leak. Requiring MFA on medium sign-in risk and a password change on high user risk costs nothing to enable and catches what static policy cannot.

Deploy in report-only mode first

Every Conditional Access policy supports report-only mode. It evaluates the policy against real sign-ins and records what would have happened without affecting anyone. Run each new policy that way for a working week, review the impact in the sign-in logs, and only then enforce.

Enforce in waves: pilot group, then IT, then a department, then the organisation. A policy that is correct in principle and wrong for one integration is much easier to identify with fifty users affected than with five thousand.

What to document

For each policy, record what it does, why it exists, who is excluded and why, and who approved the exclusion. Exclusions accumulate, and an exclusion nobody can explain is a policy gap that has been formally approved.

A reasonable baseline

• Block legacy authentication for all users
• Require MFA for all users, with break-glass accounts excluded
• Require MFA for administrative roles with no exclusions beyond break-glass
• Require a compliant or hybrid-joined device for access to company data
• Apply app-enforced restrictions for unmanaged browser sessions
• Require MFA on elevated sign-in risk, where licensed
• Block access from countries the organisation does not operate in, if that is genuinely true

That list is a starting position, not a finished configuration. The right policy set depends on how the organisation actually works, which is exactly why the report-only step matters.