Hybrid work changes where people connect from, but the access design should start with what they need to do. A useful approach maps users, devices, applications and information flows before choosing a remote-access technology. That helps an organisation avoid granting broad network access where application-specific access would be enough, while still identifying workflows that depend on network-level connectivity.
Map the work before choosing a tool
List the main user groups and the tasks they need to complete. Include employees, contractors, service providers and administrators. For each group, identify the applications, data and systems they use, the devices they work on and any dependencies between services.
Do not assume that a user’s job title tells the full story. A finance user may need a line-of-business application, shared documents and a remote support channel. An administrator may require temporary access to a management plane. A contractor may need one system for a specific period. Each use case can have different access requirements.
Document the current access path and the business owner for each important application. This helps distinguish problems with identity, device posture, network routing, application configuration and user support.
Consider identity, device and resource together
A hybrid access policy should consider who is requesting access, whether the identity is authenticated, what device is being used and which resource is requested. The organisation can then decide which conditions are appropriate for that application and user group.
NIST’s zero trust architecture describes a model that avoids granting trust solely from network location. It calls for subject and device authentication and authorisation before a session to a resource is established.NIST SP 800-207 That principle can inform remote work design, but the detailed controls depend on the organisation’s systems, risk tolerance and operational capability.
Device checks can support decisions about access, but they require a defined device management process. Decide how devices are enrolled, what compliance means, how exceptions are handled and what happens when a device falls out of policy. Identity and device controls should have an owner who can investigate issues and update the policy.
Choose access by application and risk
Some users may need access to a network segment or legacy application. Others may need only a specific cloud service. An organisation can use different patterns for different workloads rather than forcing every user through one access method.
For each application, consider its hosting location, authentication options, protocol requirements, sensitivity, user population and support model. Ask whether it can support identity-aware or application-specific access, whether it depends on network-level discovery and how administrators will manage it.
A VPN may remain appropriate for certain systems. A zero trust network access service may suit application-specific access where the design supports it. A combination can be used while the organisation transitions, provided ownership and exceptions are clear.
Protect the user experience and operational path
Security controls must work for real users. Test login flows, device onboarding, access from different locations, support scenarios and recovery when a user loses a device or changes role. Ask the service desk how it will tell whether a problem is caused by identity, the endpoint, the access service or the target application.
Communicate the change before rollout. Explain how access will work, where help is available and what users should do if a workflow fails. Start with a pilot group that reflects the different roles and devices in scope. Capture issues and refine policy before broadening access.
Agree ownership and exceptions
Decide who owns identity records, device compliance, application access, policy changes and user communications. Define who approves new access and who removes it when a person leaves or a contract ends. Make sure privileged access is treated separately from routine user access.
Some exceptions may be necessary while a legacy application or special workflow is addressed. Document the reason, owner, compensating controls and review date. Exceptions without an expiry or owner tend to become invisible parts of the access model.
Build for change, not only the first rollout
Hybrid work patterns and cloud services change. Review access when applications move, departments change, a supplier relationship ends or new devices are introduced. Monitor whether access policies still reflect the organisation’s needs and whether the support team can operate them.
NIST’s guidance is a design framework, not an instruction to remove every VPN or buy a specific product. Use it to ask better questions about resource-level access, identity, device state and operations. The selected approach should fit the applications and teams that must use it.
Read what changes between ZTNA and VPN and why identity is central to access. For AltTab’s current cloud and workplace scope, see Cloud and Microsoft services.