Conditional access
Policies that grant, restrict or block access based on context such as user, device, location and risk. They add a decision layer on top of authentication, but only at the moment of sign-in.
Reading Time:
4 min
Conditional access is a set of policies that decide whether to grant, restrict or block access, based on the context of a request: who is asking, from which device, from where and at what level of risk. Instead of a single yes or no at the login, the decision adapts to the situation.
When someone tries to sign in, the system gathers signals, evaluates the policies that apply and applies an outcome. The logic is “if this, then that”. The outcome can be to allow access, to require extra verification such as MFA, to limit what the person can do, or to block the request.
Typical examples are to require MFA for administrators, to block sign-ins from countries where the company has no staff, to allow access to sensitive applications only from managed devices, and to ask for re-authentication before high-risk actions.
Zero trust means verifying every request instead of trusting the network. Conditional access is one of the mechanisms that puts that into practice, because each request is judged on identity, device and context, not on where it comes from.
No. MFA is a control that checks a second proof of identity. Conditional access decides when to ask for it, and what else to require or restrict. A good policy asks for MFA when the context is risky and stays out of the way when it is not.
An employee signs in to the finance application from a personal laptop, in a country where the company has no office. The policy sees an unmanaged device, a new location and a sensitive application. Depending on how it was written, it blocks the request, or asks for MFA and limits the session to view-only access.
It judges the request, not what happens afterwards. A stolen session token used from an allowed device, or an attacker on a trusted network who signs in with valid credentials, can satisfy every condition. Once the request is approved, the policy has little to say about what the identity does next.
Coverage can also leave gaps. Legacy protocols, service accounts and automated processes often sit outside the policies, and exclusions made for emergency accounts or trusted locations can become permanent holes.
Some platforms re-evaluate access while a session is running, for example when an account is disabled or the location changes, so that access can be withdrawn quickly. Not every application supports this, and the checks are still limited to the conditions the policy knows about.
Service accounts, workloads and automated processes do not use MFA, so the options are narrower, such as restricting where they can connect from. Many are not covered by policies at all, which is one reason they are attractive to attackers.
Start with privileged accounts and the most sensitive applications, review exclusions regularly, test policies before enforcing them and keep them simple enough to explain. Then add what policies cannot provide: visibility into behaviour after the sign-in.
Sharelock monitors what identities do after login, down to individual transactions and queries on critical applications, so a session that passed every condition but starts behaving unlike its owner still stands out.
Explore more terms