A VPN can turn remote CI/CD into a hidden network problem: engineers get broad tunnel access, while repos, runners, secrets, and environments still depend on separate controls. That gap creates blind spots for lateral movement, audit scope, and incident containment, especially when teams ship from multiple clouds and time zones.
Zero Trust for remote Dev Teams can replace VPN access for CI/CD, but only when app-level access, continuous verification, and strong identity controls are enforced across repos, runners, secrets, and environments. The best model is often hybrid: remove VPN where it improves security and developer experience, keep it where legacy tooling, break-glass access, or network-dependent systems still need it.
When VPNless beats a VPN
VPNless access beats a traditional VPN when the target is a specific app, not an open network segment. That is the core tradeoff. A VPN gives a user a tunnel into a network, while Zero Trust gives them only the access they need, for only the time they need it.
The practical difference shows up fast. A developer who only needs GitHub, GitLab, a secrets manager, and a preview environment should not sit inside a broad corporate network just to reach four tools. That is like handing someone the keys to an office floor when they only need one desk.
NIST SP 800-207 defines Zero Trust as a model that assumes no implicit trust based on network location.
The security model shift
The main shift is from network trust to identity trust. In a VPN model, being "inside" often matters too much. In Zero Trust, the system checks who the user is, what device they are on, and whether the request fits policy.
That matters because remote dev teams move across home Wi-Fi, cafés, shared offices, and cloud consoles. The network around them changes all the time. The identity should stay the anchor.
The mistake most teams make is treating ZTNA like a VPN replacement with a nicer logo. That fails when policies still rely on subnets, static IPs, or a one-size-fits-all tunnel.
When identity beats network trust
Identity beats network trust when access can be broken into small, clean steps. A good example is a pull request review in GitHub with MFA, device checks, and short-lived session access to the repo only. No broad network reach is needed.
This works best when the resource itself can enforce rules. GitHub, GitLab, AWS, Microsoft, Cloudflare, and Google all support forms of identity-aware access that fit this model. The more the control sits at the app layer, the less the network matters.
The cleanest cutover is usually repos first, then secrets, then deployment targets.
Pros
It reduces broad network exposure. It also makes audit trails easier to read because access maps to people and sessions, not just tunnels.
It usually improves user experience for browser-based tools. Fewer tunnel drops mean fewer support tickets.
Contras
It does not solve every access problem. Legacy runners, subnet-bound tools, and admin consoles can still need network-level paths.
It can fail if policy is too strict. Overblocking creates workarounds, and workarounds become shadow IT.
For who it is
It fits teams that already use cloud DevOps tools and identity-based sign-in. It also fits organizations with remote engineers spread across the United States.
It works best when compliance teams want tighter least-privilege controls and cleaner logs.
For who it is not
It is not a clean fit for teams tied to old on-prem tooling. It also struggles when build systems live behind flat internal networks.
It is a weak first step if break-glass access has not been designed yet.
Elige esto si: the team uses cloud-first tools, can scope access by app, and wants to shrink lateral movement without hurting daily work.
Map each CI/CD surface separately
Repos, runners, artifacts, secrets, and environments do not need the same access model. That is where many migration plans go wrong. Each surface has its own risk, and each one fails in a different way.
A repo is not a runner. A runner is not a secret store. An artifact bucket is not a preview environment. Treating them all the same is like using one lock for the front door, the safe, and the car.
Repos, runners, secrets
Repos usually benefit from identity-first access. GitHub and GitLab both support MFA, SSO, branch protection, and fine-grained permissions. That makes them good early targets for VPNless access.
Runners need tighter limits. A runner that can build code can also leak tokens if it is overprivileged. Ephemeral runners work better than long-lived shared ones because the attack window is shorter.
Secrets need the most care. A secret manager should issue short-lived credentials when possible. Static secrets sitting in shared config files are one of the easiest ways to break a Zero Trust plan.
Artifacts and environments
Artifact stores often look harmless. They are not. A poisoned build artifact can move through the pipeline faster than a human notices.
Preview and staging environments need session-based controls because they often sit close to production data and test credentials. If a team lets broad VPN access reach them, it weakens the whole point of the change.
A 2023 GitHub report on software supply chain security showed how quickly trust can spread inside CI/CD once one control is loose. That is why the policy has to match the surface, not the org chart.
Pros
It cuts the blast radius. A stolen token for one repo does not need to reach every runner and secret store.
It also helps compliance. Auditors like clear separation between build, deploy, and secret access.
Contras
It takes more design work. Teams must define different rules for different tools.
It adds first-run friction. Developers may feel the process is slower at the start.
For who it is
It fits teams with several cloud tools and separate owners for code, build, and release.
It also fits firms that need strong evidence for SOC 2 or ISO/IEC 27001 reviews.
For who it is not
It is a bad fit for teams that still mix everything through one shared box.
It also struggles where runners depend on internal IP ranges that cannot change yet.
Elige esto si: the pipeline has clear trust boundaries and you can separate repos, runners, secrets, and deploy targets.
Access differences by surface
| Surface |
Best access unit |
Main risk |
Best fit |
Bad fit |
| Repos |
Identity and session |
Credential theft |
GitHub, GitLab, SSO-backed access |
Subnet-only tools |
| Runners |
Job-scoped identity |
Token reuse |
Ephemeral runners, short-lived creds |
Long-lived shared agents |
| Artifacts |
Signed object access |
Poisoned builds |
Signed artifacts, object storage policy |
Open buckets |
| Secrets |
Ephemeral credential |
Long-lived leakage |
Vault, AWS Secrets Manager, Azure Key Vault |
Shared .env files |
| Environments |
Session and role |
Overbroad deploy access |
Just-in-time deploy roles |
Permanent admin VPN |
Pros
The table makes policy design simpler. Each surface gets the access unit that fits its risk.
It also helps teams explain the plan to auditors and engineers without jargon.
Contras
It takes more coordination across tool owners. That can slow the first design cycle.
It exposes gaps fast. Some teams do not like seeing how much they still depend on shared access.
For who it is
It fits teams with mixed maturity across tools. One part may already be cloud-native while another still needs a bridge.
It also fits organizations that want a phased move, not a big bang.
For who it is not
It is not for teams looking for a single switch to flip.
It is also not ideal when no one can agree on who owns secrets, runners, or deploy access.
Elige esto si: different parts of the pipeline have different owners, different risks, and different compliance needs.
For remote development teams, the real tradeoffs of vpnless access show up in daily workflows. Repository access is usually the easiest win because identity-based access, MFA, and device posture checks can replace broad tunnel access with little friction. Build runners are harder: if they are ephemeral and tied to short-lived credentials, vpnless CI/CD can reduce lateral movement and audit ambiguity, but shared long-lived runners often need a hybrid access model during migration. The same is true for secrets and artifacts. A secrets manager such as Vault or AWS Secrets Manager works well with continuous verification, but a job that still pulls static .env files or reaches internal artifact buckets through fixed IP rules may break until app-level controls are in place.
In practice, the best rollout is often repository access first, then secrets, then runners and environments, because each step removes a different kind of network trust without forcing every workflow to change at once.
Use controls that match the workflow
Zero Trust works best when controls match the job. That means using MFA, device posture, least privilege, and short-lived credentials together. It does not mean turning every request into a maze.
NIST SP 800-207 and the CISA Zero Trust Maturity Model both point in the same direction: trust should be explicit, and access should be checked continuously. That sounds abstract until a stolen laptop and a cached token show up in the same incident.
Identity and access first
Identity and access management is the center of the model. Google, Microsoft, and Cloudflare all pushed that idea hard for a reason. Identity is easier to verify than network location.
MFA should be mandatory for human access. That is not enough by itself, but it closes a large class of account takeover attacks. For non-human access, short-lived workload identity is the safer path.
The rule here is plain. If a user or service keeps the same secret for weeks, the system is too trusting.
Device posture and sessions
Device posture means checking whether the laptop is managed, encrypted, patched, and not obviously compromised. That check does not need to be perfect, but it should exist.
Session limits matter too. A build operator who signs in at 9 a.m. should not keep the same trust level all day if the device state changes. That is one reason why browser-based access often fits better than VPN tunnels.
NIST SP 800-207 says no subject should be trusted by default, even inside the network.
Pros
It cuts the chance of broad compromise. Stolen credentials lose much of their value when they expire fast.
It also helps with SOX-like control expectations, even when the pipeline itself is not SOX scoped.
Contras
It depends on good identity hygiene. Bad account recovery breaks the model.
It can frustrate developers when posture checks fail without a clear fix.
For who it is
It fits teams that already have SSO, MFA, and managed laptops.
It also fits firms that need stronger control evidence for FedRAMP-style reviews.
For who it is not
It is a poor fit for unmanaged devices or bring-your-own-device chaos.
It is also weak if the organization cannot keep identity data clean.
Elige esto si: the team can prove identity, verify device health, and issue short-lived access cleanly.
Opinion that matters
VPNless CI/CD works well, but only when identity is the control plane and not an afterthought. It breaks down when teams try to bolt it onto old network habits, because that leaves hidden trust paths in runners, secrets, and admin flows. The safest move is to cut VPN access first where the app can enforce policy, then keep a narrow hybrid path for legacy or recovery use cases.
The hidden cost is debugging
Removing VPN access often helps security faster than it helps operations. That is the part many plans miss. The first real problem is not breach risk. It is a broken build at 4:40 p.m. on a Friday.
When a developer cannot reach a runner, a secret store, or a preview environment, the support burden goes up unless the path is easy to inspect. A VPN used to hide a lot of that complexity behind one tunnel. Zero Trust makes the pieces visible.
Break-glass and outages
Break-glass access means a narrow emergency path that bypasses normal controls during an incident. It should be rare, heavily logged, and time-limited. Think of it like the fire alarm pull, not the front door key.
This is where many guides stay vague. They talk about least privilege, then forget that incident response still needs a way in when the normal path fails. A team without a tested emergency route will improvise one under pressure.
A case that comes up often: a cloud deployment fails because a secrets service denies the CI runner after a policy change. The team spends an hour chasing identity logs before someone notices the runner lost its posture token. That is avoidable, but only if support knows where to look.
Support load after migration
Support load usually rises during the first migration phase. That is normal. The first week is rarely elegant.
What matters is whether the load drops after teams learn the new path. If it does not, the policy is probably too complex or the tooling is too fragmented. Microsoft and GitHub both push identity-first access, but neither removes the need for clear troubleshooting paths.
Pros
It makes hidden trust paths visible. That can uncover old access sprawl fast.
It also forces cleaner incident procedures.
Contras
It can slow support at the start. That is real, not theoretical.
It can expose gaps in logging and ownership.
For who it is
It fits teams that already document access flows and incident paths.
It also fits organizations that can train support on the new model.
For who it is not
It is not for teams with ad hoc incident response.
It is also a bad fit when nobody owns the CI/CD access map.
Elige esto si: the team can tolerate a short learning curve and can build a tested emergency path.
The day-to-day impact on developer experience is often what decides whether the migration succeeds. VPNless access can improve onboarding because new engineers do not need a full network profile before they can start reviewing code, checking artifacts, or requesting secrets through approved workflows. It can also reduce latency, since browser-based app-level controls often feel faster than bouncing through a distant tunnel, especially for remote development teams spread across time zones. But there is a tradeoff: support teams must be ready to troubleshoot identity failures, device posture issues, token expiry, and runner authorization problems instead of just asking whether the VPN is connected.
In practice, the best teams document a simple path for repository access, a separate path for build runners, and a clear audit trail for every session. That lowers onboarding friction, improves compliance evidence, and keeps continuous verification from becoming a blocker when engineers need to ship quickly.
Compare VPN, ZTNA, and hybrid
A hybrid model is often the best end state for remote DevOps teams. It lets the organization remove VPN where the controls are ready and keep it where the risk or dependency is still too high. That is usually the safest business choice.
The practical question is not whether Zero Trust is better in theory. It is whether the team can ship, support, and audit the change without creating new pain. The answer changes by workflow, not by vendor.
Decision criteria that change the answer
The biggest decision factors are access type, latency, onboarding time, support load, and compliance evidence. If the pipeline is browser-heavy and cloud-native, VPNless access usually wins. If the workflow still depends on flat internal networks, hybrid is safer.
CISA's Zero Trust Maturity Model supports phased adoption for exactly this reason. A mature plan does not ask every system to change at once. It chooses the highest-value paths first.
What the matrix should score
Score each access path on five things. First, how specific the access can be. Second, how much latency the team feels. Third, how long onboarding takes. Fourth, how much support the model needs. Fifth, how easy it is to explain to auditors.
That last part matters more than many leaders expect. If the model cannot be explained simply, it usually will not hold up in practice.
In many teams, the best path is not all VPNless or all VPN. It is selective removal by workflow.
Pros
The matrix gives a clear decision path.
It helps leaders avoid ideological choices.
Contras
It can feel less neat than a full cutover.
It requires honest scoring, which is where teams get stuck.
For who it is
It fits organizations with mixed legacy and cloud tooling.
It also fits teams that need a migration plan with low drama.
For who it is not
It is not for teams chasing a single answer for every tool.
It is also weak when leadership wants speed over fit.
Decision matrix
| Option |
DX impact |
Latency |
Onboarding |
Support |
Compliance |
Use when |
| VPN only |
Simple at first |
Often medium to high |
Fast for legacy teams |
Medium |
Weaker least-privilege story |
Flat networks and old tools |
| VPNless / ZTNA |
Better once tuned |
Low to medium |
Medium |
Higher at first |
Strong audit trail |
Cloud-first repos and apps |
| Hybrid |
Best balance |
Usually low to medium |
Medium |
Lowest overall risk during transition |
Strong if documented well |
Mixed maturity environments |
Pros
It makes tradeoffs visible in one place.
It helps decide without buzzwords.
Contras
It can become political if the scoring is not honest.
It still needs real policy work behind it.
For who it is
It fits security leaders and platform teams making a migration call.
It also fits teams that need a plan the business can accept.
For who it is not
It is not for teams that want to avoid hard choices.
It also fails if no one will own the rollout.
Elige esto si: the organization has mixed systems, mixed maturity, and needs a path that limits risk while improving controls.
A useful way to decide is to score each access path by how app-level it is, how much device posture matters, whether the system can enforce least privilege, and how painful an outage would be. If access is browser-based, identity-based, and easy to audit, vpnless access is usually the better option. If the workflow depends on flat internal networks, legacy build runners, or tools that only understand subnet rules, a hybrid access model is safer. For example, a team might remove VPN for GitHub, GitLab, and the secrets manager, while keeping a narrow VPN path for on-prem deployment consoles or break-glass admin access.
That approach lowers lateral movement risk without pretending every service is ready for zero trust network access on day one. It also makes compliance easier to defend because the organization can show where VPNless access is already enforced and where exceptions remain for a documented operational reason.
Build zero trust into CI/CD
Zero Trust belongs inside the pipeline, not around it. If the pipeline still trusts long-lived tokens, static runners, or broad deploy rights, the model is only skin deep. The controls must live where the work happens.
The best pattern is short-lived credentials, scoped runners, and explicit deploy approval. That sounds tidy because it is. It also maps well to AWS, GitHub, GitLab, and Microsoft-native environments.
Secrets and ephemeral creds
Secrets management should move toward ephemeral credentials whenever possible. That means the token exists for minutes, not weeks. If the job ends, the credential should die with it.
AWS, GitHub Actions, and many modern secret managers support this pattern. It lowers the value of stolen tokens and cuts cleanup time after incidents. Docker build flows benefit too when the registry token expires quickly.
A 2024 CISA advisory on software supply chain risk kept pushing the same idea in plain language: reduce standing access and limit trust windows. That lines up with NIST and with common sense.
Least privilege for deploys
Least privilege means a job gets only the rights it needs. A test job should not be able to push to production. A build job should not read every secret in the vault.
This is where a lot of teams stumble. They start with good intentions, then hand runners broad rights because "the pipeline broke." That fix works today and hurts tomorrow.
Executive Order 14028 pushed federal attention toward supply chain security and stronger identity controls.
Pros
It lowers the damage from stolen tokens.
It makes build and deploy paths easier to audit.
Contras
It can be painful to refactor old pipelines.
It needs disciplined ownership, or it drifts fast.
For who it is
It fits teams modernizing CI/CD with cloud identity.
It also fits regulated environments that need cleaner evidence.
For who it is not
It is not a good fit for ad hoc scripts that depend on shared keys.
It also struggles when secrets are buried in old shell logic.
Elige esto si: the pipeline can issue short-lived access and separate build rights from deploy rights.
Avoid the First-Migration mistakes
The first migration mistakes are usually not technical on paper. They are operational. Teams over-restrict developers, under-scope service accounts, and forget that support needs a way to see what failed.
One common pattern is easy to spot. Security tightens one tool, then the team works around it in three others. That is not Zero Trust. That is distributed risk.
Overblocking developers
Overblocking happens when policy assumes every developer has the same tools and the same workday. They do not. A staff engineer debugging a release needs different access from a contractor opening a pull request.
The fix is not to loosen everything. It is to make access specific and explainable. If a developer can say why access was denied, the model is easier to use.
One policy for all pipelines
One policy for all pipelines sounds clean. It rarely works. A release pipeline, a test pipeline, and a data pipeline do not carry the same risk.
A case that shows up often: a team copies the same runner policy across AWS EKS jobs and a self-hosted on-prem build box. The EKS path works well, but the legacy box starts failing on posture checks and internal DNS lookups. That is a sign the policy is too blunt, not that Zero Trust failed.
Pros
It exposes hidden assumptions early.
It saves time later by avoiding broad exceptions.
Contras
It can slow the first month of rollout.
It needs close support from platform and security teams.
For who it is
It fits teams that can change policy based on workflow.
It also fits groups that are willing to learn from early pain.
For who it is not
It is not for orgs that want one control template for everything.
It also fails when nobody tests the policy before rollout.
Elige esto si: the team can accept some friction early in exchange for lower risk and cleaner control later.
Keep a hybrid end state
A hybrid end state is often the most honest answer. Some paths should lose VPN access. Some should keep it. That is not indecision. It is risk management.
Legacy access, vendor constraints, and recovery paths often keep VPN in the picture longer than people want. That is fine if the exception is narrow and documented. A narrow exception is much better than a fake clean cutover.
Legacy access that lingers
Legacy access rarely disappears on a neat schedule. Old deployment boxes, subnet-bound admin tools, and vendor-managed systems often live longer than the first plan expects.
That does not mean the Zero Trust work failed. It means the org is dealing with reality. Bruce Schneier has long argued that security must match how systems actually fail, not how diagrams hope they work.
Regional and vendor constraints
Regional constraints matter too. Some vendors still require fixed IP allow lists, certain inbound paths, or old admin methods. That is common in North America, especially in mixed enterprise estates.
A hybrid model can carry those cases while the rest of the team moves forward. That is usually safer than forcing every system into the same access path.
Hybrid is not a compromise to hide behind. It is a way to remove risk where the system is ready.
Pros
It keeps the business moving.
It avoids breaking old systems that still matter.
Contras
It can become a permanent excuse if no one reviews exceptions.
It needs strict ownership or it turns into clutter.
For who it is
It fits most mid-size and large engineering orgs.
It also fits teams with both cloud-native and legacy systems.
For who it is not
It is not for teams that can fully replace network trust now.
It also fails when exceptions never expire.
Elige esto si: legacy tools, vendor rules, or recovery needs make full VPN removal too risky right now.
Frequently asked questions
Is ZTNA replacing VPN?
ZTNA is replacing VPN for many app-specific access cases. It works best when access depends on identity, device posture, and session context. It does not replace every legacy workflow, especially when tools still need subnet access or fixed internal routes.
What is zero trust remote access?
Zero Trust remote access verifies identity, device health, and policy before access starts. That lowers lateral movement because users do not enter the whole network by default. In remote DevOps, it fits repos, admin consoles, and browser-based tools well.
How does zero trust work in CI/CD pipelines?
It uses short-lived credentials, scoped access, and continuous verification across repos, runners, secrets, and deploy targets. The pipeline checks identity and context before allowing each step, instead of trusting the user or job because it is already on the network.
When should a remote dev team keep a VPN?
A team should keep a VPN when legacy systems still depend on network paths. That includes old build boxes, subnet-only admin tools, and some vendor-managed systems. A hybrid model is safer when removing VPN would slow incident response or break recovery access.
Does VPNless CI/CD slow developers down?
It can at first, usually for 2 to 6 weeks during rollout. After policies settle, many teams see less tunnel friction and fewer connection issues. The tradeoff is that support and policy design must be cleaner from day one.
What is the biggest mistake in VPNless migration?
The biggest mistake is treating ZTNA like a simple VPN replacement. That ignores app-level policy, runner scope, and secret lifetimes. The result is usually either overblocking or hidden exceptions that weaken the whole design.
How do AWS EKS and self-hosted runners differ?
AWS EKS usually fits VPNless access better because it supports identity-aware cloud controls and short-lived workload access. Self-hosted runners often need more care because they sit closer to internal networks and older systems. The right answer depends on whether the runner can be isolated and audited cleanly.
Do not drop the VPN if your tooling still depends on network-wide trust, emergency access, or brittle legacy paths.
What to do next
The cleanest answer is not all VPNless and not all VPN. It is a selective cutover that removes network trust where identity and app controls are ready. That usually gives the best mix of security, developer experience, and auditability.
Start with repos, then secrets, then deploy paths. Keep a narrow hybrid route for legacy tools and break-glass recovery. That is the path most remote DevOps teams can defend in front of security, operations, and auditors.
John Kindervag's Zero Trust idea still holds up because it asks a simple question: why trust the network at all?
