Securing Third-Party Contractor Access Without VPN Accounts

The jump in third-party involvement in breaches was not incremental: the Verizon 2025 DBIR had already recorded the largest single-year shift ever seen, and the following year's figure exceeded it again. Contractor access, not some exotic zero-day, is now the door attackers walk through. Marks & Spencer shows what that door looks like in practice: attackers social-engineered a third-party contractor, used that foothold to get inside, and the resulting damage ran into hundreds of millions of pounds in lost operating profit, alongside weeks of disrupted physical logistics. No malware had to be exotic and no exploit had to be novel. Someone picked up a phone, convinced a helpdesk they were who they said they were, and the rest followed from there.

Why contractor access is now the primary breach vector

The Marks & Spencer breach matters because of how unremarkable the method was. There was no firmware exploit, no zero-day, no nation-state tooling. A contractor was the target, the contractor's access was the prize, and the damage that followed, hundreds of millions of pounds against operating profit and a logistics operation knocked sideways, came from a single successful social engineering attempt against a third party. That is the pattern now, not the exception.

The scale of the shift backs that up. No matter which specific technique opens the door, contractors, vendors, and partners show up as the common thread across the incident data. Whether the entry point is a stolen credential, a social-engineered helpdesk reset, or an unpatched remote tool, the party holding the compromised access is, more often than not, someone outside the organization's own badge system.

Why damage compounds once a contractor account is the entry point

Getting in through a contractor account is only the first part of the problem. The IBM 2025 Cost of a Data Breach Report found that supply chain compromise has the longest mean lifecycle of any initial attack vector, so you stay blind to lateral movement for months after the initial foothold. Average disclosure time across verified 2025 incidents ran 117 days, so by the point an organization confirms a contractor account was the way in, whatever that account touched has likely already spread.

Long dwell time on its own would be bad enough. Combined with the fact that a single compromised vendor platform tends to produce several downstream victims rather than one, the arithmetic turns ugly fast: one contractor credential, unnoticed for months, can seed a breach that ripples across every organization sharing that vendor's platform. Monitoring for unusual activity sounds like an answer, but the access itself produces no anomaly to detect. Without visibility into what a contractor touched and downloaded at the application level, anomaly detection has nothing unusual to flag: broad network access looks the same whether a contractor is doing their job or an attacker is wearing their credentials.

The structural reason VPNs make contractor breaches worse than they need to be

None of this is a story about sloppy VPN administration. VPNs fail contractor use cases because of what they are built to do: authenticate a user once, then extend network-level trust to whoever just logged in. That is the design, working as intended, applied to a population of users it was never built to serve.

Network-level trust means a compromised contractor credential does not expose one application. It exposes a whole network segment, so lateral movement opens up across resources that contractor had no legitimate reason to touch. VPN infrastructure, along with the VDIs and endpoint agents that typically ride alongside it, takes real time to set up and tear down, and when contractor offboarding lags even slightly, orphaned accounts sit there holding live network access. That is a separate failure mode from what happened at Marks & Spencer, where the entry point was a social engineer impersonating an employee to talk a helpdesk into a credential reset. Both problems sit inside the same VPN architecture, and both get worse the longer contractor relationships run.

Contractor devices sit outside IT's control by definition. Endpoints can be out of compliance or already compromised, and a VPN checks posture once, at connection time, then stops looking. Malware already resident on a contractor's personal laptop rides the tunnel in alongside the legitimate traffic, because the VPN has no way to notice anything changed mid-session. A large share of organizations don't maintain a complete inventory of which external parties hold active credentials at any given time, so even the basic question of who has access becomes difficult to answer. A VPN authenticates. It does not audit at the application level, so there is often no record of what a contractor actually opened, read, or exported once inside.

The all-or-nothing nature of VPN access creates a compliance problem on top of the security one. Demonstrating the kind of granular, auditable access control that GDPR, HIPAA, and PCI-DSS expect is difficult when the underlying access model doesn't distinguish between "this contractor can see this one application" and "this contractor is on the network". And the whole arrangement gets harder to manage as the partner ecosystem grows: every new contractor relationship means another manual VPN configuration, and the administrative load scales with headcount rather than staying flat. None of this stems from a vendor doing a poor job building VPN software. It stems from a mismatch between what VPNs assume about their users, trusted employees, on managed devices, connecting to one defined perimeter, and the reality of contractor access, where none of those three assumptions hold.

What Zero Trust Network Access does differently, mechanically

Zero Trust Network Access starts from a different premise entirely. Instead of granting network-wide trust after a single login, it replaces that model with per-request, identity-verified, application-specific access, which is a structural change rather than a tighter configuration of the same VPN idea. Every request gets checked against identity, device posture, and context, and the result of that check connects the user to one specific application, not to the network that application happens to sit on.

