RDP security: remote desktop access without exposing port 3389 to the internet

The core rule for using RDP safely is that the resource’s port 3389 is not the address users connect to every day. Access comes from a session built on identity, assignment and, when the active session policy requires it, approval, not from a network path. In Cerberus the server’s address or port is not normally handed to the user; they open the assigned desktop in the browser. This page covers the risk, the common options, and what the Cerberus model supports and what it leaves to the deployment.

Why is an internet-facing RDP port risky?

An RDP port open to the internet is an entry point anyone can reach. Every open port brings a firewall rule, an exception and maintenance work. Anyone who can see the port can try passwords and target weaknesses in the service; there is no additional barrier at the network layer.

If access is thought of only as network reachability, these questions stay unanswered:

• Why is this person connecting to this server, and for how long?
• Who holds the password, and who was it shared with?
• When the work ended, did access actually close?

What options exist for secure RDP access?

Three approaches are common, each with its own limit.

Whichever is chosen, reachability and authorization are different questions.

Reachable does not mean authorized

Being able to reach a server over the network does not mean a user has the right to work on it. Cerberus keeps the two apart. The network path is prepared according to the connection model; the session decision is made separately from the inputs on Identity, scope and assignment: person, role, resource assignment, time, resource readiness and policy. A resource reachable over the network does not automatically become a startable user session.

Time, approval and revocation are part of that decision. Time-limited access sets an end time or usage budget, session approval (when the policy requires it) starts the request with a duration and policy, and revocation closes new sessions and the open session separately. To apply this flow to external teams, see supplier access.

How does an RDP session open in Cerberus?

The Zero Port model removes the resource port as the user’s daily entry address. The flow:

1. The user signs in and sees the resources assigned to them.
2. They choose the RDP, VNC, SSH or terminal working path.
3. The launch request is evaluated against the current access decision and resource readiness.
4. If the decision is positive, a working surface opens in the browser.

If the decision is negative, the user sees the reason category without being moved to a working surface: assignment, time, resource readiness, active session conflict or policy. All steps are on Session flow. A raw IP, hostname or port is not handed to the user as the normal path, and work can proceed without showing the target password.

What does the resource side need, by connection model?

“No need to open 3389” does not hold in the same way for every connection model. The Zero Trust / Zero Port model defines three connection models:

The Windows Agent is installed on the machine; it produces RDP readiness status, service health and managed local account readiness signals, and when a private network connector is selected it prepares resource reachability. On this path the user connects through the assigned working surface, not an address. Details are on Windows Agent.

For resources connected without an agent, the gateway runs in a network location that can reach the target. If the target is reachable through an existing network path or an open port, Cerberus manages the session and the records, but the firewall, allowlist and network exposure remain the deployment’s responsibility. In other words, Cerberus does not close an open port by itself; it does not give the user that port as an entry address. The models are compared on Connect resources without an agent.

In every model the network team keeps operating the firewall and reachability boundaries on the resource side.

Does Cerberus replace a VPN?

Instead of giving the user a resource address or broad network membership, Cerberus offers a managed working surface. The user device connects to the assigned working surface, not to a wide network. Behind the scenes, a private network path may be used depending on the connection model: the Windows Agent can prepare a private network connector, and a gateway can join the private network and reach the target on Cerberus’s behalf. The private network technology does not disappear; what the user receives is a policy-governed session, not a network.

What does it manage, and what does it not?

Cerberus manages who is assigned to which resource, when and for how long a session opens, revocation, and the event records for decision, start, state change and closure. These are event records, not session video; session recording is in development.

Cerberus does not manage operating system patches on the target server, firewall rules on the resource side, or in-machine readiness signals for non-Windows resources. Cerberus does not provide server hosting or virtualization management; it manages access to your own servers, virtual machines and desktops.

RDP access checklist

• Port 3389 is not the daily entry address for users.
• Access is assigned to a person and a resource; no blanket network membership is granted.
• A time limit is defined; if the session policy requires approval, the approval flow is defined too.
• The target password is not distributed to users.
• Firewall rules and network exposure on the resource side are reviewed separately.
• Revocation and closure events can be checked in the audit logs.

To try RDP access with your own resources, open the live demo.