AllTech
On this page
Most small businesses eventually face a version of the same problem: someone who is not an employee needs temporary access to something internal. A bookkeeper who works for three other clients. A contract developer on their own laptop. A vendor’s technician who needs to touch one system for one afternoon. None of them are getting a company-issued device, and they often should not receive broad VPN access.
The usual fallback is a VPN account on a personal device, or a company laptop issued for a short engagement. Either one can create access-management debt when ownership, expiry dates, device controls, and offboarding aren’t handled consistently. VPN access and loaner laptops aren’t the problem in themselves. What matters is whether they’re correctly scoped, monitored, and revoked. A Cloudflare solution brief on third-party access describes a browser-based alternative worth knowing about, and where it fits.
Why the usual options are worse than they look
Giving a contractor VPN credentials for a personal laptop can create a managed-access problem: the device may sit outside your patching, EDR, encryption, and compliance controls, while the VPN may provide a network-layer path broader than the person’s actual task requires. A ZTNA client can improve on that with more granular, least-privilege access, but it can still be impractical for an unmanaged or temporary device when the contractor won’t install company-required software, or your team can’t reasonably support yet another client. Cloudflare’s own brief is careful on this point: it says device clients “may not be a good fit” for third-party or temporary users, not that they fail outright.
The alternative Cloudflare describes is clientless access: authentication and authorization happening through the browser, with no software installed on the end user’s device at all. For third parties, unmanaged devices, and short-term engagements, that’s a different tradeoff than either a VPN or a full device-client rollout.
What it actually covers
Per Cloudflare’s brief, browser-based clientless access is built for two categories:
- Web applications: self-hosted internal apps reachable on their own hostname, made to feel like navigating to a website rather than connecting to a network.
- Infrastructure access over SSH, RDP, or VNC: proxied through the browser rather than a native client, so a contractor can reach a specific server without a network-level tunnel to everything else.
The access model layers identity and data controls on top: multiple single sign-on options (including social identity providers or one-time PINs, useful for people who aren’t in your primary directory), and granular per-resource authorization instead of network-level access. Where Cloudflare Browser Isolation and the relevant policies are deployed, session controls can also restrict actions like copy/paste, uploads, downloads, or keyboard input for sensitive workflows. Those controls depend on configuration and licensing, so not every basic clientless deployment includes them automatically. They also reduce risk rather than guarantee against exfiltration by other means (a screenshot, a phone camera, manual transcription).
Where this doesn’t apply
A solution brief is written to sell the cases where a product fits, so it’s worth being direct about the ones where it doesn’t. Browser-based clientless access is a strong match for a defined, narrow list of things: a specific internal web app, a specific server a vendor needs to touch. It’s a weaker or poor fit for:
- Legacy or thick-client applications that can’t be delivered through a browser-accessible application or an approved browser-based protocol gateway.
- Long-running, graphics-heavy, bandwidth-intensive, or latency-sensitive workflows. Test browser-mediated access against the user’s actual workload before it becomes the standard access method, instead of assuming it will perform like a native client.
- Workflows that require local-device integration (USB peripherals, smart-card readers, printers, specialized scanners, local file mounts, or proprietary hardware), which typically need a managed endpoint or another access pattern. For a small business, this is often the practical reason browser-only access can’t be the whole answer.
- Anything requiring broad, sustained network access. A properly scoped device client is the more honest tool for that job, and clientless access shouldn’t become a workaround to avoid installing one.
The judgment call is matching the access pattern to how someone actually needs to work. Clientless is the easiest to deploy, but that alone isn’t a reason to default to it.
A real example, with the caveat it deserves
Cloudflare’s brief cites Canva, the graphic design platform, as a customer example. According to the brief, as Canva scaled quickly and increased its use of third-party developers, it turned to Cloudflare to improve the security and efficiency of user authentication and application-usage tracking. Jim Tyrrell, Canva’s Head of Infrastructure, is quoted: “Cloudflare Access saved us from having to develop our own Identity and Access Management (IAM) system.”
That’s Cloudflare’s own published customer account, not something AllTech verified independently, and Canva’s engineering scale isn’t the scale most of our clients operate at. What carries over is the shape of the problem: fast-growing third-party access needs, solved without building custom identity infrastructure from scratch. That shape shows up just as often at much smaller scale.
Where this fits for a smaller business
For a lot of our clients, this fixes one specific, recurring headache without a replatforming project: the seasonal bookkeeper, the outside developer, the vendor technician who needs one afternoon of access twice a year. Clientless access is often the first practical Zero Trust use case worth standing up, before a broader VPN replacement or Zero Trust rollout, because it’s scoped, low-risk to pilot, and doesn’t require touching anyone’s existing internal access.
If you’re currently solving this with a shared VPN login, a spreadsheet of who has what credentials, or a laptop that gets mailed out and never quite comes back, that’s worth a second look. The reason isn’t that it’s about to fail dramatically. Access sprawl like that gets expensive to untangle once it’s had a few years to accumulate.
AllTech helps organizations across Northern Utah assess third-party access by identifying the exact applications external users need, the identity and device constraints involved, the controls required for each workflow, and whether browser-based access, managed-device access, or another design is the right fit. AllTech is a Cloudflare partner.
How we help
Browser-based access for contractors and vendors is part of our zero trust access service, built on Cloudflare Zero Trust. Each outside user signs in with their own identity and reaches only the applications their policy allows. If outside users reach your systems through a shared VPN login today, ask us and we will help you scope a pilot.
Source note: The product description, use cases, and the Canva customer example in this article are drawn from Cloudflare’s solution brief, Secure Third-Party Access (Q1 2025). AllTech has independently adapted and commented on this material for organizations evaluating contractor and third-party access.
Disclosure: AllTech is a Cloudflare partner. Our recommendations are based on each client’s applications, identity environment, security requirements, and operational constraints, not on any one vendor’s material.
