Conditional access closes the gap between "authenticated" and "this makes sense." Here's why most implementations leave the gap open.
Your engineer authenticates. Credentials check out. Group membership confirms access. GitHub opens.
Everything worked exactly as designed.
Except it's 3 AM, the login is from Bangkok, the device has never touched your network, and your engineer is asleep in Chicago.
This is the context problem. Group-based access control is good at one thing: defining who should have access to what. It has no opinion on whether a specific access attempt makes sense. Same credentials, same group, same permissions — regardless of where, when, or how the access is happening.
Conditional access is how you solve this. But many IT and security teams either haven't implemented it, or implemented it partially and assume they're covered. They're not.
In this article:
- What the Context Problem Actually Looks Like
- What Conditional Access Does
- How It Layers on Top of Groups
- The Policies That Actually Matter
- Why Implementation Is Harder Than It Looks
- The Visibility Problem Nobody Talks About
- Where to Start
What the Context Problem Actually Looks Like
Four scenarios. All of them involve access control working perfectly — and failing completely.
The phished contractor
Your External Contractors group has access to project management tools. A contractor's credentials get phished. The attacker logs in from Moldova at 2 AM and accesses everything the contractor group touches.
Your access control didn't fail. The attacker was in the group. The system did what it was supposed to do.
What you needed: restrictions that made that login impossible regardless of valid credentials — approved IP ranges, business hours enforcement, registered devices only. This is the core of contractor access management.
The departing sales rep
Your Sales group has access to Salesforce. You offboard a rep cleanly — remove them from the group, revoke their access. Done.
Except they spent the last two weeks downloading customer records to their personal laptop. By the time you removed them from the group, the data was already gone.
What you needed: download and export restricted to managed devices only. Read access from anywhere, exfiltration from nowhere.
The stolen admin laptop
IT Admins group has production access. An admin's laptop gets stolen. Before you can act, someone uses saved credentials to log in and make configuration changes.
The credentials were valid. The group membership was correct. The access should never have been possible from an unknown device on public WiFi.
What you needed: privileged access management that locks access to corporate network and managed devices. Anything else — blocked, regardless of valid credentials.
The breached third-party integration
Your Marketing group connects to a marketing automation platform integrated with dozens of external tools. One of those tools gets breached. Attackers use API keys to reach your platform and access customer email lists.
What you needed: API access restricted to approved IP addresses, with additional authentication required for sensitive operations.
The pattern is the same across all four. Valid credentials, correct group membership, wrong everything else. Context didn't exist as a control layer — so context couldn't stop anything.
What Conditional Access Does
Conditional access adds if-then logic to authentication. Here's what conditional access is at its core:
Without it: User is in Engineering group → grant access to GitHub.
With it: User is in Engineering group AND on a managed device AND connecting from an approved location AND using MFA → grant access to GitHub.
The signals vary by platform. Azure AD evaluates user identity, device state, location, application, and real-time risk score. Okta Adaptive MFA focuses primarily on authentication requirements — step-up auth based on device or location changes. Google Workspace Context-Aware Access applies rules around device security status, IP address, and geography.
The mechanics differ. The principle is the same: evaluate context, apply policy, enforce restrictions that identity and access management alone can't provide through static rules.
How It Layers on Top of Groups
Conditional access doesn't replace your group structure. It adds a control layer underneath the access grant.
Layer 1: Authentication — user proves who they are
Layer 2: Group membership — system confirms they should have access to this application (often defined through role-based access control)
Layer 3: Conditional access — system evaluates whether this specific attempt meets policy
Layer 4: Decision — grant, deny, require additional verification, or limit what they can do
Same application. Same groups. Different policies per group.
Take GitHub with three groups:
Engineering (full-time employees)
- MFA required from any location
- Managed device required for write access
- Read-only from unmanaged devices
- High-risk locations blocked
Contractors (external developers)
- MFA required from any location
- Approved IP ranges only
- Assigned repositories only, no full codebase downloads
- Access outside business hours blocked
Admins (DevOps)
- MFA and device compliance for any access
- Admin operations restricted to corporate network
- Privileged access workstation required for sensitive changes
- Mobile device access blocked entirely
Groups define WHO. Conditional access defines under what conditions that access is real. But as environments scale, groups themselves become a problem — group sprawl creates stale memberships and overprovisioned access that conditional policies alone can't fix. Understanding how to reduce risk in group-based access control is the necessary companion work.
The Policies That Actually Matter
Not all conditional access policies are worth the implementation effort. These are the ones that move the needle.
MFA everywhere, no exceptions
Start here. Simple to implement, protects against the most common attack vector — compromised credentials. If someone has your user's password, MFA is the only thing standing between them and your applications.
Admin access locked to corporate network
Privileged access from coffee shops and hotel WiFi is unnecessary risk. Require admins to be on corporate network or approved VPN for production access. The friction is low for admins who understand why. The risk reduction is significant. This is the principle of least privilege applied to location and device context, not just permissions.
Managed device requirements for sensitive data
Corporate data shouldn't be on personal laptops. Require managed, compliant devices for applications containing sensitive information. BYOD gets read-only or gets blocked entirely. This closes the departing employee data exfiltration problem — but only when paired with secure deprovisioning that revokes access across every app, not just SSO-connected ones.
Block high-risk geographies
If you don't operate in certain countries, block them. Credential stuffing attacks often originate from regions with no legitimate users. Simple policy, meaningful reduction in attack surface.
Contractor time and location restrictions
Contractors working on-project don't need 24/7 global access. Business hours plus approved IP ranges covers legitimate use. Anything outside that window is either a compromised account or a policy violation worth catching. For the full set of SaaS access control best practices that sit alongside these policies, that's a useful companion read.
Risk-based step-up authentication
Let your IdP calculate a risk score based on unusual signals — new device, unfamiliar location, atypical timing. Require additional MFA when risk is elevated. Users with normal patterns rarely see extra friction. Unusual access triggers it automatically.
Why Implementation Is Harder Than It Looks
The policies above sound straightforward. Deployment hits real friction.
You don't know your access patterns
You can't write location-based policies if you don't know where users normally access applications from. Block too aggressively and you break legitimate remote work. Block too loosely and you haven't actually reduced risk.
Most teams have never tracked where and how their applications are being accessed. They're writing policies based on assumptions, not data.
Legacy applications are a gap
Modern SaaS — Microsoft 365, Salesforce, Workday — supports conditional access natively. Legacy on-premise applications and custom internal tools don't.
The result: a patchwork where some applications have strong conditional policies and others have none. Attackers target the weakest link. The weakest link is usually the legacy system you can't easily protect — or the shadow IT that IT never knew existed.
Exception requests don't stop
You lock admin access to corporate network. Immediately: "I need to fix an outage from home," "I'm traveling," "I'm at a client site."
Some exceptions are legitimate. Approving them creates precedent. Denying them creates shadow IT workarounds and organizational pressure to relax the policy. The technical implementation is the easy part. Managing exceptions is the ongoing work.
Users experience friction without context
MFA prompts interrupt workflows. Device compliance checks slow logins. Risk-based policies trigger seemingly at random from the user's perspective.
This lands as "security making everything harder." Help desk tickets increase. Pressure to relax policies builds. The organizational pushback is real and consistent across every implementation.
You can't test what you can't see
Most platforms offer report-only mode — policies log what they would do without enforcing. Useful, but it requires time to collect meaningful data before you can confidently deploy. Security teams are usually under pressure to move faster than that.
You don't know if it's working
Six months after deployment: are your policies being triggered? Are users bypassing them? Are false positives blocking legitimate access? Without visibility into enforcement, you're flying blind on whether the implementation is doing anything.
The Visibility Problem Nobody Talks About
Here's what most conditional access guides skip: effective policies require visibility you probably don't have yet.
To write location-based policies, you need to know where users normally access applications from. To write time-based policies, you need to know when they're used. To write device policies, you need a complete inventory of what's actually touching your applications. To write risk-based policies, you need a baseline of what normal looks like.
Most teams have none of this across their full environment. They know their IdP-managed applications reasonably well. They have limited visibility into shadow IT, unmanaged SaaS, and applications that authenticate outside their IdP. They don't have reliable data on access patterns across their complete application estate.
This is where conditional access implementations fall short. Policies get written for the applications IT manages. Everything else — shadow IT, personal accounts used for work tools, applications that bypass the IdP entirely — sits outside the policy scope. The ability to monitor shadow IT across your full environment is what closes this gap.
Comprehensive application discovery fills this gap. Zluri maps your complete application environment, not just IdP-managed applications, and shows how each application is being accessed: which devices, which locations, which users, what patterns.
That visibility does two things for conditional access. It tells you where policies need to exist (including applications you didn't know were in scope), and it gives you the pattern data to write policies that don't break legitimate workflows or miss actual risk.
It also closes the feedback loop after deployment — you can see whether policies are being triggered, where access is being blocked, and whether anything is slipping through. This visibility also makes user access reviews meaningful: instead of reviewing access in the dark, reviewers work from real usage data.
See how Zluri approaches application visibility
Where to Start
Don't try to implement everything at once.
Phase 1: MFA on sensitive applications. Highest impact, lowest friction. Start with applications containing your most sensitive data and expand from there.
Phase 2: Lock down admin access. Managed devices and corporate network for privileged accounts. High-value target, low user friction — admins understand the rationale.
Phase 3: Device compliance for sensitive data. Require managed devices for applications with confidential information. Block or limit BYOD access.
Phase 4: Location-based restrictions. Block geographies where you don't operate. Add step-up authentication for access from unusual locations.
Phase 5: Risk-based policies. Let your IdP calculate risk scores and require additional authentication when signals are unusual. Most adaptive layer, most complex to tune.
Each phase teaches you something: access patterns you didn't know existed, legitimate workflows that would break, applications that aren't covered. Use what you learn in each phase to improve the next one.
The context problem doesn't go away by itself. Valid credentials from the wrong device, wrong location, and wrong time of night will keep getting through as long as identity is the only thing access control checks.
Conditional access adds the layer that makes context a control. Not complicated in principle. Just requires the visibility to do it right. For the broader picture of how this fits into enterprise access management, that's the natural next read.
Frequently Asked Questions
What is conditional access in simple terms?
Conditional access adds rules on top of identity. Instead of just checking "is this the right user?" it also checks "is this the right device, location, time, and risk level?" Only when all conditions are met does access go through. If something looks off, the system can block access, require extra verification, or limit what the user can do.
Is conditional access the same as MFA?
No, though MFA is often one of the conditions. Conditional access is the policy engine — it decides when and whether to require MFA, block access entirely, or allow it freely. MFA is one enforcement action that conditional access can trigger. You can have MFA without conditional access (require it for everyone, always), but conditional access lets you make MFA requirements smarter based on context.
Does conditional access work with all applications?
Not automatically. Modern SaaS applications that integrate with your IdP (Azure AD, Okta, Google Workspace) typically support conditional access natively. Legacy on-premise applications and custom-built internal tools usually don't. This creates coverage gaps that attackers can exploit — which is why application discovery matters before you write policies.
How is conditional access different from Zero Trust?
Zero Trust identity and access management is a security philosophy: never trust, always verify, assume breach. Conditional access is one of the primary technical mechanisms for implementing Zero Trust. When you evaluate device compliance, location, and risk before granting access on every request, you're applying Zero Trust principles. Conditional access is not Zero Trust by itself, but it's hard to implement Zero Trust without it. The distinction between zero trust vs least privilege is also worth understanding — both inform how conditional policies get structured.
What's the biggest mistake teams make when implementing conditional access?
Writing policies before understanding normal access patterns. If you don't know where your users normally access applications from, you can't write location-based policies without either blocking legitimate access or leaving gaps. The correct order is: discover your application environment, understand access patterns, then write policies based on what you actually see — not what you assume.
How do you handle legitimate exceptions without undermining policies?
This is one of the hardest operational challenges. The most sustainable approach: build an exception process before you deploy policies, not after. Define in advance what constitutes a valid exception, who can approve it, and how long it lasts. Time-bound exceptions with automatic expiry work better than open-ended ones. Log every exception and review them quarterly — patterns of exceptions usually mean the underlying policy needs adjustment, not more exceptions.
Do you need a separate tool for conditional access, or does it come with the IdP?
Most major IdPs include conditional access capabilities: Azure AD Conditional Access, Okta Adaptive MFA, Google Context-Aware Access. You don't need a separate tool for the policies themselves. What most teams are missing is visibility into their full application environment — which applications exist, how they're being accessed, and whether policies are being enforced across everything, not just the apps that sit in the IdP. For a deeper look at how access provisioning fits into this picture, that's where to start.
.svg)
