Before learning any settings, it helps to understand why the origin of a request is worth caring about at all, and why it is also dangerous to trust it too much.

The return address on the envelope

When you send a letter, you write a return address on the envelope. The post office does not check that it is true, but it still tells the reader something. Internet traffic works in a similar way. Every request carries the IP address of the machine that sent it, a number that identifies where on the internet the request came from. From that number, services can work out useful facts: which internet provider owns it, roughly which country or city it is in, and whether it belongs to a home line, an office, a mobile carrier, a cloud data center, or a privacy service.

These facts do not prove who is typing. They suggest how likely a sign-in is to be normal. A sign-in from the company’s office network is very likely normal. A sign-in from a country where the company has no staff and no customers is much less likely to be normal. A sign-in routed through a service whose whole purpose is to hide identity deserves a second look.

Clues, not proof

The most important lesson of this whole guide is that network information is a clue, not a verdict. Clues can mislead in both directions. An honest employee on a business trip, using hotel Wi-Fi in another country, looks unusual. A careful attacker who rents an address in the employee’s own city looks perfectly ordinary. A good design uses network clues to decide how much proof to ask for, and relies on stronger evidence, such as device-bound sign-in methods, to decide who a person really is.

Why zones, and not just a list of addresses?

You could write every rule by typing out addresses one by one inside each rule. That quickly turns into a mess: the same list copied into ten places, one copy forgotten when the office moves, nobody sure which list is current. A zone solves this by giving a name to a set of network locations once, in one place. Rules then say “if the sign-in comes from the Office zone”, and when the office changes address you update a single zone and every rule that uses it is instantly correct.

A network zone is a named collection of network locations. Let us define each word carefully so nothing later feels like jargon.

IP addresses and ranges

An IP address is a number such as one you might see on a router, written as four groups of digits separated by dots in the older format, or in a longer format called IPv6. Every device that talks on the internet has one, at least for the moment. Companies often own a whole range of consecutive addresses. A common way to write a range is with a slash and a number, called CIDR notation, which simply says “this address and all the ones that follow it, up to a certain size”. You do not need to calculate these by hand: the main point is that a zone can hold single addresses, ranges, or both.

What a zone does

In Okta, a zone has a name, a type, and some contents that describe the locations it covers. When a sign-in arrives, Okta works out which address the request came from and checks which zones that address belongs to. Policy rules can then use the result as a condition: “when the sign-in is from the Office zone, do this; when it is from the Blocked zone, do that”. Because the zone is separate from the rule, one zone can be used by many rules.

flowchart LR
    REQ["Sign-in request"] --> IP["Find the client address"]
    IP --> MATCH{"Which zones contain this address or place?"}
    MATCH --> Z1["Office zone"]
    MATCH --> Z2["Partner zone"]
    MATCH --> Z3["Blocked zone"]
    MATCH --> Z4["No zone"]
    Z1 --> RULE["Policy rules use the result as a condition"]
    Z2 --> RULE
    Z3 --> RULE
    Z4 --> RULE
    

What zones are good for

The word dynamic is used in two related ways around network zones. Separating them clears up much confusion.

Meaning one: zones defined by description, not by list

A static zone is a fixed list of addresses that you type in and maintain yourself. If the list changes, you change it. A dynamic zone, in Okta’s own terms, is a zone defined by a description instead of a list. You say “any request from this country” or “any request from this internet provider” or “any request through this category of anonymizing service”. Okta then decides whether a particular request fits that description, using data it maintains. You do not list the addresses, and when the world changes, for example when a provider gets new address blocks, Okta’s data changes and the zone follows automatically.

Meaning two: zones you keep fresh by automation

The second meaning is about how you maintain a static zone. Instead of editing addresses by hand, you can use Okta’s programming interfaces, or tools that apply configuration from files, to update a zone automatically when your real network changes. For example, a script could refresh a zone each night from a list of addresses your cloud provider publishes. The zone is still a list in Okta, but the list is kept current by a machine. People sometimes call this a “dynamically maintained” zone.

flowchart TD
    Q{"What do you want to describe?"}
    Q -- "My own offices and servers" --> S["Static zone: list your addresses"]
    Q -- "A country, a provider, or a hiding service" --> D["Dynamic zone: describe it, Okta supplies the data"]
    Q -- "A network published by a vendor that changes often" --> A["Static zone plus automation to keep it fresh"]
    

Neither is better, they are different tools

Beginners sometimes think dynamic zones are the modern replacement for static ones. They are not. Static zones remain the right choice for networks that you own and know exactly, such as your headquarters. Dynamic zones shine when the thing you want to describe is too large or changes too fast to list, such as “everything in this country” or “all known anonymizing services”. Most real designs use both, side by side.

