Conditional access
In cloud identity, conditional access is policy that evaluates the circumstances of a sign-in and decides what to require or refuse. Rather than a single yes or no at the password, it asks which user, from what device, in which location, to reach which application, at what assessed risk, and applies a control that fits the answer.
How it works
A policy pairs conditions with controls. Conditions cover the user or group, the target application, the device state and its management status, the network location, the client type, and risk signals derived from the sign-in and the user. Controls include requiring a second factor, requiring a compliant or managed device, requiring a specific credential strength, limiting the session, or blocking outright.
Two controls do disproportionate work. Requiring a managed device turns a stolen password into nothing, because the attacker’s machine cannot satisfy it. Requiring a phishing-resistant credential such as a passkey removes the proxy attack. Everything else is refinement.
What goes wrong
The gap is the finding, every time. A policy that requires a second factor for everyone except an exclusion group, and an exclusion group that has grown to include service accounts, executives and anybody who complained, means the policy protects the people who were never going to be targeted. Exclusion groups are the first thing we enumerate.
Legacy protocols are the second. Older mail and client protocols cannot present a modern credential and therefore cannot be challenged, so where they are still reachable the whole policy is bypassed by choosing a different endpoint, which is exactly what password spraying does against a tenant.
The third is what the policy does not cover: the session it already issued. Conditional access is evaluated at authentication, so a token captured afterwards by an adversary-in-the-middle proxy is used from the attacker’s machine and network without a fresh evaluation, unless continuous evaluation and token protection are enabled. That is the difference between a policy that looks strong on paper and one that stops the attack we actually run.
Where this shows up in an audit
We enumerate every policy, every exclusion and every enabled legacy path, then test the weakest combination that still authenticates rather than the intended one. The report gives the policy name, the specific condition that let us through, and the session we obtained, and it separates a missing policy from a policy with a hole, since those have different owners. Location-based rules are tested from outside the expected geography, because they are frequently the only control on a high-value application. This is part of how we test Microsoft 365 sign-in policy against a real attack.