# 54 Cloud Identity Free decoy accounts

> v0.1.3 · role: Detect · edition: All (free seats) · [policy: #30 · #33](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

A user account on a free Cloud Identity seat, named to look high-value — an ex-CFO, an svc-backup identity — left discoverable where an attacker enumerates (the directory, a stale group, an old document ACL) and used by nobody. Any successful login or password-recovery attempt against it is hostile by definition, so an activity rule on its login events can page immediately with no false-positive budget to manage.

## Caveats

- A decoy with real group memberships stops being a tripwire and becomes an attack path — grant it nothing, and verify that with GAM rather than assuming.
- Cloud Identity Free seats are capped — confirm you have a spare seat before creating decoys; if the cap is reached, additional free licences can be requested from Google support at no cost.
- The login-alert rule needs only basic activity-rule creation (AND filters, up to 5 conditions), which is available on all editions; only advanced rule features (OR filters, nested conditions, thresholds, custom actions) are gated to Frontline Plus, Enterprise Standard/Plus, Education Plus, Enterprise Essentials Plus, Cloud Identity Premium and Chrome Enterprise Premium.

## Setup steps

1. Create a decoy user on a Cloud Identity Free seat with a name that looks high-value but is never used (e.g. an ex-CFO or a 'svc-backup' identity). — `Directory › Users › Add new user`

   License = Cloud Identity Free; long random password; 2SV enrolled but never used

   docs: [Add an account for a new user](https://knowledge.workspace.google.com/admin/users/add-an-account-for-a-new-user)

2. Leave the decoy discoverable where an attacker enumerates: leave it visible in the directory (contact sharing is an organization-wide Directory setting — [№39](directory-minimization.md); scope per-OU visibility with a custom directory if needed), add it to a plausibly stale group, and list it on an old shared doc ACL.

   Contact sharing on (organization-wide Directory setting; per-OU visibility via custom directories); member of a plausible stale group; listed on an old doc ACL

   docs: [Turn Directory on or off](https://knowledge.workspace.google.com/admin/users/turn-directory-on-or-off)

3. Create an activity rule on user log events scoped to the decoy user — ANY successful login or password-recovery attempt is by definition hostile. — `Rules › Create rule › Activity`

   - **Condition: user log event (login) AND user** = decoy
   - **Severity** = High
   - **Action** = alert center + page

   docs: [Create and manage activity rules](https://knowledge.workspace.google.com/admin/security/create-and-manage-activity-rules) · [User log events](https://knowledge.workspace.google.com/admin/reports/user-log-events)

4. Verify with GAM that the decoy carries no real group memberships or Drive access that could turn it into an actual foothold.

   ```
   gam info user decoy@…
   gam print groups member decoy@…
   ```

## Ongoing maintenance

- **[requires a human]** Quarterly: keep decoys plausible — aged profile photos, group memberships, mail traffic patterns.

## How to verify

1. Attempt a sign-in against a decoy account from a clean browser and confirm the alert fires and routes to the monitored address.

## Settings screens

- Directory > Users
  - console: https://admin.google.com/ac/users
  - screenshot: ../screenshots/admin.google.com/ac/users.png
- Rules (activity rule on decoy login)
  - console: https://admin.google.com/ac/ax
  - screenshot: ../screenshots/admin.google.com/ac/ax.png