Full?tunnel Virtual Private Network access widened exposure; Zscaler Private Access and Intune enforced app?level access

Overview

A healthcare network’s move to zero trust stalled because remote users still relied on a broad, full?tunnel Virtual Private Network (VPN) for most applications. Access broke during peak times, segmentation was coarse, and device security posture had little influence on what users could reach. Intelligex layered Zscaler Private Access (ZPA) on top of the existing stack, enforced device posture using Microsoft Intune and CrowdStrike signals, and routed granular application access through an approval workflow. Remote access became predictable, broad network exposure receded, and segmentation aligned to applications rather than subnets—without replacing identity, endpoint, or change?management tools.

Client Profile

• Industry: Healthcare provider network (hospitals, clinics, and remote care)
• Company size (range): Multi?site operations with a centralized platform and security team
• Stage: Legacy VPN in place; identity provider with MFA; Microsoft Intune for device management; CrowdStrike for endpoint protection; mixed on?premises and cloud application footprint
• Department owner: IT & Infrastructure (Network, Platform/SRE, and Security Engineering)
• Other stakeholders: Clinical Applications, Telehealth, Security Operations, Identity and Access Management, Compliance/Privacy, Helpdesk/NOC, Internal Audit

The Challenge

The network boundary assumed trust once a user connected. Clinicians and staff used a full?tunnel VPN to reach everything inside, from clinical apps to admin portals. Split?tunnel policies varied by group and device type, and capacity planning hinged on peak shifts rather than on actual application flows. When the VPN faltered, remote sessions dropped, workarounds appeared, and incident queues filled.

Device posture signals were disconnected from access. Intune compliance and CrowdStrike detections were reviewed after the fact, not enforced at the moment of connection. Contractors and third?party clinicians used a patchwork of profiles with uneven controls. Application rollouts required firewall rule changes and DNS updates across zones, and approvals for new access lived in tickets that were difficult to trace to specific apps.

Compliance and privacy added pressure. Clinical workloads demanded least?privilege access and auditable decisions. The team wanted to move to a zero trust model that bound user identity and device posture to application?level access, but migration plans stalled over legacy dependencies and the fear of breaking remote work.

Why It Was Happening

Root causes were a perimeter mindset and fragmented enforcement. The VPN provided a coarse “in or out” control, and segmentation relied on network zones and firewall rules. Device compliance existed, but there was no authoritative gate to combine user, device, and application signals at runtime. Access requests captured business intent, but approvals were not bound to the actual policies that governed connectivity.

Ownership and timing were split. Network managed VPN gateways and firewalls, Endpoint Engineering enforced baselines in Intune, Security ran CrowdStrike, and IAM handled authentication. Without a shared control plane to express application?level policy and posture, every change required bespoke coordination and created drift between tickets and enforcement.

The Solution

Intelligex implemented an application?centric access layer using Zscaler Private Access (ZPA), tied to device posture from Microsoft Intune and CrowdStrike, with approvals and evidence captured through the existing ITSM. Users reached only the applications they were authorized to use, from compliant devices, with policy evaluated on each request. Legacy VPN remained for limited scenarios during transition. The approach aligned with zero trust design principles as described in NIST SP 800?207 and leveraged official guidance for the components: Zscaler ZPA, Microsoft Intune, and CrowdStrike’s zero?trust posture capabilities (CrowdStrike Zero Trust).

• Integrations: ZPA connectors deployed near applications; identity provider for Single Sign?On (SSO) and Multi?Factor Authentication (MFA); Intune compliance and CrowdStrike posture signals; DNS and private name resolution; ITSM (for example, ServiceNow) for access requests and approvals; logging to the existing Security Information and Event Management (SIEM).
• Application segmentation: Catalog of private apps with owners, sensitivity, and network backends; policies mapped user and device attributes to specific apps and protocols; no broad subnet exposure.
• Device posture enforcement: Intune compliance states and CrowdStrike health scores as conditions; minimum OS, encryption, and EDR presence checks per app class; grace paths for remediation.
• Approval workflow: Service Catalog for app access requests; maker?checker approvals for sensitive apps; access packages with time?bound expirations; ticket linkage to policy entries.
• Legacy coexistence: VPN retained for a limited set of use cases and phased out per wave; fallback documented; traffic steering based on application lists.
• Observability and audit: Dashboards for posture denials, app?level access, and connector health; immutable logs linking approvals, posture decisions, and app sessions; exportable evidence packs.
• Security and privacy: Least?privilege defaults; inline posture checks; no client?to?network reachability; role?based access to policies and logs.

Implementation

