VPN and Remote Access Security

To meet the VPN and remote access security requirement, you must force all remote connections through a VPN that uses strong encryption and mandatory multi-factor authentication (MFA), disable split tunneling, and restrict access to authorized users and approved systems. Operationally, this means standardizing remote access paths, tightening identity and device controls, and retaining evidence that proves enforcement.

Key takeaways:

• Require VPN + MFA for every remote connection, including third-party and admin access, with strong encryption. ¹
• Disable split tunneling and tightly scope which users, devices, and systems can be reached remotely. ¹
• Keep audit-ready artifacts: configurations, access inventories, MFA enforcement proof, and logs that show remote sessions are controlled and monitored.

“Remote access” usually grows faster than governance. A few IT exceptions for admins, an urgent third-party support request, an acquired clinic that needs access “temporarily,” and soon you have multiple paths into your network with uneven controls. HICP Practice 5.5 targets that exact risk: remote connectivity expands your attack surface, so remote access must be secured through VPN connections with strong encryption and mandatory MFA, split tunneling should be disabled, and access should be limited to authorized users and systems. ¹

For a Compliance Officer, CCO, or GRC lead, the work is less about selecting a VPN brand and more about making the requirement testable: one approved remote access architecture, clear decision points for exceptions, and durable evidence. This page gives requirement-level implementation guidance you can hand to IT and then audit without guesswork: what “strong encryption” and “mandatory MFA” should look like in policy, how to operationalize split-tunneling prohibition, what to do about third parties, and what artifacts to retain so you can pass an assessment without scrambling.

Regulatory text

HICP Practice 5.5 excerpt: “Secure remote access connections using VPN with strong encryption and multi-factor authentication requirements.” ¹

Operator interpretation (what you must do):

• Force remote access through a VPN: Remote connectivity into your environment must traverse an organization-controlled VPN, not ad hoc port forwards, exposed RDP, or “temporary” firewall rules.
• Use strong encryption: Configure the VPN to use modern, secure cryptography and disable weak/legacy protocol options.
• Require MFA: Every remote access login must require MFA, including privileged/admin access and third-party access.
• Disable split tunneling: Remote devices connected to the VPN should not simultaneously route general internet traffic outside the VPN if that creates an uncontrolled dual path.
• Limit access to authorized users and systems: Remote access should be granted only to approved identities and only to the systems necessary for their job function. ¹

Plain-English requirement (what “good” looks like)

A remote user or third party should have exactly one sanctioned way to connect. They authenticate with MFA, connect to a VPN using strong encryption, and only then can they reach a narrowly defined set of internal resources. You can prove this with configurations and logs, and you have an exception process for any edge cases.

Who this applies to

Entity scope

• Healthcare organizations (providers, payers, labs, integrated delivery networks)
• Health IT vendors (including managed service providers supporting healthcare environments) ¹

Operational scope (where this requirement bites)

• Workforce remote access to internal apps, EHR access paths, and corporate resources
• Privileged remote administration (domain admins, network engineers, server administrators)
• Third-party remote support (EHR vendors, billing vendors, MSPs, medical device support)
• Cloud admin consoles and remote access into hosted environments, where VPN is part of the control plane or a compensating control for admin access paths

What you actually need to do (step-by-step)

1) Define the sanctioned remote access patterns (and ban the rest)

Create a short “Remote Access Standard” that answers:

• Which VPN technology is approved for workforce remote access
• Which method is approved for third parties (often separate from workforce)
• Whether any direct remote protocols are prohibited (example: direct RDP from the internet)
• What “no split tunneling” means in your environment (all traffic through VPN, or at minimum no dual-path access to internal networks plus open internet)

Deliverable: Remote Access Standard + prohibited-connection statement mapped to HICP Practice 5.5. ¹

2) Inventory every remote access entry point

You cannot enforce what you cannot enumerate. Build and maintain an inventory of:

• VPN gateways and configurations (including “temporary” ones)
• Remote administration tools and jump hosts
• Third-party remote access mechanisms (agent-based tools, support tunnels, dedicated accounts)
• Firewall rules that permit inbound management access
• Cloud remote admin paths (where remote access is effectively a privileged session)

