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.

How does conditional access work?

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.

What signals does it use?

  • The user and the groups they belong to.
  • The state of the device: managed, compliant or unknown.
  • Location and network, such as country or IP range.
  • The application being accessed, and how sensitive it is.
  • Sign-in risk, such as unusual behaviour or impossible travel.
  • Time and session context.

What can a policy decide?

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.

How does conditional access relate to zero trust?

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.

Is conditional access the same as MFA?

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.

What does conditional access look like in practice?

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.

Where does conditional access fall short?

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.

Can policies be evaluated during a session?

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.

How does conditional access treat non-human identities?

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.

What are common mistakes?

  • Excluding accounts or locations and never reviewing the exclusion.
  • Leaving legacy authentication enabled.
  • Applying policies to users but not to service accounts.
  • Writing policies so complex that nobody can explain them.
  • Treating an approved sign-in as the end of the decision.

How do you get the most from conditional access?

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.

‍

Sharelock investigates identity alerts in 31 seconds. Autonomously

See the Autopilot in action, no slides, no pitch.

Get in Touch

Request a demo or get more details of how our product works.

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.