Restrict who can reach RDP, keep Network Level Authentication enabled where supported, use individual strong credentials and minimise administrative privilege. Test a second session and recovery access before closing the current connection.
Treat the desktop as an administration boundary
An RDP session provides interactive access to a remote system, so the account used for it can become a valuable target. Begin by deciding who needs access and what work they must perform. A shared administrator login is convenient until you need to remove one person's access or understand a configuration change. Individual accounts make those operational tasks clearer.
Separate routine activity from privileged changes where the software permits it. A user who needs a business application does not necessarily need unrestricted system administration. Keep the administrator's endpoint maintained too: securing the remote machine does not protect credentials entered from an infected or shared local device. Consider both ends of the session in the access design.
Limit reachability before relying on login protection
Decide which networks or authorised devices should be able to reach the session host. Where your architecture supports it, use a controlled VPN or Remote Desktop Gateway rather than broadly exposing administration. Microsoft documents RD Gateway as a route to internal resources with connection and resource authorisation policies. Its suitability depends on the environment; it is not an included feature merely because a plan supports RDP.
Restrict firewall rules to the intended path, and confirm how dynamic client addresses will be handled. Do not make a restrictive rule that immediately disconnects the only administrator without a recovery option. Keep the existing session open, test the new path from another session and document the authorised recovery mechanism before removing the older access route.
Keep authentication and trust explicit
Microsoft recommends Network Level Authentication for most supported environments. NLA requires authentication before establishing a full remote session, adding protection at that stage. It does not replace a firewall, account policy or system updates. Check client compatibility and troubleshoot authentication problems rather than permanently weakening the configuration as the first response.
Use unique credentials and a second factor through a supported access architecture where possible. Verify the expected remote identity and certificate behaviour, especially after a rebuild or hostname change. A certificate warning deserves investigation; repeatedly accepting unexpected identities turns a useful trust check into an ignored dialog. Keep recovery credentials in an approved private store.
| Layer | Decision | Verification |
|---|---|---|
| Network | Which clients may reach the host? | Unexpected sources cannot connect |
| Authentication | Which account and factors are required? | A permitted second session succeeds |
| Privilege | Which tasks require administration? | Routine users cannot change system settings |
| Recovery | How is access restored after a mistake? | The documented recovery path is available |
Reduce what the session can carry
Review clipboard, drive, printer and other redirection features against the actual workflow. An administrator may not need every local resource exposed to the remote host. Conversely, disabling a required transfer path without an alternative can encourage unsafe workarounds. Document the allowed method for moving files, and keep secrets out of ordinary desktop notes or shared download directories.
For suitable domain-based environments, Microsoft provides Remote Credential Guard to reduce credential exposure during RDP connections. It requires compatible clients and Kerberos authentication and supports direct connections to the target machine; connections through Remote Desktop Gateway or Connection Broker are not supported. Check the requirements for your actual access path rather than treating it as a universal protection for standalone hosted Windows machines.
Maintain the machine and the evidence you need
Schedule operating system and application updates, including a deliberate restart process. Check whether an update requires a reboot and verify the service afterwards. Set sensible session policies for unattended or disconnected work, but consider applications that must continue running. A timeout policy should answer a security or operational need rather than simply copying an arbitrary number from another environment.
Retain useful access and incident information under a documented policy. Monitor repeated authentication failures and unexpected administration activity without collecting unnecessary content. Restrict who can read diagnostic records and decide how long they are needed. A precise logging policy is more meaningful than either keeping everything indefinitely or promising that no operational record can ever exist.
A safe first-session sequence
On delivery, verify the expected system, change temporary credentials through the approved process and establish individual access. Confirm the firewall and recovery route, then test a second connection. Apply updates, review redirection and install the required application. Create a backup and practise recovering the settings that matter before depending on the desktop for daily work.
DeskLink RDP and selected dedicated configurations offer Windows-related choices in the SwissOctet catalogue. Confirm the operating system, licensing, account privileges and management responsibilities for your order. A supported desktop connection is the beginning of an administration plan; the controls you configure and verify determine how that access is used.
Your practical checklist.
- Use individual accounts and appropriate privilege.
- Restrict the intended RDP access path.
- Keep NLA enabled on compatible systems.
- Test a second session before closing current access.
- Review redirection, updates and session policy.
- Confirm licensing and the recovery procedure.
The details that matter.
Does NLA make an exposed RDP host completely safe?+
No. NLA is one authentication control. Reachability, credentials, updates and privilege still need attention.
Can I use Remote Credential Guard on every Windows server?+
No. The client, host and authentication environment must meet Microsoft's requirements, including the applicable Kerberos arrangement.
What should I do before tightening the firewall?+
Verify a recovery route, preserve the working session and test the new allowed path through a second connection.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Microsoft: Enable Remote Desktop and Network Level Authentication learn.microsoft.com
- Microsoft: Remote Desktop Gateway access learn.microsoft.com
- Microsoft: Remote Credential Guard learn.microsoft.com
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.