Remote employment is now an established part of how businesses hire and operate. Employees no longer need to live within commuting distance of an office, and employers can recruit from a much wider pool of candidates.
That flexibility changes the job for the network team.
A remote employee may work from home most of the time, spend a week at a client site and connect from a hotel while traveling. The company may control the laptop, identity platform and applications. It does not control every network the employee uses to reach them.
Remote access therefore has to work without turning a successful login into broad trust. An employee needs enough access to do the job, while a stolen credential, compromised endpoint or vulnerable gateway should have limited value to an attacker.
1. Decide what remote access should actually provide
Remote access does not automatically mean extending the corporate network to an employee’s laptop.
A VPN still makes sense when a user genuinely needs network-level connectivity. Network administrators using SSH, RDP or management tools are an obvious example.
Many other employees need applications rather than subnets. Zero Trust Network Access (ZTNA) and identity-aware proxies can expose approved applications or services without giving the endpoint general reachability into the internal network.
This is not a contest between VPN and ZTNA. The access method should follow the requirement. Giving network access to someone who only needs two web applications creates exposure without adding any business value.
2. Use phishing-resistant MFA where remote access matters most
A password should not be enough to establish remote access. The more important distinction now is what happens after the password.
SMS codes, one-time codes and push notifications add protection, but they still leave room for interception, phishing and social engineering. Repeated push requests also create a decision for the user every time one appears.
Phishing-resistant methods such as FIDO2 security keys and passkeys remove much of that weakness by tying authentication to the legitimate service rather than relying on the user to identify a convincing fake.
Prioritize the accounts that can change the network. Remote administrators, identity administrators and other privileged users should not rely on the weakest MFA method the organization happens to support.
3. Treat the device as a separate trust decision
A legitimate employee can still be connecting from a laptop that should not receive normal access.
Remote endpoints can miss patches, stop reporting to management platforms, lose endpoint protection or drift out of compliance for days before anyone notices. Credentials prove who is attempting to connect. They do not prove that the endpoint is healthy.
Device posture should influence what happens next. A compliant managed laptop can receive normal access. A device that fails a required check can be restricted to remediation services, denied access to sensitive systems or blocked entirely.
The useful control is not simply blocking unhealthy endpoints. It is preventing a valid identity from overriding an unhealthy device.
4. Give BYOD its own access model
A personal computer is not a corporate endpoint with a different name.
IT may not control its local administrator accounts, patch schedule, disk encryption, installed software, USB devices or other users. A policy requiring corporate security standards does little if those standards cannot be verified or enforced.
If BYOD is permitted, limit what the unmanaged device can receive. Browser-based access, virtual desktops and application proxies can keep sensitive workloads away from local storage. Download, clipboard and copy controls can be added where the data justifies them.
Where a role requires extensive local access, privileged tools or sensitive data, issuing a managed endpoint is usually cleaner than building exceptions around an unmanaged one.
5. Make a stolen session worth as little as possible
The meaningful test of remote-access security is what an attacker gains after one control has already failed.
Suppose a finance employee needs three internal applications. If the same remote session also exposes server networks, management interfaces, file shares and systems belonging to other departments, the network has created opportunities the employee never asked for.
Remote access should therefore follow role and resource requirements rather than membership in a generic VPN group. Privileged administration should use a separate access path. Management protocols should not be reachable from ordinary remote-user segments without a specific requirement.
Network segmentation matters because it changes the result of a compromise. It does not stop an attacker stealing a credential. It can stop that credential becoming a convenient starting point for lateral movement.
6. Treat the remote access gateway as a target
The security appliance protecting remote employees is also one of the systems most exposed to attackers.
VPN concentrators, firewalls and other remote-access gateways accept connections from the public internet and can provide direct access toward internal resources. Their position makes them more consequential than an ordinary endpoint.
Keep a clear inventory of internet-facing access infrastructure. Know the software and firmware versions, enabled services, exposed interfaces and support status. Patch according to exposure and exploitation risk rather than simply waiting for the next routine maintenance window.
Pay particular attention to management access. Employees may need to reach the gateway from the internet. Administrators usually do not need its management interface exposed to the same audience.
7. Assume the employee’s local network is untrusted
One employee may have a recently installed WiFi 7 router with current firmware and strong encryption. Another may still be using the router their ISP installed years ago. Either could be on hotel WiFi tomorrow.
The remote-access design needs to work safely in all of those conditions.
Employees should secure home networks, but the organization cannot make corporate security depend on hundreds of routers it neither owns nor administers. Protect the endpoint and encrypt the access path on the assumption that the underlying network is outside corporate control.
This also puts responsibility in the right place. Asking an employee to change a router’s default password is reasonable. Depending on that employee to maintain an enterprise-grade perimeter at home is not.
8. Decide where remote traffic should be inspected
Moving a laptop outside the office can also move its traffic outside controls that were previously unavoidable.
Full-tunnel VPN sends traffic back through corporate infrastructure. That preserves centralized inspection but consumes bandwidth and can add latency. Split tunneling lets selected traffic take a direct path to the internet, which can make far more sense for SaaS applications, video conferencing and other cloud services.
The problem appears when traffic takes the direct path and nobody accounts for the controls it has bypassed.
DNS security, endpoint controls, secure web gateways and Secure Access Service Edge (SASE) can move inspection and policy enforcement closer to remote users without dragging every packet through headquarters.
Full versus split tunneling is therefore not a preference setting. Decide which traffic needs centralized inspection, which controls can follow the endpoint and which cloud services can be reached directly without creating a blind spot.
9. Make the session reconstructable
A log entry showing that a user connected successfully at 9:12 a.m. will not answer many questions when that session becomes suspicious at noon.
Responders need to establish which device connected, which authentication method succeeded, whether the endpoint passed its posture checks, what resources were accessed and what else the account or device was doing at the same time.
The evidence is often spread across the identity provider, endpoint platform, VPN or ZTNA service, DNS infrastructure, firewall and applications. The operational failure comes when those records cannot be correlated quickly enough to establish the sequence of events.
Design logging from the investigation backward. Decide what the response team would need to know after a stolen credential, compromised laptop or suspicious remote session, then make sure the infrastructure records it.
10. Reevaluate access after the session starts
An access decision made at 9:00 a.m. should not automatically remain valid at 4:00 p.m.
The user’s risk can change. A device can become noncompliant. Credentials can be reset. An account can be disabled. If the remote-access design only evaluates trust when the session begins, an existing session or token can remain useful after the reason for trusting it has disappeared.
Continuous access evaluation allows participating systems to react to changes in identity, device or session state rather than waiting for a long-lived token to expire. That can shorten the gap between detecting a problem and removing useful access.
Do not assume revocation works because the identity platform says an account is disabled. Test it. Disable a test account and observe what survives. Check VPN or ZTNA sessions, SaaS applications, application tokens and device credentials.
Test account recovery as well. Phishing-resistant MFA is far less impressive if an attacker can persuade the help desk to register a replacement factor using weak identity verification.
When remote access fails
Remote employees use networks the company does not control. Endpoints occasionally fall behind on patches. Credentials are targeted. Internet-facing access infrastructure sometimes requires urgent fixes.
Rmote-access architecture cannot make those events disappear. It determines how far each one can spread.
If compromising one employee gives an attacker broad network reach, the problem is bigger than the stolen credential. If one vulnerable gateway provides a path past multiple internal controls, the problem is bigger than the missing patch.
The goal is simpler and more useful: make one failure remain one failure for as long as possible. That is what separates remote access that merely works from remote access designed to survive compromise.
Sources
- NIST SP 800-207: Zero Trust Architecture
- NIST SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Location Environments
- CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
- CISA: #StopRansomware Guide
- OpenID Foundation: Continuous Access Evaluation Profile 1.0
