For remote work, network segmentation under NIST SP 800-207 means giving each user and device access to the specific application or workflow they need—not placing a trusted laptop on a broad virtual office network. Start with resource-level policies, identity and device signals, and monitored enforcement points.
At 6:52 a.m. in a Modesto school district, the technology director is looking at two requests before the first bell. A remote school psychologist needs access to the student information system and a video platform for a 7:30 meeting. At the same time, a third-party curriculum contractor needs temporary access to a testing application from a personal laptop at home.
The quick answer would be to place both users on the district VPN and let the existing firewall rules do the rest. That answer is convenient—and dangerous. If either account or device is compromised, the VPN may provide a route toward administrative systems, file shares, printers, or other school applications that have nothing to do with the request.
The decision is not whether remote users should be “on the network.” The decision is which resource each person may reach, under what conditions, for how long, and how the district will know when the request no longer makes sense.
That is the practical edge of network segmentation for remote work under NIST SP 800-207 Zero Trust Architecture.
What does NIST SP 800-207 change about segmentation?
Traditional segmentation divides an environment into large zones: users, servers, guest Wi-Fi, administrative systems, and perhaps a data center VLAN. A remote-access VPN then often places an authenticated user into one of those zones.
NIST’s model changes the starting point. NIST describes zero trust as enforcing accurate, least-privilege access decisions for each request while treating the network as potentially compromised.1 Its central focus is protecting resources—such as assets, services, workflows, and accounts—not treating a network segment itself as the thing that deserves trust.2
That distinction matters. A segmented network is not automatically a Zero Trust Architecture. A remote worker can still receive excessive access inside a well-segmented environment. Conversely, an identity-aware access service can protect a specific application without extending the entire internal network to the user’s home computer.
For Datapath customers, the design question becomes:
- Which application or workflow is needed?
- Which identity is requesting it?
- Is the device managed, encrypted, patched, and protected?
- Is the request consistent with the person’s role and schedule?
- What is the smallest useful access path?
- Which control will terminate access when risk changes?
Segmentation remains important, but it becomes one enforcement layer in a broader decision system.
Why is a remote-work VPN often too broad?
A conventional VPN can solve an encryption problem while leaving an authorization problem unsolved. It may protect traffic between the remote device and the organization, but the resulting tunnel can still expose more internal destinations than the user needs.
Consider the Modesto school district example. The psychologist needs the student information system and a video meeting service. The contractor needs a testing application. Neither needs access to:
- Domain controllers or identity administration
- The finance system
- Staff file shares
- Building-management systems
- District-wide printer management
- Backup infrastructure
- Security tooling and log collectors
A broad VPN policy may rely on the user’s location—“inside the VPN”—as a proxy for trust. A Zero Trust design instead evaluates the user, device, application, session, and request. CISA describes this shift as moving from location-centric controls to more granular, data-centric controls between users, systems, data, and assets.3
This does not mean every VPN must be discarded. A VPN may still be appropriate for a defined administrative workflow, legacy application, or site-to-site connection. The key is to avoid treating VPN membership as a permanent pass to the internal network.
For modern remote access, we generally want one of three outcomes:
- Per-application access: The user reaches only the approved application through a Zero Trust Network Access or software-defined perimeter control.
- Restricted network access: The user receives access to a narrowly defined segment with explicit allow rules and strong monitoring.
- Privileged administration: An administrator receives just-in-time access to a specific system, with elevation, session logging, and automatic expiration.
How should a remote-work segmentation plan be designed?
1. Map workflows before drawing VLANs
Start with the work, not the diagram. Interview department leaders and document the actual access paths.
For a school district, that may include:
| Workflow | Remote user | Required resources | Access boundary | Useful enforcement signals |
|---|---|---|---|---|
| Student counseling session | School psychologist | Student information system, approved video platform | Application-specific; no general server access | Identity, managed device, MFA, device health, session risk |
| Curriculum upload | Vendor contractor | Testing or learning application only | Per-application access with time limit | Vendor identity, approved device, expiration, file-transfer logging |
| Payroll approval | Finance manager | Payroll system and approval portal | Finance applications only | MFA, managed device, location or risk signal, transaction logging |
| Network administration | IT administrator | One named server or management console | Privileged path, no broad user VLAN | Just-in-time elevation, admin workstation, session recording |
This table is deliberately not a collection of “remote,” “office,” and “guest” networks. It describes business workflows and the resources they require. That makes policy review possible: if the psychologist’s role changes, the application path can change without automatically granting access to unrelated systems.
2. Separate resource groups by consequence
Use macro-segmentation where it gives the operations team a manageable boundary. Typical groups might include user endpoints, administrative systems, sensitive business applications, infrastructure management, backups, and building or operational technology.
Then apply smaller controls around high-value resources. A payroll database should not be reachable merely because a user is connected to the employee network. A backup console should not be reachable from an ordinary workstation. A dispatch or public-safety system should not share an unrestricted access path with general office applications.
CISA’s microsegmentation guidance explains that smaller segments can reduce lateral movement, improve containment, increase visibility, and create more opportunities for fine-grained policy enforcement.4
The objective is not to create hundreds of fragile rules. The objective is to make a compromised endpoint less useful to an attacker and to make abnormal traffic easier to identify.
3. Put identity and device posture into the decision
Remote access policies should not ask only, “Is this person allowed?” They should also ask, “Is this device an acceptable way for this person to access this resource right now?”
Useful signals include:
- User identity and group membership
- Multifactor authentication status
- Device enrollment and encryption
- Endpoint detection and response status
- Operating-system patch posture
- Application sensitivity
- Sign-in risk or anomalous behavior
- Whether access is temporary or recurring
A personal laptop may be acceptable for a low-risk public application but inappropriate for downloading sensitive records. A managed district laptop may be allowed to reach the student information system while an unmanaged device receives browser-only access—or no access at all.
CISA specifically notes that remote and other user devices may have limited security protections and may require access to and from those resources to be limited as much as feasible. That is a useful operational test: if a device cannot support the required control, reduce the reachable resource rather than pretending the device is equivalent to a managed endpoint.
4. Use policy enforcement points where access actually happens
NIST’s Zero Trust Architecture includes policy decision and enforcement functions. In practical terms, a policy engine evaluates the request, while a policy enforcement point permits, limits, or denies the connection.
That enforcement point may be:
- A ZTNA or software-defined perimeter service
- A next-generation firewall
- Network Access Control at a wired or wireless boundary
- A cloud application gateway
- An identity-aware proxy
- Host-based or workload-based microsegmentation
- An application’s own authorization layer
CISA describes policy-controlled access as using policy decision and enforcement components, with decisions informed by identity, device information, connection metadata, and authorization rules.
The important question is not whether a product has “segmentation” in its name. Ask where the rule is enforced, what data informs the decision, how quickly the rule can change, and what logs prove the decision occurred.
What should a practical remote segmentation rollout look like?
A Datapath engagement should not begin by promising a complete redesign in one weekend. A safer rollout starts with a limited set of workflows and expands after testing.
Phase 1: Choose one high-value remote workflow
Pick a workflow with a clear owner and measurable consequences. Examples include remote access to an EHR, a finance approval portal, a school information system, or a county application used by employees outside the main office.
Document the normal path:
- User identity provider
- Device type and security state
- Application entry point
- Supporting services such as DNS, identity, or printing
- Data that may be downloaded
- Administrative exceptions
- Required logs and alert destination
If the team cannot describe the normal path, it will struggle to recognize the abnormal one.
Phase 2: Create a deny-by-default pilot
Start with explicit allow rules for the selected workflow. Do not begin with a universal “remote employees” group that inherits every internal route.
For the Modesto district, the pilot might authorize the psychologist’s managed laptop to reach the student information system through an application gateway, while denying direct access to server subnets. The contractor might receive access to the testing application for a defined window, with no route to file shares or administrative services.
Microsoft’s Zero Trust network guidance similarly emphasizes segmentation, identity-based controls, continuous evaluation, and least-privilege access rather than one large internal pipe.
Phase 3: Test the failure modes
A segmentation policy is not finished when the successful login works. Test what happens when:
- The device loses its security-management status
- MFA is not completed
- The user’s role is removed
- The access window expires
- The endpoint begins unusual east-west traffic
- A required supporting service is unavailable
- A legitimate workflow needs a documented exception
CISA advises monitoring, testing, and assessment when updated microsegmentation policies are deployed so business functions continue while security requirements are met.
Phase 4: Operate the policy, do not just install it
Every rule should have an owner, a purpose, an expiration or review date, and a log source. Review access after role changes, vendor offboarding, application migrations, and major incidents.
We also recommend measuring operational outcomes rather than counting firewall rules. Useful measures include:
- Time to approve or remove remote access
- Number of remote workflows using broad VPN access
- Unapproved east-west connection attempts
- Time to isolate a compromised endpoint
- Number of exceptions without an owner
- Help-desk incidents caused by policy changes
These measures connect segmentation to accountability and uptime. A policy that blocks a critical morning workflow is not a success merely because it is restrictive. A policy that allows everything is not successful because it creates no help-desk tickets.
When does a business need more than basic segmentation?
A smaller organization may begin with identity-aware application access, endpoint controls, firewall policy, and centralized logging. A larger or regulated environment may need deeper workload segmentation, privileged-access management, network telemetry, and formal policy ownership.
The right design depends on the applications, the sensitivity of the data, the number of remote users, and the organization’s ability to operate the controls. CISA notes that fine-grained segmentation can limit lateral movement but may be harder to develop, deploy, and maintain than coarse segmentation.
That tradeoff is why Datapath does not approach segmentation as a product purchase. Our managed IT services and managed cybersecurity teams can help inventory workflows, design access boundaries, coordinate with an internal IT team, and monitor whether the controls remain useful after deployment.
For an organization with an established IT department, co-managed IT can provide implementation capacity without taking ownership away from the people who understand the environment. A vCISO engagement can help turn the policy model into governance, risk decisions, and an accountable review process.
The buyer’s test: can you explain one remote access decision?
Before selecting a segmentation platform, ask your IT or security provider to explain one real request from end to end:
- Who requested access?
- Which exact resource was requested?
- Which identity and device signals were checked?
- Where was the decision enforced?
- What was denied by default?
- How long did access last?
- Where was the decision logged?
- Who reviews the exception?
- How would the team revoke access during an incident?
If the answer is “the user connected to the VPN and could reach the internal network,” you have network connectivity, not yet a Zero Trust remote-work design.
If the answer identifies the user, device, application, policy, enforcement point, expiration, and monitoring path, you are much closer to the model NIST describes.
For Datapath customers across Modesto, Fresno and the Central Valley, Modesto, and California communities including Modesto, that is the practical goal: remote access that supports the bell schedule, the approval workflow, the patient appointment, or the public-service mission without making the entire environment part of the request.
Start with one workflow. Define the smallest useful path. Enforce it at the resource. Test the failure modes. Then expand with evidence—not assumptions.
