Because they control network entry, not endpoint trust. In hybrid work, a user can connect from anywhere on a device that is outdated, unencrypted, or unpatched. Conditional access closes that gap by evaluating the device itself before the sensitive resource is reachable.
Why network controls stop being enough in hybrid work
VPNs and firewalls were designed to decide whether traffic can enter a network boundary, not whether the device, user context, or session should be trusted at the moment access is requested. In hybrid work, that boundary is porous: users connect from home, public networks, unmanaged locations, and a wider range of endpoints. Access control has to shift from location-based entry to context-aware decisioning.
The practical problem is that a successful VPN login does not prove the endpoint is healthy, current, or safe. A firewall can segment traffic, but it cannot tell whether the device is encrypted, whether the OS is patched, or whether the session should be limited because the user is on an unmanaged laptop. That is why conditional access and zero trust patterns matter more than perimeter-only controls.
For remote access design, the useful question is no longer “Can this device reach the network?” but “Should this identity, from this device, at this moment, reach this resource?” The answer depends on posture checks, authentication strength, and policy decisions that happen before the sensitive application is reachable. Remote Access Identity Guide covers that shift clearly, including VPN retirement, MFA at every entry point, and device posture.
Why hybrid work changes the trust model
Hybrid work expands the number of trust assumptions that used to be implicit inside the office network. The same user may connect from a corporate device one day and a personal device the next. The same account may be used from a compliant endpoint or from a machine that is stale, jailbroken, or missing disk encryption. Network controls do not see enough of that context to make a safe access decision on their own.
This is where identity, device posture, and authorization converge. Conditional access can require stronger authentication for sensitive systems, block access from risky endpoints, and force step-up checks when the session context changes. A broader identity model is needed because the control point moves from the network edge to the access request itself. IAM and IGA Basics is useful here because it frames authentication, authorization, entitlements, and governance as separate decisions rather than one blended perimeter control.
That change also affects how least privilege is enforced. A VPN often gives broad network reach once the tunnel is established, which is too coarse for modern SaaS, cloud, and internal application access patterns. Fine-grained authorization can limit what a user can do even after they are authenticated, which is essential when access comes from outside the corporate environment. Authorisation Models Guide is a strong companion for understanding why policy-based access is better than flat network trust.
What conditional access adds that VPNs and firewalls cannot
Conditional access adds decision points that live at the moment of entry and can be based on user, device, location, risk, and resource sensitivity. Instead of assuming the tunnel is enough, the policy engine can require encryption, managed-device status, MFA, or a compliant build before the request reaches the application. That makes the control adaptive rather than purely structural.
This matters most when the resource itself is the real target, not the network. An attacker who steals credentials can often satisfy a VPN login, but may still be blocked if the device is not compliant or the sign-in context is suspicious. In that sense, the control shifts from “network access granted” to “resource access justified.” For remote-access architectures, that is the right control boundary.
A zero trust model is the clearest external reference point for this approach. It treats access as continuously evaluated, not permanently granted after one network check. NIST SP 800-207 Zero Trust Architecture formalises the idea that trust should be explicitly verified rather than inherited from network location.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PA — Policy Engine | Hybrid work access must be evaluated before resource reachability. |
| Recommendation — Enforce explicit policy checks for each access request before granting resource reachability. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Remote work depends on stronger user authentication than network presence. |
| AC-6 — Least Privilege | Network-only access is too broad for hybrid work and needs tighter authorization. | |
| IA-5 — Authenticator Management | Hybrid access depends on secure credential handling and renewal. | |
| Recommendation — Require strong authentication before allowing remote access to sensitive systems. Limit remote users to only the resources and actions they actually need. Rotate and protect authenticators used for remote access and conditional access flows. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Hybrid work requires policy-based access decisions rather than perimeter trust. |
| Recommendation — Define and enforce access control rules that account for device and user context. | ||
| NIST CSF 2.0 | PR.AA-05 — Assets are identified, authenticated, and authorised | Conditional access depends on authenticating users and devices before access. |
| Recommendation — Require authentication and authorization checks for each remote access attempt. | ||
Practitioner Guidance
What to prioritise: Move the first control decision to the access request, not the tunnel. If you still rely on VPN as the main gate, treat it as a transport mechanism and add device posture, MFA, and resource-level policy before sensitive applications are exposed.
What to verify: Check whether your remote access policy can distinguish managed from unmanaged devices, enforce encryption and patch posture, and apply different rules by application sensitivity. If it cannot, the organisation is still using network location as a proxy for trust.
Decision rule: If a user can authenticate successfully from an untrusted or non-compliant endpoint and still reach high-value data, the access model is too coarse. Tighten the policy before expanding remote access further, because exposure scales quickly in hybrid work.
Practitioner takeaway: VPNs and firewalls still have a role, but they no longer define sufficient trust. Hybrid work requires access decisions that evaluate the endpoint and context before the user reaches the resource.
Related resources from NHI Mgmt Group
- Why do firewalls and VPNs no longer provide enough protection on their own?
- What breaks when OT access control relies on VPNs, firewalls, and shared passwords alone?
- What are the signs that traditional access control is no longer working well enough?
- How should organisations replace traditional access control when passwords, RBAC, and firewalls no longer stop modern attacks?