A VPN Is No Longer the Trust Boundary: 4 Ways to Secure Remote Work

Remote-work security is no longer achieved simply by routing every employee through a corporate VPN. The current model treats the network as potentially hostile and decides whether to grant access from the identity, device, requested application and surrounding risk signals.

Encrypted connections remain necessary, but they are only one layer. Published in May 2026, the NCSC’s current ZTNA guidance says that using a VPN or a known location must not grant access by itself; it calls for policy checks before connection, multiple identity and device signals, limited application exposure and observable access decisions. The four measures below turn that architecture into a practical remote-access plan.

1. Grant access to applications, not the whole network

A remote employee should reach the applications required for a role, not acquire broad visibility of an internal network. Put an access proxy, gateway or other policy-enforcement point in front of private applications, then authorize each request according to the user, device and sensitivity of the resource.

This is the central difference between a protected tunnel and a secure access model. A VPN can encrypt traffic while still placing an authenticated device inside a large network segment. Application-level access reduces what compromised credentials or an infected laptop can discover and reach.

NIST’s Zero Trust Architecture formalizes that distinction: trust should not follow automatically from network location or device ownership, and authentication plus authorization should occur before a session to an enterprise resource begins. It also shifts protection toward individual resources rather than relying primarily on network segments.

Inventory remote user journeys before changing the architecture. Identify the applications, data stores, administrative interfaces and legacy protocols each role genuinely needs. Publish private services through narrowly scoped connectors, retain segmentation behind the access layer and use strong encrypted transport such as correctly configured TLS or IPsec.

2. Replace weak login challenges with phishing-resistant authentication

Require multifactor authentication for remote access, but do not treat every second factor as equivalent. One-time codes and approval prompts add protection compared with a password alone, yet they can still be captured, relayed or approved after repeated fraudulent prompts. Prioritize phishing-resistant methods for email, identity administration, source-code repositories, finance systems and other high-impact services.

FIDO2 credentials and passkeys use public-key cryptography instead of giving the user a reusable secret to type into a website. The FIDO authentication specifications explain that each passkey is unique to an online service and bound to its domain; biometric information, when used to unlock an authenticator, stays on the user’s device. Supported authenticators can be built into a device or supplied as an external security key.

Deployment must include account recovery, enrollment and lost-device procedures. A strong login method can be undermined if a help desk can reset it after checking easily obtained personal details. Require stronger verification for recovery, notify users of credential changes, protect administrators with separate privileged accounts and keep emergency access tightly controlled and audited.

3. Make device health part of every access decision

A valid employee identity should not override an unsafe endpoint. Enroll company laptops and phones in centralized management, maintain a device identity and evaluate posture before allowing access to sensitive applications. Useful signals include operating-system patch level, encryption state, endpoint protection status, secure configuration and whether the device has been reported lost or compromised.

Define a small number of understandable access tiers. A compliant managed device might receive normal business access; an unmanaged personal device might be limited to browser-based services with downloading disabled; a non-compliant device should reach only remediation and support services. Highly privileged work may require a separate managed workstation rather than the same computer used for personal browsing and email.

Do not make device compliance a permanent label. Re-evaluate it during longer sessions and when risk changes. If endpoint protection detects malicious activity, a device falls behind on required updates or its management record is revoked, the policy engine should restrict the session instead of waiting for the next morning’s login.

4. Limit privileges and make access observable

Build roles around job tasks and data sensitivity, then assign the minimum permissions needed. Separate everyday accounts from administrative identities, make elevated access temporary where possible and remove access promptly when a worker changes roles, leaves the organization or completes a contract. Shared accounts weaken attribution and should be replaced with individual identities wherever the system permits.

Collect successful and denied access events from the identity provider, remote-access layer, applications and endpoint tools. Logs should preserve enough context to show which identity requested which resource, from what device, when the decision occurred and why it was allowed or blocked. Central correlation can reveal impossible travel, repeated denials, unexpected administrative activity or a device that becomes non-compliant during a session.

Logging is also an operational control. It exposes policies that are too broad, but it can also show when legitimate workers are being blocked unnecessarily. Define alert owners, retention rules and response procedures before deployment so that telemetry produces action rather than an unattended archive.

Roll out the four controls without locking out employees

Start with a representative pilot covering ordinary staff, contractors, administrators, managed devices, personal devices and at least one legacy application. Run new policies in observation or report-only mode when the platform supports it, inspect the results and then enforce them in stages. Keep a documented recovery route for authentication failures, unavailable policy services and accidental configuration changes.

Measure outcomes that reveal whether the architecture works: the proportion of important applications behind policy enforcement, coverage of phishing-resistant authentication, the share of devices reporting current posture, stale privileges removed and suspicious access events investigated. A successful remote-work network is not defined by one product. It is defined by encrypted traffic, explicit application access, strong identity proof, healthy endpoints and evidence that those controls continue to operate.

Also read:

• How to Create Your Perfect Remote Work Environment
• Top 7 Smart Ways to Create a Scalable Business Setup
• Top 7 Ways to Prevent a Successful Phishing Attack on Your Remote Team