Article·1,840 words · ~8 min read
Identity-based access control limits connected-site access to verified identities and named services. See how that changes lateral-movement risk compared with IPsec VPNs.
Identity-based access control changes the unit of trust from a site or subnet to a verified identity and an explicitly authorized service. That distinction matters after a site-to-site connection is established: an IPsec VPN usually makes a network path available, while identity-first connectivity can keep each service unreachable until the caller is authenticated and policy permits that exact connection.
Why IPsec VPNs can preserve lateral movement
An IPsec VPN protects traffic between trusted network endpoints, but tunnel authentication does not prove that every workload inside the tunnel should reach every other workload. After the tunnel comes up, routing, firewall rules, and subnet ACLs decide what is reachable.
That model is useful for connecting networks. It is weaker at containing a compromised host inside one of those networks. If the tunnel permits a broad route, an attacker who gains a foothold can probe hosts and services on the remote side using the same network reachability available to legitimate systems.
NIST describes this distinction directly in SP 800-207: zero trust does not grant implicit trust based on network location, and authentication and authorization happen before a session to a resource is established. A VPN can still be part of a zero trust design, but the tunnel itself is not the authorization decision.
What identity-based access control changes
Identity-based access control makes authorization specific to the caller, the destination service, and the policy that connects them. The question changes from “Is this source IP inside the connected network?” to “Which identity is requesting this service, and is that identity authorized right now?”
The practical controls are:
- Authenticate before connect: establish the caller’s cryptographic or federated identity before creating the application path.
- Authorize the service, not the subnet: grant access to a database, API, broker, or management service rather than an entire remote network.
- Deny by default: keep services unreachable until a policy allows the identity-to-service relationship.
- Separate policy from location: move a workload or site without treating its new IP address as a new trust decision.
- Log identity and service: record the named identity that reached the named service, not just an IP-to-IP tunnel.
This is a narrower control than simply adding more network ACLs. A subnet rule can reduce reachability, but it still treats the address range as the main security object. Identity-first policy keeps the authorization decision tied to the workload or endpoint that needs access.
Identity-based access control vs. IPsec VPNs
Identity-based access control is stronger for lateral-movement containment because it limits what a compromised identity can reach after a connection is established. IPsec VPNs remain useful when the requirement is broad network interoperability and the trust boundary is acceptable.
| Control question | IPsec site-to-site VPN | Identity-based access control |
|---|---|---|
| Primary trust object | Tunnel endpoint, route, and source network | Verified user, device, workload, or site identity |
| Default reachability | Determined by routes and network policy after tunnel establishment | No service reachability until policy authorizes it |
| Typical scope | Network, subnet, or routed prefix | Specific service or application endpoint |
| Compromised host impact | Can probe any permitted remote route | Limited to services allowed for that identity |
| Moving a workload | Often requires route, address, or ACL changes | Policy follows the identity or endpoint registration |
| Investigation record | Source and destination IPs, ports, and tunnel events | Identity, service, policy decision, and connection event |
| Best fit | Network-level interoperability and legacy routing | Least-privilege workload and site connectivity |
The table does not mean every VPN is flat or every identity system is automatically safe. A tightly scoped VPN with host firewalls can reduce exposure. An identity platform with broad allow rules can recreate the same problem under a different name. The architecture review must test the effective policy, not the product label.
How the model contains a compromised connected site
Identity policy contains a compromised site by refusing to turn site membership into universal reachability. A site can authenticate to the fabric and still have access to only the services assigned to its identity.
Consider a retail site that needs to reach a payment API and a monitoring collector in a central environment. A broad site-to-site VPN route may make other systems on the central network discoverable unless additional controls block them. An identity-scoped design can authorize two service relationships and leave administrative interfaces, databases, and unrelated applications unreachable.
The same pattern applies to a partner network, a factory, or a cloud environment. NetFoundry’s site-to-site model describes outbound-only connections in which each endpoint proves its identity and policy authorizes specific identity-to-service connections. That is the relevant security difference: the connection does not imply access to the rest of the network.
The blast-radius test
Ask one question during an architecture review: if this connected site is compromised, what can the attacker reach without a new authorization decision?
For a network-level VPN, the answer is usually every route, port, and protocol allowed by the tunnel and the downstream controls. For identity-scoped connectivity, the answer should be the small set of named services assigned to the compromised identity.
A useful test plan includes:
- Enumerate the services the site legitimately needs.
- Attempt access to an authorized service and confirm the identity in the audit record.
- Attempt access to an unauthorized service on the same remote network.
- Confirm that the unauthorized service is unreachable, not merely denied after a routable session begins.
- Revoke or change the site identity and verify that authorized access stops.
- Review the logs for the identity, destination service, and policy decision.
The last two steps matter. Containment is not only about the first connection. It is also about how quickly operators can revoke access and whether the evidence tells them who connected to what.
Where IPsec still makes sense
IPsec remains a reasonable choice when two environments need broad routed connectivity, both teams accept the resulting trust boundary, and existing controls can enforce least privilege inside that boundary.
It can fit these cases:
- Legacy applications that depend on network discovery or broadcast behavior.
- Environments where both sides control the routers, address plans, and firewall policy.
- Temporary interoperability while a narrower application connectivity model is built.
- Network services that genuinely need access to a complete routed prefix.
The limitation is not encryption. IPsec encrypts traffic and authenticates tunnel peers. The limitation is that peer authentication does not identify every application workload using the path, and a routed path can expose more services than the original business requirement.
Where identity-first connectivity is the better control
Identity-first connectivity is the better control when the requirement is “connect these services and nothing else,” especially across sites, clouds, OT environments, or partner networks. It also fits teams that need policy and audit records to use stable workload identities rather than changing IP addresses.
Look for these properties:
- A service is unreachable before authorization, rather than reachable and filtered later.
- Each endpoint has a distinct identity that can be revoked.
- Policy grants named service relationships instead of broad subnet access.
- The design works across on-premises and cloud locations without making each location a separate trust zone.
- Logs show the identity, service, time, and access decision.
- Deployment can run over existing network infrastructure without requiring a new routed topology.
This approach complements, rather than replaces, network controls. Firewalls, routing, host hardening, and detection still matter. Identity-based policy adds a more precise authorization layer for the connections those controls cannot scope cleanly.
How to evaluate lateral-movement protection
Evaluate the control by walking through a breach scenario, not by comparing tunnel encryption algorithms. The decisive question is what an attacker can do after obtaining valid access from one connected site.
Use this checklist:
- Identity source: What proves the identity of the site, device, or workload?
- Pre-connection decision: Is authorization completed before a routable application path exists?
- Service granularity: Can policy name one API or broker, or only a subnet?
- Compromise behavior: What can the identity reach after one endpoint is breached?
- Revocation: Can operators disable one identity without taking unrelated sites offline?
- Auditability: Do records identify the caller and service without reconstructing activity from NAT and DHCP logs?
- Operational fit: Can the team add or move a site without opening new inbound ports or rebuilding a tunnel mesh?
NIST’s zero trust architecture centers protection on resources rather than network segments. CISA’s zero trust microsegmentation guidance also treats microsegmentation as a way to create smaller, policy-driven trust zones. For connected sites, the strongest implementation applies that principle to the service relationship itself.
FAQ
Does identity-based access control replace an IPsec VPN?
It can replace an IPsec VPN when the requirement is service-specific connectivity rather than broad routed network access. If legacy applications need complete network adjacency, keep IPsec or another network transport and add identity-aware controls around the services that need tighter authorization.
Can a site-to-site VPN stop lateral movement?
A site-to-site VPN can reduce lateral movement with narrow routes, firewall rules, host controls, and monitoring. The tunnel alone does not stop it because tunnel authentication proves the peers, not that every workload inside one peer should reach every service on the other side.
What is the difference between network-based and identity-based access control?
Network-based access control uses addresses, routes, ports, and zones to decide reachability. Identity-based access control evaluates a verified user, device, workload, or site identity and grants access to a specific resource, which keeps the decision tied to the caller instead of its network location.
How does zero trust prevent lateral movement between sites?
Zero trust prevents lateral movement by removing implicit trust from network location and requiring authentication and authorization before access to a resource. The result is stronger when policy authorizes individual identity-to-service relationships instead of exposing an entire remote subnet.
Is identity-based access control useful for partner networks?
Yes. It lets an organization authorize a partner identity to one application or service without making the partner network broadly reachable. Revoking that identity can remove the partner’s access without changing unrelated site routes.
What should security teams log for connected-site access?
Teams should log the requesting identity, destination service, policy decision, timestamp, and connection outcome. IP addresses and tunnel events still help with troubleshooting, but identity and service records make an access review and incident investigation more direct.
Sources & References
- NIST SP 800-207, Zero Trust Architecture – zero trust principles and resource-focused authorization
- CISA, The Journey to Zero Trust Microsegmentation – microsegmentation guidance
- NetFoundry, Zero Trust Site-to-Site Connectivity – identity-first site connectivity model
- NetFoundry, Network vs Identity-Based Segmentation – related segmentation context