Most fintech infrastructure teams did not choose their VPN. It was the default answer years before zero trust had a name, and it stayed in place because replacing it meant touching every engineer’s laptop, every ops runbook, and every auditor’s assumptions about how the network is drawn. The problem is that a flat VPN was built for a world where “inside the network” meant “trusted,” and a distributed fintech team with contractors in three time zones and support staff on shared office wifi does not have an inside anymore.
This piece is about the mechanics of moving off that VPN: how to sequence the migration to zero trust network access for a fintech team without an outage, without a gap an auditor can find, and without breaking the ledger and payment rail access that the business runs on every day.
Why a Flat VPN Breaks Down for a Distributed Fintech Team
A VPN authenticates a connection, not a person, a device, or a request. Once a credential is valid, the tunnel opens to whatever the network route allows, and in most fintech environments that route was drawn years ago by whoever configured the firewall rules at the time. An engineer who needed temporary access to a payments database in 2023 often still has that route open in 2026, because nobody owns the job of closing it.
Distributed teams make this worse in three specific ways. First, device diversity: a VPN client installed on a contractor’s personal laptop gives that laptop the same network position as a company-issued machine with full disk encryption and endpoint monitoring. Second, time zone spread: a login at 3 a.m. local time for one engineer is unremarkable, but the same pattern from a credential that should only ever be used during business hours in a different region is a signal a flat VPN cannot see, because it only checks whether the tunnel is up. Third, support staff access: customer support agents frequently need read access to transaction records but not to ledger write paths, and a VPN segmented by subnet rarely maps cleanly to that distinction once the team has grown past its original headcount.
The result is a network where the blast radius of one stolen credential or one compromised laptop is “everything that credential’s route touches,” which in a ledger-and-payment-rail environment is rarely a small thing.
What Identity-Aware Access Actually Changes About Who Can Reach What
Zero trust network access replaces the network route with a policy decision made at the time of the request. Instead of asking “is this connection coming from inside the tunnel,” the system asks “is this identity, on this device, in this state, allowed to reach this specific resource right now.” The access decision moves from the network layer to the application layer, and it gets re-evaluated continuously rather than once at login.
Practically, this means a support agent’s session to the customer data store can be authorized while their session to the ledger write API is denied, even though both requests originate from the same laptop at the same time. It also means that a device that was compliant at 9 a.m. but has since had its disk encryption disabled, or picked up a known-bad process, can lose access mid-session without anyone having to revoke a VPN certificate or push a firewall change.
The shift that matters most for a fintech specifically is that access stops being a property of the network segment and becomes a property of the resource. A payment rail integration, a ledger database, and a customer PII store can each carry their own policy, enforced the same way regardless of whether the person requesting access is on the office network, a home connection, or a mobile hotspot in an airport.
Mapping Access Policies Before Touching Any Infrastructure
The mistake most teams make is installing a ZTNA product first and writing policy around whatever the tool’s defaults suggest. The policy work has to come before the tooling decision, because the tooling only enforces what you’ve already decided, and an incomplete map produces either access gaps that break someone’s workflow or access grants that are wider than anyone intended.
Start by building an actual inventory, not a diagram, that answers four questions for every system engineers or support staff touch:
- Who needs access to this system, by role, not by name
- What action do they need, read, write, or administrative
- Under what conditions does that access make sense, business hours, specific device types, specific locations
- What’s the cost of this access being wrong, measured in what it touches: ledger integrity, payment rail availability, or customer data exposure
This inventory will surface access that nobody can explain. In most flat VPN environments, a meaningful share of the open routes trace back to a project that ended, a person who changed roles, or a temporary exception that was never revoked. Mapping this before migration means the zero trust policy set starts from what access should exist, not from what access currently exists, which is a materially cleaner starting point and one that an auditor will notice.
Device Posture and Continuous Verification in Practice
Identity alone is not enough, because a valid credential on a compromised device is still a compromised path into the ledger. Device posture checks add a second input to the access decision: is the device encrypted, is its OS patched to a current version, does it have the required endpoint agent running, has it been seen on a network associated with known bad activity.
The practical question for a distributed team is where to draw the line between company-issued hardware and personal devices, especially for contractors and support staff who may not be issued a laptop at all. A workable approach ties posture requirements to the sensitivity of what’s being accessed rather than applying one standard everywhere. A support agent reading ticket data might be allowed from a personal device that meets a baseline encryption and patch requirement, while anyone touching ledger write paths or payment rail credentials is required to connect from a managed device with a hardware-backed key store.
Continuous verification means the posture check doesn’t stop at login. A session should be re-evaluated on a rolling basis, and specific triggers, a new impossible-travel login location, a device falling out of compliance, a spike in request volume, should be able to force re-authentication or terminate the session outright. This is the part of ZTNA that a VPN structurally cannot do, because a VPN’s trust decision is made once, at tunnel establishment, and never revisited for the life of the connection.
Segmenting Access to Ledgers, Payment Rails, and Customer Data Separately
Treating “production access” as one tier is the single biggest policy mistake teams carry over from their VPN habits. Ledgers, payment rail integrations, and customer data stores carry different regulatory exposure, different blast radius if compromised, and different legitimate user populations, and they should be segmented as separate policy domains rather than folded into a shared “prod” bucket.
A reasonable segmentation splits access into at least three domains:
- Ledger systems, where write access should be restricted to a small, named set of engineers, logged at the field level, and never granted to support or on-call rotations outside the engineering team that owns it
- Payment rail connections, where access often needs to be scoped by specific rail or corridor rather than granted broadly, since a credential compromise here has direct financial consequence
- Customer data stores, where read access is wider across support and engineering but write access and bulk export should carry their own separate, tighter policy
Teams running event-driven pipelines that move transaction data between these domains have an additional reason to keep this segmentation strict: a policy that’s too loose at the data pipeline layer can quietly reopen access that was deliberately closed at the application layer. If your data flows between ledger, payment, and customer systems through a streaming pipeline, the access controls on that pipeline’s consumers deserve the same scrutiny as the systems it connects, a point covered in more depth in designing fault-tolerant event-driven pipelines for real-time financial data.
Running ZTNA and VPN in Parallel During the Cutover
A cutover that turns the VPN off on a fixed date is the fastest way to generate an outage, a support queue full of locked-out engineers, or a quiet workaround where someone keeps a VPN client installed “just in case” and the old flat-access path never actually closes. The safer sequence runs both systems in parallel for a defined period, moving access domain by domain rather than all at once.
A workable order:
- Stand up the ZTNA policy engine and identity provider integration without removing any existing VPN access, so nothing changes for users yet.
- Move the lowest-risk, highest-volume access first, typically internal tooling and non-production environments, to validate that the policy engine behaves as expected under real usage.
- Migrate customer data read access next, since the user population is larger and problems here surface quickly through support team feedback.
- Migrate payment rail and ledger access last, in the smallest possible batches, with the engineers who own those systems validating each policy change before it goes live.
- Only after a domain has run clean on ZTNA for a full billing or audit cycle, remove the corresponding VPN route for that domain specifically, rather than removing VPN access wholesale.
Throughout this sequence, keep the VPN’s access logs and the ZTNA’s access logs comparable, so you can confirm that nobody lost legitimate access and that no access slipped through on the VPN path that the new policy would have denied. That comparison is also the evidence an auditor will want to see later.
Proving the Switch Holds Up Under a PCI-DSS or SOC 2 Audit
A migration that improves security but can’t be demonstrated to an auditor hasn’t actually reduced your audit burden, it’s just moved the work from engineering to the weeks before the audit. ZTNA systems generate far more granular access logs than a VPN does by default, identity, device posture, resource, and decision for every request, but that data is only useful if it’s retained, structured, and mapped to the specific controls an auditor will ask about.
For PCI-DSS specifically, the requirement to show that access to cardholder data environments is restricted and logged maps directly onto a ZTNA policy set that segments payment rail and ledger access as its own domain. The access-mapping work done before migration becomes the documentation that answers “who can access this system and why” without anyone having to reconstruct it retroactively from firewall rules. Teams running containerized workloads in scope for PCI have a related set of segmentation questions worth reviewing alongside this one, covered in running Kubernetes in scope: container orchestration practices that pass a PCI-DSS audit.
For SOC 2, the relevant trust service criteria around logical access controls are generally easier to satisfy under ZTNA because the continuous verification model produces evidence of ongoing enforcement rather than a point-in-time control. The parallel-run period described above is itself useful audit evidence: it shows a controlled transition with comparable logging on both sides, rather than a sudden cutover that an auditor has no way to verify happened cleanly.
The one gap to close before any audit is the VPN routes left over from the migration. Any access path that was never formally decommissioned, even if nobody is using it, is a finding waiting to happen. Treat full VPN decommissioning, not just ZTNA rollout, as the actual finish line.
Vendors sit underneath every part of this migration, the identity provider, the ZTNA policy engine, the endpoint posture agent, and each one gets evaluated differently depending on what it’s allowed to see and decide. For the broader due-diligence lens on evaluating the vendors involved in this kind of migration, see how to vet a fintech vendor before you sign: a risk framework that actually works.