How should security teams secure remote access when employees use a mix of company-owned and personal devices?

Why This Matters for Security Teams

Remote access becomes harder to secure when employees connect from both managed and personal devices because trust can no longer be inferred from the network location alone. Security teams need to decide whether a device is compliant, whether the session is low risk, and whether the user should receive full access or a narrowly scoped path. That is the practical difference between secure remote work and accidental exposure of internal systems. Guidance from the NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access control must be tied to conditions, not assumptions.

This is also where identity and device governance overlap with broader non-human identity discipline. The same least-privilege thinking that reduces blast radius for service accounts applies to remote employee sessions: reduce standing access, verify context at request time, and revoke what is no longer needed. NHI Management Group has repeatedly shown how weak credential hygiene and over-privilege create durable exposure in mixed-trust environments, especially in its Ultimate Guide to NHIs. In practice, many teams discover remote access gaps only after a personal device is lost, unmanaged software is present, or a legacy VPN rule has already granted more access than intended.

How It Works in Practice

Effective remote access control starts with identity-aware policy at the front door and continues through every sensitive request. A user authenticates, the device is assessed for posture, and the policy engine decides whether the session is allowed, limited, or denied. The key point is that company-owned and personal devices should not receive the same trust level by default. Managed endpoints can be placed into a higher-trust tier if they meet patching, encryption, EDR, and MDM requirements. Personal devices usually need a narrower model, such as browser-only access, application-level segmentation, or step-up verification for high-risk actions.

Security teams should also treat remote access as a time-bound authorization problem rather than a permanent entitlement problem. That means using conditional access, short-lived tokens, and session re-evaluation when risk changes. It also means limiting what a device can reach after login. A good policy does not just ask, “Is the user valid?” It asks, “Is this the right device, at the right time, from the right context, for the right app?” For broader control design, the OWASP Non-Human Identity Top 10 is useful because it normalises short-lived, scoped, and continuously checked access rather than broad standing trust.

For mixed-device environments, the most practical implementation pattern is:

• Require strong authentication and device registration before any internal access is granted.
• Use device posture checks for encryption, OS version, jailbreak or root status, and endpoint protection.
• Apply least privilege at the application layer instead of exposing broad network segments.
• Use step-up controls for finance, admin, source code, and sensitive customer data.
• Reassess the session when device risk changes or when the user attempts a higher-risk action.

These controls tend to break down when legacy VPNs are still granting flat network reach, because posture checks stop mattering once the user lands inside an overly trusted internal segment.

Common Variations and Edge Cases

Tighter device controls often increase friction for employees, requiring organisations to balance user productivity against exposure from unmanaged endpoints. That tradeoff is real, and there is no universal standard for it yet. Some teams will accept a stronger experience burden on personal devices in exchange for better containment, while others will prefer broader access with more monitoring and faster revocation.

One common edge case is contractor or bring-your-own-device access to a small set of SaaS tools. In that scenario, current guidance suggests using browser isolation, conditional access, and data loss controls rather than giving the device broad internal reach. Another edge case is executive access, where exception handling is often rushed. Exceptions should be explicit, time-limited, and reviewed, not hidden inside a permanent policy carve-out. If the environment supports it, segment personal-device sessions away from admin consoles, source control, and production tooling.

The biggest failure mode is assuming that device compliance equals session safety. A compliant laptop can still be compromised, and a personal device can be temporarily trustworthy before its state changes. That is why continuous evaluation matters more than one-time approval. The same practical lesson appears in breach analysis across identity-heavy incidents, including the 52 NHI Breaches Analysis and the SonicWall VPN Mass Breach via Stolen Credentials, where trusted access paths became the attack path.

Related resources from NHI Mgmt Group

• How should teams secure smart devices that use companion apps and remote access?
• How should security teams enforce access controls when employees use managed and unmanaged devices for web apps?
• How should security teams use an enterprise browser to enforce zero trust for SaaS access?
• How should security teams evaluate VPN alternatives for remote access to internal services?