• Blog

Conditional access for business security and compliance

Conditional access is the zero trust system that lets businesses grant, customise or block user access to apps or systems depending on their location, device or role. It constantly monitors requests to ensure security policies are met at all times, bolstering overall security.

This guide covers conditional access in detail, from how it works, its business use cases, and how it differs from traditional access systems.

Contents

• What is conditional access?
• How conditional access works
• Conditional access and zero trust
• Conditional access vs traditional access

What is conditional access?

Conditional access is a zero trust login system where gaining and keeping access to a business app or system depends on meeting a set of predefined security conditions.

IT teams define access rules for users, devices, and systems within their network and a conditional access platform monitors every login attempt and active session to ensure these rules are followed.

For example, a conditional access policy might require that any login attempt or session:

• Passes Multi-Factor Authentication (MFA)
• Uses an approved or company-managed device
• Connects from an approved network or location (IP address)
• Complies with device security requirements (active antivirus solutions, updates installed)

If these conditions aren’t met, the system automatically blocks access or prompts for additional verification.

In business environments, conditional access is applied via an Identity and Access Management (IAM) platform such as Microsoft Azure ID or Google Workspace, alongside other IAM tools like Single Sign-On (SSO) and MFA.

How conditional access works

Conditional access operates through an IAM platform, which combines:

• Predefined access rules set by IT teams through a central dashboard
• Continuous, real-time assessment of security data from users, devices, and apps
• Optional risk-based assessment (available in advanced or premium tiers), which assigns a risk score to each sign-in or session based on behavioural and contextual analysis

Every login attempt or active session is checked against these conditions to decide whether to grant, challenge, or block access. This happens automatically, within seconds, through the IAM platform’s backend policy engine.

Here is a step-by-step of how conditional access works once it’s been setup:

1. Requests flow between users, systems and apps

In any business network, requests are constantly exchanged between users, systems, and cloud services. For example:

• A user logging data into the company CRM or ERP
• A VoIP analytics API retrieving call metrics from a cloud business VoIP phone system
• A remote employee accessing Microsoft 365 from a personal device
• Gmail synchronising inbox data with Google’s servers

Before these requests are processed, they pass through the IAM platform so that conditional access policies can be applied.

2. IAM platform collects request data

Each request carries metadata (in the form of tokens, certificates, or credentials) containing key contextual details such as:

• User identity data: Account type, group membership, role, privilege level, sign-in history, and any risk indicators from identity protection services (e.g., leaked credentials).
• Device posture: Device ID, compliance status, encryption, OS version, endpoint protection status, and management registration (for example, via Microsoft Intune).
• Network and location: IP address, geolocation, VPN or proxy detection, and whether the connection originates from a trusted network range.
• Application and resource details: Which app or API is being accessed and its sensitivity (e.g., payroll vs. internal portal).
• Session risk telemetry: Indicators such as anonymous IP use, multiple failed sign-ins, or requests from known malicious infrastructure.

The conditional access engine collects this data in real time for evaluation.

3. Request data is contextualised and risk-scored (advanced systems)

Premium IAM licences (e.g., Microsoft’s P2 tier) add risk-based assessment, which analyses normal login patterns, such as location, device, and time, to calculate a dynamic security risk score (low, medium, or high).

These systems can automatically detect anomalies like credential stuffing, unusual travel, or device compromise, prompting extra verification or blocking risky logins outright.

4. Access policies are evaluated

The IAM platform then compares the request against the organisation’s conditional access policies, the rules defining what’s allowed, challenged, or blocked.

Policies can be as broad or specific as needed. For example:

• Require strong hardware-based MFA for users outside the corporate network, and allow only biometrics when on-site
• Block access from unencrypted or unmanaged devices to reduce Shadow IT exposure
• Allow API calls only from registered service identities with valid certificates
• Deny access automatically to sessions marked “high risk” (advanced systems)

Policies can use Boolean logic (“AND”, “OR”) to combine multiple conditions, enabling even complex models to be configured through a simple dashboard.

5. IAM platform implements access policies

Finally, the IAM platform implements policy by granting, conditionally granting or denying the request based on its assessment. The possible responses are:

• Grant request: All conditions met; a fresh access token is issued.
• Challenge access: An additional verification step (e.g., MFA, device registration) is required before issuing a token.
• Restrict access: Access proceeds but with limitations (for example, browser-only, no downloads); a restricted token or session context is issued.
• Block access: The request is denied, no valid token issued, and the event is logged for audit or incident response.

Conditional access and zero trust

Conditional access is the practical application of Zero Trust Network Access (ZTNA) at the identity and access layer.

It enforces the principle of “never trust, always verify” to logins, active sessions and APIs by checking each against defined security rules before allowing or maintaining access.

However, to extend zero trust across an organisation’s digital environment, traffic and data needs to be protected after access is granted. To do this, conditional access needs to integrate with network and data-level controls, including:

