49 Deny-by-default IP/geo gating

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 (№19) 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 (№35) 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. 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.
   open ↗

   

   https://admin.google.com/ac/security/context-aware/access-levels · captured 2026-07-15

   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

2. 2. Add the device conditions that make the level meaningful rather than purely geographic (a VPN defeats geography alone).
   open ↗

   

   https://admin.google.com/ac/security/context-aware · captured 2026-07-15

   Security › Access and data control › Context-Aware Access › Access levels

   Device policy

   company-owned / encrypted / screen-lock ON

3. 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.
   open ↗

   

   https://admin.google.com/ac/security/context-aware/settings · captured 2026-07-15

   Security › Access and data control › Context-Aware Access › General settings

   General settings: all three default policies

   the allow level

4. 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

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).