Remote Desktop Protocol (RDP) sits at the centre of a troubling paradox. IT teams rely on RDP daily for server management, remote support, and access to legacy applications. Attackers rely on it too. Recent incident response data shows RDP involvement in 90-95% of ransomware cases, making it the single most abused remote access tool in enterprise environments.
The problem is not the protocol itself. RDP does what it was designed to do. The problem is how organisations expose it: open ports, weak credentials, flat network access, and authentication that stops at the perimeter. These patterns turn a useful administrative tool into a direct path to ransomware deployment.
This guide explains what makes RDP vulnerable, why traditional defences fall short, and how identity-based access with Zero Trust principles removes the risk without removing the functionality your team depends on.
How to secure RDP access with Zero Trust
- Stop exposing port 3389 to the internet. Use identity-based access that makes RDP invisible to scanners.
- Require multi-factor authentication for every session, not just VPN entry.
- Enforce device posture checks before granting any remote desktop connection.
- Scope access to specific applications, not entire network segments.
- Log every session with user identity, device state, and timestamp for audit.
- Monitor for impossible travel and credential anomalies in real time.
Why RDP keeps appearing in breach reports
RDP has been shipping with Windows since 1996. It works reliably. It is familiar to administrators. And it is installed by default on nearly every Windows system in your environment. That ubiquity creates scale for attackers. Automated scanners find exposed RDP services within hours of them going online.
The attack patterns have matured. Early RDP exploits targeted protocol vulnerabilities. Current attacks overwhelmingly target credentials. Brute-force campaigns test thousands of password combinations. Credential stuffing uses leaked username and password pairs from previous breaches. Phishing captures valid credentials that attackers then use to log in through the front door.
Once inside via RDP, attackers have a graphical interface to the compromised system. They can disable security tools, deploy ransomware manually, exfiltrate data, and pivot to other systems. The session looks like legitimate administrative activity because it uses a legitimate administrative tool.
| Attack vector | Method | Why it works |
|---|---|---|
| Brute force | Automated password guessing | Weak passwords, no lockout policy |
| Credential stuffing | Using leaked credentials | Password reuse across services |
| Phishing | Stealing valid credentials | Credentials alone grant full access |
| Session hijacking | Taking over active sessions | Lack of continuous verification |
| Protocol exploits | CVE-based attacks | Unpatched systems, slow update cycles |
Recent vulnerabilities illustrate the ongoing risk. CVE-2025-48817, disclosed in July 2025, allows remote code execution through the RDP client itself when connecting to a malicious server. Earlier in 2025, CVE-2025-21309 and CVE-2025-21297 enabled unauthenticated remote code execution on RDP services. These vulnerabilities affect systems from Windows Server 2008 through Windows 11.
What makes traditional RDP protection insufficient
Most organisations attempt to secure RDP using one of three approaches: exposing it through a VPN, placing it behind a firewall with port restrictions, or using Microsoft’s Remote Desktop Gateway. Each approach reduces some risk while leaving significant gaps.
VPN-based RDP access
VPNs create an encrypted tunnel to the network perimeter. The assumption is that once the tunnel is established, the user can be trusted with broad network access. This model has two problems. First, it relies on perimeter authentication. A compromised VPN credential grants the attacker the same access as a legitimate user. Second, VPNs provide network-level access rather than application-level access. An attacker who breaches the VPN can scan internal networks, discover RDP services, and attempt lateral movement.
Recent years have seen multiple high-profile VPN compromises. Attackers have exploited vulnerabilities in Fortinet, Ivanti, and Cisco VPN products to gain persistent access to enterprise networks. These are not theoretical risks.
Firewall port restrictions
Blocking port 3389 at the perimeter prevents direct internet scanning. This is a necessary baseline control. However, it does not address attacks that originate from within the network, phishing that captures valid credentials, or lateral movement from an already-compromised endpoint. Firewall rules also tend to accumulate exceptions over time as users request access for specific use cases.
Remote Desktop Gateway
Microsoft’s RD Gateway proxies RDP traffic over HTTPS on port 443, hiding the standard RDP port from external scanners. This improves the situation but does not fundamentally change the security model. RD Gateway still relies on username and password authentication. It does not include native multi-factor authentication. It does not verify device posture. It grants access based on network location rather than identity context.
How Zero Trust changes the RDP security model
Zero Trust Network Access applies three principles that directly address RDP weaknesses: verify identity continuously, enforce least privilege access, and assume breach.
Verify identity continuously
Rather than authenticating once at the VPN perimeter, ZTNA verifies identity for each access request. Multi-factor authentication is required, not optional. Device posture is checked before access is granted. Contextual signals like location, time, and risk score influence access decisions. If any of these factors change during a session, access can be revoked or stepped-up authentication can be required.
Enforce least privilege access
ZTNA grants access to specific applications, not entire networks. A user who needs RDP access to a particular server receives precisely that access and nothing more. They cannot scan the network, discover other services, or pivot to systems outside their authorised scope. This dramatically limits the blast radius of a compromised credential.
Assume breach
ZTNA architectures treat every connection as potentially hostile. Traffic is inspected. Sessions are logged with full user and device context. Anomalies trigger alerts. The goal is not just to prevent unauthorised access but to detect and contain it quickly when prevention fails.
| Aspect | Traditional VPN | Zero Trust (ZTNA) |
|---|---|---|
| Trust model | Trust after perimeter auth | Never trust, always verify |
| Access scope | Network-level | Application-level |
| Authentication | Once at connection | Continuous verification |
| Device posture | Usually not checked | Required for access |
| Visibility | Limited after connection | Full session logging |
| Lateral movement | Possible | Blocked by design |
Making RDP invisible to attackers
One of the most effective ZTNA techniques for RDP security is making the service invisible to unauthorised users. In a traditional deployment, RDP listens on a port that anyone can scan and probe. In a ZTNA deployment, the RDP service has no public exposure. Connections are only possible for authenticated users through the access platform.
This approach eliminates the reconnaissance phase of most RDP attacks. Automated scanners cannot find what is not exposed. Brute-force attacks cannot target a service they cannot reach. The attack surface shrinks from “anyone on the internet” to “authenticated users with appropriate permissions and compliant devices.”
For organisations still using RDP for remote administration and support, this model preserves the functionality while removing the primary attack vector.
Practical implementation for mid-market teams
Securing RDP with ZTNA does not require a complete infrastructure overhaul. The process works in stages.
Phase 1: Inventory and assessment
Identify all RDP usage in your environment. Which servers have RDP enabled? Who uses them and for what purpose? Are there exposed RDP services you are not aware of? External attack surface scanning can reveal RDP ports that were opened for a specific project and never closed.
Phase 2: Identity and posture foundation
Connect your identity provider to the ZTNA platform. Define which users should have RDP access to which systems. Establish baseline device posture requirements: managed device status, OS version, disk encryption, endpoint protection.
Phase 3: Application publishing
Publish RDP access through the ZTNA platform rather than exposing it directly. Users connect through the platform, which verifies their identity and device before establishing the RDP session. The RDP service itself never accepts direct connections from the internet.
Phase 4: Policy refinement
Monitor access patterns. Identify users with excessive permissions. Implement just-in-time access for administrative functions that are not needed continuously. Add step-up authentication for high-risk operations.
Phase 5: Legacy cleanup
Remove direct RDP exposure from firewalls. Close port 3389 to inbound traffic. Decommission VPN access paths that were previously used for RDP. Document the new access model for audit purposes.
How Jimber addresses RDP security
Jimber’s SASE platform provides the components needed to implement Zero Trust RDP access without adding operational complexity.
ZTNA Network Isolation replaces broad VPN access with identity-based, application-level access. RDP services are published through the platform and become invisible to external scanners. Users authenticate with their existing identity provider, device posture is verified, and only then is the connection established.
The Network Isolation Access Controller (NIAC) extends protection to devices that cannot run agents, including servers in isolated network segments where RDP access might be needed for maintenance.
Secure Web Gateway and centralised policy management ensure consistent controls across all access types, not just RDP. Logging and monitoring provide the visibility needed for compliance and incident response.
For organisations with multiple sites or hybrid environments, SD-WAN maintains secure, performant connectivity without the latency penalties of traditional VPN backhauling.
The result is RDP access that works for the users who need it while remaining invisible and inaccessible to everyone else.
Compliance considerations for NIS2 and GDPR
European organisations face specific requirements around access control, logging, and incident response. RDP security directly affects compliance posture.
NIS2 requires measures to ensure network and information system security, including access control and authentication. Exposing RDP directly to the internet, with only password authentication, does not meet a reasonable interpretation of these requirements. ZTNA-based access with MFA, device posture checks, and comprehensive logging demonstrates the required level of control.
GDPR requires appropriate technical measures to protect personal data. If RDP provides access to systems containing personal data, the access controls must be proportionate to the risk. Identity-based access with least privilege scoping is more defensible than network-level VPN access.
Both regulations require the ability to demonstrate compliance. Centralised logging of RDP sessions, with user identity, device state, and access decisions, provides the evidence needed for audits and incident investigations.
Frequently asked questions
Is RDP inherently insecure?
The protocol itself is not the problem. The risk comes from how organisations deploy it: exposed ports, weak credentials, network-level access. With proper controls including identity verification, device posture, and application-level scoping, RDP can be used safely.
Do I need to stop using RDP entirely?
No. Many organisations have legitimate use cases for RDP, including server administration and access to legacy applications. The goal is to secure how RDP is accessed, not to eliminate it.
How does ZTNA differ from using a VPN for RDP?
VPNs grant network-level access after a single authentication event. ZTNA grants application-level access with continuous verification. A VPN user can scan the internal network and attempt to access services beyond their authorised scope. A ZTNA user can only access the specific applications they are permitted to use.
What about Microsoft’s Remote Desktop Gateway?
RD Gateway improves on direct RDP exposure by proxying traffic over HTTPS. However, it lacks native MFA, device posture verification, and the application-level access controls that ZTNA provides. It can be a component of an RDP security strategy but is not sufficient on its own.
Can small IT teams implement this without a major project?
Yes. ZTNA platforms like Jimber are designed for rapid deployment. Start with your highest-risk RDP use cases, publish them through the platform, and expand coverage over time. The transition can happen alongside existing access methods until you are confident in the new approach.
How does this affect user experience for remote workers?
Done well, ZTNA improves the experience. Users authenticate once through their identity provider and can access authorised applications without managing VPN connections. Latency is often lower because traffic does not backhaul through a central data centre.
Next steps
RDP remains a valuable tool for IT operations. The security challenges come from how it is exposed, not from the protocol itself. Identity-based access with Zero Trust principles removes the primary attack vectors while preserving the functionality your team relies on.
Ready to secure RDP access without the complexity of traditional approaches? Book a demo to see how Jimber makes Zero Trust access practical for mid-market IT teams.