Okta offers several zone types. Knowing what each can describe lets you pick the right one for each job.

IP zones

An IP zone is the classic static type. You list addresses and ranges that belong together, such as the head office, a branch, a partner, or your cloud servers. An IP zone can also describe two special roles. Gateway addresses are the addresses your own network edge uses when your people go out to the internet, which is what Okta will see. Proxy addresses are trusted proxy servers that sit in front of Okta traffic and pass on the real client address. Setting these correctly matters, because it affects which address Okta believes the person is using, a point the next chapters explore.

Dynamic zones

Okta’s dynamic zones describe network origin by location, such as countries or regions, and by other attributes that Okta can evaluate. The newer form, often called an enhanced dynamic zone, can combine several kinds of description: locations, autonomous system numbers that identify internet providers and large networks, and IP service categories that identify types of services such as anonymizing proxies. The exact names and choices differ between releases, so check what your org offers.

Two purposes: policy and blocklist

Zones are used in two broad ways. A zone for policy is a normal zone that rules can read as a condition. A zone for blocklist is special: requests from a blocklist zone are refused at the front, before ordinary policy rules even run. This makes blocklist zones powerful and dangerous. They are covered in their own chapter.

Location is the most intuitive way to describe a network. It is also the one most likely to surprise you.

How location is worked out

An IP address does not carry a map reference. Companies that build geolocation databases estimate where each address block is used, by combining information about who registered it, where its traffic seems to enter the internet, and other sources. Okta uses such data to guess the country, region, or city for a request. The guess is usually good for country, less good for region, and often rough for city. For mobile phones, the guess may point to the carrier’s hub rather than the person.

When location is right, and when it is wrong

Using location wisely

Because location is an estimate, treat it as a reason to ask for more, not as a reason to refuse. A common good pattern is a pair of zones: one called “Countries we operate in” and one called “All other countries”. Sign-ins from the first follow normal rules. Sign-ins from the second are stepped up to a strong factor, and from a short list of places where the company has no reason to be at all, they may be blocked. Always include a path for honest travelers.

flowchart TD
    A["Sign-in with estimated country"] --> B{"Country group"}
    B -- "Countries we operate in" --> C["Normal rules"]
    B -- "Other countries" --> D["Step up to strong factor"]
    B -- "No-business countries" --> E["Block, with support contact"]
    

Sometimes the useful question is not “which country?” but “which company runs this network?”. Provider zones answer exactly that.

What an autonomous system number is

The internet is made of many separate networks run by different organizations: internet providers, cloud companies, universities, large businesses. Each such network that connects to the wider internet has an identifying number called an autonomous system number, or ASN. You can think of it as a license plate for a network operator. When a request arrives, the address it came from belongs to one of these networks, so Okta can tell you which operator’s network was used.

Why provider information helps

Provider names tell you a great deal about the kind of traffic. Requests from a home broadband provider look like a person at home. Requests from a mobile carrier look like a phone. Requests from a big cloud or hosting company look like a server, not a person sitting at a laptop. Real people rarely type passwords directly from a rented server in a data center, but attack software often runs from exactly such places. A provider zone can therefore be used to treat hosting networks with extra caution, or to recognize the specific provider that your own company or a partner uses.

The limits of provider zones

• Large providers are mixed. A big cloud company hosts both attackers and your own legitimate servers and many honest services. Blocking a whole provider can break legitimate things.
• Companies change providers. A branch that switches internet providers suddenly looks different, and a provider-based rule may stop recognizing it.
• VPN and privacy services use ordinary providers. Many such services rent space at normal hosting companies, so the provider alone may not reveal them.
• Mobile carriers cover enormous populations. Allowing or blocking a carrier affects huge numbers of unrelated people.

flowchart LR
    ADDR["Client address"] --> LOOK["Look up network operator"]
    LOOK --> ASN["Autonomous system: provider identity"]
    ASN --> K{"Kind of provider"}
    K -- "Home or office internet" --> H["Likely a person at a normal place"]
    K -- "Mobile carrier" --> M["Likely a phone, location approximate"]
    K -- "Cloud or hosting" --> C["Likely a server, treat with extra care"]
    

Some services exist mainly to hide where traffic really comes from. Okta can recognize categories of these, which makes them a valuable dynamic clue.

The kinds of hiding services

Privacy and anonymity services have many honest uses, such as protecting journalists, travelers, and ordinary people on public Wi-Fi. They are also a favorite tool of attackers, because they make many different attackers look like they come from a few shared addresses, and hide the attacker’s true location. The main families are the following.

How a dynamic category zone behaves

You pick one or more categories. Okta keeps its own information about which addresses currently belong to those categories, updating as services appear, move, and disappear. When a request arrives, Okta checks whether its address falls inside any chosen category. If it does, the request matches the zone. You never see or manage the actual list of addresses, which is both the convenience and the limitation.

