Cloud Identity Free provides managed Google identities and core endpoint administration without a paid Google Workspace subscription. It can also establish the identity account required for a Google Cloud organisation resource.
It is not a free version of Workspace. The Free edition does not include Gmail or Calendar, and its user allowance is capped. Google currently documents a default cap of 50 Free edition users and a process for requesting more at no cost. Check the Cloud Identity pricing page before rollout because licensing terms can change.
What the setup gives you
After domain verification and organisation creation, Google Cloud resources can sit in this hierarchy:
Organisation
-> folders
-> projects
-> resourcesIdentity and resource hierarchy solve different problems:
- Cloud Identity manages people, groups, and devices.
- The Google Cloud organisation contains folders and projects.
- IAM policies grant principals access to resources.
- Organisation policies constrain what projects and resources may do.
Creating the organisation does not automatically make access safe. It creates a place where policies and inherited permissions can be managed consistently.
When Cloud Identity Free is a sensible fit
Consider it when all of these are true:
- the organisation controls a public domain;
- administrators need managed identities or groups;
- Google Cloud projects should have a formal organisation parent;
- Gmail and Calendar are not required from this subscription;
- the documented user cap fits, or Google approves a higher cap;
- the team can operate domain ownership, recovery, administrator roles, and policy changes.
It may be the wrong starting point for a solo experiment with one low-risk project. Organisation policies, managed accounts, and project migration add operational work. The benefit appears when central ownership and inherited controls justify that work.
If the domain is already attached to Google Workspace or Cloud Identity, do not create a second account. Identify the existing administrator and organisation first.
Plan identity ownership before signing up
Write down:
- the domain to verify;
- who can change its DNS;
- at least two durable administrator identities;
- recovery channels that do not depend on one employee or device;
- which existing Google accounts use addresses on the domain;
- which projects, billing accounts, Firebase resources, and service accounts may move;
- any organisation policies that should be introduced later.
Domain verification proves control of the namespace. It can also affect how existing unmanaged accounts on that domain are handled. Review Google’s current account-transfer and conflicting-account guidance before inviting users.
Do not make a personal Gmail account the only super administrator. Do not use a shared password for administrator access. Require strong multi-factor authentication and maintain a tested recovery procedure.
Create the Cloud Identity account
Google’s current organisation setup guide is the authority for the console flow. Interface labels may change, so follow the current guide rather than a screenshot checklist.
The sequence is:
- Sign up for Cloud Identity Free using the domain the organisation controls.
- Verify domain ownership using the method Google provides.
- Create and secure administrator identities.
- Confirm the Cloud Identity edition and user allowance in the Admin console.
- Confirm that the Google Cloud organisation resource exists for the domain.
- Add groups and ordinary users only after administrator recovery has been tested.
Use groups for recurring roles such as billing viewers, project creators, or security reviewers. Granting access to a group is easier to audit and revoke than repeating individual bindings across projects.
Understand the Free edition boundary
Google’s edition comparison documents the current Free and Premium capabilities. The Free edition covers core identity, directory, two-step verification, and fundamental endpoint management. It does not include Workspace productivity applications.
Free licensing is site based. Google’s licensing explanation describes how the cap is assigned and increased. Do not publish an internal onboarding plan based on an old “one user” or “unlimited users” claim.
Also distinguish an identity licence from Google Cloud spend. Cloud Identity Free may have no per-user subscription charge, while projects under the organisation can still incur normal Google Cloud and Firebase charges.
Establish the resource hierarchy deliberately
An organisation resource allows IAM and organisation policies to inherit downwards. That inheritance is powerful and can also break workloads.
Start with a small hierarchy based on governance needs, not an elaborate chart:
Organisation
-> Production
-> Non-production
-> Shared infrastructureAdd more folders only when they support a real ownership, policy, or billing boundary. Before enforcing organisation-wide constraints, test them on a non-critical folder or project. Common controls around allowed regions, external principals, service-account keys, and domain-restricted sharing can affect deployments and automation.
Treat project migration as a change operation
Moving a project changes its parent metadata; Google states that resources remain in place. The important risk is inherited state. After a move, the project can lose policies inherited from its old parent and gain policies, IAM access, quotas, or constraints from the new parent.
Google’s project migration overview and migration procedure describe the current permissions and policy checks. Use them as the runbook.
For each project, record:
- current and intended parent;
- project owners and direct IAM bindings;
- inherited IAM bindings at the source;
- organisation policies at source and destination;
- billing account relationship;
- shared VPC, VPC Service Controls, service agents, and cross-project dependencies;
- Firebase and App Hosting integrations;
- deployment identities and external principals;
- rollback owner and validation window.
Run policy analysis before the move. Confirm that both source and destination organisations permit migration. Migrate one low-risk project first, then verify deployments, scheduled jobs, secret access, logging, billing export, and administrator access.
Avoid the external-user shortcut
An organisation resource does not require every collaborator to become a managed Cloud Identity user. Google Cloud IAM can grant roles to supported external principals when organisation policy permits it.
That flexibility is not a reason to grant broad roles to personal accounts. Decide whether a collaborator needs a managed identity, a group membership, workforce federation, or a narrowly scoped external binding. Record the reason and expiry or review date.
Be especially careful with domain-restricted sharing policies. A policy intended to reduce external access can block legitimate CI, support, marketplace, or service-agent identities if introduced without an inventory.
Verification checklist
After setup:
- Confirm two administrators can sign in and use multi-factor authentication.
- Test account recovery without relying on the primary administrator.
- Confirm the organisation, folders, and projects appear under the intended parent.
- Export or review IAM and organisation policies.
- Verify billing links and cost controls.
- Test one deployment and one scheduled workload in every migrated project.
- Verify Secret Manager, service accounts, Firebase, logging, and monitoring.
- Record the Cloud Identity edition, licence cap, and next review date.
Cloud Identity Free is valuable when it supports a specific governance need. The decision should be based on identity ownership and resource controls, not on the mistaken idea that it provides Workspace applications or removes Google Cloud usage costs.