RDP in the Browser: Cloudflare’s Zero Trust Take on a Legacy Protocol
Cloudflare has expanded its Access for Infrastructure suite with browser-based support for the Remote Desktop Protocol (RDP). The feature, which follows last October’s introduction of short-lived SSH access, lets users connect to Windows servers through a standard web browser—no native RDP client or VPN required. Built on Cloudflare’s existing proxy architecture, the solution applies Zero Trust authentication and policy controls to a protocol that has long been a security sore spot.
Why RDP Remains a Target
RDP dates back to Windows NT 4.0 Terminal Server Edition and is still widely used for remote access to Windows machines. The protocol’s graphical nature—streaming screen updates, drawing commands, and bitmap data—makes it computationally heavy and awkward to run over conventional VPNs.
More problematic is its security history. RDP servers often sit behind weak or shared passwords, leaving them exposed to brute force and credential stuffing. The default port, 3389, has been exploited in on-path attacks, most notably in the BlueKeep vulnerability (CVE-2019-0708), which allows unauthenticated remote code execution and is wormable. Attackers have used RDP for lateral movement and to deploy ransomware strains like Ryuk and Conti, earning it the nickname “Ransomware Delivery Protocol.” While patching and better password practices have reduced exposure, many unpatched or misconfigured systems remain online.
Despite these risks, RDP is still essential for organizations that need to provide contractors or distributed teams with access to high-powered Windows servers. Issuing corporate devices to third parties is expensive, so many organizations rely on bring-your-own-device policies. That creates a problem: traditional RDP needs client software installed on the user’s machine. Previously, enabling browser-based RDP meant self-hosting tools like Apache Guacamole or Devolutions Gateway, which add infrastructure overhead, maintenance burdens, and compliance review requirements.
How Browser-Based RDP Works
Cloudflare’s approach pairs an RDP client that runs in the browser with the policy enforcement already available in Cloudflare Access. Administrators can control authentication via SSO, MFA, and device posture checks; set authorization policies per target; and rely on Access logs for auditing. The RDP server itself is reached through Cloudflare Tunnel, a deployment model common among existing Access customers.
The browser client is built on IronRDP, a Rust-based RDP client that Cloudflare chose for its modern codebase and performance. Browsers cannot speak RDP directly over TCP, so the client encapsulates the session in a WebSocket connection, which also lets Cloudflare Access verify an authorization JWT at every hop. Because the WebSocket is already TLS-secured to Cloudflare, the implementation uses IronRDP’s RDCleanPath extension to avoid a second layer of TLS encryption between client and server.
Inside the Proxy Path
The RDP proxy itself runs on Cloudflare Workers, a decision reached after discarding two alternatives. Building a dedicated service on every server would add too much operational overhead; integrating the proxy into Front Line, Cloudflare’s legacy HTTP handling service, was rejected because that service is undergoing significant architectural changes. Workers provided automatic scaling and eliminated the need to expose new IP addresses.
From the WebSocket proxy, traffic moves into Apollo, Cloudflare’s service for routing between Zero Trust on-ramps and off-ramps. Apollo finds the colocation closest to the target Cloudflare Tunnel and connects to a counterpart instance there, which completes the final hop. All these services run on the same physical server, communicating over UNIX domain sockets; if that server fails, traffic shifts automatically via Unimog, Cloudflare’s L4 load balancer.
The connection path proceeds as follows:
- The user selects an RDP server from the App Launcher or a direct URL.
- The request lands at the nearest Cloudflare data center.
- Access validates the JWT to confirm the user is authorized.
- Workers deliver the IronRDP client to the browser.
- The client tunnels RDP over a TLS-secured WebSocket to a Worker.
- That Worker terminates the WebSocket and connects to Apollo, which routes to the RDP server.
- Apollo relays NTLM authentication messages between browser and server.
- Once authenticated, Cloudflare proxies the RDP session freely.
- Oxy, Cloudflare’s proxy framework, applies L4 policy enforcement and logging.
Modern Authentication Only
Cloudflare’s browser-based RDP explicitly refuses to support weak legacy RDP security features. Traffic using unsecured password authentication or RC4 encryption never reaches the customer endpoint. Instead, the solution requires a TLS-based WebSocket, enforces SSO and MFA policies, and integrates with enterprise identity providers through SAML or OIDC. Every session is encrypted and authenticated before it proceeds.
This selective stance reflects a deliberate design choice. The standard industry narrative posits a tradeoff between security and performance; Cloudflare argues that with the right architecture, both can be delivered. The proxy’s placement inside its global network means there is no additional infrastructure for customers to operate.
Roadmap: Session Monitoring and FedRAMP High
Cloudflare has already outlined the next phases for browser-based RDP. Session monitoring is planned, along with potential data loss prevention controls such as restricting file transfers and clipboard use. The company is also evaluating passwordless authentication methods, including client certificates, passkeys, smart cards, and third-party identity providers.
The feature is slated for inclusion in Cloudflare’s FedRAMP High offering, a certification effort announced in February. That work is aimed at validating data protection, identity management, continuous monitoring, and incident response capabilities, particularly for government, healthcare, and financial sector customers.
The browser-based RDP solution is currently in closed beta, with new customers onboarded weekly. Access for Infrastructure remains free for teams under 50 users and is included in existing Access or Zero Trust subscriptions.