Choosing a response

flowchart TD
    A["Sign-in arrives"] --> B{"Address in anonymizer category?"}
    B -- "No" --> C["Continue with normal rules"]
    B -- "Yes" --> D{"Application tier"}
    D -- "Low" --> E["Allow with MFA, log"]
    D -- "Moderate or high" --> F["Step up to phishing-resistant factor"]
    D -- "Critical" --> G["Deny, alert, explain how to get help"]
    

A blocklist zone is the strongest and most dangerous use of a zone. It acts before any normal rule has a chance to speak.

How a blocklist differs from a policy zone

A normal zone used in a policy rule is only a condition. The rule decides what to do about it, and rules can be written with many other conditions, exceptions, and careful alternatives. A blocklist zone is different. When a zone is marked for blocklist use, requests from it are refused at the front gate, across the organization, before ordinary policy rules are evaluated. It is a blunt instrument, built for clear, high-confidence danger.

flowchart TD
    R["Incoming request"] --> BL{"In a blocklist zone?"}
    BL -- "Yes" --> X["Refused immediately"]
    BL -- "No" --> POL["Evaluate policy rules and conditions"]
    POL --> D["Allow, step up, or deny"]
    

Exempt addresses

Because a blocklist is so blunt, Okta provides a way to exempt certain addresses so they are never blocked, even if they fall inside a blocklist zone. Exemptions protect critical paths: your own offices, your identity infrastructure, your emergency access routes. Think carefully about what must always be reachable, and put exactly that in the exemption, and no more.

Policy zones are usually the better tool

In most cases, a normal zone plus a well-written rule is better than a blocklist. The rule can say “block this for the payment console, but only ask for a strong factor for the intranet”. A blocklist cannot make that distinction; it blocks everything everywhere. Reserve blocklists for the few cases where you truly want a blanket refusal.

To trust a zone, you must know which address Okta is actually looking at. Several things can make that address differ from what you expect.

Finding the client address

When a person opens an Okta sign-in page, the request travels through the internet and reaches Okta. Okta sees the address of the machine that connected to it. If the person is on a normal connection, that address is the person’s own. But many requests pass through other machines on the way: a company web proxy, a cloud security gateway, a content delivery network, or a VPN. Then Okta sees the address of the last machine in the chain, not the person’s own.

Forwarded addresses

To handle this, well-behaved proxies add the original client address to the request in a standard header, often called X-Forwarded-For. Okta can read this header, but it must be careful: anyone can write a false header. So Okta only trusts forwarded addresses that arrive through proxies you have declared as trusted in a zone. This is why IP zones have a place to list trusted proxy addresses. If you do not declare them, Okta uses the proxy’s address, and every user behind that proxy appears to come from the same place. If you declare a proxy you should not trust, an attacker may be able to claim any address they like.

sequenceDiagram
    participant P as Person
    participant X as Company proxy
    participant O as Okta
    P->>X: Request from 198.51.100.7
    X->>O: Request from proxy 203.0.113.9 with forwarded header naming 198.51.100.7
    O->>O: Is 203.0.113.9 a declared trusted proxy?
    O-->>X: Trusted proxy means the forwarded address 198.51.100.7 is used, otherwise 203.0.113.9 is used
    

The order of evaluation

A zone by itself does nothing. Its power comes from the places that read it. Here are the main ones.

flowchart LR
    Z["Network zones"] --> AP["Authentication policies"]
    Z --> GS["Global session policy"]
    Z --> PW["Password and recovery rules"]
    Z --> API["API token network restrictions"]
    Z --> AS["Authorization server policies"]
    Z --> TI["ThreatInsight exemptions"]
    Z --> BL["Blocklist"]
    

Why this reach is both useful and dangerous

The benefit of zones being shared is consistency: one correct definition supports many controls. The danger is the same fact turned around. Editing a zone changes every control that uses it, often in ways nobody remembered. A tiny edit to the “Office” zone can alter how dozens of applications ask for proof, how API tokens work, and which partners are exempt from threat blocking. Before editing any zone, find everything that depends on it.

A handful of well-designed zones beats a hundred improvised ones. A little structure at the start saves years of confusion.

Think in layers

A useful way to design zones is in layers, from most trusted to least trusted. Each layer answers a question, and rules combine them. Keep the number of zones modest and the purpose of each crystal clear.

Naming that explains

Use a naming pattern that tells a reader the type and purpose at a glance, such as a short prefix for the family (NET for your networks, GEO for places, SVC for service categories, ASN for providers) followed by a clear name. Add a short description to each zone stating who owns it, why it exists, and when it was last reviewed. A zone with a vague name and no owner is a future outage waiting for someone to edit it.

