RDP Restricted Admin Mode and Remote Credential Guard: Protecting Admin Credentials

RDP has a long-standing security problem: when an administrator logs into a remote server using standard RDP, their cleartext-derived credentials are exposed in the remote session’s memory. Malware on a compromised server can harvest those credentials and pivot to every other machine that admin touches. Two Windows features were built specifically to close this gap — Restricted Admin mode and Remote Credential Guard. Understanding the difference matters, because they solve related but distinct problems.

The credential exposure problem

In a normal interactive RDP logon, the client authenticates to the server, and the server then holds the credentials so it can build the logon session locally. That local session can perform single sign-on to network resources — convenient for the user, dangerous if the server is hostile. Pass-the-hash attacks against lateral movement depend on exactly this exposure.

Restricted Admin mode

Restricted Admin mode changes the logon type from interactive to network. The admin’s credentials are not cached on the remote server, so they cannot be harvested there. The tradeoff is real: in a Restricted Admin session you cannot authenticate to other resources, because there is no full token with network credentials. It is designed for jump servers and one-off administration, not for daily driver sessions.

• Enable the client with the DisableRestrictedAdmin value set to 0 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
• Launch the client with mstsc /restrictedAdmin.
• Verify the session: whoami /groups shows the “Restricted” marker in some configurations.

Critically, Restricted Admin implies that whoever can authenticate to the server controls it — a compromised client becomes a direct path in. That is why it should be used only from trusted, hardened management workstations and only with a dedicated admin account that has no other privileges.

Remote Credential Guard

Remote Credential Guard solves the usability complaint. It also prevents credentials from being stored on the remote host, but it keeps single sign-on working by having the server refer authentication requests back to the client over the existing RDP channel. From the server’s perspective there is no reusable credential to steal; from the user’s perspective SSO still works. It requires the client and server to be joined to the same Active Directory forest and is enabled with mstsc /remoteGuard.

Property	Standard RDP	Restricted Admin	Remote Credential Guard
Credentials cached on server	Yes	No	No
Single sign-on inside session	Yes	No	Yes
Requires AD domain	No	No	Yes
Protects against server-side theft	No	Yes	Yes

Which to use when

In an Active Directory environment, Remote Credential Guard is the better daily choice: it preserves workflow and removes the exposure. Restricted Admin mode remains useful for standalone servers and for workgroup scenarios where no domain exists — common on a Windows VPS that is not domain-joined. For a single-admin VPS, enabling an admin account that is used exclusively with /restrictedAdmin is a meaningful reduction in blast radius.

Complementary controls

• Require Network Level Authentication on the server — never allow RDP without it.
• Use dedicated administrative accounts that are not used for email or browsing.
• Add Credential Guard on the client to protect the credential material there too.
• Alert on RDP logon type 10 events in the Security log; unusual sources are worth investigating.

None of these features help if the admin reuses a privileged account for day-to-day work. The controls reduce exposure; account hygiene determines whether exposure exists at all. Together they transform RDP administration from a credential-leakage risk into a manageable one.

Detection and event IDs

Both features change the logon type recorded on the server, which is itself useful telemetry. Standard RDP logons appear as Type 10 (RemoteInteractive); Restricted Admin and Remote Credential Guard sessions are recorded differently and carry distinctive markers. Monitoring your RDP sources for anomalies — a first-ever source IP, a logon outside business hours, a burst of failures — catches credential-stuffing attempts before they succeed. Combine the event log with the RDP connection events that the Remote Desktop Services operational log records for a complete picture.

Requirements and pitfalls

Requirement	Restricted Admin	Remote Credential Guard
Domain-joined client and server	Not required	Required (same forest)
Server version	2012 R2+	2016+ on both ends
Works with MSTSC only	Yes	Yes
Breaks SSO inside session	Yes	No

• Both require the client to be Windows; third-party RDP clients generally do not implement the extensions.
• Restricted Admin will break any workflow that needs the session to reach a file share or database, so test it before standardizing.
• Remote Credential Guard needs Kerberos working end-to-end; if your VPS is not domain-joined, it is not an option.
• Do not enable Restricted Admin on a machine you would not fully trust: the protection is one-directional.

A practical baseline for a standalone VPS

For an admin managing a non-domain-joined Windows VPS, the pragmatic configuration is: require NLA, use a dedicated admin account not used elsewhere, connect with mstsc /restrictedAdmin, and keep a second break-glass account available through the provider’s console in case RDP is unavailable. Reboot and log in once with Restricted Admin to confirm the tooling works before you rely on it. Add source-IP allow-listing at the firewall so that even a stolen credential cannot be used from an arbitrary address.

Why this matters more in 2026

Ransomware crews routinely target RDP as the initial foothold, and post-exploitation credential theft on a compromised server is the standard next step. Removing the ability to harvest admin credentials from a remote session breaks that chain at a point the attacker depends on. It is not a complete defense, but it is one of the few controls that specifically defeats the lateral-movement technique these groups rely on most.

If you are deploying a Windows VPS for administrative work, start with a clean image and layer these controls on from day one rather than retrofitting later: see our Windows VPS plans, and read our security guidance for the recommended RDP baseline.