Cloud Identity is Google’s identity-as-a-service product: a managed home for the users, groups and security settings of an organization.

The problem it solves

Every system that holds valuable data needs to know who is asking. In the early days of Google Cloud, people simply used personal Gmail accounts. That worked for hobby projects, but it is a disaster for companies. The company cannot reset a personal account, cannot force strong sign-in rules, cannot remove access when an employee leaves, and cannot prove who did what. The company does not truly own those identities.

Cloud Identity fixes this by letting a company own its identities. You prove that you own a domain name, such as your company’s web address. From then on, accounts under that domain are managed accounts, controlled by your administrators. You can create them, suspend them, force two-step verification, and delete them. When you leave the Google Cloud world and look at the identity layer, Cloud Identity is the foundation everything else stands on.

What it is used for

Organizations use Cloud Identity to give employees a single sign-in, to organize people into groups, to enforce security rules like two-step verification, to manage laptops and phones, and to connect with thousands of business applications. It also creates the top-level container for all Google Cloud resources, called the organization, which lets security teams set rules for every project at once.

A small vocabulary unlocks the rest of this guide, so learn these eight terms before moving on.

Beginners often confuse these two services, but they answer two completely different questions.

Who are you, and what may you do?

Authentication answers the question “who are you?” It checks a password, a security key or a fingerprint. Authorization answers the question “what are you allowed to do?” It checks rules that say which actions are permitted on which resources. Cloud Identity handles the first question and manages the people. Identity and Access Management, usually called IAM, handles the second question and manages permissions on Google Cloud resources.

The two services meet through names. When an IAM rule says “this group may view this project”, the group named in that rule is one that Cloud Identity created and maintains. If Cloud Identity removes a person from that group, they lose that access everywhere without anyone editing a single IAM rule.

Cloud Identity comes in more than one edition, and choosing wisely affects both cost and security.

Cloud Identity Free

The free edition gives you the essentials: a verified domain, an organization resource, user and group management, basic two-step verification, single sign-on with a catalog of applications and basic security reporting. It is ideal for small teams or for companies that only need an identity layer to use Google Cloud properly. Free licenses are limited in number by default, though the limit can be raised on request.

Cloud Identity Premium

The premium edition adds enterprise controls. These include advanced device management for phones and laptops, context-aware access rules, more detailed security reporting, a secure directory protocol for legacy applications, automatic provisioning to many third-party applications, and additional audit and alerting features. It is charged per user per month.

Google Workspace

Google Workspace is the family of collaboration tools, such as email, calendar, documents and meetings. Workspace already includes the identity features of Cloud Identity. If your company uses Workspace, you do not need Cloud Identity separately, because your users already live in the same directory. Cloud Identity is for organizations that want the identity and security layer without the office tools.

Cloud Identity is made of a few clearly separated pieces that work together like departments in one company.

The big picture

At the center sits the directory, which stores users, groups and settings. In front of it sits the sign-in service, which checks credentials and applies security rules. The admin console is the control room where administrators manage everything. Around these are connectors: directory sync brings people in from a legacy directory, single sign-on connects to an outside identity provider or to applications, and APIs let other tools read and change the directory. On the other side, Google Cloud IAM and the resource hierarchy consume the identities that Cloud Identity produces.

flowchart LR
  HR["HR System or Legacy Directory"] --> SYNC["Directory Sync"]
  SYNC --> DIR["Cloud Identity Directory"]
  ADM["Admin Console and APIs"] --> DIR
  DIR --> AUTH["Sign-in Service"]
  AUTH --> POL["Security Rules and 2-Step Verification"]
  DIR --> GRP["Groups"]
  GRP --> IAM["Google Cloud IAM"]
  IAM --> RES["Projects and Resources"]
  AUTH --> SSO["Single Sign-On to Apps"]
  DIR --> DEV["Device Management"]
        

Each piece in one line

The directory remembers who exists. The sign-in service proves who someone is. The security rules decide how strongly they must prove it. Groups organize people. IAM turns groups into permissions. Single sign-on spreads trust to applications. Device management makes sure laptops and phones are safe. The admin console and APIs allow humans and automation to control all of it.

