# 47 Deny-by-default IP/geo gating

> v0.1.2 · role: Prevent · edition: Ent Std+, Edu Std+, Frontline Std+, Ent Ess Plus · [policy: #4 · #14](https://docs.google.com/spreadsheets/d/1nOztaPd1Y7eNeRSR_hdovYy-ncpx-bAx/edit?usp=sharing&ouid=115159875779023172526&rtpof=true&sd=true)

An allow-list posture at the network layer: a Context-Aware Access level enumerates the countries and IP ranges you actually operate from, plus device conditions that keep it from being purely geographic, and it is applied through the three default policies on CAA General settings — Google-owned apps, SAML apps, OAuth apps — so an app enabled next month is covered without anyone remembering to add it. The deny-by-default comes from allowing a short list, not from writing deny rules.

Documentation: [Protect your business with Context-Aware Access](https://knowledge.workspace.google.com/admin/security/protect-your-business-with-context-aware-access)

## Caveats

- Selecting an access level sets it to Monitor mode by default — it simulates without blocking, and an assigned-but-monitored level looks identical in the console to an enforced one, so check the mode, not the assignment. Do not use Warn either: it does not reliably surface to the user, and converting a policy to Warn silently drops the apps that do not support it.
- Lock-yourself-out risk — assign the level to the Admin console last, and keep the break-glass admin (№20) exempt from the OU the level applies to.
- CAA does not cover every access path — legacy IMAP/POP, some native and desktop clients and service-account traffic can bypass it, so disable legacy auth (№33) first or the geo-fence has a side door.
- A commercial VPN endpoint inside your allowed region defeats geography — the device-policy conditions are what carry the weight.
- Enterprise Standard+, Education Standard+, Frontline Standard+, Enterprise Essentials Plus and Cloud Identity Premium — expect this screen to be absent on a Business tier tenant.

## Setup steps

1. Create an ALLOW level enumerating the countries/IP ranges you actually operate from — the deny-by-default posture comes from allowing a short list, not from writing deny rules. — `Security › Access and data control › Context-Aware Access › Access levels`

   Basic mode; Condition = IP subnet in CIDR (office/VPN egress) OR Region in {GB, DE, …}; Attribute match = ALL

   docs: [Create Context-Aware access levels](https://knowledge.workspace.google.com/admin/security/create-context-aware-access-levels)

2. Add the device conditions that make the level meaningful rather than purely geographic (a VPN defeats geography alone). — `Security › Access and data control › Context-Aware Access › Access levels`

   - **Device policy** = company-owned / encrypted / screen-lock ON

   docs: [Create Context-Aware access levels](https://knowledge.workspace.google.com/admin/security/create-context-aware-access-levels)

3. Apply the level through the three default policies on Context-Aware Access > General settings (Google-owned, SAML, OAuth apps) instead of enumerating apps — a per-app assignment leaves every later-enabled app as an open door around the level, a default policy does not. The Google-owned default policy does not apply to the Admin console — it needs a separate, deliberate assignment. — `Security › Access and data control › Context-Aware Access › General settings`

   - **General settings: all three default policies** = the allow level

   docs: [Assign access levels to Google-owned apps](https://knowledge.workspace.google.com/admin/security/assign-access-levels-to-google-owned-apps) · [Apply a default Context-Aware Access policy for all SAML apps](https://knowledge.workspace.google.com/admin/security/apply-caa-policy-for-all-saml-apps)

4. Ramp the action: Monitor first, read the audit log for who would have been blocked, then and only then Active (Active blocks users who don't meet the level). Do not use Warn — it does not reliably surface to the user, and converting a policy to Warn silently drops the apps that do not support it. — `Security › Access and data control › Context-Aware Access › General settings`

   Action ramp: Monitor → (after review) Active

   docs: [Assign Context-Aware Access levels to apps](https://knowledge.workspace.google.com/admin/security/assign-context-aware-access-levels-to-apps)

## Ongoing maintenance

- **[requires a human]** On travel/office changes: update the allowed set before the trip, and remove it after.
- **[automatable: AI agent]** Weekly: review CAA denial logs for legitimate users caught by the fence.

## How to verify

1. Sign in as a test user via a VPN egress in a non-allowed country — the CAA log must show the block (or the would-block while still in Monitor).

## Settings screens

- Security > Access and data control > Context-Aware Access > Access levels (create the allow-list level)
  - console: https://admin.google.com/ac/security/context-aware/access-levels
  - screenshot: ../screenshots/admin.google.com/ac/security/context-aware/access-levels.png
- Security > Access and data control > Context-Aware Access > Assign access levels to apps
  - console: https://admin.google.com/ac/security/context-aware
  - screenshot: ../screenshots/admin.google.com/ac/security/context-aware.png
- Security > Context-Aware Access > General settings (default policies for Google-owned, SAML and OAuth apps)
  - console: https://admin.google.com/ac/security/context-aware/settings
  - screenshot: ../screenshots/admin.google.com/ac/security/context-aware/settings.png