Chrome Remote Desktop Security: Policies to Control, Restrict or Block It

Chrome Remote Desktop lets anyone with a Google Account install a host on a computer and reach it from anywhere, so in a managed fleet the question is not whether it works but who decides where it may run and who may connect. Google gives administrators a set of RemoteAccessHost policies, a per-user switch in the Google Admin console and documented network endpoints, which together let you allow it for named groups, restrict it to your own domain, or block it entirely. This guide covers how identity and access work in Chrome Remote Desktop, the administrative controls, host authentication settings, detection, a policy baseline for allow, restrict and block postures, and common mistakes. It is written for endpoint, Chrome Enterprise and Google Workspace administrators and SOC teams.

This is an independent guide from NHI Mgmt Group, based on Google's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google's current documentation.

Key takeaways

• Two connection modes, two policies. Remote access (anytime access to your own computer) and remote support (a one-time share with someone else) are controlled separately by RemoteAccessHostAllowRemoteAccessConnections and RemoteAccessHostAllowRemoteSupportConnections, so decide on each.
• Domain lists decide who connects. RemoteAccessHostDomainList limits which accounts can own a host, and RemoteAccessHostClientDomainList limits which accounts can connect; with an empty client list, remote assistance accepts clients from any domain.
• Network blocking is complete. Google documents that blocking remotedesktop-pa.googleapis.com stops all Chrome Remote Desktop functionality, outgoing and incoming, which makes it the cleanest fleet-wide block.
• Keep traffic on your network if you allow it. Turning off RemoteAccessHostFirewallTraversal and RemoteAccessHostAllowRelayedConnection limits connections to the local network or VPN, and the host then uses UDP ports 12400 to 12409.
• Turn on curtain mode for unattended hosts. RemoteAccessHostRequireCurtain turns off the host's physical input and output during a session, so someone at the desk cannot watch or interfere.

How identity and access work in Chrome Remote Desktop

Chrome Remote Desktop has two roles on every connection: the host, the computer being reached, which runs the host service (on Windows the service is named chromoting), and the client, the browser or mobile app connecting to it. Identity enters in three places:

• Host owner account: a host set up for remote access is registered to a Google Account. By default, for anytime remote access only the host owner can connect.
• Host PIN and pairing: the owner protects remote access with a PIN. RemoteAccessHostAllowClientPairing, enabled or unset, lets users pair a client so the PIN is not asked every time; RemoteAccessHostAllowPinAuthentication controls whether PIN and pairing methods are used at all.
• Remote support code: for remote support, the person sharing selects Generate Code under Get Support and sends the code to the helper. Google states the code works only once. When the helper enters it, a dialog shows the helper's email address and the sharer selects Share to grant full access; while sharing, the sharer is asked every 30 minutes to confirm they want to continue. With RemoteAccessHostClientDomainList empty, remote assistance accepts clients from any domain.

The Chrome policy definitions state that RemoteAccessHostAllowRemoteAccessConnections does not affect remote support, and RemoteAccessHostAllowRemoteSupportConnections does not affect remote access. Set both to match your intent.

Google states that remote desktop sessions are encrypted. The question for administrators is therefore authorisation rather than transport: who may own a host, who may connect, from which network, for how long, and with which data channels (clipboard, files, URLs) open. RemoteAccessHostMaximumSessionDurationMinutes disconnects remote access sessions after a set time but does not stop the client reconnecting, so pair it with the domain and network policies rather than relying on it alone.

When to allow, restrict or block

Our view: block by default for most users, because sanctioned remote support usually runs through a managed service desk tool with its own audit trail. Restrict rather than block where engineers genuinely need anytime access to a lab or office machine and VPN access is already in place; the restrict posture keeps connections inside your domain and network. Allow remote support connections only on devices the service desk supports, with the client domain list set, so a code read out to an outside caller cannot connect.

Admin roles and privileged access

Control of Chrome Remote Desktop sits with whoever can change Chrome policy for your fleet and the Workspace services for your users, so the administrators who hold those rights are effectively deciding who has remote access.

