Managed devices
Require supported operating systems, current security updates, endpoint protection, disk encryption, device registration, and healthy management status where the risk justifies it.
Reviewed September 2026CISA + NIST informed
Shrink remote access from network trust to explicit application access.
Secure remote access should verify the user, device, application, and context for each meaningful access decision. Traditional VPNs may still be necessary, but broad network access creates unnecessary blast radius when users only need specific applications or administrative paths.
CISA and partner guidance on modern network access security encourages organizations to consider Zero Trust, Secure Service Edge, and Secure Access Service Edge approaches while understanding the risks of traditional remote access and VPN misconfiguration. NIST SP 800-207 provides the foundational zero trust architecture model.
Access inventory
Find every remote path before redesigning any of them.
Inventory VPN concentrators, remote desktop gateways, bastion hosts, virtual desktop infrastructure, cloud access proxies, management portals, third-party support connections, vendor tunnels, SSH gateways, exposed administrative interfaces, remote monitoring tools, and application-level access services.
For each path, identify users, devices, applications, network reach, authentication method, privilege level, logging, owner, business purpose, and dependencies. Unknown remote access is an attack surface problem even when the underlying product is fully patched.
Identity
Make strong authentication the minimum, not the entire design.
Require strong MFA for remote access, prioritize phishing-resistant methods for administrators and high-impact systems, disable dormant accounts, separate privileged identities, and restrict risky legacy authentication. Evaluate session context continuously rather than assuming a successful login creates permanent trust.
Device posture
Decide what a device must prove before it reaches sensitive resources.
Unmanaged access
Limit access from unmanaged devices to low-risk applications or controlled browser sessions. Avoid granting a personally owned or unknown device broad network reach merely because the user passed MFA.
VPN risk reduction
If VPN remains, constrain it aggressively.
Patch and monitor internet-facing VPN infrastructure, minimize exposed management interfaces, disable unused protocols, require strong authentication, segment remote users, restrict routes, separate administrator access, and monitor configuration changes. Avoid routing every remote user into large internal address ranges when their job requires only a small set of services.
Plan for resilience as well as security. Remote access may become mission-critical during weather events, building outages, public-health incidents, or local infrastructure failures. Capacity, failover, identity dependencies, and emergency access must be tested.
ZTNA
Grant access to applications and resources, not an implied trusted network.
A zero trust network access model should evaluate identity, device posture, requested resource, policy, and context before establishing access. Use application-specific policy to reduce lateral movement, hide internal addressing where practical, and keep authorization tied to the resource rather than the network location.
Policy design
Define who may access which application, from which device state, with what authentication strength, during what conditions, and with what session restrictions.
Migration
Move low-complexity web applications first, then administrative and legacy workflows after validating dependencies. Avoid a single cutover that strands support or recovery access.
Administrative access
Use dedicated paths for privileged remote administration.
Separate privileged remote access from ordinary workforce access. Require stronger authentication, managed administrative workstations where appropriate, controlled bastions or privileged access tooling, narrow destination allowlists, session logging, time-bounded elevation, and explicit emergency procedures.
Detection and evidence
Instrument the decision points that grant remote access.
- Authentication success, failure, step-up, and recovery events.
- New device registration and posture changes.
- Policy changes that broaden remote reach.
- Unusual geolocation, impossible travel, or anomalous session behavior where reliable.
- Administrative access outside expected bastion or privileged workflows.
- Repeated blocked access to resources outside a user’s normal role.
- VPN or ZTNA service degradation, logging gaps, and policy synchronization failures.
90-day implementation
Reduce network-level trust in controlled stages.
Days 1–30
Inventory remote access, eliminate unknown or unsupported paths, enforce MFA, patch exposed infrastructure, and document network reach.
Days 31–60
Segment VPN access, add device posture, centralize remote-access logging, and pilot application-level ZTNA for a low-complexity service set.
Days 61–90
Migrate additional applications, isolate privileged administration, test failover and emergency access, and measure how much broad network reach has been removed.
Access design
Model remote access around resources and transactions.
Classify applications by access consequence
Group applications by sensitivity, privilege, operational criticality, and data handled. Public low-risk collaboration, internal business systems, production administration, identity control planes, regulated data, and recovery infrastructure should not inherit the same remote-access policy. This classification makes it possible to require stronger devices, authenticators, networks, or approvals only where the consequence justifies them.
Document dependency paths
Application-level access can still depend on DNS, identity, device management, certificate services, proxies, secrets, databases, and internal APIs. Map those dependencies before removing broad VPN routes. A migration that protects the front door but leaves unrestricted administrative or backend paths does not meaningfully reduce lateral movement.
Separate user and administrator entry points
Ordinary workforce sessions should not automatically provide a route to management interfaces. Use dedicated administrative paths, stronger policy, hardened devices, restricted destinations, and time-bounded privilege for sensitive operations. This separation limits the blast radius of a stolen workforce session even when the user also holds administrative duties.
Define fail-closed and emergency behavior
Decide what happens when posture, policy, identity, or connectivity services are unavailable. High-risk access should not silently fail open because a policy engine cannot respond. At the same time, critical operations need documented emergency access that is narrow, monitored, tested, and independent enough to function during an outage.
Third-party access
Treat vendor and contractor connectivity as its own attack surface.
Inventory support tunnels, remote monitoring tools, vendor VPN accounts, temporary accounts, cloud-console invitations, outsourced administrators, and machine-to-machine connections. Tie each path to a contract or business owner, defined systems, authentication method, permitted hours or conditions where appropriate, and a termination trigger.
Avoid permanent broad vendor network access when a provider only needs one application or management service. Use application-specific policy, bastions, privileged access tooling, destination allowlists, and session recording where the risk warrants it. Require vendors to use named identities rather than shared credentials so activity can be attributed and revoked independently.
Build offboarding into procurement and support processes. When a project ends, a contract changes, or a vendor technician no longer needs access, remove identities, keys, certificates, remote agents, firewall rules, and trust relationships. Review persistent third-party pathways periodically because they can outlive the business relationship that justified them.
Monitor remote-access policy changes as security events. New routes, bypass groups, excluded devices, disabled posture checks, emergency exceptions, and changes to privileged destinations can materially alter exposure even when no software vulnerability exists. Send high-impact changes to a reviewable log and make unexpected changes part of detection engineering.
Primary sources
Use current network access and zero-trust guidance.
Continue learning
Related guides after Secure Remote Access & ZTNA
Follow the next implementation topic without returning to search.
Zero Trust Frameworks
Translate zero-trust principles into an implementation program
Continue readingNetwork Security Fundamentals
Understand and apply durable network-security fundamentals
Continue readingIdentity & Access Management Program
Govern identity lifecycle, authentication, federation, privileged access, service identities, access review, and identity evidence
Continue reading
Put this guide to work
Turn Secure Remote Access & ZTNA Guide | Zeph Tech into a decision-ready next step.
Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.