Everything begins with proving that you own a domain name, and that single step creates the root of your Google Cloud estate.

Verifying the domain

When you sign up, you provide your company domain. Google asks you to prove ownership, usually by adding a special record to your domain’s public settings or by placing a file on your website. Once verified, Google knows your company legitimately owns that name, and it creates the Cloud Identity account for it. The first administrator becomes the first super administrator.

The organization appears

As soon as a verified domain exists, Google Cloud automatically creates an organization resource linked to it. This is the top of the resource hierarchy. Beneath it you can create folders for departments or environments, and beneath those you create projects. Policies applied at the organization level flow down to everything beneath, which is why this node is so important for governance.

graph TD
  DOM["Verified Domain"] --> CI["Cloud Identity Account"]
  CI --> ORG["Organization Resource"]
  ORG --> F1["Folder: Production"]
  ORG --> F2["Folder: Development"]
  F1 --> P1["Project A"]
  F1 --> P2["Project B"]
  F2 --> P3["Project C"]
        

Additional and alias domains

A company often owns several domain names. You can add secondary domains, which let you create users under each name, or alias domains, which give existing users an extra email-style name. Each must be verified.

These three building blocks organize people, and each solves a different problem.

Users

A user is a managed account for a human. It has a name, a primary email-style address, recovery information, a password policy and optional attributes like department and manager. Users can be created one by one, in bulk from a file, through the programming interface, or synced from another directory. They can be suspended, which blocks sign-in but keeps data, or deleted, which removes them after a recovery window.

Organizational units

Organizational units form a tree, much like folders on a computer. You place users in them so that different settings apply to different parts of the company. Contractors might sit in one unit with stricter rules, while the engineering unit gets different application access. Settings are inherited from parent to child unless overridden.

Groups

Groups are about sharing access and communication, not about settings. A group can contain users, other groups and even service accounts. Groups can be marked as security groups, which signals that they are meant for access control, and this label allows them to be used in more features across Google services. Groups can also nest, so a group for all engineers can include a group for backend engineers.

The people who manage identities hold the most dangerous powers in the company, so their roles deserve careful design.

Levels of administrative power

The super administrator can do everything and cannot be restricted. Below that are predefined administrator roles with narrower powers, such as managing users, managing groups, resetting passwords or viewing reports. You can also create custom roles with exactly the privileges you choose, and assign them to specific organizational units so that, for example, a regional helpdesk can reset passwords only for its own region.

Protecting super administrators

Super administrator accounts should be few, named after real people, protected with hardware security keys, and never used for daily work such as reading email. Many companies also keep one or two emergency accounts, often called break-glass accounts, stored securely and used only if everything else fails. Every use of these accounts should trigger an alert.

Most companies already have an identity system, and Cloud Identity is designed to cooperate with it rather than replace it overnight.

Two separate ideas

Two different mechanisms are often mixed up. Provisioning decides how user and group records get into Cloud Identity. Authentication decides where the password or sign-in check actually happens. They can be combined in several ways.

Directory synchronization

Google Cloud Directory Sync is a tool that reads users and groups from a directory such as Microsoft Active Directory or an LDAP server and creates matching records in Cloud Identity. The sync is one way, from your source of truth to Google. You choose which users and groups to include, and you run it on a schedule. Changes made in the source, such as a new hire or a departure, appear in Cloud Identity at the next run.

Federation with single sign-on

With federation, Cloud Identity trusts an external identity provider to check passwords. When a person signs in, Google sends them to the company’s own login page. After they succeed there, the provider sends back a signed message that says “this person is genuine”, and Google lets them in. Google never sees the password. This keeps one place where passwords live and one place where password rules are enforced.

sequenceDiagram
  participant U as Employee
  participant G as Google Sign-in
  participant I as Company Identity Provider
  U->>G: Open Google Cloud console
  G->>U: Redirect to company login
  U->>I: Enter credentials and second factor
  I->>I: Verify identity
  I->>G: Send signed confirmation
  G->>U: Grant access
        

An identity is not a one-time creation. It has a life, and the dangerous moments are the changes.

Why movers are the hidden risk