Ownership and change control

Give every zone a named owner. Require a second pair of eyes for changes to zones used in the blocklist, in API token restrictions, or in critical application policies. Keep a short history of changes with reasons. Review all zones on a calendar, perhaps quarterly, deleting those no longer used and fixing those that have drifted.

flowchart TD
    A["Need a new zone"] --> B{"Does an existing zone already fit?"}
    B -- "Yes" --> C["Reuse it"]
    B -- "No" --> D["Pick type: static, dynamic, or automated"]
    D --> E["Name by pattern and add owner and purpose"]
    E --> F["Review by second person"]
    F --> G["Test with real examples"]
    G --> H["Use in rules and record the change"]
    

Millions of people work from home. Networks designed for the office suddenly have to cope with a workforce spread across thousands of home connections.

Home workers do not have a stable address

An office has a fixed set of addresses. A home worker has whatever their internet provider gives them, which may change often and is shared with nobody in the company. A zone listing every employee’s home address is impossible. A rule saying “only allow the office zone” would lock out remote staff entirely. So for remote work, network zones are used differently: not to say “this is trusted”, but to say “this is not obviously dangerous“.

Company VPN as a trusted path

Many companies ask remote staff to connect through a company VPN, a secure tunnel into the company network. Traffic then leaves the VPN from a small set of known exit addresses. A static zone listing those exit addresses lets you recognize “this came through our VPN”. Rules can then treat VPN traffic as familiar. Note that a VPN is only as trustworthy as its sign-in, so a stolen VPN credential makes the exit address meaningless as proof. Use the VPN zone to reduce friction, not as a substitute for strong factors.

Split tunnel versus full tunnel

The distinction matters. Under split tunnel, Okta sees the person’s home address when they sign in to cloud applications, and a VPN zone will not match even though the person is connected. If your design depends on VPN exit zones, check how the VPN is configured, and test sign-ins from a real remote laptop with the VPN on and off.

flowchart TD
    H["Remote worker"] --> V{"VPN mode"}
    V -- "Full tunnel" --> E["Sign-in appears from VPN exit address: VPN zone matches"]
    V -- "Split tunnel" --> HA["Sign-in appears from home address: no VPN match"]
    V -- "No VPN" --> HA
    E --> R1["Rules treat as familiar"]
    HA --> R2["Rules rely on device, factor, and risk signals"]
    

Better signals for remote work

Because the network tells you little about a home worker, shift your trust to better signals: whether the device is managed and healthy, whether sign-in uses a device-bound method, and whether the behavior fits the person’s history. Use zones mainly to catch the unusual, such as a sign-in from an anonymizing service or an unexpected country, instead of expecting zones to confirm that remote workers are legitimate.

A company with people who travel, or staff in many countries, cannot treat every unexpected country as an attack. Zones can help treat travel fairly.

The traveler problem

A salesperson flies from Delhi to Frankfurt for a conference and signs in from hotel Wi-Fi. Their location suddenly changes. A rule that blocks unfamiliar countries would lock them out at the worst moment. A rule that ignores country entirely would also let an attacker in from the same unexpected place. The right answer lies between: treat the unexpected country as a reason to ask for stronger proof, not as a reason to refuse.

A fair pattern

The global team problem

If staff routinely work in dozens of countries, the “operating countries” list becomes long, and location tells you little. In that case, location is a weak clue, and the real protection must come from strong factors and device trust. Use country zones to flag the truly odd, not to define the normal.

Not every sign-in is a person. Programs also talk to Okta, and zones are one of the best ways to keep those programs on a short leash.

Machines have predictable homes

A person may sign in from anywhere. A server running an automated job almost always runs from the same place: a data center or a cloud account with a stable set of outgoing addresses. This predictability makes zones a strong control for machines. You can say “this API token may only be used from these addresses”. If the token is stolen and used from anywhere else, Okta refuses it, even though the token itself is valid.

What an API token is

An API token is a secret code that a program uses to prove it is allowed to manage Okta, for example to create users or read logs. Tokens are powerful, since they carry the permissions of the administrator who created them. Restricting a token to a network zone limits where its power can be used from. It does not replace good storage and rotation of the secret, but it shrinks the damage of a leak.

sequenceDiagram
    participant J as Automation job
    participant O as Okta
    participant A as Attacker with stolen token
    J->>O: API call from server zone address
    O-->>J: Allowed, address is in the allowed zone
    A->>O: API call with same token from another address
    O-->>A: Refused, address is outside the allowed zone
    

Keeping server zones accurate

Cloud servers can change outgoing addresses when they are rebuilt or moved. Use a stable arrangement, such as a fixed outgoing address or a managed gateway, and put exactly those addresses in a dedicated server zone. If your cloud provider publishes its address ranges, resist the temptation to allow an entire published range: other customers of the same provider share it. Prefer your own fixed outgoing addresses.