That single design choice closes the lateral movement gap by construction, because applications stay invisible to the broader internet, so a contractor authorized to reach one internal tool has no way of even discovering that a second tool exists, since they are never placed "on the network" in the first place. NIST SP 800-207 draws a useful line here: ZTNA is the access method, while Zero Trust is the broader discipline of continuously validating identity, device posture, policy, and permissions. ZTNA is one of the ways an organization puts Zero Trust into practice.

The key distinction is the one between authentication and authorization. Proving who a user is says nothing about what that user should be allowed to do once verified, and that is exactly the layer a VPN leaves unaddressed. ZTNA enforces that authorization layer directly, on every request, rather than treating a successful login as a blank check. That single distinction is what makes contractor access safe to grant at all, not merely safe to watch.

The clientless ZTNA pattern that makes contractor onboarding practical

Applying all of this to contractors specifically produces a narrower pattern: clientless ZTNA. It enforces the full set of ZTNA access controls through an ordinary browser session, with no agent installed on the endpoint and no corporate identity provisioned for the contractor. They get a link.

Identity is where the practical difference appears first, in how a contractor proves who they are. Contractors can authenticate using identities they already have, from LinkedIn, GitHub, Google, or other existing providers, so there's no IT ticket to create a new credential and no orphaned account left behind once the engagement ends. ZTNA supports multiple identity sources at once, so contractors working for the same organization can authenticate through entirely different providers, and you never have to unify everyone under one corporate directory. One contractor logs in with GitHub, another with Google, and neither requires a new line item in the company's identity system.

Device risk gets handled differently too. If you build clientless ZTNA properly, it isolates the contractor's interaction with the permitted application inside an air-gapped cloud container, so even a device carrying active malware has no path from that session into your company systems. The onboarding math changes accordingly: ZTNA has been shown to cut remote access support tickets by 80% compared to VPN, because IT sends a link instead of provisioning a VPN account or shipping hardware, and the contractor is working inside their permitted application immediately. Offboarding mirrors that simplicity. To end access, you just remove a policy entry or an identity grant; there's no VPN account to hunt down afterward and no laptop to collect. For the terminal-based work that developers and sysadmin contractors actually need, clientless access covers HTTP/S, RDP, and SSH straight through the browser, without opening inbound ports or requiring any client software on the contractor's side.

How organizations replaced VPN with clientless ZTNA in practice

Organizations making this switch report faster onboarding, the elimination of shared-credential risk, and a general drop in operational overhead, so they don't just score better on a security audit.

Canva adopted Cloudflare Access to secure internal applications, which eliminated shared passwords, let the company skip building its own internal identity and access management system, and made contractor onboarding and offboarding faster and safer. Canva's Head of Infrastructure said: "Cloudflare Access saved us from having to develop our own identity and access management (IAM) system".

Delivery Hero was an early adopter of Cloudflare One's ZTNA, replacing a VPN setup it had outgrown and scaling the new model to protect tens of thousands of employees across every internal application. Fujitec replaced its aging VPN infrastructure with Cloudflare Access, moving from a "trust but verify" posture to "never trust, always verify" across ZTNA, Gateway, DNS, and network firewall, and finished the rollout in 45 days. Anadolu Efes put its public-facing web applications behind Cloudflare's WAF and DDoS protection, delivering its application portfolio to employees and partners across Turkey, Georgia, Moldova, and Kazakhstan, and completed its full migration off VPN in 2025 with deployment times cut dramatically. Estonian Railways consolidated onto Cloudflare's SSE platform, covering ZTNA, SWG, CASB, and Remote Browser Isolation, following a public procurement process aimed squarely at reducing the railway's dependence on perimeter-based security for a workforce that includes remote staff and third-party contractors and partners.

Line up a design company, a food delivery platform, an elevator manufacturer, a beverage company, and a national railway operator, and the common denominator is the reason each one moved: VPN provisioning was slow, shared credentials had become unmanageable, and proving who accessed what was effectively impossible. The security gain arrived as a byproduct of fixing an operational headache, not as the headline the IT team pitched to leadership.

Designing least-privilege policies that constrain contractor access

Getting a contractor past the front door through clientless ZTNA solves half the problem. Once inside, the contractor must only be able to reach the specific application they were brought on to work with, not a neighboring system that happens to share infrastructure. Least-privilege policy is what keeps a legitimate contractor relationship from quietly turning into a second, wider VPN in disguise.

Policy scoped to the individual application, rather than to a department or a VPN tunnel, is what makes ZTNA's architectural advantage actually bite. Because ZTNA checks identity, device posture, and context on every request rather than once at login, policy can also be time-bound and condition-bound in ways a VPN account never was: access that expires automatically at the end of a contract, or that tightens if a device's posture changes mid-session. The goal is for a compromised contractor credential to be worth exactly one application to an attacker, never a segment and never a network, and that is the plain, unglamorous discipline least-privilege design demands, the only version of contractor access that survives contact with an attacker who has already done the social engineering legwork once before.