Traditional IPsec VPNs focus on network path creation, often relying on inbound firewall access, route advertisement, and manual certificate and policy management. Identity-first site-to-site connectivity starts with authenticated identities and grants access only to approved services. The practical difference is that one expands network reach first, while the other keeps the network closed and authorises access explicitly.
How the two connectivity models differ in practice
Traditional IPsec VPNs are built to create a network path: you establish tunnels, advertise routes, and then decide which subnets can talk. Identity-first site-to-site connectivity inverts that model. It starts by authenticating the parties and then grants only the approved service relationships, so connectivity is explicit, narrower, and easier to reason about than broad network reach.
The operational difference shows up in how access is expressed. A VPN usually treats a connected endpoint as sitting inside a trusted network zone, which makes route scope and firewall policy the primary control points. Identity-first connectivity treats the service or workload as the unit of trust, so authorisation is tied to authenticated identity and the specific service-to-service relationship, not to the whole network segment.
That shift matters most when the environment has many services, many tenants, or frequent change. The more you rely on static routes and network reach, the more you accumulate implicit access. Identity-first design reduces that by making each connection decision more discrete, so you can allow one approved path without opening adjacent paths by default.
Why identity-first changes the security model
Identity-first connectivity changes the control plane from “where can this host reach” to “what is this caller allowed to access.” That is a security improvement because it narrows the trust boundary and reduces the blast radius of a compromised endpoint or exposed tunnel credential. The same principle underpins NIST SP 800-207 Zero Trust Architecture, where access is continuously evaluated rather than granted by network location alone.
Traditional VPNs can still be appropriate when you need broad administrative reach, legacy application compatibility, or a simple remote-access pattern. But they often encourage “network inside the network” thinking, where the tunnel becomes the security boundary. Identity-first connectivity is better suited to environments that want service-specific access, stronger segmentation, and less dependence on inbound exposure.
In practice, the key design question is not whether the traffic is encrypted, because both approaches can encrypt traffic. The real question is whether trust is anchored in network membership or in authenticated identity plus explicit authorisation for each approved service path.
What changes for operations, governance, and troubleshooting
Traditional IPsec VPNs tend to create operational work around certificate handling, route management, firewall openings, and exception tracking. As the number of sites or partners grows, that manual overhead often becomes the hidden cost of the model. Identity-first connectivity shifts the burden toward identity lifecycle, policy clarity, and service registration, which is usually easier to scale if the organisation already has strong identity governance.
That also changes how you troubleshoot. With a VPN, engineers often start by asking whether the tunnel is up, the route exists, and the firewall allows the traffic. With identity-first connectivity, the first question is whether the caller authenticated correctly and whether the policy allows that exact service relationship. The debugging surface is smaller, but the policy model must be more precise.
For teams modernising remote access and east-west connectivity together, Remote Access Identity Guide is a useful reference point because it frames VPN retirement, MFA, and zero trust access as one connected decision rather than separate projects. For a broader view of governance and lifecycle issues that emerge once identity becomes the control plane, NHI Lifecycle Management Guide helps explain why provisioning, rotation, and offboarding matter as much as the tunnel design itself.
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) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | PR.AA-01 — Identity Management | Identity-first connectivity centers access on authenticated identities rather than network reach. |
| PR.AA-05 — Least Privilege Access | Explicit service authorization maps to least-privilege access boundaries. | |
| Recommendation — Anchor access decisions to verified identities before allowing any site-to-site service path. Limit each connection to the specific services and ports the caller needs. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Site-to-site connectivity is fundamentally about controlling permitted traffic flows. |
| IA-2 — Identification and Authentication (Organizational Users) | VPN and identity-first models both depend on reliable authentication before access is granted. | |
| Recommendation — Enforce policy that restricts traffic to approved source-destination flows. Require strong authentication before issuing any network or service access. | ||
Practitioner Guidance
What to prioritise: Decide whether the problem you are solving is network reach or service access. If the real requirement is “this workload may call that service,” identity-first connectivity is usually the cleaner pattern; if the requirement is “this whole subnet needs broad reach,” a VPN may still be the simpler transitional choice.
What to verify: Check that every allowed connection is tied to an authenticated identity, a bounded service scope, and a clear ownership model. If the design still depends on broad subnet trust, manual route sprawl, or shared credentials, it is behaving like a traditional VPN even if the product label says otherwise.
Common mistake: Treating identity-first connectivity as just a newer tunnel. The point is not to replace one transport with another, but to stop using network adjacency as the main authorisation mechanism. If the network is still the unit of trust, the security model has not really changed.
Practitioner takeaway: The meaningful difference is not encrypted traffic versus encrypted traffic, it is whether access is implicit after network attachment or explicit after identity authentication. That distinction determines blast radius, policy precision, and how safely the environment can scale.
Related resources from NHI Mgmt Group
- What is the difference between patching a vulnerability and reducing identity blast radius?
- What is the difference between a traditional site-to-site VPN and 4via6 subnet routing for edge connectivity?
- What is the difference between identity-first security and traditional login-based access control?
- What is the difference between identity-first reachability and traditional network-based access control?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
