Chrome Remote Desktop in Google Workspace

Chrome Remote Desktop (CRD) lets users access one computer from another through Chrome — either persistently (“remote access,” via remotedesktop.google.com/access, protected by a PIN) or ad-hoc screen sharing for support (“remote support,” via a one-time access code that must be re-confirmed every 30 minutes). All sessions are encrypted end-to-end. From a security standpoint CRD is a full-fidelity remote access channel: a support session grants the remote party access to “apps, files, emails, documents, and history,” so whether users may enable it is a genuine policy question for Workspace admins.

The admin control: an “additional service,” not a core one

CRD is not a Google Workspace core service (like Gmail or Drive). It is an additional Google service, and in the Admin console it is not listed with its own on/off toggle. Access is governed by:

Apps → Additional Google services → “Access to additional services without individual control”

That single setting controls the whole bucket of consumer-grade additional services lacking per-service toggles — CRD included. Consequences:

• OU-level granularity only. The setting can be turned on/off per organizational unit (and per access group in newer consoles), but you cannot disable CRD alone while keeping other “uncontrolled” additional services — it’s all-or-nothing for that category.
• To enable CRD: turn the setting On for the OU containing the users, after which they can set up hosts at remotedesktop.google.com/access per the standard consumer flow.
• To disable CRD: turn the setting Off for the OU. Managed Chrome/ChromeOS environments can additionally restrict it via enterprise policy, but the Workspace-side lever is the additional-services switch.

Security and governance considerations

• Data-processing commitments: additional services are not covered by Google Workspace’s core-service data-processing terms — one reason Google separates them and why regulated orgs often leave the uncontrolled bucket off.
• Shadow remote access: because CRD hosts register to a user’s Google account rather than to device management, an enabled CRD can bypass MDM visibility; offboarding flows should consider dangling CRD host registrations.
• Support-style sessions are one-time-code gated and require the local user to keep confirming every 30 minutes, which limits (but doesn’t eliminate) abuse potential.

Sources

• Access another computer with Chrome Remote Desktop - Google Support
• Chrome Remote Desktop Blocked by Admin - WindowsReport
• Google Workspace Admin: Turn services on/off — dead link
• Google Workspace Admin: Additional Google services settings — dead link

See also

• google-drive-direct-links — Drive is a core Workspace service; contrast its per-service admin toggle with CRD’s category-level control
• confirm-gmail-address-existence — Workspace account reconnaissance
• rdp-session-hijacking — abuse patterns for another remote-desktop channel