Cloud Identity: Managing Users, Groups, and Devices Without Workspace
A confusing question comes up constantly for teams new to GCP, usually somewhere around the point where a second or third engineer needs a login and the founder doesn’t want to keep sharing one shared Google account: “do we need Google Workspace to manage users on Google Cloud?” The answer is no, and the product that decouples the two is Cloud Identity — Google’s standalone identity and device management service that gives you real users, groups, org-unit structure, and mobile device management, without bundling in Gmail, Docs, or any of the productivity suite. If your organization already runs Microsoft 365 or another email platform but wants to run infrastructure on GCP with proper user lifecycle management instead of a pile of individually-created Google accounts, Cloud Identity is the product built for exactly that gap.
It’s easy to conflate with IAM because both show up in the same “security” conversation, but they solve different layers of the problem — Cloud Identity establishes who a person is and what groups they belong to; IAM decides what that already-authenticated person is allowed to do. Understanding the boundary between them clears up a lot of confusion that otherwise looks like overlapping, redundant products.
Cloud Identity vs Google Workspace vs IAM
┌───────────────────┬────────────────────────────────────────────┐│ Product │ What it actually does │├───────────────────┼────────────────────────────────────────────┤│ Cloud Identity │ Users, groups, org units, device management,││ │ SSO — the identity layer, no productivity ││ │ apps included ││ Google Workspace │ Everything Cloud Identity does, plus Gmail, ││ │ Docs, Drive, Meet, Calendar ││ Cloud IAM │ Authorization — what an already-identified ││ │ principal can do to GCP resources │└───────────────────┴────────────────────────────────────────────┘Cloud Identity is, functionally, Workspace with the productivity apps stripped out — same admin console, same underlying directory, same device management, same SSO capability. Organizations that already have email and collaboration tools elsewhere (Microsoft 365, a self-hosted system) and only need Google-grade identity management for GCP access adopt Cloud Identity specifically to avoid paying for and rolling out a productivity suite they don’t need.
Core Capabilities
Users and org units mirror how you’d structure identity in Active Directory — a hierarchical org unit tree lets you apply different policies (password requirements, 2-step verification enforcement, device policies) to different parts of the organization, like Engineering versus Sales, without managing each user individually.
Groups are the backbone of scalable IAM in practice. Rather than granting a Cloud IAM role to fifteen individual users, you grant it once to a Cloud Identity group and manage membership through the group — someone joining or leaving the team is a group membership change, not fifteen separate IAM policy edits.
# Create a group for a data engineering teamgcloud identity groups create data-eng@company.com \ --organization="organizations/123456789" \ --display-name="Data Engineering Team"
# Add a membergcloud identity groups memberships add \ --group-email=data-eng@company.com \ --member-email=jane@company.comDevice management enforces policy on mobile and desktop devices accessing company resources — requiring screen lock, disk encryption, or remote wipe capability for lost devices. This matters for GCP access specifically when combined with context-aware access policies that condition resource access on device compliance status, not just user identity.
Single Sign-On lets Cloud Identity act as the identity provider for both Google services and third-party SaaS applications via SAML, or lets you federate Cloud Identity itself to an external identity provider your organization already uses.
Syncing an Existing Directory
Very few organizations want to manage two separate sources of truth for user identity. Cloud Identity supports syncing from an existing directory rather than becoming a second, competing one.
On-prem Active Directory │ ▼Google Cloud Directory Sync (GCDS) (scheduled one-way sync) │ ▼ Cloud Identity (mirrored users/groups)Google Cloud Directory Sync (GCDS) runs as a scheduled job — typically on a server with LDAP connectivity to your AD — that pushes user and group changes into Cloud Identity on a recurring basis (hourly is common). It’s one-directional: AD remains the source of truth, and GCDS keeps Cloud Identity as a mirror, not the other way around.
For organizations using Azure AD / Entra ID or Okta as their primary identity provider, SAML-based SSO federation is often the better fit than directory sync — users authenticate against the existing IdP, and Cloud Identity trusts assertions from that IdP rather than maintaining a full synced copy of every user attribute.
Azure AD / Okta (Identity Provider) │ SAML assertion ▼ Cloud Identity (Service Provider) │ ▼ GCP Console / gcloud CLI accessHow Identity, Device Status, and Access Actually Connect
The reason Cloud Identity’s device management matters beyond basic compliance checkbox-ticking is that it feeds directly into access decisions elsewhere in GCP — specifically, context-aware access policies that condition resource access not just on who you are, but on the trustworthiness of the device you’re connecting from.
Practically, this means a stolen laptop with disk encryption disabled can be denied access to sensitive resources even with valid, unrevoked user credentials — the device signal is a genuinely independent security layer, not a redundant check on top of password authentication. Organizations that only think about identity in terms of “who logged in” and never wire device compliance into access policy are leaving a meaningful portion of Cloud Identity’s actual security value unused.
Real-World Use Case: Contractor and Partner Access
A common scenario: a company needs to grant a small number of external contractors scoped access to specific GCP projects, without issuing them full company email accounts or granting broad organizational access. Cloud Identity supports this through a dedicated org unit for external users, with tightly scoped group membership and IAM bindings limited to exactly the projects those contractors work on, and device policy requirements that are more lenient than employee-owned devices but still enforce baseline security (screen lock, no jailbroken devices). This pattern keeps external access auditable and revocable through a single group membership change, rather than a scattered set of ad-hoc individual grants that are easy to lose track of when a contract ends.
Best Practices
- Manage IAM access through groups, never individual users. This is the single highest-leverage habit for keeping access reviews manageable as an organization grows — auditing group membership scales; auditing hundreds of individual IAM bindings does not.
- Enforce 2-step verification organization-wide, not just for admin accounts — credential compromise is still one of the most common initial access vectors in real incidents.
- Use org units to segment policy, not just for org-chart tidiness. A finance org unit with stricter device compliance requirements than a general engineering org unit is a real security control, not just administrative organization.
- Treat GCDS or SSO federation as critical infrastructure, not a one-time setup task — a sync job silently failing for weeks means new hires and departures aren’t reflected in Cloud Identity, which is a genuine access control gap.
- Monitor sync jobs the same way you’d monitor any production system — an alert on GCDS failure, not a manual check someone remembers to do occasionally, is what actually catches a silent break before it becomes an audit finding months later.
Common Mistakes
Managing GCP access through individually created Google accounts instead of Cloud Identity. This is common in smaller organizations that started with a handful of engineers using personal or ad-hoc Google accounts and never migrated to a real identity system — it works until an employee leaves and nobody has a clean way to revoke every access grant they accumulated over time.
Treating GCDS sync failures as low priority. A silently broken sync job means offboarded employees can retain Cloud Identity access long after they’ve left, which is exactly the kind of gap that shows up in a security audit finding.
Confusing Cloud Identity’s device management with a full mobile device management (MDM) solution. Cloud Identity’s device policies are genuinely useful but more limited than dedicated enterprise MDM platforms — organizations with complex device management needs (kiosk mode, granular app whitelisting) often need it as one layer alongside, not instead of, a purpose-built MDM tool.
Editions and What They Actually Add
Cloud Identity ships in Free and Premium editions, and the difference isn’t cosmetic — it determines whether the platform can be a serious enterprise identity foundation or stays a lightweight directory for a small team.
┌───────────────────┬──────────────────┬─────────────────────────┐│ Capability │ Free │ Premium │├───────────────────┼──────────────────┼─────────────────────────┤│ Users │ Capped │ Unlimited ││ Basic SSO / SAML │ Yes │ Yes ││ Advanced device mgmt│ No │ Yes (app management, ││ │ │ Windows/Chrome policies) ││ Security center │ No │ Yes ││ Data regions │ No │ Yes │└───────────────────┴──────────────────┴─────────────────────────┘Teams frequently start on the Free edition during early adoption and hit the user cap or the lack of advanced device policy right around the time they’d want it most — during a security review or compliance audit. Budgeting for Premium before that point, rather than reactively upgrading under pressure, is worth planning for if the organization is on a clear growth trajectory.
Frequently Asked Questions
Do I need Google Workspace to use GCP? No — Cloud Identity provides the full identity and access management layer GCP needs without requiring a Workspace subscription.
Can I upgrade from Cloud Identity to Google Workspace later without re-provisioning users? Yes — because Cloud Identity and Workspace share the same underlying directory, upgrading adds the productivity app layer on top of existing users and groups rather than requiring a migration.
Is Cloud Identity free? Google offers a free edition with a per-user cap suitable for smaller organizations, alongside a paid Premium edition that adds advanced device management, security features, and higher user limits — check current limits before assuming the free tier covers a growing organization indefinitely.
How does Cloud Identity relate to Firebase Authentication? They’re unrelated for most purposes — Firebase Authentication is for authenticating end users of your own application (customers), while Cloud Identity manages your organization’s internal users and their access to GCP itself. Conflating the two is a common early architecture mistake.
What happens to IAM bindings when I delete a Cloud Identity user? Bindings tied to the deleted principal become dangling references — GCP doesn’t automatically clean these up, so periodic IAM policy audits should include checking for orphaned bindings referencing deleted or suspended accounts, not just reviewing active grants.
Summary
Cloud Identity is the unglamorous but foundational layer that answers “who is this person and what groups do they belong to” — a question that has to be answered correctly before IAM’s authorization model can do its job. The organizations that get the most value from it are the ones that resist the temptation to manage access through individually created accounts and instead invest early in proper group-based access management and a reliable sync (or federation) path from whatever directory already holds the organizational source of truth. That investment pays for itself the first time an employee leaves and access revocation is a single group membership change instead of an audit-triggering scramble across a dozen disconnected systems and forgotten grants.