• Discovery: Cataloged private and clinical apps, protocols, and owners; mapped current VPN split?tunnel lists; reviewed Intune compliance and CrowdStrike posture signals; inventoried identity groups and approval routes; gathered audit and privacy requirements.
• Design: Defined the application catalog and ownership; authored access policies by app class (clinical, admin, vendor); specified device posture requirements and remediation paths; designed the access request catalog, approver tiers, and expirations; planned rollout waves and fallback.
• Build: Deployed ZPA connectors and app segments; integrated SSO and MFA; connected Intune and CrowdStrike posture to policy conditions; configured DNS and name resolution; built the Service Catalog with approvals and evidence linkage; wired logs to the SIEM and built dashboards.
• Testing/QA: Ran in shadow mode: evaluated posture and access without blocking; piloted a subset of apps with a small cohort; validated EHR and clinical workflows; tuned policies, posture thresholds, and remediation prompts; confirmed fallback to VPN where needed.
• Rollout: Onboarded applications by wave (low?risk admin apps first, clinical apps later); enabled enforcement per app group; kept VPN available for documented exceptions; tightened policies after stable cycles; turned on time?bound approvals for sensitive apps.
• Training/hand?off: Delivered sessions for Helpdesk, Clinical Apps, and Security on posture denials, approvals, and diagnostics; created user guides for new access paths; updated SOPs for onboarding, offboarding, and exception handling; transferred ownership of policy and dashboards to Platform/Security under change control.
• Human?in?the?loop review: Established a recurring review of denials, exception aging, connector health, and policy updates; decisions recorded with rationale and effective dates.

Results

Remote access stabilized and became more predictable. Users reached defined applications through ZPA with SSO and MFA, and device posture determined eligibility in real time. Policy lifted the burden from firewall and VPN rule changes; new apps were published by mapping them to connectors and policies rather than by widening network zones. Helpdesk used consistent remediation paths when posture checks failed, which shortened support loops.

Exposure narrowed. Broad VPN access gave way to application?level connectivity, reducing lateral movement risk. Access requests carried owner approvals and expirations, and the audit trail tied every session to the user, device posture, and policy version. The legacy VPN remained only for specific, documented cases; the primary change was a zero trust access layer that integrated with identity, endpoint, and ITSM systems the teams already used.

What Changed for the Team

• Before: Full?tunnel VPN exposed large network segments. After: ZPA granted per?application access with least?privilege defaults.
• Before: Device compliance was checked after incidents. After: Intune and CrowdStrike posture gated access at the moment of connection.
• Before: New access meant firewall and VPN rule changes. After: App mapping and policy updates published access without broad network changes.
• Before: Approvals lived in tickets unconnected to enforcement. After: Service Catalog approvals created policy entries with expirations and evidence.
• Before: Troubleshooting posture errors varied by team. After: Standard remediation prompts and runbooks guided users and Helpdesk.
• Before: VPN was the default for all remote work. After: VPN remained only for documented exceptions during the transition.

Key Takeaways

• Start with an application inventory; policy follows clean app definitions and owners, not subnets.
• Bind access to posture; tie Intune compliance and CrowdStrike health to runtime decisions.
• Keep approvals in the loop; time?bound access packages with maker?checker convert intent into enforceable policy.
• Run in shadow mode; test posture and access with cohorts before enforcing across clinical apps.
• Stage the cutover; move by application waves and retain a documented VPN fallback early on.
• Integrate, don’t replace; keep identity, endpoint, and ITSM tools—add a zero trust access layer around them.

FAQ

What tools did this integrate with? The solution used Zscaler Private Access for application connectivity, Microsoft Intune for device compliance, and CrowdStrike posture signals (CrowdStrike Zero Trust). Identity and MFA ran through the existing provider, and the ITSM platform (for example, ServiceNow) handled access requests and approvals. Logs flowed to the SIEM. Design principles aligned with NIST SP 800?207.

How did you handle quality control and governance? Application entries carried owners, sensitivity tags, and policy versions under change control. Access packages required maker?checker approvals and expirations. Posture requirements were documented with rationale and tuned through review. All approvals, policy changes, posture evaluations, and sessions were immutably logged with evidence packs for audit and privacy review.

How did you roll this out without disruption? Policies ran in shadow mode first, evaluating posture and access without blocking. A pilot cohort exercised admin apps, followed by clinical apps in planned waves. VPN remained available for documented exceptions during the transition. Enforcement expanded only after stable cycles and training, with rollback paths and clear remediation steps.

How were legacy and non?web apps handled? ZPA connectors published TCP and UDP applications in addition to web apps. For protocols that did not fit, the VPN remained as a temporary path while alternatives were evaluated. App definitions included ports, hostnames, and backends, and policy scoped access to those specifics.

How did you manage contractors and BYOD? Contractors requested app access through the Service Catalog with time?bound approvals. BYOD access required registered devices that met posture requirements or used virtual desktops as a compensating control. Exceptions were documented with review dates and monitored in dashboards.

What changed for troubleshooting? Helpdesk received clear posture denial reasons and runbook links. Dashboards showed connector health, top denials by cause, and recent policy changes. Tickets included the affected app, user identity, device posture, and policy version, which shortened root?cause analysis.

How did you align this with privacy and clinical safety? Policies enforced least privilege and device health without exposing networks. Sensitive app access required additional approvals and shorter expirations. Logging captured decisions and outcomes while masking fields not needed for support, and reviews included Privacy and Clinical IT representatives.