What is conditional access and why does it matter for your mobile fleet?

Conditional access is a security framework that grants or blocks access to corporate resources based on real-time conditions—who is requesting access, from what device, in what state of compliance, from what location. This resource answers the most common questions IT administrators have about conditional access, specifically in the context of managing enterprise mobile device fleets.

What is conditional access?

A warehouse worker’s Zebra handheld tries to access the corporate email server and gets blocked. The device’s OS patch was three weeks out of date. That block didn’t happen by accident—it happened because a conditional access policy evaluated the device’s compliance status in real time and denied the connection.

That’s conditional access in practice: an if/then gate that sits between your users and your corporate resources, checking conditions before granting entry.

The security impact is measurable. Microsoft reports that organisations using conditional access policies see up to 99.9% reduction in compromised account sign-ins when combined with MFA. For an IT admin managing hundreds of devices that access corporate resources, this isn’t theoretical—it’s the difference between a fleet that’s a security liability and one that’s actively defended.

Here’s how most IT admins actually encounter conditional access for the first time: a user complains they “can’t get into email” on a device that was working yesterday. The block is usually a compliance policy the admin set up in MDM weeks ago finally being enforced at the identity layer—and nobody connected the two events.

How does conditional access differ from basic device management?

Enrolling a device in your MDM platform tells you the device exists. Conditional access tells you whether that device deserves to touch your data right now, in this moment, given its current state.

MDM controls what’s on the device—apps, configurations, security settings. Conditional access controls what the device can reach—which corporate resources it can access based on its compliance posture, the user’s identity, and contextual signals like location.

This distinction matters because the industry is moving this direction. Gartner estimates that by 2025, more than 60% of enterprises will have replaced traditional VPN-based access with zero-trust network access, of which conditional access is a foundational component. The perimeter isn’t the firewall anymore—it’s the identity and device compliance check at the moment of access.

The common mistake: an IT admin configures a strict compliance policy in SOTI or 42Gears—requiring encryption, minimum OS version, screen lock—but never connects that compliance signal to the identity provider. The device is technically “non-compliant” in the MDM console, but the user still accesses SharePoint, email, and internal apps without restriction.

Conditional access closes that gap.

What conditions can a conditional access policy evaluate?

The power of conditional access is that it doesn’t make a binary allow/deny decision based on one factor. It evaluates multiple signals simultaneously and applies the appropriate level of access.

In a mixed fleet—say, 400 Zebra TC53 handhelds in warehouses and 200 Samsung Galaxy phones for field sales—the conditional access policies will be materially different for each group. The warehouse devices might be restricted to three LOB apps and denied browser access entirely, while the sales phones get broader access but require MFA on every sign-in from outside the corporate network.

One policy set doesn’t fit both populations.

Why does conditional access matter for mobile device fleets specifically?

A fleet of 300 Honeywell CT60 handhelds runs an older Android version because the OEM hasn’t released the latest security patch for that model yet. A conditional access policy that requires “latest OS version” would lock out the entire fleet. The IT admin now has to choose between security policy and operational continuity.

This is the tension that makes conditional access harder for mobile fleets than for laptops.

Most enterprise mobile devices aren’t running current software. SOTI’s annual mobility report found that 73% of enterprise mobile devices run at least one version behind the latest available OS. This means most mobile fleets would fail a strict conditional access compliance check out of the box—the IT admin needs to build policies that account for real-world patch lag, not theoretical patch currency.

Rugged device OS update cycles don’t follow the same cadence as consumer phones. Zebra and Honeywell release LifeGuard and security patches on their own timelines, often months after Google’s Android release. Any conditional access policy that doesn’t account for OEM patch lag will create false non-compliance across the fleet—and the IT admin will spend their week fielding “I can’t log in” tickets instead of doing actual security work.

The question then becomes: how does the MDM platform feed this compliance reality to the identity layer in a way that’s both secure and operationally sustainable?

What role does MDM play in conditional access?

Conditional access without MDM is like a security guard checking IDs at the door but having no idea whether the person’s badge is still valid. The MDM platform is what keeps the badge current.

The relationship is straightforward: MDM evaluates device compliance (encryption enabled, OS version, passcode configured, no jailbreak detected) and reports that status to the identity provider. The identity provider then uses that compliance signal as one input in its conditional access decision. Microsoft’s documentation confirms that device compliance policies are a prerequisite for device-based conditional access—without MDM feeding compliance data, the identity layer is blind to device state.

Organisations running SOTI MobiControl or 42Gears SureMDM can integrate with Microsoft Entra ID for conditional access—but the integration isn’t automatic. It requires partner compliance configuration, API connections, and ongoing monitoring to ensure compliance signals are flowing correctly.

Most IT admins discover this gap only when a policy fails silently—devices appear compliant in the MDM console but the identity provider never received the signal. That’s why conditional access policies should be configured during initial staging and deployment, not retrofitted months later when someone notices the gap.

Common conditional access mistakes in mobile fleet environments

The most common conditional access failures aren’t security breaches. They’re self-inflicted outages where legitimate users on compliant devices get locked out because the policy was too broad, the compliance signal was stale, or nobody tested the policy against the actual device fleet.