• Google Admin console service switch: in the Admin console, go to Apps, Additional Google services, Chrome Remote Desktop, Service status, and set On or Off for the whole organisation, an organisational unit or an access group. Changing it needs the Service Settings administrator privilege, so hold that privilege to a small group. Set the top level to Off and override to On only for the units or access groups you approve.
• Chrome policy administrators: policies reach Windows through HKLM\Software\Policies\Google\Chrome (Group Policy or Intune), macOS through managed preferences for com.google.Chrome, Linux through JSON files in /etc/opt/chrome/policies/managed/, and ChromeOS and enrolled browsers through the Admin console. Limit write access to these channels to your endpoint administrators. See the Privileged Access Management Guide.
• Enterprise remote support on ChromeOS: administrators can start remote support sessions to managed ChromeOS devices from the Admin console. RemoteAccessHostAllowEnterpriseRemoteSupportConnections set to Disabled prevents this; RemoteAccessHostAllowEnterpriseFileTransfer, unset or Disabled, keeps file transfer off in those sessions. Treat the admin role that can start these sessions as privileged.
• Elevated windows: RemoteAccessHostAllowUiAccessForRemoteAssistance (Windows) lets a remote helper interact with elevated windows when Enabled. Leave it Disabled or unset unless your service desk needs it, and then only for help desk devices.

Integrations, API tokens and service accounts

Chrome Remote Desktop does not use API tokens you issue, but it does create long-lived credentials that behave like non-human identities on each host.

• Host registration: each remote access host is bound to an owner account. RemoteAccessHostDomainList restricts host ownership to accounts in your domains, so a host cannot be registered to a personal account. On Linux and macOS, RemoteAccessHostMatchUsername requires the local user name to match the owner's account name.
• Paired clients: pairing removes the PIN prompt for a client. Set RemoteAccessHostAllowClientPairing to Disabled so every connection needs the PIN, which is our recommendation for managed hosts.
• Security key forwarding: RemoteAccessHostAllowGnubbyAuth proxies security key requests across a connection when Enabled; Google notes it needs components only available inside Google's network, so leave it Disabled or unset.
• Clipboard, files and URLs: RemoteAccessHostClipboardSizeBytes set to 0 disables clipboard sync for both modes; RemoteAccessHostAllowFileTransfer set to Disabled stops file transfer in remote access; RemoteAccessHostAllowUrlForwarding set to Disabled stops the host sending URLs to the client browser.

Users can remove a host from the access page with Disable remote connections, and uninstall it with the operating system's normal uninstaller (Chrome Remote Desktop Host Uninstaller on macOS). Build both into your offboarding and device reassignment steps so hosts do not outlive their owner's role. See the Employee Offboarding Security Checklist.

For a wider view of host credentials and remote paths into endpoints, see the Remote Access Identity Guide.

Logging and detection

Whether you allow or block Chrome Remote Desktop, verify that reality matches the policy.

Forward these to your SIEM and alert on hosts outside the approved group. See the Google Workspace Audit Log Detection Guide and the Endpoint Telemetry Guide.

Metrics that show it is working

• Percentage of managed devices reporting the intended RemoteAccessHost policies (target 100%).
• Number of devices with the chromoting service outside the approved group (target zero).
• Blocked requests to remotedesktop-pa.googleapis.com per week, trending down after communication to users.
• Percentage of approved hosts with curtain mode and client pairing disabled.
• Number of users with the Admin console service switch on, compared with the approved list.

Hardening baseline

Pick a posture per population. The values below come from the Chrome policy definitions; the posture choices are NHI Mgmt Group recommendations.

Curtain mode on Windows

