What Is Conditional Access?

Conditional access evaluates the circumstances of an access request against policy and decides what to do: allow, require additional verification, restrict the session, or deny. It is the enforcement engine that makes zero trust operational in practice.

The inputs are who is asking, from what device, from where, to reach what, and how risky the attempt appears.

Policy design that survives contact with users

The temptation is to write many granular policies. The result is a configuration nobody can reason about, where the effective outcome of overlapping rules is unclear and troubleshooting a blocked user takes hours.

Fewer, broader policies with clearly understood exclusions are easier to operate and easier to audit. Baseline policies — require multi-factor authentication for everyone, block legacy authentication, require compliant devices for sensitive applications — cover most of the value.

Exclusions are the architecture attackers see

Every deployment accumulates them: the service account that cannot do modern authentication, the executive who found the prompts disruptive, the application that broke, the break-glass account that must be excluded by design.

Those exclusions are the policy from an attacker's perspective. Each needs an owner, a compensating control and a review date, and the list needs to be short enough that someone reads it.

Testing before enforcement

Policies can lock out an entire organisation, including administrators, and this has happened to large enterprises. Report-only mode shows what a policy would have done without doing it, which is the only safe way to understand impact.

Emergency access excluded from all policies is the other requirement, and it should be verified working before any policy is enforced rather than after.

Device trust is the hardest input to get right

Policies requiring a compliant device are among the strongest available, and they depend on device management covering the devices people actually use. Personal devices, contractor laptops and anything unenrolled either fail the policy or need an exclusion.

The practical resolution is usually tiered rather than binary: unmanaged devices get browser-only access with download restrictions and no persistent session, while managed devices get full access. That gives people a working path without extending full trust to equipment you cannot assess, and it avoids the long exclusion list a hard requirement would otherwise generate.

Visibility into what the policies are doing is the part most commonly neglected. Sign-in logs showing which policy applied, which conditions were evaluated and what the result was are what make troubleshooting tractable and what let you verify a policy is actually reaching the traffic it was written for. Without that, the configuration is a statement of intent rather than a demonstrated control.

Where to start

List every identity excluded from your conditional access policies, and confirm legacy authentication is disabled. Those two checks describe your real posture far better than the policy list does.

See zero trust architecture. GuardsArm delivers zero trust security.