Most companies handle new hires and departures well but forget movers. A person who has been in five teams over six years may quietly hold access to all five. This is called privilege creep. Automatic lifecycle management, where the human resources system drives account changes, and regular group membership reviews, are the cures.

Passwords alone are weak. Most real attacks begin with a stolen or guessed password, so the second proof matters enormously.

Two-step verification

Two-step verification requires something you know, like a password, plus something you have, like your phone or a physical key. An attacker with only the password is stopped. Cloud Identity can require it for everyone, for specific units, or for specific groups, and can give new users a grace period to enroll.

The strength ladder

Not all second steps are equally strong. A text message code is better than nothing but can be intercepted or tricked out of people. An authenticator app is stronger. A prompt on a trusted phone is stronger still. The strongest options are hardware security keys and passkeys, which are bound to the real website and cannot be fooled by fake login pages.

Session and password controls

Administrators can set how long a signed-in session lasts before the person must sign in again, with special control for Google Cloud sessions so that people reauthenticate regularly before touching sensitive resources. Password rules such as minimum length and reuse limits apply for accounts that use Google passwords. Login challenges can add extra checks when a sign-in looks unusual.

Who you are is only half the story. From where, and on what device, you sign in also matters.

Knowing the device

With device management, laptops, desktops and phones can be registered with the company. Endpoint verification collects basic facts about a computer, such as whether the disk is encrypted, whether a screen lock is set and what operating system version runs. Mobile management can go further by enforcing passcodes, wiping lost phones and separating work data from personal data.

Context-aware access

Context-aware access lets you write rules that combine identity with conditions. A rule might say that people in the finance group may open the finance application only from a company-managed device with an encrypted disk, and only from approved countries. If the conditions are not met, access is denied or limited. This idea is often called zero trust, because no request is trusted just for coming from inside the company network.

flowchart TD
  REQ["Access Request"] --> ID{"Who is the user?"}
  ID --> DEVC{"Is the device managed and healthy?"}
  DEVC --> LOC{"Is the location allowed?"}
  LOC --> RISK{"Does the sign-in look normal?"}
  RISK -->|"All checks pass"| ALLOW["Allow Access"]
  RISK -->|"A check fails"| DENY["Block or Require More Proof"]
        

Cloud Identity can act as the identity provider for the applications your company uses every day.

Modern protocols

Cloud Identity supports two widely used standards for application sign-in. SAML is a long-standing standard in which the identity provider sends a signed message proving who the person is. OpenID Connect is a newer standard built on top of an authorization framework, popular with modern web and mobile applications. Many popular business tools are available in a catalog, and custom applications can be added using either standard.

Automatic provisioning

For many applications, Cloud Identity can also create, update and disable accounts in the application automatically as people join, change teams or leave. This closes a classic gap, where a former employee’s account in some forgotten application remains active for months.

Secure LDAP for older software

Some older applications and devices, such as certain network equipment or file servers, only understand a traditional directory protocol called LDAP. The premium edition offers a secure LDAP service so these systems can check users against Cloud Identity without needing a separate on-premises directory.

The cleanest Google Cloud environments grant almost every permission to groups instead of to individual people.

Why groups win

Granting permissions to individuals does not scale. If thirty people need access to ten projects, you create three hundred separate grants, and when someone leaves you must find every one. With groups, you create a few grants to groups once, and from then on you manage people simply by adding or removing them from the group. Audits become easy because you review group membership instead of thousands of scattered grants.

Naming and structure

A clear naming convention makes groups self-explanatory. Names can reflect the function, such as network administrators or billing viewers, rather than the person or the project, so they remain correct when the project changes. Nested groups let a broad group contain narrower ones, but deep nesting can make it hard to see who really has access, so keep it shallow.

flowchart LR
  U1["User 1"] --> G["Group: Network Admins"]
  U2["User 2"] --> G
  U3["User 3"] --> G
  G --> R["IAM Role: Network Admin"]
  R --> F["Folder: Production"]
        

If you cannot see what happens to identities, you cannot defend them.

The kinds of records

Cloud Identity produces records of administrative actions, such as who created a user, changed a setting or added someone to a group. It also records sign-in events, including successful logins, failures, suspicious attempts and use of second steps. Security reports summarize things like how many users have two-step verification enabled and which accounts are at risk.

