The corporate VPN has been quietly accumulating risk for more than a decade. It was designed to extend a trusted network to remote employees during an era when "the office" was the security boundary, laptops were company-issued, and attackers lived outside the perimeter. None of those assumptions hold anymore, and nowhere is the mismatch more dangerous than in the systems that build, sign, and publish software. A compromised VPN credential today does not just give an attacker access to a SharePoint site; it gives them a direct path to the artifact repository, the build agents, and the package signing keys that downstream customers implicitly trust.
Migrating from VPN to zero trust network access (ZTNA) is therefore not a networking project. It is a supply chain security project that happens to involve networking. This post walks through the migration as we have executed it across several customer environments, with particular focus on the sequencing decisions that reduce risk to build and release pipelines during the transition window.
Why the VPN Model Fails for Build Systems
A traditional VPN terminates at a concentrator, authenticates the user once, and then places the endpoint on a routable network segment. From that moment on, every packet the endpoint sends is treated as if it originated from inside the corporate perimeter. For a developer reading email, this is already too permissive. For a build agent that pulls source code, fetches dependencies, compiles artifacts, and pushes to a signing service, it is catastrophic.
Three failure modes recur in incident reports we have reviewed:
First, lateral movement from a single compromised credential. Once an attacker authenticates to the VPN, the flat network topology means they can probe artifact stores, internal package mirrors, and Jenkins masters without any additional friction. The SolarWinds build environment compromise illustrated how much damage can be done when network-level trust is treated as identity.
Second, long-lived sessions that outlive the context in which they were authorized. A VPN session established at 9 a.m. from a corporate laptop may still be active at 11 p.m. from the same laptop after it was left unattended in a coffee shop. The session persists even if the user's risk posture changes.
Third, inability to enforce workload identity. VPNs authenticate users or devices, not the specific process that is making a request. A build agent and a developer's IDE appear identical to the concentrator, which means policies cannot distinguish between "the CI system fetching a dependency" and "an interactive shell fetching the same dependency."
The Zero Trust Alternative in One Paragraph
Zero trust replaces network-level trust with per-request authorization. Every connection to every resource is authenticated, authorized against current context, and logged. There is no "inside." The model relies on four building blocks: strong identity for both users and workloads, device posture signals, a policy engine that evaluates each request against business rules, and an enforcement point that sits in front of every protected resource. For supply chain pipelines, the enforcement point is usually an identity-aware proxy in front of the artifact store, the source control system, and the CI orchestrator.
Phase One: Inventory and Classification
Before any technology decisions, spend two to four weeks building an honest inventory of what the VPN is actually being used for. In every engagement we have run, this inventory surprises the team that commissioned it. Typical findings include forgotten admin consoles reachable only over the VPN, legacy build agents still using static IP allowlists, and third-party vendor tunnels that were set up years ago for a specific engagement and never torn down.
Classify each discovered resource by sensitivity. Source repositories, signing services, artifact registries, and secrets managers belong in the highest tier. These systems directly produce or authenticate the software that customers install. One tier down sits the CI infrastructure itself, followed by developer productivity tools, and finally general-purpose internal sites. The migration should proceed from the highest tier downward, because the goal is to remove the broad, flat access to critical supply chain systems first.
Phase Two: Workload Identity Before User Identity
Most organizations approach ZTNA by rolling out an agent to every employee laptop. This is backwards for supply chain pipelines. Start by giving every non-human actor a strong, verifiable identity. Build agents should authenticate using short-lived workload credentials, ideally issued through SPIFFE or a cloud provider's workload identity service. Deployment pipelines should assume roles through OIDC federation rather than holding long-lived service account keys.
This step is often the most time-consuming, because it requires rewriting pipeline definitions and, in some cases, replacing tooling that assumes static credentials. But it yields the largest security benefit. Once every pipeline component has a verifiable identity, policies can be written in terms of "the release pipeline for product X may sign artifacts tagged with version Y" rather than "the host at IP 10.0.4.17 may connect to the signing API." The difference in blast radius between those two formulations is the difference between a contained incident and a supply chain breach.
Phase Three: Identity-Aware Proxies for Human Access
With workload identity in place, route human access to build and release systems through an identity-aware proxy. The proxy enforces short-lived sessions, device posture checks, and explicit authorization for each resource. Developers no longer connect to "the build network"; they connect to specific consoles, and only for the duration of a specific task.
Three configuration choices matter here. Sessions should be scoped to a single resource and expire in minutes rather than hours. Device posture checks should include attestation that the endpoint is running current patches and a functioning EDR agent. Administrative actions on signing services and artifact stores should require step-up authentication, typically a hardware key tap, even within an authenticated session.
Phase Four: Decommission, Do Not Coexist
The temptation during migration is to leave the VPN running as a safety net. This is a mistake that extends the risk window indefinitely. Set a hard deadline, communicate it widely, and enforce it by physically disconnecting the concentrator on the target date. Any remaining use cases that surface in the final weeks almost always turn out to be either already supported by the ZTNA deployment or legacy workflows that should have been retired years ago.
The exception is vendor access. Third-party tunnels often have contractual obligations that require more runway. Move these to a separate, heavily monitored enclave with a firm sunset date, and treat each one as a discrete project rather than a blocker for the broader migration.
Common Pitfalls
Two patterns have caused the most pain in migrations we have observed. The first is treating ZTNA as a VPN replacement at the network layer only, without changing how policies are written. Teams deploy the new tooling but recreate the flat access model on top of it, gaining little security benefit. The second is underestimating how much institutional knowledge is encoded in VPN routing tables and firewall rules. Budget time for archaeology.
How Safeguard Helps
Safeguard supports the migration by continuously mapping which build agents, artifact stores, and signing services are present in your environment and who is accessing them. The platform ingests access logs from identity-aware proxies and correlates them with supply chain artifacts, so you can see whether a given release was built by workloads with the expected identities. Policy gates can block promotions when a pipeline component was accessed by an unexpected identity or from an out-of-policy device. Together, these capabilities give security teams a defensible answer to the question every ZTNA migration eventually faces: did we actually reduce risk, or just change the shape of it?