Zero Trust Network Access (ZTNA) replaces the assumption that users and devices inside a corporate network are trustworthy.
Zero Trust Fundamentals for Mobile Environments
The Zero Trust model, formalized in NIST SP 800-207 and popularized through Google's BeyondCorp research, rests on a small set of axioms: the network is not a trust boundary; every access request must be authenticated and authorized; access grants should provide minimum necessary privilege and expire.
Applied to mobile devices, these principles demand that every API call, file access, or application session origination from a mobile device be verified against the current state of both the user and the device—not the network topology from which the request arrives.
Traditional perimeter security models extend VPN tunnels to mobile devices, granting network-level access to the corporate segment once authenticated. This approach grants overly broad access (network reachability rather than application-level authorization), relies on a perimeter that no longer meaningfully exists for distributed workforces, and cannot enforce device health as a prerequisite for access.
A Zero Trust mobile access model requires three data inputs for every access decision: verified user identity, verified device health, and the specific resource being requested. Each input is evaluated independently and continuously—not just at session start.
Why Traditional VPN Falls Short for Mobile Security
Split-tunnel VPN, the most common enterprise mobile access architecture, allows mobile devices to route corporate traffic through an encrypted tunnel while routing personal traffic directly to the internet. This reduces VPN gateway load but creates a blind spot: if the device is compromised by malware, the malware can use the VPN tunnel to reach corporate resources using the device's authorized session—without the organization being able to distinguish malicious traffic from legitimate application traffic.
Full-tunnel VPN eliminates the split-tunnel blind spot but introduces scalability and performance challenges for mobile users accessing cloud SaaS applications: traffic must traverse the VPN gateway before reaching a public internet destination, adding latency and gateway load. This conflicts with the performance expectations of users on mobile connections. As organizations have migrated critical workloads to Microsoft 365, Google Workspace, and SaaS platforms, the hairpinning VPN architecture has become a performance bottleneck.
VPN also lacks granular access control: a VPN connection grants network access to a broad network segment, not to a specific application with specific permissions. Application-level access policies require additional tooling layered on top of VPN (network access control lists, application firewalls), increasing complexity.
ZTNA addresses all three limitations: it evaluates device health at access time, routes traffic directly to application endpoints, and enforces application-level access policies without requiring network-layer access.
ZTNA Architecture: How It Works with MDM
ZTNA implementations follow one of two architectural patterns: agent-initiated and service-initiated.
In agent-initiated ZTNA (the most common enterprise model), a software agent runs on the mobile device alongside the MDM client. When a user attempts to access a protected application, the agent contacts the ZTNA controller, submits device health claims (from the MDM compliance API), and receives time-limited access tokens for the specific application. The device connects directly to the application via an encrypted session—without gaining network access to other resources.
Device health evaluation includes MDM compliance status, certificate validity, OS version, and threat detection signals.
In service-initiated ZTNA (more common for third-party access or environments without persistent agents), an inline proxy evaluates access requests at the network edge. The proxy checks identity assertions from the IdP and device compliance signals from MDM before forwarding or blocking requests.
MDM integration in both architectures provides the device trust signal. Without MDM, ZTNA systems can verify identity but cannot verify device health—they're forced to grant access to any authenticated user regardless of the security state of the device they're using. With MDM compliance APIs wired into the ZTNA access policy engine, a device that has fallen out of compliance (OS update pending, encryption disabled, unauthorized app detected) automatically loses access to protected resources until remediation occurs.
Device Trust vs User Trust in Zero Trust Models
A frequent point of confusion in Zero Trust mobile deployments is conflating device trust with user trust. Both are required; neither alone is sufficient for authorizing access to sensitive resources.
User trust is established through identity verification: primary authentication (username and password), multi-factor authentication (TOTP, hardware security key, push notification), and behavioral analytics (sign-in risk scoring from Microsoft Entra ID Protection, Okta ThreatInsight, or equivalent). A low-risk authentication from a known location on a recognized device generates high user trust. An authentication from a new location against the user's pattern generates lower trust and may trigger step-up authentication.
Device trust is established through MDM enrollment, compliance verification, and hardware attestation. An enrolled device with current OS, enabled encryption, valid management certificate, and passed hardware attestation (Android Play Integrity, Apple DeviceCheck) generates high device trust. An unenrolled personal device, or a managed device with an outdated OS, generates lower device trust.
Zero Trust policy engines combine these signals through weighted scoring or explicit policy rules. The most restrictive policies require both high user trust and high device trust for access to sensitive systems.
Less sensitive resources may permit access with lower device trust (unmanaged devices accessing read-only document repositories through browser sessions, for example).
Implementing ZTNA with BlackBerry UEM and Microsoft Intune
Two MDM platforms dominate enterprise Zero Trust mobile deployments: BlackBerry UEM and Microsoft Intune, each integrating into ZTNA frameworks through distinct approaches.
BlackBerry UEM and BlackBerry Gateway
BlackBerry's ZTNA solution, BlackBerry Gateway, integrates natively with BlackBerry UEM for device compliance signals. BlackBerry Dynamics-managed applications enforce application-level Zero Trust policies: each app authenticates independently, traffic is encrypted at the application layer (not just the transport layer), and data sharing between managed and unmanaged apps is blocked by policy. BlackBerry's approach is particularly strong in regulated industries where BlackBerry Dynamics' FIPS 140-2 validated encryption satisfies compliance requirements that generic ZTNA tools do not address.
Microsoft Intune and Entra Conditional Access
Microsoft's Zero Trust mobile architecture centers on Intune device compliance publishing to Microsoft Entra ID (formerly Azure AD) conditional access policies.
Entra conditional access evaluates device compliance status from Intune, user sign-in risk from Entra ID Protection, and application sensitivity classifications before issuing access tokens to Microsoft 365 and third-party SaaS applications registered in Entra ID.
Microsoft's Global Secure Access (formerly Azure AD Private Access/Internet Access) extends this to ZTNA for on-premises applications and internet traffic, completing the full-stack Zero Trust architecture within the Microsoft ecosystem.
Cross-Platform ZTNA Integration
Vendors including Zscaler Private Access, Cloudflare Access, and Palo Alto Prisma Access integrate with both MDM platforms through device compliance APIs. These solutions provide ZTNA for heterogeneous environments where Android, iOS, Windows, and macOS devices are managed through different MDM platforms, centralizing access policy in the ZTNA layer while consuming device compliance signals from each underlying MDM.
Continuous Authentication on Mobile Devices
Traditional authentication models authenticate users at session start and maintain session state until explicit timeout or logout. Continuous authentication extends identity verification throughout the session lifecycle, re-evaluating trust at intervals or triggered by behavioral anomalies.
For mobile devices, continuous authentication mechanisms include: periodic re-challenge with biometrics or PIN at application layer (common in BlackBerry Dynamics managed apps); behavioral biometrics analysis of typing rhythm, touch pressure, and device movement patterns that can detect device handoff to a different user; geolocation monitoring that triggers re-authentication when the device moves outside an expected geographic boundary; and network location changes that trigger risk re-evaluation.
Continuous authentication at the application layer differs from session reauthentication at the identity provider layer. MDM compliance re-evaluation operates separately: the MDM client checks in with the server on a configured schedule (typically 4–24 hours) and updates compliance status. An access control policy that waits for the next MDM check-in to respond to a compliance change has a gap window.
Tighter integration—where MDM compliance changes trigger immediate access token revocation through the ZTNA controller—reduces this gap to seconds.
Conditional Access Policies: A Practical Framework
Effective conditional access policy design requires segmenting the application portfolio by sensitivity and matching access requirements to that classification.
A three-tier classification framework is common in enterprise deployments. Tier 1 (low sensitivity): public-facing tools, read-only knowledge bases, corporate intranet news—permit access from any enrolled device, any authentication method, any location. Tier 2 (standard sensitivity): corporate email, collaboration tools, project management systems—require MDM-enrolled device, standard MFA, and device compliance. Block access from non-enrolled devices.
Tier 3 (high sensitivity): financial systems, HR records, source code repositories, PII-containing databases—require MDM-enrolled device with full MDM management (not BYOD Work Profile), hardware-attested device health, phishing-resistant MFA (FIDO2 security key or passkey), and optionally network location restrictions.
Named location policies add geographic dimensions: blocking authentication attempts from countries outside expected operating regions (effective against broad credential stuffing attacks), or requiring stronger authentication factors for access from outside the corporate campus network. BYOD-specific policies may restrict download and print permissions for Tier 2 applications when accessed from non-corporate devices, preventing data exfiltration through personal device storage.
Challenges in Zero Trust Mobile Deployments
ZTNA mobile deployment projects encounter several recurring operational challenges.
Legacy Application Compatibility
Applications that authenticate against IP-based access control lists or rely on network location as an implicit authentication factor break under ZTNA. Migrating these applications to identity-based access control requires either application refactoring or ZTNA connectors that maintain backward-compatible IP-based session management while enforcing identity and device health checks at the connector layer.
MDM Enrollment Coverage Gaps
Zero Trust mobile access requires MDM enrollment; unmanaged devices cannot contribute device trust signals. Organizations with large contractor, vendor, or partner user populations—who use personal devices and are unlikely to enroll in corporate MDM—must design ZTNA policies that provide limited access to these populations without requiring full MDM enrollment. MAM-only policies (enrolling specific apps without enrolling the device) provide a partial solution for contractor access scenarios.
User Experience Trade-offs
Aggressive continuous authentication and frequent re-challenge policies create friction that drives users toward workarounds: sharing credentials, using personal devices outside MDM scope, or accessing corporate data through unsecured channels. Successful Zero Trust implementations balance security controls with user experience through context-aware policies that reduce friction for low-risk access patterns while applying stronger verification to high-risk requests. See also the BYOD Security Policy Guide for employee communication strategies around device management.
Token Revocation Latency
OAuth 2.0 access tokens issued by identity providers have lifetimes that create a gap between when a device loses compliance status and when that non-compliance results in access denial. Short token lifetimes (15–30 minutes) reduce this gap but require frequent token refresh operations, increasing network overhead. Continuous Access Evaluation Protocol (CAEP) and Shared Signals Framework (SSF)—supported by Microsoft Entra ID and increasingly by Okta—allow MDM compliance events to trigger near-immediate access token revocation without waiting for token expiration.
Frequently Asked Questions
What is ZTNA and how does it differ from a VPN?
ZTNA (Zero Trust Network Access) grants access to specific applications based on continuous verification of user identity and device health, without providing network-level access to the surrounding infrastructure. A VPN creates an encrypted tunnel that grants network access to a segment, from which the user can reach any host on that network.
ZTNA is application-specific, requires no network access, and evaluates device compliance on each access request; VPN provides broad network access once authenticated and does not continuously evaluate device health.
Can ZTNA work without MDM enrollment?
ZTNA can operate without MDM, but loses the device health verification dimension. Without MDM, ZTNA can only verify user identity—it cannot confirm that the device is encrypted, running a compliant OS, or free of detected threats. Many organizations implement tiered access: MDM-enrolled devices receive full access to all authorized applications; non-enrolled devices receive limited access (browser-only, read-only, restricted data classification) without device health verification. Full Zero Trust requires both identity and device health verification.
How does ZTNA handle offline mobile access?
ZTNA requires network connectivity for access authorization. Offline access to ZTNA-protected resources is not possible without pre-cached content or application-level offline modes. Organizations that need offline access (field workers, aircraft crews) must architect application-layer offline capabilities separately from ZTNA access control. Data cached offline should be protected by MDM-enforced device encryption and application-level encryption to maintain security without active ZTNA enforcement.
What MFA methods work best for Zero Trust mobile deployments?
Phishing-resistant MFA methods are preferred in high-assurance Zero Trust deployments: FIDO2 security keys (hardware tokens), device-bound passkeys, and certificate-based authentication (which MDM distributes to enrolled devices). Push notification MFA (Microsoft Authenticator, Duo) is effective against password spray but vulnerable to MFA fatigue attacks. Time-based OTP (TOTP) codes are the weakest MFA option in a Zero Trust context—they can be phished in real-time. For Tier 3 (high-sensitivity) applications, FIDO2 or certificate-based authentication is recommended.
How does NIST SP 800-207 define Zero Trust architecture?
NIST SP 800-207 defines Zero Trust as an evolving set of cybersecurity paradigms that move defenses from static, network-based perimeters to focus on users, assets, and resources.
The document identifies seven tenets of Zero Trust: (1) all data sources and computing services are resources; (2) all communication is secured regardless of network location; (3) access is granted per-session; (4) access is determined by dynamic policy including behavioral and environmental attributes; (5) the enterprise monitors and measures integrity of all assets; (6) authentication and authorization are dynamic and strictly enforced; (7) the enterprise collects information to improve security posture.
Mobile device MDM compliance is a direct contributor to tenets 4, 5, and 6.
What is the role of hardware attestation in Zero Trust mobile access?
Hardware attestation provides cryptographic proof that a device's security claims originate from unmodified hardware and OS, not from a software agent that could be spoofed. Android Play Integrity API provides a verdict signed by Google's attestation infrastructure;
Apple DeviceCheck and App Attest provide device-bound attestation from Apple's infrastructure. Both rely on hardware security elements (Secure Enclave on Apple, Titan M on Google Pixel) that cannot be spoofed without hardware compromise. ZTNA policies requiring hardware attestation prevent attackers from presenting fake device compliance claims to gain access.
How should organizations phase a Zero Trust mobile rollout?
A phased Zero Trust mobile rollout typically proceeds in four stages. Phase 1: complete MDM enrollment of all corporate-owned devices and establish compliance baselines. Phase 2: implement conditional access policies that block non-compliant devices from Tier 2 applications (email, collaboration) in monitor-then-enforce mode—log violations before blocking to identify issues.
Phase 3: extend conditional access to Tier 3 applications with phishing-resistant MFA requirements. Phase 4: implement ZTNA for on-premises application access, eliminating VPN for enrolled devices. Each phase should include user communication and help desk preparation to handle access denial scenarios.
What is Continuous Access Evaluation Protocol (CAEP)?
CAEP (Continuous Access Evaluation Protocol) is an emerging standard under the OpenID Foundation's Shared Signals Framework that enables real-time communication of security events between identity providers and resource servers. When an MDM platform detects a compliance change (device encryption disabled, threat detected), it can emit a CAEP event that the identity provider consumes and uses to revoke active access tokens immediately—without waiting for token expiration.
CAEP closes the gap between access token lifetime and the speed of access revocation. Microsoft Entra ID supports CAEP for Microsoft 365 resources; Okta support is in development.
How does Zero Trust apply to contractor and third-party mobile access?
Contractors and third parties rarely enroll personal devices in corporate MDM programs. Zero Trust for this population typically uses browser-based ZTNA access (no agent required), MAM-only enrollment (specific apps managed without full device enrollment), virtual desktop infrastructure (VDI) sessions where corporate data never touches the physical device, and restricted data classification access (read-only, no download).
Identity verification for contractors uses federated authentication (guest accounts, B2B federation) with organizational MFA requirements enforced at the identity provider layer, compensating for the absence of device trust signals.
Conclusion
Zero Trust mobile access represents a structural improvement over perimeter-based models for modern enterprise mobility: it eliminates the implicit trust granted by network location, enforces least-privilege at the application level, and enables organizations to manage security posture for diverse device populations without requiring homogeneous management profiles.
The foundational dependency is MDM: without device enrollment and compliance monitoring, ZTNA access decisions are limited to identity verification alone, leaving device health as an unresolved trust gap.
For organizations beginning a Zero Trust mobile journey, the sequencing matters: complete MDM deployment and establish compliance baselines before layering ZTNA access policies on top. A ZTNA architecture built on incomplete MDM enrollment produces access policies with significant coverage gaps. For related implementation considerations, see the BYOD Security Policy Guide and enterprise mobile vulnerability coverage.