Outsiders who legitimately need access bring networks that you do not control. Zones help you welcome them without opening the whole house.

Why partners need special handling

A partner company’s staff sign in from the partner’s own offices and networks. If you do nothing special, those sign-ins look like strangers from unknown places, and your threat features may even treat the partner’s shared outgoing address as suspicious, particularly if one of their computers is infected. Zones let you describe partners clearly, so you can grant exactly the right level of trust and no more.

A zone per partner, not one for all

Resist a single catch-all “Partners” zone. Different partners have different needs and different risk. A payroll provider needs access to one application; a consulting firm may need several. Creating one zone per partner, named after them, lets you give each the access they need and take it away cleanly when the contract ends. It also makes logs readable: “blocked from Partner-Logistics” tells a story that “blocked from Partners” does not.

Do not treat a partner zone as proof

A partner’s network being in a zone means only that the request came from where you expected. It does not prove which of the partner’s thousands of employees is signing in, nor that their computer is healthy. People at the partner can be phished just like your own staff. Keep strong factors, scoped application access, and device checks wherever you can, and use the zone to reduce unnecessary blocking, not to excuse proof.

Many attacks come in huge, automated waves. Dynamic zones are a handy tool for making such waves harder, though never impossible.

The shape of an automated attack

In credential stuffing, attackers take lists of stolen usernames and passwords from other breaches and try them against your sign-in page, hoping people reused passwords. In password spraying, they try a few very common passwords against many accounts. Both are automated and run from servers or networks of infected machines. They tend to come from cloud and hosting providers, from anonymizing services, and from a modest set of countries, though the exact mix changes constantly.

What dynamic zones add

• Service category zones let you apply extra proof to traffic that arrives through anonymizing services, without maintaining a list of those services yourself.
• Provider zones let you treat sign-ins that come directly from hosting networks as unusual, since real people rarely sign in from rented servers.
• Location zones let you apply stronger checks to places that are not part of your business.
• Threat features such as ThreatInsight add Okta’s wider knowledge of attacking addresses on top of your own zone choices.

flowchart TD
    A["Wave of sign-in attempts"] --> B{"Blocklist zone?"}
    B -- "Yes" --> X1["Refused at front gate"]
    B -- "No" --> C{"Known threat address?"}
    C -- "Yes" --> X2["Blocked or logged by ThreatInsight"]
    C -- "No" --> D{"Anonymizer or hosting zone?"}
    D -- "Yes" --> S["Step up to strong factor, alert on bursts"]
    D -- "No" --> E["Normal rules and risk checks"]
    

The honest limits

Attackers can use residential proxies, rented addresses in your own country, or compromised computers inside your region. When they do, zones see nothing unusual. Dynamic zones raise the cost for lazy attackers and cut down noise, but they cannot protect an account whose password is stolen and whose second factor can be relayed. The reliable defense is a strong factor tied to the real website address. Zones decide who is asked for it more often.

Sometimes thousands of unrelated people share a single address. Rules that treat an address as one person’s identity then go badly wrong.

Many people, one address

The internet has far more devices than available addresses, so providers often make many customers share a single public address, a practice usually called network address translation, or NAT. Large mobile carriers and some home providers use an extreme form called carrier-grade NAT, where thousands of phones may appear to come from the same few addresses. Company offices do the same on a smaller scale: everyone inside appears as one address to the outside world.

What goes wrong

• Collateral blocking. If one bad actor on a shared address triggers a block, thousands of honest users on the same address are blocked too.
• False trust. If an office address is in a trusted zone, any visitor or infected device inside the office inherits that trust.
• Misleading behavior detection. “New address” may mean nothing when the address changes constantly for a mobile user.
• Hotspot surprises. A phone shared as a hotspot gives a laptop the phone’s carrier address, which may look like a different place from the laptop’s usual one.

flowchart LR
    U1["Person A"] --> NAT["Shared public address"]
    U2["Person B"] --> NAT
    U3["Attacker"] --> NAT
    NAT --> OK["Okta sees one address for all three"]
    OK --> Q["A block on this address hits everyone"]
    

A zone that was right last year may be wrong today. Freshness is not a nice extra; it decides whether your rules still match reality.

Why zones go stale

Networks change all the time. A branch moves offices. A provider renumbers its customers. A partner adds a new data center. A cloud migration changes outgoing addresses. Each change makes some zone slightly wrong. A stale “trusted office” zone might include an address that now belongs to a stranger, or fail to include the new office, so your own staff are challenged on arrival.

Three ways to keep zones fresh

A safe automation pipeline