Tip for operators: Ask IT for a list, then validate with firewall configs and identity system group membership. “We only have one VPN” is often incorrect.

3) Enforce MFA for all remote access identities

MFA enforcement must be technical, not “policy says.” Confirm:

• VPN authentication requires MFA for every user, every time, including admins
• Third-party accounts require MFA and are uniquely assigned (no shared logins)
• “Break glass” accounts exist, are tightly controlled, and are not used for routine remote access

Evidence goal: A screenshot/export showing MFA required in the VPN/IAM configuration plus a sample authentication policy applied to the relevant groups. ¹

4) Configure “strong encryption” by disabling weak options

For compliance purposes, treat “strong encryption” as a configuration management problem:

• Disable legacy protocols/ciphers on the VPN gateway
• Standardize the approved VPN profile(s)
• Ensure certificate management and key handling are owned, documented, and monitored

Control-owner note: Compliance can set the requirement and test criteria; IT/security engineering should document the specific cipher/protocol configuration as the system-of-record.

5) Disable split tunneling (and document any approved exception)

Implement the no-split-tunnel stance for remote clients where feasible:

• For workforce laptops, enforce a VPN profile that routes traffic per your standard
• For BYOD or constrained use cases, consider restricting remote access entirely or limiting to specific managed methods

If you must allow split tunneling for a limited case, treat it as an exception:

• Business justification
• Compensating controls (tighter device posture, narrower network access, enhanced monitoring)
• Approval and expiry

This aligns directly to the HICP plain-language summary that calls out split tunneling disabled. ¹

6) Limit remote access to authorized users and approved systems

This is where audits often focus, because “VPN + MFA” alone still allows broad lateral movement.

Implement:

• Role-based access: VPN access groups aligned to job function
• Network segmentation rules: remote users can reach only required subnets/services
• Privileged access separation: admin remote access should go through a hardened path (for example, a jump host) with tighter monitoring
• Third-party scoping: third parties get access only to the systems in their support scope, during approved windows where possible

Testing method: Pick a sample remote user and demonstrate what they can and cannot reach.

7) Log, monitor, and periodically review remote access

HICP 5.5 is a security requirement; auditors will still ask how you detect misuse.

• Log VPN authentications and session metadata
• Review remote access group membership changes
• Review third-party account activity
• Investigate anomalous access (odd geographies, off-hours, repeated MFA failures)

Artifact approach: Keep a recurring “Remote Access Review” record with findings and remediation tickets.

8) Build third-party remote access into due diligence and contracting

Remote access for third parties is a common gap: the vendor uses their tool, your team lacks visibility, and access persists.

Minimum operational rules:

• Third-party remote access must use your approved method or a formally approved exception
• Contracts/SOWs should require MFA and define access boundaries (systems, purpose, support hours)
• Offboarding must include removal of accounts, certificates, agents, and tunnels

Where Daydream fits naturally: If you manage many third parties and struggle to track who has remote access, Daydream can centralize third-party access evidence (who has access, to what, via which method), tie exceptions to approvals, and keep artifacts audit-ready without chasing screenshots across teams.

Required evidence and artifacts to retain

Keep artifacts in a single evidence folder per audit period:

Policy/standards

• Remote Access Policy / Standard (VPN required, MFA required, split tunneling stance)
• Exception process and exception register entries (if any)

Technical configurations (exported or screen-captured)

• VPN gateway configuration showing encryption settings and disabled weak options
• MFA enforcement configuration for VPN access
• Split tunneling setting (client profile / gateway policy)
• Group-based access rules and network ACLs/segmentation for VPN users

Identity and access management

• List of users/groups authorized for VPN access
• Third-party account list with owners, purpose, and end dates where applicable

Operational records

• Remote access logs (authentication/session logs) and retention proof
• Periodic access reviews and remediation tickets
• Offboarding tickets showing removal of remote access for terminated users and third parties

Common exam/audit questions and hangups