• SASE (Secure Access Service Edge): Combines SD-WAN solutions with cloud-based security functions such as firewalls, threat filtering, and data-loss prevention. It applies zero trust principles to how traffic moves between users, sites, and cloud services.
• CASB (Cloud Access Security Broker): Applies zero trust at the application layer by inspecting and controlling how users interact with cloud apps and data.

Together, these layers ensure zero trust is applied end-to-end, from verifying who and what can connect through conditional access, to securing how their data travels and is used once inside.

Conditional access business use cases

Conditional access is now standard across many organisations, and adoption continues to accelerate as businesses strengthen their defences against growing security threats.

It has already helped companies of all sizes enable remote and hybrid work, grant secure access to contractors and suppliers, and meet strict compliance and audit requirements.

Below are key examples that illustrate how conditional access is applied across different business environments:

Securing remote and hybrid work

With hybrid work now the norm for most organisations, network security has had to evolve from fixed perimeters to flexible, cloud-first environments.

Conditional access plays a central role in this shift by ensuring that users connecting from home, guest WiFi, or co-working spaces meet the organisation’s security requirements.

Typical policies might:

• Require strict multi-factor authentication (MFA) when logging in from outside the corporate network
• Allow access only from compliant, company-managed devices, and through the corporate VPN
• Block access from unfamiliar or high-risk locations

Conditional access grew rapidly in popularity during the pandemic as it ensured users could work productively across devices and locations, while automatically enforcing MFA and device compliance for all cloud logins.

By contrast, businesses without conditional access continued to rely on static access rules that required manual IT intervention to the frustration of staff.

Controlling third-party and contractor access

External vendors and contractors often require access to shared or internal systems but pose elevated risk because their own security controls sit outside the organisation’s governance.

Conditional access allows businesses to grant temporary or customised access securely within their own environment.

Common policies include:

• Restricting sign-ins to approved partner domains
• Requiring MFA for all external identities
• Automatically expiring or revoking access when projects end

This use case is particularly common among UK accountancy and consulting firms using Microsoft Entra ID to manage access for third-party auditors and outsourced IT providers.

External users must authenticate via MFA, connect only from trusted IPs, and use devices that meet minimum compliance standards. Once an engagement ends, their access automatically expires, preventing lingering credentials or unmanaged devices.

In fact, inadequate controls over third-party access were identified as a key factor in the 2025 M&S supply chain attacks, where attackers exploited compromised vendor credentials to gain entry.

Enforcing BYOD (Bring Your Own Device) securely

Many organisations permit employees to use personal devices, but unmanaged hardware introduces major security gaps.

Conditional access enables strict device-based controls to reduce those risks.

Policies can:

• Allow personal devices that meet minimum security standards (encryption, PIN or biometrics, antivirus, updates)
• Restrict file downloads, data syncing, or copy/paste from corporate apps on unmanaged devices
• Enforce web-only access for sensitive applications to prevent shadow IT activity

Private healthcare providers are known to use conditional access to protect patient data when clinicians access systems from personal phones or tablets, making sure policies require MFA, device encryption, and automatic blocking of data downloads.

This ensures compliance with NHS Data Security and Protection Toolkit (DSPT) standards while still letting clinicians securely access records off-site.

Protecting access to sensitive applications and data

Not all business systems carry the same level of risk. Conditional access enables granular protection by applying stricter policies to high-sensitivity resources such as finance, HR, or client data platforms, while allowing lighter rules for lower-risk applications.

Policies might include:

• Requiring MFA and device compliance for payroll or CRM apps
• Allowing basic sign-in for internal knowledge portals
• Restricting access to privileged admin consoles from unmanaged devices

For example, UK financial advisory firms use conditional access to protect HR and payroll applications. Finance-related apps require MFA and device compliance for all users, even internal ones, while internal dashboards allow read-only access with minimal friction.

This setup helps these firms meet ISO 27001 controls and prevent credential theft targeting payroll systems.

Meeting compliance and audit requirements

Cybersecurity compliance frameworks increasingly require organisations to demonstrate strong identity and access management (IAM) controls, which conditional access directly supports through automated enforcement and auditable records.

Here’s how it supports key UK standards:

Cyber Essentials Plus

Cyber Essentials Plus requires MFA for all administrator and remote access accounts. Conditional access enforces MFA automatically and restricts remote access to compliant devices or trusted networks.

These settings are reflected in audit logs, making compliance easy to demonstrate during certification.

ISO 27001 (Control A.9.4.2: Secure log-on procedures)

Requires secure authentication and regular access reviews. Conditional access enforces both continuously, verifying users, devices, and context in real time. All policy changes and sign-ins are version-controlled and logged, creating a full audit trail.

GDPR (Article 32: Security of processing)

Requires personal data to be accessible only to authorised users through appropriate technical controls. Conditional access enforces least-privilege, context-based access, automatically blocking or revalidating users and devices that fall out of compliance, reducing data exposure risk.

Securing application-to-application (API) access

Conditional access can also govern how applications talk to each other by dynamically adjusting trust levels based on real-time security signals. This allows systems to connect without exposing sensitive data or requiring manual oversight.

Policies can assess:

• The identity and trust level of the requesting application or service
• The type of data or resource being accessed
• The security posture of the calling environment
• The network location and time of request

For example, a UK fintech company integrating its CRM, payment gateway, and reporting systems via Microsoft Entra ID can use conditional access to allow its finance API to retrieve payment data only when requests originate from within the office local area network, during business hours, and via a verified service identity.

Responding to real-time risk

Conditional access can also function as an incident response tool, allowing administrators to adjust policies instantly in response to new threats such as phishing campaigns or leaked credentials.

Rapid responses might include:

• Requiring MFA for all accounts
• Blocking sign-ins from specific regions or IPs
• Forcing password resets for users with risky sign-ins

Setting up conditional access

Setting up conditional access doesn’t require advanced technical skills. Most identity and access management (IAM) platforms that support conditional access have policy-driven interfaces that make configuration straightforward.

The process typically follows a structured path: planning, defining baseline rules, piloting with selected users, and then rolling out across the organisation in stages. Each phase focuses on balancing stronger protection with minimal disruption to how people work.

1. Planning and scoping

Most organisations begin by defining the scope of conditional access, determining which users, devices, and applications are covered:

• Categorising users and roles (e.g., all staff, privileged admins, contractors)
• Grouping applications by sensitivity (e.g., finance, HR, email, internal tools)
• Identifying the main risks to address, such as phishing, unmanaged devices, or access from high-risk regions

Clear scoping helps ensure policies are tailored and proportionate, avoiding unnecessary complexity later.

2. Establishing prerequisites

Before conditional access policies are enforced, several prerequisites are usually put in place:

• Multi-factor authentication (MFA) is enabled for all accounts (these can be activated/deactivated as per policies)
• Device management or compliance monitoring (e.g., Microsoft Intune, Google Endpoint Management) is activated
• Emergency “break-glass” accounts are created to guarantee administrative access during outages or misconfigurations
• Audit and sign-in logs are enabled for visibility

These foundations allow access controls to operate reliably and safely.

3. Creating baseline policies

Organisations typically begin with a small set of baseline policies, which are tested in report-only or audit mode before enforcement. Common baseline policies include:

• Requiring MFA for privileged or administrative roles
• Blocking legacy authentication protocols (e.g. SMS codes) that don’t support modern security standards
• Enforcing MFA for users logging in from unfamiliar or high-risk locations
• Allowing access to sensitive applications only from compliant, managed devices
• Restricting downloads or session behaviour on unmanaged devices

Running policies in audit mode first allows IT teams to understand user impact and refine configurations before enforcement.

Companies want to avoid over-restrictive policies that risk making workflows untenable (e.g. users unable to run processes due to being constantly locked out).

4. Piloting and gradual rollout

After testing, conditional access is typically introduced in phases. Organisations often start with a small pilot group, usually IT teams and selected business units, before expanding to all users.

This phased rollout helps identify potential friction points and gather user feedback early.

A common sequence might include:

• Enforcing MFA for admin roles and critical systems
• Extending MFA and location-based policies to all users
• Applying device compliance requirements for sensitive apps
• Expanding controls to contractors, partners, and application integrations

5. Managing exceptions and service access

Not every user or system fits perfectly within standard policies. Businesses often define controlled exceptions for legacy apps, integration accounts, or third-party services that cannot support modern authentication.

These exceptions are time-limited, documented, and reviewed periodically to prevent security gaps.

For automated systems and API integrations, registered service identities or managed identities are commonly used. Conditional access rules then verify their source, credentials, and network environment before approving requests.

6. Monitoring and refinement

Once conditional access is live, ongoing monitoring ensures that policies remain effective without disrupting productivity. Organisations regularly review:

• Sign-in and risk reports
• Failed and successful MFA attempts
• Blocked legacy authentication traffic
• Helpdesk trends related to access issues

Adjustments are made as the company’s digital footprint evolves. For example, adding trusted locations (new offices), updating device compliance rules (as technologies emerge), or refining session restrictions (in response to evolving threats).

7. Governance and continuous improvement

Conditional access is ultimately a core element of an organisation’s broader Identity and Access Management (IAM) framework. Once deployed, it becomes part of routine security governance, a process of continuous review, documentation, and adjustment.

This typically means:

• Enforcing MFA for all accounts
• Blocking sign-ins from specific regions or IP addresses
• Forcing password resets for users with risky sign-ins

Conditional access vs traditional access

The key difference between traditional and conditional access lies in how each responds to context.

Traditional access relies on fixed security checks (credentials, MFA, network rules) that remain the same for every login. It can be very robust but it’s rigid, applying the same steps regardless of risk.

Conditional access adapts. It analyses signals like user identity, device, and location in real time to decide when to challenge, allow, or restrict access. This means fewer unnecessary MFA prompts when conditions are safe, and tighter control when they’re not, even after access has been granted.

That flexibility can make all the difference. A system that notices a sudden login from another country, or from an unmanaged device, can block or verify it before damage occurs.

Here’s a summary table looking at the general differences in more detail:

Back to blog Back to broadband guides

• Share:
• 
• 
• 
•