When you automate zone updates, build in safety. Take addresses only from a trusted source of truth, such as your network team’s inventory. Compare the proposed new list with the current one and refuse any change that is suspiciously large, for example one that removes half the addresses or adds an enormous range. Send a notice to the zone owner for every change. Keep the previous version so you can restore it quickly. Limit which accounts and tokens can edit zones, and restrict those tokens to the automation server’s own zone.

flowchart LR
    SRC["Source of truth: network inventory"] --> JOB["Scheduled update job"]
    JOB --> CMP{"Change size reasonable?"}
    CMP -- "No" --> HOLD["Hold and alert owner"]
    CMP -- "Yes" --> APPLY["Apply to Okta zone"]
    APPLY --> LOG["Record change and notify owner"]
    LOG --> ROLL["Keep previous version for rollback"]
    

Detecting drift

Drift is the slow gap between what you intended and what is configured. Detect it by regularly comparing the zones in Okta with your source of truth, by watching for zone changes in the System Log made by anyone other than your automation, and by reviewing which zones have not matched any sign-in for months. Zones that never match are probably obsolete and should be deleted, because stale zones are future mistakes.

A zone change can quietly lock out a whole office or leave a door open. Test before you trust, and test where mistakes cost nothing.

Observe before you enforce

The gentlest approach is to add the zone first and watch. Create the new zone, and attach it to a rule that only logs or that applies to a tiny test group. Read the System Log for a week. Look at how many sign-ins match the zone, who they are, and whether they are honest. A zone that you thought matched only attackers may turn out to match your finance team’s mobile phones.

Test from real networks

It is surprisingly hard to test location and provider zones, because you need to actually sign in from those places. Options include a test device on a mobile hotspot, a laptop at a home connection, a test machine at a branch, or a test sign-in through a VPN with an exit in the target country. Use test accounts, never real employees. Record the address, location, and provider that Okta saw, and compare them with what you expected. Where your org offers a policy simulation tool, use it to see which rule would match a described situation, but still confirm with at least a few real attempts.

Roll out in rings

A zone is one clue among several. The best designs combine it with other signals so no single clue decides alone.

Why combine

Consider the clue “this sign-in is from an unfamiliar country”. By itself it is common and mostly harmless. Add “on a device never seen before”, and it becomes more interesting. Add “and a burst of failed attempts just before”, and it becomes alarming. Rules that combine clues are more precise: they catch more real attacks and trouble fewer honest people. Okta’s behavior detection, device assurance, and risk levels exist so that policy can use these combinations.

flowchart LR
    Z["Zone clue"] --> C["Combine in rule"]
    DV["Device clue"] --> C
    BH["Behavior clue"] --> C
    RK["Risk level"] --> C
    C --> ACT{"Response"}
    ACT -- "All reassuring" --> A1["Allow smoothly"]
    ACT -- "Mixed" --> A2["Step up"]
    ACT -- "Several alarming" --> A3["Deny and alert"]
    

Use zones for what they are good at

Zones are strongest when the question is about place or kind of network, and weakest when the question is about identity. Use them to say “treat hiding services with suspicion”, “let our own VPN pass more easily”, or “keep this token on our servers”. Do not ask them to say “this person is who they claim to be”. That is a job for factors and devices.

Zones are a security control, and like any control they can be bypassed, abused, or misconfigured. Knowing the weak points makes your design sturdier.

How attackers get around zones

• Residential and mobile proxies. Renting ordinary home or phone connections in your region makes traffic look local and normal.
• Fresh infrastructure. Newly rented servers may not appear in any list of bad addresses yet.
• Using your own trust. If an attacker gets into a device inside your office or VPN, they inherit the benefit of trusted zones.
• Header tricks. If a trusted proxy setting is too broad, an attacker may forge a forwarded address to claim a trusted one.
• Zone editing. An attacker with administrator rights can add their own address to a trusted zone.
• Waiting for stale data. Attackers exploit lists that are out of date, such as a trusted range that your company released long ago.

Hardening steps

flowchart TD
    ATT["Attacker goal: look like a trusted network"] --> M1["Rent local proxy addresses"]
    ATT --> M2["Compromise a device inside office or VPN"]
    ATT --> M3["Forge forwarded address header"]
    ATT --> M4["Edit zones with stolen admin rights"]
    M1 --> D1["Defense: strong factors, device trust, behavior"]
    M2 --> D2["Defense: device health, least privilege, monitoring"]
    M3 --> D3["Defense: narrow trusted proxy declarations"]
    M4 --> D4["Defense: restrict zone editing, alert on changes"]
    

Zones look at where people sign in from. That touches on privacy, on law, and on how fairly your staff are treated. A secure design is also a respectful one.

What zones reveal about people

