When GeoIP policies in authentik decide who gets in
A security or IAM lead who needs to restrict logins by location or flag implausible travel between sign-ins will use authentik's GeoIP policy. According to the authentik policies documentation, this policy allows or denies requests by country or ASN, and it can also check the distance from recent logins and detect impossible travel. Since authentik 2022.12, the GeoIP database is bundled, and authentik loads /geoip/GeoLite2-City.mmdb by default, so the policy works without extra setup on a fresh install.
The policy is one step in a flow, not a standalone control. A GeoIP policy only decides something when it is bound to a stage or flow that uses its result, such as a login flow that denies the request or a stage that asks for a second factor. Before going live, confirm which flows the binding applies to, what the deny or challenge path looks like for a user, and whether service accounts or API clients will be caught by the same rule. Test each binding with a sign-in from an expected location and from an unexpected one, and record how authentik responds in each case.
The bundled database is a starting point. Country and ASN lookups depend on the accuracy of the GeoIP data, and mobile carriers, VPN exit nodes and corporate proxies can all place a legitimate user somewhere unexpected. Plan a review step for false positives, and decide who approves changes to country or ASN lists. If you mount /geoip to update the file from outside the container, authentik reloads it when the file changes, so confirm how your team sources and validates new database files and who is responsible for keeping them current.
Which GeoIP checks authentik offers
The GeoIP policy in authentik can allow or deny requests by country or ASN, and it can also check distance from recent logins and impossible travel. Each check reads a different signal, so each fits a different point in a flow and fails in a different way. Confirm exact field names and behavior in your authentik version before you build rules around them.
Country checks
A country check reads the country that the GeoIP database assigns to the client IP address and allows or denies the request based on that result. It is the simplest rule to write and explain to auditors, and it works well as a first filter on a login or authorization flow. It cannot tell you whether the user is actually in that country, because VPNs, proxies and mobile carriers can place a legitimate user somewhere else. Confirm how your version handles unknown or private addresses before you deny by country.
ASN checks
An ASN check uses the autonomous system number that identifies the network operator announcing the client IP address. It can separate traffic from a residential ISP, a corporate network or a hosting provider, which country data alone cannot do. An ASN does not identify the person or device, and large providers serve many customers, so an ASN block can also catch legitimate users. Confirm the ASN field name and how the database maps to organizations in your version.
Recent login distance
The distance check compares the geographic location of the current request with the location of recent successful logins for the same user. It uses the coordinates the GeoIP database returns, so its accuracy depends on the database and on how precisely it places an IP address. It is useful for challenging a login that is far from the user's usual locations. It cannot measure physical distance traveled in real time, and an IP-based location can be off by a wide margin. Confirm how many recent logins the check considers and where it sits in your flow.
Impossible travel
Impossible travel checks whether the distance between two logins, divided by the time between them, implies a speed no person could travel. A pair of logins from distant cities minutes apart is the typical trigger. This check depends on the same location data as the distance check, so a wrong city placement can create a false alarm, and a VPN exit can hide real movement. Plan a challenge, such as a second factor, rather than an outright block, and confirm the time window and speed threshold in your version.
Configuration options and when each fits
This table compares the main design choices for GeoIP and impossible travel checks in authentik: how the policy responds, how it matches location, and where it is bound. Read each row as a trade-off, since stricter settings block more attackers but also more legitimate users behind VPNs, proxies and carrier networks. The main takeaway is to start with the least disruptive response on consumer-facing flows and reserve hard denies for narrow, well-understood cases.
| Choice | Option | Trade-off | When it fits |
|---|---|---|---|
| Response | Deny the request | Blocks immediately, but a false match gives the user no path forward inside the flow. | Countries or networks with no legitimate users, such as administrative access from outside approved regions. |
| Response | Challenge through a stage | Adds MFA or another verification step, so legitimate users with unusual locations can still sign in. | Consumer apps and mixed populations where location signals are useful but not certain. |
| Match method | Country allow list | Everyone outside the list is refused, so any country missing from it becomes an outage for those users. | Workforces that operate from a small, known set of countries and have few remote exceptions. |
| Match method | Country deny list | Easier to start with, but it only stops the countries you named and tends to grow over time. | Blocking specific high-risk regions while leaving the rest of the user base unaffected. |
| Match method | ASN checks | Corporate egress networks are stable and identifiable, but VPN and cloud providers share ASNs with other customers. | Corporate or partner networks with known ASNs, where access should follow the organization's network. |
| Match method | Country checks | Broader and simpler to explain, but mobile carriers and VPN exit nodes can place legitimate users in unexpected countries. | Consumer applications where a coarse regional signal is enough to trigger a challenge. |
| Scope | Bound to a specific flow | Limits the effect to the login or recovery path you chose, which makes testing and rollback easier. | Admin logins, high-value applications or a single sensitive recovery path. |
| Scope | Bound to a broader flow | Covers more entry points, but a single false positive can affect every sign-in path the flow serves. | Organization-wide protection where every authentication route must be checked, after staged testing. |
Setting up a GeoIP policy with checks
This sequence takes a GeoIP policy from a confirmed database file to a tested, logged rule that allows or challenges logins by location before it is enforced on real users.
Confirm the GeoIP database is mounted
Check that the GeoIP database file is present in the container at the path authentik loads by default, or that the /geoip directory is mounted from the host so you can update the file outside the container. The bundled database is GeoLite2-City.mmdb, and authentik reloads the file when it changes if you mount the directory. Your platform engineer does this on the host or in the Helm values, and the check is complete when the server container lists the file and the server logs show it loaded without errors. Confirm the license terms and update source for the database with your own compliance owner before you rely on it.
Create the GeoIP policy with its rules
In the authentik admin interface, create a GeoIP policy under the policies section and set the rules you need: allowed or denied countries, allowed or denied ASNs, or a check on distance from recent logins and impossible travel. Start with a narrow rule, such as a single country you already know your users come from, so the effect is easy to read. The policy is done when it appears in the policy list with the settings you chose, and you have written down each rule and the reason for it.
Bind the policy to the right flow or application
Attach the policy to the specific authentication flow or application binding that should enforce it, rather than to every flow by default. Use a binding order and a test group so that only the intended population is affected at first. Confirm the binding in the flow or application view and check that it does not sit in front of the recovery or administrator flows, where a block could lock people out. The step closes when the binding shows the policy, the order is set, and the scope is recorded.
Test the policy with known locations
In a non-production instance, sign in from locations you can control, such as a home connection, a corporate office, a mobile network in another country and a VPN exit. Confirm that each login evaluates the policy as you expected, allowing the known location and denying or challenging the test location. Also run a sequence of logins from distant places in a short period to see whether the impossible travel check triggers. The step is complete when your test results match the rule you wrote for every location, and any mismatch has a recorded cause.
Check the policy result in logs
Open the event and log views for the test logins and read the policy evaluation for each attempt. Look for the country, ASN and distance values that authentik recorded, and confirm that the database lookup returned a location for each address. Compare these values with the locations you actually used. Where a login has no location, treat that as a finding to resolve before enforcement, because a missing lookup changes the outcome of the rule. The step is done when every test login has a readable, expected result in the logs.
Test the database failure path
Temporarily make the GeoIP file unavailable in the non-production instance, such as by pointing the mount at an empty directory, and repeat a few test logins. Record what happens to each login and whether the server logs report the missing database. Use this result to decide how the policy should behave in production and who is alerted if the file disappears after an update. Restore the file afterward and confirm the policy evaluates normally again. The step closes when you have a written record of the failure behavior and the recovery check.
Enable enforcement after log review
After the test results and log review are accepted by the security owner, move the policy from a test binding to the production flow, keeping the original binding order and scope. Watch the first real logins through the event log and be ready to remove the binding if legitimate users are blocked. Document who approved the change, the rules in force and the rollback steps. Enforcement is complete when the production flow shows the policy, the first logins evaluate as expected, and the change record is filed.
Keeping the GeoIP database current without breaking logins
authentik loads its GeoIP database from `/geoip/GeoLite2-City.mmdb` by default, and the file ships inside the image since authentik 2022.12. That default is fine for a first test, but it means updates only arrive when you upgrade authentik. To refresh the database on your own schedule, mount a host directory at /geoip in both the server and worker containers, place the updated GeoLite2-City.mmdb there, and let authentik pick it up. According to the GeoIP documentation, authentik reloads the file when it changes, so a refresh does not require a restart. Confirm this behavior against the version you run, using the GeoIP documentation as the reference.
Assign one owner for the update process, usually the team that runs the identity platform, and write down who fetches the file, where it is stored and who checks it after each change. Confirm the refresh cadence with your database provider and your own risk team, since the facts available to us do not set one. Also confirm the licensing terms of the database you use, including redistribution and internal use rules, before you mount it into a shared image or backup set. Keep a copy of the previous file so you can roll back quickly if a new file misclassifies large groups of users.
To verify a reload, change the file in a test environment, then sign in from a known country and check that the GeoIP policy's decision matches what you expect. Watch the server and worker logs for a message showing the file was loaded, and confirm that the file's owner and permissions let the container process read it. If the file is missing or unreadable, test the flow before production, because the policy behavior depends on that database being present. Record each update with its date and source so that an auditor or incident responder can tie a login decision to the database that was in use at the time.
What breaks when the GeoIP database is missing or stale
GeoIP and impossible travel rules depend on a database lookup for every request, so a missing, unreadable or outdated file changes decisions silently. The cards below cover the failure modes that matter most, the signal to watch for each one, and the test to run before go-live.
Missing or unreadable mmdb file
authentik loads /geoip/GeoLite2-City.mmdb by default, so a container that starts without that file, or with a file the process cannot read, is the first thing to rule out. Check that the path exists inside both the server and worker containers and that file permissions allow the authentik user to read it. Confirm in the logs that the database loaded at startup. Treat a failed load as a deployment defect, not a cosmetic warning, because GeoIP policies cannot evaluate without it.
Outdated database misplaces addresses
IP geolocation data drifts as address blocks change hands, so an old database can place a legitimate user in the wrong country or city. Impossible travel checks are especially sensitive, because a stale city coordinate can make a normal login look like a fast move between two places. Ask who owns the database update process, how often it runs, and how you would notice a sudden rise in denied logins from one region. Record the database build date in your change log.
Carrier-grade NAT and VPN egress
Many users can share one public IP through carrier-grade NAT, and corporate VPNs or cloud proxies can exit in a different country from where the user sits. A country rule may then block a whole mobile carrier, and a distance check may flag a user who has simply switched between a VPN exit and a home connection. Review the policy against known egress ranges and ASNs before you deny anything. Use challenges where the decision is uncertain, and reserve hard denies for clear cases.
Session binding on a changing client IP
Session binding that ties a session to the client IP depends on that address staying stable for the life of the session. Mobile networks, Wi-Fi roaming and VPN reconnects can change the source address mid-session, which can end a session the user never meant to lose. Decide whether the binding is needed for each application and set the session lifetime with that in mind. Test a session from a laptop that switches networks during a sign-in.
Lookup failures and fail-open behavior
When a lookup fails, the outcome depends on how the policy is written and how your flow treats an error, so the result can be an unexpected allow or an unexpected deny. Review each GeoIP binding for the behavior on a missing IP, a private address behind a load balancer, or a reverse proxy that does not forward the client address. Confirm the real client IP reaches authentik through your proxy configuration before you trust any country or distance decision.
Test the failure path before go-live
Run the failure cases in staging before any user depends on the policy. Remove or rename the mmdb file and confirm the behavior and the log message. Sign in through a VPN exit in another country, from a mobile network and from a second device to see which decisions change. Keep a short list of test accounts and expected outcomes, and rerun it after each database update or authentik upgrade.
Questions buyers ask about GeoIP and impossible travel in authentik
Is the GeoIP policy included in the open-source edition of authentik?
The GeoIP policy is part of the core policy engine and is documented in the authentik policies and GeoIP documentation, but you should confirm its edition status yourself before you plan around it. The pricing page lists enterprise-only features separately, and the named items there are Google Workspace and Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. GeoIP is not on that list, so it does not appear to be an enterprise-only feature. Check the current pricing page and the repository license before you commit, because the MIT license covers most of the code while the enterprise directory has its own license.
What drives the cost of a GeoIP and impossible travel implementation?
The main cost driver is how many business rules you need and how many applications they must cover. Costs come from four areas: deciding which countries, ASNs and travel patterns should be allowed, challenged or denied; building and binding the policies to the right flows and applications; testing them against real traffic paths including VPNs, mobile carriers and remote offices; and handing the result to your operations team with runbooks. Ongoing costs are mostly database updates, review of denied-login reports and tuning. A fixed-scope quote follows from a written list of rules, flows and applications, so ask for each of those to be itemized.
Can our in-house team configure GeoIP and impossible travel policies on its own?
Yes, a team that already runs authentik can usually build the basic policies from the documentation, because the setup is a set of policy objects bound to flows. The harder part is the judgment: choosing thresholds for distance and time, deciding how to treat shared corporate egress IPs, and making sure a denial does not lock out legitimate users during travel. Teams without prior authentik flow experience should plan for more review time. A common split is to build internally and bring in a partner for a security review of the rules, or the reverse if your identity engineers are already stretched.
What do we need to provide before a GeoIP pilot can start?
A pilot needs five inputs from your side:
- Visibility of the network path, so the team knows whether client IPs reach authentik directly or through a load balancer or reverse proxy that must forward the real address.
- Test accounts in several countries or networks, including at least one mobile connection and one VPN path.
- Access to authentik and proxy logs, so denied and challenged logins can be reviewed.
- Written business rules for which countries, ASNs and travel patterns are allowed, challenged or denied, and who approves exceptions.
- A named owner for the GeoIP database file on the host or container, because updates must be applied and checked.
How long does a GeoIP pilot take in our change windows?
Duration depends on your change calendar, not only on the technical work. The configuration itself is small, but each change to a production login flow usually needs a window, a rollback plan and a monitoring period afterward. Plan the pilot as a sequence: a test environment run, a limited production group in a monitored window, then a wider rollout. Ask your change board how many windows a month they approve for identity changes, and build the pilot around that. No fixed duration is set here, so confirm the schedule with your own change and security teams before agreeing dates.
What breaks if the GeoIP database is missing or out of date?
authentik loads the GeoLite2-City database from /geoip/GeoLite2-City.mmdb by default, so a missing file means country and location checks have no data to evaluate. Test the failure mode before go-live: confirm how your policy behaves when the lookup returns nothing, and make sure that behavior matches your rules. An outdated file gives wrong answers for recently reassigned IP ranges. Mounting /geoip lets you update the file from outside the container, and authentik reloads it when the file changes. Monitor the file age and the presence of the file as part of your health checks.
When should we bring in a partner for GeoIP and impossible travel controls?
Consider a partner when the rules affect regulated access, when many applications share one login flow, or when your team cannot test from realistic network paths. A partner is also useful when a denial policy could lock out executives, clinicians or field staff during travel. DeployOpen plans and implements authentik inside your own infrastructure, runs security testing of the resulting login flows, and prepares evidence for compliance assessments. It does not issue audit reports or certifications. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that scope.
Does impossible travel detection need session binding to work well?
Impossible travel checks compare the location of a recent login with the current one, so they depend on stored login history and the IP address of each request. Session binding is a separate control that ties a session to properties such as the client context, which helps stop a stolen session cookie from being reused elsewhere. Confirm with your authentik version's documentation how session behavior and binding settings interact before relying on both together. Test with a deliberate location change to see what the user experiences and what the logs record.
How DeployOpen scopes and delivers GeoIP policy work
DeployOpen treats GeoIP and impossible travel rules as access decisions that need a written scope, a tested build and a handover your team can run. We plan the country, ASN and travel thresholds with your security and business owners, then build and verify them inside your own authentik deployment.
How we scope
- Engagements are fixed-scope, with the written scope agreed before any work begins.
- The scope lists which applications and flows the GeoIP rules will bind to, and which users are exempt.
- We record the allowed countries, ASNs and travel thresholds, and who approves changes to them.
How we build
- We configure the GeoIP policy and bindings in a non-production authentik instance first.
- We confirm the GeoIP database mount, update method and reload behavior in your environment.
- We test allowed, denied and challenged logins, including VPN and mobile network sources, before go-live.
How we hand over
- Deliverables include a written policy map, the database update procedure and the rollback steps.
- Your operators receive a runbook for reviewing denied logins and handling false positives.
- We document the session binding settings and the behavior you should expect if the database is missing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover re-testing of GeoIP rules after authentik upgrades and policy changes.
- Ask us to confirm scope, deliverables and timelines in writing before choosing a support model.