• Applying laptop-grade compliance policies to rugged devices. A policy requiring “latest OS version” makes sense for Surface tablets that receive monthly updates. Applied to a fleet of Zebra TC72s waiting on a LifeGuard patch, it locks out the entire warehouse.
• Not creating exclusion groups for break-glass accounts or shared-use devices. When every account gets blocked—including the IT admin’s emergency access account—nobody can fix the policy that caused the lockout.
• Skipping report-only mode before enforcement. Microsoft Entra supports testing conditional access policies without enforcement. Skipping this step is the most common cause of fleet-wide lockouts.
• Ignoring location-based policies for field workers. A delivery driver operating in a rural area with inconsistent network connectivity triggers a “sign-in from unknown location” block—not because they’re compromised, but because their GPS signal bounced.

Shared-use devices are a particular blind spot. When 15 workers share five Zebra devices across shifts, user-based conditional access policies behave unpredictably unless the MDM is configured for shared device mode with proper session management. Most conditional access guides assume one user per device.

How organisations are approaching conditional access at fleet scale

For a fleet of 50 devices, an IT administrator can probably configure and maintain conditional access policies manually. At 500 devices across multiple locations, device types, and user groups, it becomes a full-time job. At 2,000+, it requires dedicated MDM expertise and continuous policy management.

The operational burden is real. IDC research indicates that organisations managing mobile fleets above 500 devices spend an average of 25+ hours per month on MDM policy administration alone—before adding conditional access complexity. That’s time spent adjusting compliance baselines when OEM patches release, troubleshooting failed policy evaluations, and fielding tickets from users who got blocked unexpectedly.

Add ongoing lifecycle management—device repairs, hot-spare swaps, SIM changes, OS updates—and the policy maintenance compounds. Every device that enters or leaves the fleet, every user that changes roles, every OEM patch that shifts the compliance baseline requires policy attention.

The organisations that get conditional access right at scale typically have a dedicated MDM administrator—or they outsource MDM operations to a managed service provider who handles policy configuration, compliance monitoring, and identity integration as part of ongoing operations.

Where managed MDM services fit in

For many Canadian organisations, the gap isn’t technology. They already own the MDM licence. The gap is operational capacity—having someone who understands both the MDM platform and the conditional access framework well enough to keep policies current, test changes before enforcement, and troubleshoot the inevitable conflicts between device compliance and identity-layer access controls.

This is where managed MDM services enter the picture.

PiiComm’s MDM as a Service (MDMaaS) includes conditional access policy configuration and ongoing management as part of its operational scope. PiiComm’s certified MDM administrators—based in Canada and operating on SOTI, 42Gears, and Intune—handle the integration between device compliance and identity providers, monitor for policy drift, and adjust compliance baselines when OEM patch cycles change.

This matters for Canadian regulatory context. When conditional access compliance data flows between the MDM platform and the identity provider, that data includes device identifiers, user identities, location information, and compliance status—all of which may constitute personal information under PIPEDA. PiiComm’s MDMaaS operates entirely from Canadian infrastructure with Canadian-based administrators, ensuring that conditional access compliance data stays in-country.

This isn’t a software licence. It’s an operational service—someone else monitoring the OEM patch releases, adjusting the compliance baselines, testing policy changes in report-only mode, and keeping the identity integration healthy so your IT team can focus on something other than “I can’t log in” tickets.

If your team is managing conditional access policies across a growing mobile fleet and finding it harder to keep up, learn how managed MDM services can take that operational burden off your plate.

Frequently asked questions

What is conditional access in simple terms?

Conditional access is a security framework that checks conditions—device compliance, user identity, location—before granting access to corporate apps and data. Think of it as an if/then gate: if the device meets the requirements, access is granted; if not, it’s blocked until remediation.

Do I need an MDM platform to use conditional access?

For device-based conditional access policies, yes. Without MDM, conditional access can only evaluate user-level signals like identity and location. Device compliance policies require MDM to report encryption status, OS version, and passcode configuration to the identity provider.

Does conditional access work with rugged enterprise devices like Zebra or Honeywell handhelds?

Yes, but with caveats. Rugged Android devices are supported, but OEM-specific patch cycles mean compliance baselines must account for the lag between Google’s Android release and the manufacturer’s update. Shared-use configurations also require specific MDM setup.

What happens when a device fails a conditional access check?

The device is blocked from accessing the requested resource—email, apps, SharePoint—until it meets compliance requirements. Users see a remediation prompt; IT admins see a spike in support tickets if the policy was too aggressive.

How does conditional access affect shared-use devices in warehouses or retail?

Shared-use devices require MDM shared device mode to properly evaluate per-user conditional access policies. Without it, the system evaluates the last signed-in user’s compliance status—creating security gaps when workers switch shifts.

Is conditional access required for PIPEDA compliance?

Not explicitly mandated, but strongly aligned. PIPEDA’s Accountability Principle requires security safeguards appropriate to the sensitivity of personal information. Conditional access is a demonstrable, auditable technical control that supports compliance posture when devices access systems containing personal information.

Can I test conditional access policies before enforcing them?

Yes—and you should. Microsoft Entra supports report-only mode for conditional access policies, showing which sign-ins would have been blocked without actually blocking them. Skipping this step is the most common cause of self-inflicted fleet lockouts.