Every sign-in carries an address, and an address can suggest a city, a country, a workplace, or a home. Over time, logs of those addresses reveal where a person lives, when they travel, and which networks they use. That is personal information in many places, and some regions have rules about how long it may be kept and for what purpose. Check with your privacy or legal team about retention periods for sign-in logs and about notices you owe to employees. This post is not legal advice, and requirements vary by country and industry.

Fairness in rules

• Country blocks can hurt honest people. A rule that blocks a whole country affects every employee, contractor, and customer there, as well as anyone traveling through. Make sure the business reason is real and that there is a documented path for exceptions.
• Privacy tools are not proof of guilt. Journalists, activists, and ordinary people in restrictive places use anonymizing services for legitimate protection. Stepping up proof is gentler than a flat denial.
• Some staff are affected more. Remote and traveling staff, field workers, and people with poor connections meet more challenges. Watch whether certain groups are repeatedly inconvenienced and fix the rules rather than asking them to put up with it.
• Be clear with people. Tell employees why extra proof is sometimes required, and give them a way to ask for help that does not feel like an accusation.

A zone you cannot see working is a zone you cannot trust. Good monitoring tells you whether the rules match reality and when something changes.

What the logs tell you

Okta’s System Log records each sign-in with the network information it used: the address, the location, the provider, and which zones the request matched. It also records changes to zones and policies, along with who made them. These records are the raw material for everything below. Send them to your central security monitoring system so you can search and alert on them alongside other logs.

Useful measures

flowchart LR
    SL["Okta System Log"] --> SIEM["Central monitoring"]
    SIEM --> DASH["Dashboards of zone matches and challenges"]
    SIEM --> ALR["Alerts on zone edits and spikes"]
    ALR --> OWN["Zone owner and security team"]
    DASH --> REV["Monthly review"]
    REV --> TUNE["Adjust zones and rules"]
    

Alert on changes first

If you can alert on only one thing, alert on zone changes. A zone edit is rare, important, and easy to check against a change request. Every unexpected edit deserves a human look. After that, add alerts for sudden shifts in matching patterns, since those reveal both attacks and broken assumptions.

Zones are checked on every sign-in, so they must be fast, and they must keep working when parts of the world around them fail.

Speed and limits

Checking a request against zones happens quickly, and for normal sizes you will not notice any delay. The practical limits are about manageability rather than speed. Okta limits how many zones and how many addresses per zone you can have, and the numbers differ by license and change over time. Check your own limits in the admin console. Very long address lists are also hard for humans to review. Aim for fewer, clearer zones, and use ranges rather than thousands of single addresses.

What reliability means for zones

• Data dependence. Location, provider, and service category zones depend on data that Okta maintains. That data is approximate and changes. Your rules must tolerate occasional errors.
• Your network dependence. Office and VPN zones depend on your network team keeping addresses stable. A failover to a backup internet link changes your outgoing address. If the backup address is not in the zone, everyone appears to come from an unknown place at the worst possible time.
• Vendor dependence. Partners and cloud providers may change addresses with little warning.
• Automation dependence. A broken update job leaves zones frozen at last month’s truth.

sequenceDiagram
    participant N as Network team
    participant Z as Okta zone
    participant U as Employee
    N->>N: Main internet link fails
    N->>N: Traffic moves to backup link with a new address
    U->>Z: Sign in from backup address
    Z-->>U: Not in the office zone, stronger proof required
    N->>Z: Backup address added to office zone ahead of time
    Z-->>U: With the backup listed, normal experience continues
    

Zones fail in a few predictable ways. Knowing the symptoms and the fix in advance turns a panic into a routine.

Common failures

A recovery routine

These patterns have proved themselves in many organizations. Treat them as starting points to adapt, not as scripts.

flowchart TD
    A["Request"] --> B["Blocklist zone: refuse known abusers"]
    B --> C["Dynamic zones: classify location, provider, service"]
    C --> D["Policy zones: office, VPN, partner, automation"]
    D --> E["Device and behavior signals"]
    E --> F{"Combined decision"}
    F --> G["Allow"]
    F --> H["Step up"]
    F --> I["Deny"]
    

These are the mistakes seen most often. Each looks reasonable at first and causes trouble later.

Every zone decision trades one good thing for another. Naming the trade-off openly helps you choose on purpose rather than by accident.

quadrantChart
    title Choosing zone strength
    x-axis Low confidence in signal --> High confidence in signal
    y-axis Low impact of mistake --> High impact of mistake
    quadrant-1 Verify before acting
    quadrant-2 Step up and observe
    quadrant-3 Log and watch
    quadrant-4 Enforce firmly
    Known abuser list: [0.85, 0.7]
    Anonymizer category: [0.45, 0.4]
    Foreign country: [0.5, 0.55]
    Hosting provider: [0.6, 0.35]
    Office zone: [0.8, 0.3]
    

