Ridge CloudIdentitySecurity

Conditional Access: The If-This-Then-That of Enterprise Security

Zero trust sounds abstract until you see the policy engine that enforces it: signals in, decision out, on every single sign-in.

The zero trust post earlier on this trail made a promise: every access request gets evaluated on evidence — identity, device, context — every time. Fine words. This post is about the machinery that keeps them: the conditional access engine, the policy layer sitting between every sign-in and every application in a modern cloud identity platform. If zero trust is the philosophy, conditional access is the enforcement.

The shape of a policy

Every conditional access policy, stripped of vendor dressing, is an if-this-then-that statement with three parts:

Concrete examples, in plain English: "Everyone accessing anything from outside the office network → require MFA." "Payroll app → require MFA and a compliant device, always." "Sign-in assessed as high-risk → block outright." Stack twenty such policies and you've turned an abstract architecture into rules that fire billions of times a day.

The signal that makes it interesting: risk

The condition worth dwelling on is risk — a machine-learning assessment attached to each sign-in and each user. Impossible travel (London then Singapore in an hour), anonymised networks, password-spray patterns, credentials spotted in criminal marketplaces: these raise risk scores, and policies can key off them — step up to MFA at medium risk, block and force remediation at high. This is the genuinely modern part: the system adapts per-request, which no static firewall rule ever could. It's also where the zero trust slogan becomes literal — trust computed from evidence, per sign-in.

Trail note

Operational wisdom that separates practitioners from brochure-readers: conditional access is powerful enough to lock everyone out — including all administrators, permanently, with one bad policy. Hence the two iron habits of the trade: every new policy launches in report-only mode first (evaluating and logging what it would do, affecting nothing), and every tenant keeps break-glass accounts — emergency admin accounts excluded from all policies, stored like the fire axe behind glass. If you ever administer one of these systems, these two habits are non-negotiable.

Why this matters even if you never write a policy: as a user, every MFA prompt, device-enrolment demand, and "you can't access this from here" message you've ever seen was a conditional access decision. As a professional, "sign-in logs plus policy evaluation" is where a huge share of modern access troubleshooting lives — and now you know the shape of the machine you'd be debugging.

Next waypoint — Summit

Beyond VLANs: Microsegmentation and the East-West Problem →