Ask what RDP is and you get two answers, both correct. One is a feature that has shipped inside Windows since the Windows NT era. The other is a rented Windows machine, sold by the month, that people call "an RDP."
If an employer or a client told you to "use RDP," they almost certainly mean the first one. You probably already have it. If you found RDP on a vendor page with a price beside it, you were looking at the second.
RDP Means Two Different Things
RDP stands for Remote Desktop Protocol. It is Microsoft's protocol for controlling one computer from another over a network, and it is built into Windows. The same three letters also show up on hosting product pages. In that context, an "RDP server" usually means a hosted Windows machine, often a VPS, with Remote Desktop already enabled. You reach it using the protocol.
So: what is RDP in your case? It depends on where you saw the word. Setup instructions usually mean the protocol; hosting listings often mean a rented Windows machine with RDP enabled.
Microsoft developed RDP in 1998. It first shipped with the first release of Windows NT Terminal Server. On a Windows PC the client side is already installed and already paid for. It is called Remote Desktop Connection, and you find it by typing that name into the Start menu search box. Microsoft also publishes newer clients, including Windows App. They are available on many different types of devices beyond Windows.
If the machine you need to reach already exists and runs an edition that can host Remote Desktop, you usually do not need a separate RDP product. That covers an office PC, a server your team runs, or a VPS you already have. Enable access, make the host reachable, then open the client, enter the address, and sign in.
How Remote Desktop Protocol Works
Three conditions have to hold before any RDP connection succeeds, and a failure is almost always one of them. Remote Desktop must be turned on at the host. The host must be reachable from where you are sitting. That means the same office network, or an open path across the internet. And you must have an account or credentials accepted by the host, with permission to sign in remotely. Entering an IP address is only the last of the three.
With those in place, a session runs in three stages:
- Setup. An administrator enables Remote Desktop on the host machine and decides who may connect. This is where securing an RDP host is cheapest, because nothing is exposed yet.
- Connection. The client sends the host address and your credentials. If they are accepted, the host opens a session for your account. The steps for connecting from Windows are the same whether the host is next to you or in another country.
- Communication. The host sends desktop graphics to you; your keyboard and mouse input travels back. Your applications run on the host, not on your own machine.
Underneath, RDP separates different kinds of session data into logical virtual channels, then multiplexes those channels over the connection. Screen updates, input, printing, and device redirection can be handled and prioritized separately even though they still share the underlying network path. Session traffic is encrypted in transit. Microsoft's own architecture documentation places the components that manage those channels in the ITU's T.120 family. T.122 defines the multipoint services; T.125 defines the data transmission protocol.
The number to remember is 3389. Remote Desktop is listening on port 3389 by default, on both TCP and UDP. That port is configurable through the registry. UDP is the newer of the two. It arrived with the RDP 8.0 update, which lets an administrator use both TCP and UDP. Sessions then degrade more gracefully on lossy networks. When somebody asks you to "open the firewall for RDP," 3389 is what they mean.
What RDP Can Do
With printer redirection enabled, the printer on your desk can appear inside the remote session as though it were connected there. That trick, called redirection, is most of what separates RDP from a plain screen viewer.
| Property | What it does | Why it matters |
|---|---|---|
| Smart Card Authentication | Accepts physical security tokens with embedded chips | Stronger than a password on its own |
| Bandwidth Reduction | Encodes and compresses desktop updates instead of sending raw full-screen video | Usable sessions on slow connections |
| Multiple Display Usage | Drives more than one monitor in a single session | The remote desktop matches your physical setup |
| GPU Support | Can use host GPU acceleration and hardware H.264/AVC encoding when supported and enabled | Graphics-heavy applications stay watchable |
| Audio Redirection | Plays remote sound through your local speakers | Video and calls work inside the session |
| File System Redirection | Exposes your local drives to the remote session | Copying files needs no third-party tool |
| Printer Redirection | Exposes your local printer to the remote session | No exporting a document just to print it at your end |
| Port Redirection | Supports serial/COM redirection and selected USB redirection when configured | Compatible peripherals can remain available remotely |
The GPU row carries a caveat worth knowing. The old RemoteFX vGPU component is gone. Microsoft lists the RemoteFX 3D video adapter among removed Windows Server features and points to Discrete Device Assignment instead. The component also carried a remote code execution vulnerability, CVE-2020-1036. Modern Hyper-V hosts can expose GPU resources through Discrete Device Assignment or GPU partitioning instead of RemoteFX vGPU. That is why remote gaming setups are so particular about host hardware.
Whether several people can be signed in at once is a property of the host, not of the protocol. A single Windows desktop generally serves one interactive session. Hosting many isolated sessions on one Windows Server is the job of Remote Desktop Services, not of plain RDP. In a normal Windows Server RDS deployment, each user or device also needs the appropriate RDS CAL. Check both the session model and licensing before you promise a shared machine to a team.
Where RDP Falls Short
RDP is a good protocol with four specific costs. Three of them are yours to manage. The fourth decides whether RDP is the right tool at all.
Port 3389 on the Open Internet
Do not put RDP directly on the public internet. An internet-facing 3389 is a standard initial-access vector, and the history is documented. CVE-2019-0708, known as BlueKeep, allowed an unauthenticated attacker to execute code on a target. Connecting and sending crafted requests was enough.
BlueKeep and DejaBlue were both disclosed and patched in 2019. The exposure pattern they exploited has not gone anywhere. Credential guessing against an open port never needed a vulnerability in the first place.
The mitigations are ordinary. Put the host behind a VPN or a Remote Desktop Gateway so the port is not reachable from arbitrary addresses. Restrict which source addresses may connect. Add multi-factor authentication at the access layer where your setup supports it, such as an RD Gateway deployment. Apply Windows updates on a schedule you can keep. If the machine has to be reachable from anywhere, rate-limiting failed logins belongs on that list too.
The Connection Is the Experience
Every frame you see crossed a network. On a stable link RDP feels close to local. On a congested or high-latency one, each keystroke arrives late, and the delay compounds across a sentence. Large file operations are worse than the screen redraw. Mobile networks amplify this. RDP from an Android device benefits from lowering the session resolution before you blame the server.
The Host Pays for the Session
Rendering the desktop, encoding it, and running your applications all happen on the host. A machine that is comfortable running a background service can struggle once someone works on it interactively. It gets worse with each additional session. Size the host for the work you intend to do inside it, not for the work it does today.
Windows on the Host, Almost Anything on the Client
This is the boundary that decides the tool. The client side is much less constrained. The host side is not. Microsoft's documentation names the editions that can host a session: Professional, Enterprise, Education, and Windows Server. Home editions cannot.
That is what limits Microsoft's built-in RDP hosting to Windows. macOS does not natively provide an RDP host, so controlling a Mac sends you to a different remote-access tool. Linux is the exception worth knowing. The open-source xrdp implementation answers RDP connections without anything from Microsoft, and xRDP on Ubuntu is the usual starting point.
What Hosting Providers Mean by an RDP Server
You buy one and the provider gives you connection details: typically an IP address, a username, and a password. There is no physical box or local installer. Depending on the provider, you may choose the Windows version during deployment; the server itself runs in a data center with Remote Desktop enabled before you connect.
In hosting listings, that product is usually a Windows VPS with RDP enabled. The VPS runs its own Windows environment on shared physical infrastructure, and you rent the virtual machine rather than own the hardware. The provider pre-configures the protocol half, so the host is enabled, reachable, and running before you connect for the first time.
The main variable between plans is whether the machine is yours alone or shared. That decides what you may install, and what happens when a neighbor gets busy. It is the line between shared and admin RDP plans.
What You Get With a Hosted RDP Server
The first session looks like this. Open Remote Desktop Connection, paste in the address, then enter the username and password you were sent. A Windows desktop appears. From that point it behaves like any other Windows machine. You install software, browse, run applications, and leave things running when you close the window.
What you are paying for is the part underneath. The provider owns the hardware, the network, and the physical security. It keeps the machine powered on when your own laptop is not. Be clear about where the line sits. On a self-managed plan, what happens inside Windows stays with you. Updates, user accounts, and firewall rules are your job. A hosted server moves the hardware problem off your desk; it does not move the patching problem.
Two other properties matter in practice. Resources are usually elastic, so an undersized machine can be given more CPU or memory without a rebuild. And location is a choice you make once and feel every day, because distance sets the floor on how responsive the session can be. Providers differ on both, and on how much of the stack they will touch. Those are the three points worth weighing when you choose an RDP provider.
Who Uses RDP Servers
These four situations need the same thing: a Windows machine that stays powered on, stays reachable, and does not travel in a bag.
Remote and Distributed Teams
A hosted desktop gives every team member the same tools and files, whatever hardware is in front of them. It can keep working data on a company-controlled machine instead of storing it locally, provided clipboard, drive, and other redirection policies are configured accordingly.
Development and Test Environments
Building and testing needs hardware that sits idle most of the time. Renting it by the month avoids buying hardware for the peak. A test machine that gets corrupted can be rebuilt without anyone losing a workstation.
Training and Lab Environments
An identical pre-configured desktop, handed to every student, means every student starts from the same state. Nobody spends the first session installing software or debugging one laptop's driver problem.
Contract and Freelance Work
A client can hand a contractor a separate working environment without giving them direct access to a company workstation. Data can stay on the hosted machine if clipboard, drive, and other redirection paths are restricted. When the project ends, the account or machine can be removed.
RDP Alternatives Worth Knowing
Two of the three alternatives below can control a Mac. That is the axis this category turns on. The test is not which tool has more features, it is what the target machine runs, and whether you can reach it.
| Tool | Target platforms supported | How you reach it |
|---|---|---|
| Remote Desktop Protocol | Windows | The host's own address, on TCP or UDP port 3389 by default |
| Chrome Remote Desktop | Mac, Windows, or Linux | Through the browser, with a PIN entered at connect time |
| TeamViewer | Windows, macOS, Linux, and supported Android devices; screen sharing only on iOS/iPadOS and ChromeOS | TeamViewer software on the remote device; desktop or web client on the connecting side |
| UltraVNC | Windows | A Windows viewer, or a Java viewer from Linux, macOS, and other systems |
Google's own documentation covers setting up Chrome Remote Desktop for remote access to a Mac, Windows, or Linux computer, which is exactly the case RDP cannot serve. It is the easiest option here to get running. It is also the one that puts the most third-party infrastructure in the connection path, which is where its security trade-offs sit.
TeamViewer covers the widest platform range here, but support is not identical on every target. Its current support matrix includes Windows, macOS, Linux, Android, iOS/iPadOS, and ChromeOS; iOS/iPadOS and ChromeOS are screen-sharing cases rather than full remote control.
The VNC family is the closest technical relative, and the most different in practice. UltraVNC's own documentation lists a Windows-only server with a Java-based viewer for other platforms. It also treats encryption as a plugin rather than a default, which is the single most important thing to know before running it across an untrusted network. On a Windows host, the choice between RDP and VNC usually comes down to that.
When Renting a Windows Machine Is the Right Answer
The host side of RDP adds up to a short specification: a machine that stays powered on and reachable, has enough CPU and memory for interactive work, and gets patched. If you already have that machine and it can host Remote Desktop, there is no separate RDP service to buy. Enable Remote Desktop, make the host reachable, and connect with a client.
If you do not have it, that specification is what a hosted RDP server fills. At Cloudzy, our Windows RDP servers ship with Windows Server preinstalled and Remote Desktop enabled, on a 99.95% uptime SLA. They run in data centers across North America, Europe, the Middle East, and Asia-Pacific, so you can put the machine near the people using it. There is a 14-day money-back guarantee if the latency turns out worse than you hoped.
Frequently Asked Questions
Is RDP Free?
There is no separate fee for the RDP protocol or the built-in Windows client. If you already own or operate a supported host, you can connect to it without buying an "RDP" product. What costs money is the machine at the other end. A vendor advertising "an RDP" for a monthly price is renting you a hosted Windows server, not the protocol.
Can I Use RDP on a Mac or Linux?
You can connect from both. Microsoft provides Windows App and Remote Desktop clients for macOS and several other platforms; on Linux, you need a third-party RDP client. Hosting is the other direction. Linux can answer RDP through xrdp, while macOS does not natively provide an RDP host.
Is Remote Desktop Protocol the Same as a VPN?
No. RDP gives you the screen and keyboard of one specific machine. A VPN puts your device onto a network so you can reach what is on it, but it hands you no desktop. The two are often used together: the VPN provides the private path, and RDP runs the session across it.
Should I Change the Default RDP Port?
It reduces noise, not risk. Untargeted scanning checks 3389 and moves on, so a different port keeps that traffic out of your logs. It is not access control: a scan aimed at your address will still find the service. Treat it as tidying up, never as a replacement for restricting access.