The picture above is a way of thinking, not a measurement. Place each zone you use where you honestly believe it belongs. Signals you trust highly and whose errors are cheap can drive firm actions. Signals you trust less, or whose errors lock out the wrong people, deserve a gentler response such as a stronger factor. Whenever you feel torn, choose the response that is easiest to reverse.

A short checklist you can use at the start, and a list of slips to look for when something feels off.

Best practices

• Write down the purpose. Each zone gets a name, an owner, a reason, and a review date in its description.
• Start narrow. Add zones and exemptions in the smallest form that solves the problem.
• Observe first. Watch matches in the log before turning on enforcement.
• Pair trust with proof. Reduce friction in trusted places, but keep strong factors for sensitive actions.
• Prefer step-up for uncertainty. Reserve denial for strong evidence.
• Protect zone editing. Few editors, review for changes, alert on every edit.
• Include backups. Failover links, secondary VPN endpoints, and disaster recovery sites belong in the right zones.
• Declare proxies exactly. Trust forwarded addresses only from proxies you operate.
• Keep automation tied to one address. Restrict service tokens to the zone of the servers that use them.
• Test emergency access. Make sure the break-glass path works and is monitored.
• Review regularly. Every quarter, check matches, owners, and need.

Common mistakes

To pull everything together, here is an invented company and a complete zone design. The company, its numbers, and its addresses are made up for illustration.

The company

Harbor and Pine is a fictional furniture retailer with 2,400 employees. It has one headquarters in Portland, four regional warehouses, around 600 remote staff, a logistics partner, a payroll provider, and a set of cloud servers that run its inventory and ordering software. Customers do not sign in through Okta; this is workforce identity only. The security team is small, and the network team is separate.

The design

The rules, in plain words

1. Anyone in Block-Known-Abusers is refused before anything else.
2. Administrators must be on the Portland office or VPN zones with a managed device and a strong factor. Anonymizer and other-country sign-ins to the admin console are denied.
3. Staff on a managed device from the office or VPN zones get the standard experience with a long session.
4. Staff from expected countries on other networks are asked for a strong factor on every new device.
5. Staff from other countries, anonymizers, or hosting networks must use a strong factor and a short session, and each such sign-in is logged for review.
6. Partner staff reach only their one application and use strong factors.
7. API tokens work only from the automation zone.

flowchart TD
    S["Sign-in"] --> A{"Block-Known-Abusers?"}
    A -- "Yes" --> R["Refuse"]
    A -- "No" --> B{"Admin console?"}
    B -- "Yes" --> B1{"Office or VPN, managed device, strong factor?"}
    B1 -- "Yes" --> OK1["Allow"]
    B1 -- "No" --> R2["Deny"]
    B -- "No" --> C{"Office or VPN with managed device?"}
    C -- "Yes" --> OK2["Standard experience"]
    C -- "No" --> D{"Anonymizer, hosting, or other country?"}
    D -- "Yes" --> ST1["Strong factor, short session, log"]
    D -- "No" --> ST2["Strong factor on new devices"]
    

How the first quarter went

The team started in log-only mode and spotted two surprises. Warehouse tablets used a mobile carrier connection at one site, so they appeared to come from a shared carrier address instead of the warehouse network. Rather than trusting the carrier range, the team moved those tablets to device-based sign-in. They also found that a few sales staff traveled often and were challenged repeatedly in other countries. A short travel notification process and a stronger device-based factor reduced the prompts without lowering protection.

In the second month, an attack wave from cloud servers hit several accounts. Hosting-provider and anonymizer rules stepped up the sign-ins, and the extra factor stopped the attackers, who only had passwords. The alerts were reviewed the next morning, passwords were reset for the targeted accounts, and no account was taken over. In the third month a portion of the Portland office moved to a new internet provider. Because the network team had agreed to warn the identity team, the new addresses were added a day before the move, and staff noticed nothing.

When zones behave strangely, work through a few questions in order. Most problems fall into a small number of causes.

First questions

1. What did Okta actually see? Open the sign-in event in the System Log. Note the address, the location, the provider, and the zones that matched.
2. What did you expect? Compare with the person’s real situation: office, home, VPN, hotspot, or travel.
3. What changed recently? Look for zone edits, rule changes, network changes, and partner announcements.
4. Which rule applied? Find the policy and rule that handled the sign-in, and check the order of the rules.
5. Is a proxy involved? If the address is the same for everyone, look at forwarded headers and trusted proxies.

Short answers to questions that come up often. Details such as feature names and license tiers change, so confirm them in your own Okta documentation.

Network zones give Okta a sense of where a sign-in comes from. Used well, they reduce friction for trusted places and add care for the unusual ones.