Recovering from a country-based lockout, and why it happened
A country-only network zone used to never match, and an exclude condition built on one silently denied everyone. Both are fixed. What changed, and the one confirm-and-override dialog that is not built yet.
This article explains an incident class that has now been closed, in plain terms, because it is the kind of thing you deserve to hear from us rather than discover the hard way. If you have a network zone or a sign-on policy that names a country, read this before you touch either one again.
What could go wrong before this fix
A network zone can be built to match a country — for example, a zone listing every EU country code. Before this fix, nothing on the sign-in path could actually resolve a client address to a country at all. There was a table an administrator could populate by hand with address-to-country mappings, but nothing else, and if it had no entry for a given address, the country was simply unknown for that sign-in.
A country-only zone therefore never matched anybody, ever, for any address it hadn't been manually told about. That on its own is a quiet failure — the zone does nothing, silently — and by itself is not dangerous.
What made it dangerous is a second, separate defect. A sign-on policy can be written to exclude a zone: "deny sign-in from everywhere except this zone." The system read "we could not confirm this address is in the zone" as "we have confirmed this address is not in the zone." For an exclude condition, that is exactly backwards: it means the policy denied everyone, including people genuinely inside the zone it was supposed to allow, because the country could never be confirmed for anyone. A policy meant to protect one part of your organisation instead locked out the whole thing, indiscriminately — the legitimate person in the country and an attacker on the other side of the world were treated identically.
How a country is resolved now
Three sources are tried in order, and the first one that answers wins:
- Your own IP-intelligence entries, if you populated any by hand. This still wins when present, exactly as before.
- The
CF-IPCountryheader, when your traffic is fronted by Cloudflare. This is new. The header is trusted only when the request reached us through a proxy you have configured as trusted — a caller that reaches the platform directly cannot simply claim a country any more than it could claim an address. Cloudflare's own "unknown" and "Tor" markers are rejected outright rather than treated as real countries. - An optional MaxMind database (GeoIP2 or GeoLite2), if your deployment has one configured, as a second, independent source.
If none of the three can answer, the country is still genuinely unknown for that sign-in — that has not changed, and cannot be made to change without one of the three sources actually knowing. What changed is what an unknown country now means to a policy, which is the fix that actually closes the incident.
The fail-safe rule, fixed in both directions
A zone that cannot be resolved for a given request is now recorded honestly as unresolvable, and treated the same way regardless of which side of a condition it sits on:
| Zone named in | What it does when unresolvable |
|---|---|
include | Never grants. "We couldn't confirm you're in it" cannot be read as "you're in it." |
exclude | Never denies. "We couldn't confirm you're not in it" cannot be read as "you're not in it." |
In both cases the whole condition is treated as not matching, and the event is reported — not silently absorbed. It appears on the sign-on decision trace as a network warning naming the policy and the zone, so an administrator reviewing why a sign-in was allowed or denied can see "this zone could not be resolved for this request" as a first-class fact, rather than a country condition just quietly doing nothing. The same warning is also written to your audit log, rate-limited to once per organisation per policy per hour so it cannot flood you.
The new check: would saving this lock out the person saving it
A separate, existing guard already refused to save a sign-on policy that would strand every administrator of the organisation, checked from two synthetic positions (inside no zone, and inside every zone the organisation has defined). That guard is unconditional — there is no override — and it is still in force. It did not catch this incident, because its "inside every zone" synthetic position happened to include the newly created country zone, so it concluded a safe position existed even though no real sign-in could ever actually land in that zone before this fix.
A new, second guard now runs alongside it: when you save a sign-on policy, the platform checks it against your own live, real network position — your actual address, your actual resolved country, the actual zones you're sitting in right now — not just the synthetic "everywhere / nowhere" check. If saving the policy would lock you out personally, the save is refused with HTTP 409 and a message naming the problem.
One more honest limit on this second guard: when Sentinel-Q proposes a sign-on policy change on your behalf, the check runs against the same conservative "outside every zone" position the original all-administrators guard uses, because there is no live network request to evaluate at that moment — and the AI's own proposal payload cannot set the override field at all. Only a human, resubmitting the request from a real browser session, can confirm past this guard.
What to actually do
Check whether you have a country-only zone or an exclude-on-country policy
If you built one before this fix landed, it either did nothing (an include-based rule) or was actively denying more people than you intended (an exclude-based rule). Re-open it and re-read what it is meant to do.
Confirm Cloudflare is actually fronting your traffic
Country resolution via the header only works when the request reaches the platform through a trusted proxy that is genuinely forwarding a real
CF-IPCountryvalue. If you're not certain, ask us to confirm your deployment is configured this way before you rely on a country condition for anything that denies.Watch the network-warning entries on the decision trace for a week before tightening anything
See Sign-on policies and the decision trace for how to read a trace. If you're seeing frequent "zone could not be resolved" warnings, your country resolution isn't as reliable as you'd want for a hard deny yet.
Keep a real route back in
The rollout advice in Network zones — an emergency access account, a second administrator on a different network, testing before you tighten — applies here without qualification. This incident is exactly the shape that advice exists to prevent.
If you are locked out of your own console right now by a policy that predates this fix, the recovery path has not changed: reach the console from an address the policy does not cover, or contact us — see A locked-out tenant.