How to harden RDP (port 3389) exposure beyond closing the port
Removing a direct port forward to RDP closes the most urgent gap, but an RDP deployment that still lacks Network Level Authentication, account lockout policy, and a plan for how remote access should actually happen is still fragile — this guide covers the configuration and access-architecture work that makes an RDP setup resilient, not just unreachable from the open internet.
By AdminKit team, Netbase JSC · Updated October 23, 2026
Why “closed to the internet” is the start of the checklist, not the end
A joint CISA & FBI advisory, AA22-137A, names Remote Desktop Protocol “one of the most common infection vector[s] for ransomware” — and its guidance doesn’t stop at “don’t expose it directly.” CISA’s Binding Operational Directive 23-02, which governs how federal agencies must handle internet-exposed management interfaces, treats removing direct exposure as the baseline requirement, with authentication strength and access control as the controls that determine how much damage a remaining or future gap can actually do. RDP is exactly this kind of management interface — a protocol built to grant an interactive, highly privileged session — so the hardening work matters even once the port itself isn’t reachable from outside.
Step 1: confirm the port itself isn’t reachable
If you haven’t already, confirm your current exposure with AdminKit’s port check tool against your own public IP (confirmed first with what is my IP), and remove any direct port forward to 3389 if one exists. This remains the single highest-priority action — everything below assumes it’s already done.
Step 2: require Network Level Authentication
NLA moves authentication earlier in the connection process: a client must authenticate before a full remote-desktop session is created, rather than being shown the logon UI first. This is a built-in Windows Remote Desktop Services setting (configurable via Group Policy or directly on the host) and should be enabled on every RDP host without exception — there’s no legitimate scenario where allowing unauthenticated clients to reach the full logon screen first is the better choice.
Step 3: evaluate Restricted Admin mode for administrative connections
Microsoft’s guidance on Remote Credential Guard and Restricted Admin mode describes Restricted Admin as a mode that reduces how much of an administrator’s credential material is sent to and cached on the remote host, specifically for scenarios like helpdesk support where an admin connects to many machines of uncertain trust. It’s a specific trade-off, not a blanket best practice for every account — review Microsoft’s current documentation for your Windows version before enabling it broadly, since the right choice depends on your specific credential-delegation setup.
Step 4: enforce account lockout and strong credential policy
A directly reachable login prompt is dangerous specifically because it invites unlimited guesses. Configure account lockout thresholds so repeated failed attempts against any account trigger a lockout or escalating delay, and ensure every account reachable via RDP uses a unique, strong credential rather than one reused elsewhere — credential-stuffing attacks work specifically because people reuse passwords across services.
Step 5: require multi-factor authentication on the access path
CISA’s AA22-137A advisory names multi-factor authentication directly as a mitigation for RDP-related ransomware risk, because it defeats credential-stuffing and brute-force attempts even when a correct password is guessed or reused from an unrelated breach. MFA can sit on the RDP connection itself (where your environment supports it) or, more commonly, on the VPN or access-broker layer that fronts RDP access — either way, a password alone should never be sufficient to reach an RDP session.
Step 6: put RDP behind an access layer, not a direct listener
Even with NLA, MFA, and account lockout in place, the strongest architectural fix remains not exposing the RDP listener directly to any untrusted network, including your own broader internal network if it isn’t otherwise segmented. Route access through a VPN or zero-trust access broker so the RDP login prompt itself is only ever reachable by a connection that’s already authenticated at that layer — this means a vulnerability in RDP itself, or a misconfiguration in one of the steps above, doesn’t automatically become reachable by everyone.
Step 7: re-check periodically
Re-run port check on a schedule, not just once — a firewall rule change, a new router, or a restored backup configuration can silently reopen direct RDP exposure without anyone deliberately deciding to allow it.
A related protocol, the same underlying lesson
Telnet shares RDP’s basic shape as a protocol that grants administrative access and is routinely found exposed directly to the internet, though for a different underlying reason — Telnet has no encryption at all, where RDP’s issue is almost always deployment, not the protocol’s own cryptography. See our guide on securing an exposed Telnet device for the comparable hardening checklist on that protocol.
Defensive use only
Every check this guide links to is for systems you own or are explicitly authorized to test. Never scan, probe, or attempt to log in to a system you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
I already removed the port forward. Is that enough?
It removes the most urgent exposure — a login prompt reachable by anyone on the internet — but it doesn't address what happens if the network itself is later compromised, or whether the accounts RDP relies on would hold up against credential-stuffing from a path you didn't anticipate, like a compromised VPN endpoint that still reaches the RDP host directly.
What does Network Level Authentication actually add?
NLA requires a user to authenticate before a full remote-desktop session is even created, rather than presenting the full login screen to anyone who connects. Beyond reducing resource use on the host, it means an unauthenticated connection attempt never reaches the point of interacting with the logon UI at all, narrowing what an unauthenticated network path can actually do.
What is Restricted Admin mode, and should I enable it?
It's a Windows RDP mode designed to reduce how much of an administrator's credential material gets sent to and cached on the remote host during a session, specifically to limit exposure if that remote host is later compromised. Microsoft recommends it for helpdesk-style scenarios where an admin connects to many machines of varying trust level. It's a configuration trade-off worth understanding rather than a universal default — review your specific environment against Microsoft's current guidance before enabling it broadly.
Does multi-factor authentication actually stop RDP attacks?
The joint CISA/FBI advisory on initial access techniques names MFA specifically as a mitigating control for RDP risk, because it defeats the credential-stuffing and brute-force attacks that make a directly reachable RDP login dangerous in the first place — even a correct password alone no longer grants access.
How do I check whether my own RDP setup is still reachable from outside?
Use AdminKit's port check tool against your own public IP, with authorization, to confirm 3389 doesn't respond from outside your network after you've made changes — re-checking after a configuration change is how you catch a rule that didn't take effect the way you expected.
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.