Sending identity logs to Cloud Logging

These records can be shared with Cloud Logging, which means identity events can be searched together with Google Cloud activity, kept for longer, exported to analysis systems and used to trigger alerts. This is valuable during an investigation, because a single search can show a suspicious sign-in followed by a permission change followed by a resource deletion.

Alerts that matter

Not every event deserves an alarm. A few are worth immediate attention: a super administrator signing in, a new super administrator being created, two-step verification being turned off, a single sign-on configuration changing, or many failed sign-ins in a short time. These are the footprints of an attacker who has gained a foothold.

Follow one engineer from opening the Google Cloud console to seeing their project.

sequenceDiagram
  participant P as Person
  participant S as Sign-in Service
  participant R as Security Rules
  participant I as IAM
  participant C as Cloud Resource
  P->>S: Present identity and proof
  S->>R: Check device, location, second step
  R-->>S: Decision
  S->>P: Issue session and tokens
  P->>C: Request an action
  C->>I: Check permissions for identity and groups
  I-->>C: Allow or deny
  C-->>P: Result
        

Experienced teams reuse a few proven layouts, each answering a specific organizational need.

Anti-patterns to avoid

Identity is not usually the largest line on a cloud bill, but waste still adds up and the wrong edition can cost either money or security.

What you pay for

The free edition costs nothing but has limits on the number of free licenses, which can be raised on request. The premium edition is billed per user per month and brings advanced device, access and provisioning features. If you already pay for Google Workspace, identity features are included. The exact amounts and limits change, so always check the current official pages before budgeting.

Ways to spend wisely

You do not need to treat everyone the same. Some companies place premium licenses only on people who need the advanced features, such as administrators or those handling sensitive data, and use free licenses for others, within the rules of the product. Others find that the value of device management and context-aware access justifies premium for everyone.

A short checklist of habits that separate calm identity teams from stressed ones.

Best practices

Common mistakes

Stories show how the pieces combine when real organizations face real pressure.

No service is perfect, and a mature team knows both sides before committing.

Choosing your setup

Quick answers to the questions beginners ask most often.

You can start with a personal account, but for any real organization you should use managed identities. Cloud Identity or Google Workspace provides them and creates the organization resource that enables central governance.

Cloud Identity manages who people are, including users, groups and sign-in security. IAM manages what those identities may do on Google Cloud resources. They work together through users and groups.

No. Workspace includes the identity features, so your Workspace directory already provides managed users, groups and the organization resource.

No. Cloud Identity is for people. Service accounts are identities for programs and are managed in IAM.

Yes. You can synchronize users and groups into Cloud Identity and optionally let your existing provider handle sign-in through single sign-on, so passwords stay where they are today.

It can be configured to synchronize password hashes in some setups, but many organizations prefer federation instead so that passwords are never stored in Google at all. Follow current official guidance for your chosen design.

Yes. A user can belong to many groups but sits in exactly one organizational unit.

When the account is suspended or deleted and group memberships are removed, they lose the access granted through those groups. You should also revoke sessions, tokens and any credentials they created.

Changes take a short time to spread, and some tools cache access. Waiting a few minutes or signing in again usually resolves it.

As few as practical, commonly a small named handful plus a protected emergency account, each secured with hardware security keys and monitored by alerts.

It is a way to grant access only when conditions are met, such as a managed device, approved location or healthy security state, in addition to correct identity.

It is a major improvement, but strength varies by method. Use security keys or passkeys for administrators, and combine with device checks, monitoring and good lifecycle practices.

Cloud Identity is the front desk and badge office of Google Cloud. It lets a company own its people’s identities by verifying a domain, creates the organization root that governs every project, and gives administrators one place to manage users, groups, organizational units, devices and sign-in security. It cooperates with existing directories through synchronization and federation, signs people in to thousands of applications, and feeds clean identities and groups into IAM, where permissions are granted. Good designs share the same habits: one source of truth for people, strong second steps for everyone, very few super administrators, access granted to groups, an automated joiner, mover and leaver process, and identity logs watched for warning signs. Companies that treat identity as the foundation, rather than an afterthought, build everything else on solid ground.