Curtain mode matters most for hosts in shared spaces, such as lab machines or office desktops reached from home. Google's administrator article explains that curtain mode on Windows needs RemoteAccessHostRequireCurtain set to 1 together with Remote Desktop settings (fDenyTSConnections 0, and UserAuthentication 0 under RDP-Tcp, with SecurityLayer 1 under RDP-Tcp on Windows 10), on Professional, Ultimate, Enterprise or Server editions. Those Remote Desktop changes affect your RDP posture, so review them with the Remote Desktop (RDP) Security Guide before rolling out. As of November 2026, Google's article describes macOS curtain mode for releases before Big Sur; for newer Macs, place unattended hosts in controlled locations and rely on the domain and network policies.

Rollout steps (NHI Mgmt Group recommendation)

1. Discover current use: query DNS and proxy logs for the two Google endpoints and inventory devices with the chromoting service.
2. Decide posture per population (block for most, restrict for named groups) and record business owners for each exception.
3. Pilot the block posture on one organisational unit: set the two Allow policies to Disabled and confirm in chrome://policy, then watch for help desk tickets for two weeks.
4. Roll out by ring through Group Policy, Intune, macOS profiles, Linux JSON and the Admin console, then add the network block at the gateway.
5. For restricted groups, apply domain lists, firewall traversal off, pairing off and curtain mode, and test from a client on VPN.
6. Roll back by removing the policy from the ring or reverting the gateway rule; both take effect as devices refresh policy.

Small and large organisations

A small organisation on Google Workspace can turn the service off for everyone except IT in the Admin console and push the two Allow policies through Chrome Browser Cloud Management. A large mixed fleet needs every policy channel covered, because a policy only applies where Chrome is managed, plus a gateway block as the backstop. Where you need managed remote support at scale, align with your RMM decision. See the RMM Tool Security Guide and the Application Allowlisting Guide.

Common misconfigurations

• Blocking one mode only: disabling remote access but leaving remote support allowed, or the reverse. The policies are independent, so set both.
• Empty client domain list: with RemoteAccessHostClientDomainList unset, remote assistance accepts helpers from any domain. Set it to your domains wherever support connections stay on.
• Policy only on managed browsers: devices outside your Chrome management never see the policy. Add the remotedesktop-pa.googleapis.com block at the network layer.
• Client pairing left on: a paired client connects without the PIN. Set RemoteAccessHostAllowClientPairing to Disabled.
• Curtain mode without RDP review: the Windows curtain settings change Remote Desktop configuration. Review them against your RDP baseline first.
• No user guidance: users are not told to check the email address shown in the Share dialog, or that an unexpected request to read out a support code is a warning sign. Brief them through the Vishing and Help Desk Social Engineering Awareness Guide.

Framework mapping

Practitioner checklist

• Inventory hosts (chromoting service) and query DNS and proxy logs for remotedesktop-pa.googleapis.com.
• Set Chrome Remote Desktop Service status to Off at the top level and override to On only for approved units or access groups.
• Set RemoteAccessHostAllowRemoteAccessConnections and RemoteAccessHostAllowRemoteSupportConnections to match your posture.
• For allowed groups, set RemoteAccessHostDomainList and RemoteAccessHostClientDomainList to your domains.
• Turn off firewall traversal, relayed connections and client pairing on allowed hosts.
• Turn on curtain mode for unattended hosts after reviewing the RDP settings it needs.
• Block remotedesktop-pa.googleapis.com at the gateway for everything outside the approved group.
• Confirm policy application in chrome://policy and Admin console reports, and alert on drift.
• Restrict who can change Chrome policy and Workspace service settings, and review those admins quarterly.

Standards and references

• Google: Control use of Chrome Remote Desktop
• Google: Turn Chrome Remote Desktop on or off for users
• Google: Chrome Enterprise policy list, Remote access
• Google: RemoteAccessHostClientDomainList policy
• Google: RemoteAccessHostAllowRemoteSupportConnections policy
• Google: Access another computer with Chrome Remote Desktop
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls
• MITRE ATT&CK: T1219.002 Remote Desktop Software

Related NHI Mgmt Group resources: RMM Tool Security Guide · Browser Security Hardening Guide · ChromeOS and Chromebook Security Guide · Unauthorised Remote Monitoring and Management Tool Playbook