• “Show me that MFA is required for VPN for all users, including administrators.”
• “Is split tunneling enabled? If yes, who approved it and what compensating controls exist?”
• “Which third parties have remote access today, and what systems can they reach?”
• “Are there any alternate remote access paths (remote tools, direct admin ports) outside the VPN?”
• “Demonstrate least-privilege access: pick a user and show what internal resources they can access remotely.”

Frequent implementation mistakes (and how to avoid them)

1. MFA enforced for employees but not for third parties.
   Fix: Require named third-party accounts with MFA, owned internally, and reviewed.

2. Split tunneling disabled “in policy,” enabled in actual profiles.
   Fix: Evidence must come from the VPN profile/gateway settings, not a PDF.

3. One giant “VPN Users” group with broad network reach.
   Fix: Break access into roles and segment network routes/firewall rules by role.

4. Shadow remote access tooling (helpdesk tools, emergency RDP rules).
   Fix: Inventory remote tooling quarterly; treat any inbound management exposure as a critical exception.

5. No offboarding discipline for remote access.
   Fix: Tie VPN entitlement removal to HR termination workflow and third-party offboarding checklists.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific enforcement actions.

From a risk perspective, remote access is a high-consequence control because it can bypass perimeter assumptions. Weak remote access hygiene often turns a single compromised credential into internal network access. HICP’s focus on VPN encryption, MFA, disabling split tunneling, and limiting access is aimed at preventing that pivot. ¹

Practical execution plan (30/60/90-day)

First 30 days (Immediate stabilization)

• Assign ownership: IT/security owns technical controls; GRC owns requirement mapping and evidence.
• Publish the Remote Access Standard: VPN required, MFA required, split tunneling stance, authorized access boundaries. ¹
• Inventory all remote access paths, including third-party access.
• Confirm MFA is enforced for VPN across all access groups; open remediation tickets for gaps.

By 60 days (Control enforcement and scoping)

• Disable split tunneling in standard VPN profiles; document exceptions with compensating controls. ¹
• Implement role-based VPN access groups and network restrictions.
• Stand up a third-party remote access register with owners, systems in scope, and approval status.
• Begin recurring remote access reviews (group membership and third-party access).

By 90 days (Evidence hardening and audit readiness)

• Validate “no alternate path” by reviewing firewall rules, remote tooling, and admin exposure.
• Produce a clean evidence package: configs, exports, review records, exception register, and sample logs.
• Tabletop a remote access incident scenario (credential compromise) and verify monitoring and response steps.
• If managing many third parties, operationalize Daydream to track third-party remote access approvals, evidence, and offboarding tasks in one place.

Frequently Asked Questions

Does HICP Practice 5.5 require a VPN for every remote connection, even for cloud applications?

The requirement text is explicit about securing remote access connections using VPN with strong encryption and MFA. ¹ For SaaS, document your remote access model and ensure MFA and access restrictions meet the intent; use VPN where it is the chosen control path for remote entry to managed environments.

What counts as “strong encryption” for a VPN in an audit?

Treat “strong encryption” as “weak options are disabled and approved profiles are standardized.” Keep the VPN configuration export that shows which protocols/ciphers are enabled and which are prohibited.

We need split tunneling for performance. Can we allow it?

HICP’s plain-language summary calls out split tunneling disabled. ¹ If you approve an exception, document the business reason, compensating controls, and an expiry date, then be prepared to defend it to assessors.

How do we handle third-party remote support that insists on its own tool?

Require your approval process for any nonstandard remote access method, and constrain scope to specific systems and time windows. Capture evidence of MFA, access boundaries, and offboarding steps for that third party.

What evidence is usually missing during audits?

Teams often have a policy but cannot show enforcement. The most common gaps are proof of MFA enforcement at the VPN, proof split tunneling is disabled in the actual profile, and a current list of third parties with remote access and system scope.

Who should own this control: IT, Security, or GRC?

IT/Security should own implementation and logging; GRC should own the requirement mapping, testing procedure, and evidence package. Shared ownership fails when nobody owns the inventory and exception register.

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices