Start with the ground floor, then build up.

Every device that uses the internet shows the outside world an address, called an IP address. IP stands for Internet Protocol. An IP address looks like a set of numbers separated by dots, and it works a bit like the address on a house. When you visit a website, the website sees the address your traffic comes from. When you sign in to Okta, Okta sees it too.

An office usually shares one or a few of these addresses with everyone inside. All the laptops in the building appear to the outside world as if they come from the same front door. A home connection has its own address. A coffee shop has another. A mobile phone on a phone network has yet another.

So what is a zone?

A network zone is a saved description of a set of places on the internet. You give it a name, such as “Head Office” or “Countries We Do Not Serve”, and you list what belongs in it. After that, you can refer to that name inside Okta rules instead of repeating long lists of numbers every time.

Passwords travel anywhere. That is the problem.

A password does not know where it is being typed. A criminal in another continent who has stolen your password can type it into the same sign-in page that you use. From the website’s point of view, the words are the same. Without any other clue, the site must treat both people alike.

The place a request comes from is a useful extra clue. Most staff sign in from a small number of familiar places: the office, home, a few trusted partner sites. Attackers often come from unusual places, from networks that hide their identity, or from countries where the company has no staff. If you can describe the familiar and unusual places once, you can ask Okta to treat them differently.

Three things companies want from zones

First, smoother access in trusted places. Staff in the office should not be bothered more than necessary. Second, extra checks in unusual places. A sign-in from a strange network should face stronger proof. Third, blocking the worst places entirely. If a company never expects visitors from certain countries or from anonymizing services, it can refuse them before a password is even tried.

The big picture first, the details later.

Okta is an identity provider, which means it is the trusted service that knows who everyone is and decides whether they may enter an app. When a sign-in arrives, Okta can look at the address it came from, compare it with your saved zones, and use the answer inside your rules. In the admin console, zones are created in the networks area of the security settings.

The main kinds of zone

What “basic” means in this guide

This guide covers the foundation: what zones are, the two main types, where they are used, how a sign-in is checked, how to set up a first zone, and how to avoid the classic traps. It leaves out rare, heavily customized designs so that you can build a strong picture first. Once the basics feel natural, the advanced options become easier to learn.

Ten small ideas explain almost everything about zones.

CIDR in one paragraph

Writing out every address in a big office network one by one would take pages. CIDR, which stands for Classless Inter-Domain Routing, is a compact way to write a range. It has the first address, a slash, and a number. The bigger the number after the slash, the smaller the range. For example, a block written as 203.0.113.0/24 covers 256 consecutive addresses. These example numbers are reserved for teaching, so you will not find a real company using them.

Gateway and proxy in one paragraph

When you list your office in a zone, you usually list the gateway, which is the public address of the place your traffic leaves from. If you also use a trusted proxy, such as a company security service that sits in the middle, you can tell Okta about it too, so that Okta knows which proxy it may believe when it reports the original address. Treat that list of trusted proxies with care, because trusting the wrong proxy is like trusting a forged letter.

Who are the players, and what does each one do?

flowchart LR
  U["User or Application"] --> I["Internet"]
  I --> O["Okta Sign-In Service"]
  O --> Z["Zone Check: which zones contain this address?"]
  Z --> P["Policy Rules"]
  P --> R{"Decision"}
  R -->|Allow| A["Allow access"]
  R -->|Extra proof| M["Ask for stronger proof"]
  R -->|Deny| B["Block access"]

The parts, one by one

The user or application is whoever makes the request. It may be a person at a laptop, a mobile app, or a script that talks to Okta automatically. The internet carries the request, and along the way the address of the sender becomes visible to Okta.

The Okta sign-in service receives the request. It notes the address, and it asks the zone check which of your saved zones contain that address. A single address can sit in several zones at once. For example, it may be in “Head Office” and also in “Country A”.

The policy rules are the rulebook that your administrators have written. They take the answer from the zone check, plus other facts such as the app and the group of the person, and produce a decision. The decision can be to allow, to ask for stronger proof, or to deny.

Admin side and user side

The administrator creates zones, writes rules, and watches logs. The end user simply signs in and sees a smooth path or a stricter one. Most users never learn that zones exist. They only notice that sign-in feels easy at work and a bit stricter when they travel.

The most common and most trusted kind of zone.

An IP zone is the simplest zone to understand. You make a list of addresses, and anything coming from those addresses belongs to the zone. It is the best choice for places you control and know well.

What you can put in the list

Gateways and trusted proxies

Okta lets you describe two kinds of entries. Gateway addresses are the public addresses that your traffic really leaves from. Proxy addresses are the addresses of trusted middle servers. If a request passes through one of those, Okta may use the original address that the proxy reports. If you list the wrong proxy, an attacker could try to pass along a fake original address, so only list proxies you own or truly trust.

What IP zones are good at

• Describing your offices, branches and data centers.
• Describing the fixed exit addresses of your company VPN.
• Describing the addresses of trusted partners and service providers.
• Making a custom blocklist of addresses that have caused trouble.

When listing addresses is not enough, describe traits instead.

Where an IP zone says “these exact addresses”, a dynamic zone says “any address that has these traits”. The traits are worked out by Okta using databases that are kept up to date by others. This is useful because nobody can list every address in the world, and the list keeps changing.

Traits you can describe

Be honest about accuracy

Location information is a guess, not a fact. Some addresses are mapped to the wrong country. People who travel, who use a company VPN that exits in another country, or who use mobile networks that route traffic through distant centres can look as if they are somewhere they are not. Because of this, dynamic zones work best as one clue in a larger rule, and not as a lone judge.

Two special jobs that zones can do.

The blocklist

A blocklist zone does not give access. It takes it away. Okta can be told to refuse requests that come from certain zones. Because this happens early, the person never gets a chance to try a password. This is a strong tool for places that you never expect legitimate sign-ins from.

The exempt idea

Automatic protections can sometimes be too eager. A partner company that sends a large number of sign-ins from one address may look like an attacker. Some accounts offer a zone that lists addresses to leave alone. Use it with great care. Anything you place there is trusted more than usual, so it should only hold addresses you fully understand.

Why order matters

The blocklist and exempt ideas work before most of your normal rules. This means a small mistake can have a large effect. If you add the wrong range to the blocklist, a whole office could be locked out. Always test changes with a small, safe range and keep another way to reach the admin console.

A zone on its own does nothing. The power comes from where you use it.

Creating a zone is like drawing an area on a map. It only matters once your rules refer to it. Here are the most common places where Okta can use a zone.

A quick picture of how it reads

A rule that uses a zone is easy to read out loud. “For the payroll app, if the person is not in the Head Office zone, then require a phone approval every time.” “For the admin console, if the person is not in the VPN zone, then deny.” Each rule looks at where, and then at what to do.

Careful planning matters more than clever clicking.

Choose names you will understand later

A name like “Zone 1” tells you nothing. A name like “London Office Egress” tells you what it is and where it is used. Add the owner’s team in the description, so that anyone who finds a strange zone knows whom to ask.

A lot happens in the second between pressing Sign In and seeing the next screen.

sequenceDiagram
  autonumber
  participant U as User
  participant O as Okta
  participant B as Blocklist Zone
  participant Z as Zone Engine
  participant P as Policy
  U->>O: Open sign-in page from some address
  O->>B: Is this address on the blocklist?
  B-->>O: No
  O->>Z: Which zones contain this address?
  Z-->>O: A list of matching zones
  O->>P: Evaluate rules using those zones
  P-->>O: Allow, ask for more proof, or deny
  O-->>U: Show the next step

Walking through the diagram

The request arrives, and Okta reads the address it came from. The first stop is the blocklist. If the address is on it, the request ends there. If not, Okta asks the zone engine which of your zones contain the address. The answer may be none, one, or several.

Next, the rules take the stage. Rules are read from top to bottom. The first rule whose conditions match the situation decides what happens. A condition might say “the person is in the Finance group, and the address is not in the Head Office zone.” If that matches, the rule’s action applies, for example “ask for a phone approval each time.”

Order of rules matters

Because the first matching rule wins, the order in your list is part of your design. A broad “allow everything” rule placed above a careful “ask for proof outside the office” rule will quietly cancel the careful one. Always read your rules from the top and ask which one will match first.

A made-up story helps all the pieces click together.

Asha works in finance at a company that uses Okta. The administrators created three zones: “HQ Office Egress”, “Company VPN”, and “Blocked Anonymizers”. They wrote rules for the payroll app. Follow Asha through a week. The names and details here are invented for teaching.

What the story shows

The same person got four different experiences without anyone editing her account. The zones and rules did the work. The stranger on Friday never even reached the password check. This is the heart of the idea, and it becomes more valuable as the company grows.

Zones adjust how much proof is asked. They do not replace it.

The most common use of zones is to fine-tune multi-factor authentication, often shortened to MFA, which means asking for more than one kind of proof when someone signs in. A company can ask for a second proof, such as an approval on a phone app, more often when a sign-in looks less familiar.

Three popular designs

Do not let zones turn into a free pass

It is tempting to say “people in the office never need a second proof”. This is risky. An attacker who plugs into the office network, or who takes control of an office computer, now enjoys the free pass. A safer plan keeps some proof even in trusted zones, perhaps less often, and always requires strong proof for sensitive apps.

Where traffic appears to come from is not always where the person sits.

flowchart LR
  E["Employee at Home"] -->|"Direct"| OK["Okta"]
  E -->|"Through company VPN"| V["VPN Gateway with a fixed public address"]
  V --> OK
  OF["Office Network"] --> NAT["Office Exit Address"]
  NAT --> OK
  OK --> ZN["Zones: Office, VPN, Everywhere Else"]

VPNs

A VPN, or virtual private network, sends your traffic through a company-controlled server. To Okta, the person appears to come from the VPN’s exit address. If you list that address in a zone, VPN users enjoy the same treatment as office users. If the VPN has many exit addresses, or if they change, the zone must be kept up to date.

Split tunneling

Some VPNs send only some traffic through the company server and let the rest go straight out. If Okta traffic goes out directly, Okta sees the home address and not the VPN address. This causes confusing results where “I am on the VPN but I am treated as outside”. Ask your network team how the VPN is set up.

Cloud security services and shared exits

Many companies use cloud security tools that sit in the middle. Staff traffic then leaves from shared addresses used by many companies at once. Be careful before trusting such addresses. If the address is shared, then anyone else using the same service also looks “trusted” to your rule.

Mobile networks and home internet

Mobile networks often share one address among many customers, and addresses can change in the middle of a session. Home connections change without notice. These addresses are poor candidates for a trusted zone. Use them to trigger stronger checks, not to give shortcuts.

Zones are not a set-and-forget feature. They have a life.

flowchart LR
  C["Create the zone"] --> T["Test with one small rule"]
  T --> A["Apply to more rules"]
  A --> R["Review on a schedule"]
  R --> U["Update addresses"]
  U --> R
  R --> X["Retire the zone when no longer needed"]

Create

A new zone starts with a purpose. Someone should be able to say why it exists and who owns it. Gather correct addresses from the network team, and give the zone a clear name and description.

Test

Before using a zone in important rules, try it in a low-risk rule with a small group. Check the log to confirm that the addresses match as expected.

Apply

Extend the zone to more rules only after it behaves correctly. Keep a list of which rules use which zones, because a change to a zone affects all of them at once.

Review

Offices move, providers change, and VPN exits are replaced. Review each zone on a schedule, perhaps every few months, and after every network change. Remove addresses you no longer own, because an old address may later belong to a stranger.

Retire

When a zone is no longer used, remove it from the rules first and then delete it. Dead zones clutter the list and invite mistakes.

Every design trades something away. Here is an honest balance sheet.

Zones compared with other clues

The big trade-off: convenience versus caution

The wider your trusted zone, the smoother things feel, and the more places an attacker might hide. The narrower your trusted zone, the safer you are, and the more often people see extra prompts. A good design trusts a small set of well-known places a little, and never trusts any single clue completely.

Know the tricks so that you can design against them.

Threat 1: Hiding behind anonymizing services

Attackers often route traffic through proxies and privacy networks to hide their true place. A dynamic zone for these services, used in a blocklist or a stricter rule, removes a great deal of this noise.

Threat 2: Using a trusted-looking address

If an attacker gains control of a computer inside your office, or connects to a shared service whose address you trusted, they inherit the benefits of that zone. Keep proof requirements even in trusted zones and avoid listing shared addresses as trusted.

Threat 3: Forged address information

If you trust a proxy that reports the original address, make sure the proxy is yours and that it cannot be told what to say by outsiders. A badly set trusted proxy list lets an attacker pretend to be anywhere.

Threat 4: Zones that quietly go stale

An old office address may later be given to a stranger by the provider. A zone that still lists it now trusts that stranger. Regular review removes this risk.

Threat 5: Over-blocking and self-lockout

A careless blocklist can lock out your own staff or administrators. Always keep a safe path in, such as a protected emergency administrator account.

Threat 6: Relying on location alone

Because location guesses can be wrong and addresses can be faked through many tricks, never rely on a zone as the single safeguard. Combine it with a strong second proof and device health checks.

Plan for the day the network changes under your feet.

Zones depend on facts about the outside world. When those facts change, rules can start to behave differently overnight. Good design expects change and makes recovery easy.

Fail safely

Think about what should happen if a zone does not match, for example if a new office address has not been added yet. A safe design asks for stronger proof and does not simply grant access. Staff may be mildly annoyed, but the company is protected.

Keep a break-glass plan

Keep a small number of specially protected emergency administrator accounts that are not blocked by network rules. They are used only when normal access is broken, and every use is checked afterwards.

If nobody looks at the dashboard, a quiet mistake stays quiet.

Okta writes a record of important events into its system log. Each sign-in event records the address the request came from, and it can show which zone matched and what decision followed. This is the best way to check that your zones behave the way you meant.

What to keep an eye on

Useful numbers to track over time

Teams track simple health numbers, such as how many sign-ins are allowed, challenged and blocked each day, how many are matched to each zone, and how often people contact the help desk about unexpected prompts. Slow changes in these numbers often reveal a problem long before a user reports it.

Most problems have simple causes. Check these before anything else.

A calm step-by-step routine

Habits that work well, and habits that cause trouble.

Think in layers

flowchart TD
  S["Sign-in attempt"] --> L1["Layer 1: Blocklist zone"]
  L1 --> L2["Layer 2: Threat intelligence signals"]
  L2 --> L3["Layer 3: Network zone rules"]
  L3 --> L4["Layer 4: Behavior and device signals"]
  L4 --> L5["Layer 5: Multi-factor proof"]
  L5 --> OK["Access decision"]

Security experts call this idea defense in depth. No single layer is perfect, so you stack several, and a weakness in one layer is covered by another. Zones are a very good layer, but they are only one.

Patterns that work

Anti-patterns that cause trouble

A short checklist for the person setting this up.

Before you start

• Get correct public addresses from the network team, and not guesses.
• Write down the goal of each zone in one sentence.
• Study your logs to learn where people really sign in from.
• Decide who owns each zone and who must be told about network changes.

While you build

• Start with one small rule on one low-risk app and one pilot group.
• Use clear names and descriptions.
• Prefer stricter proof over outright blocking when you are unsure.
• Keep an emergency administrator path that is not blocked by zones.
• Read your rules from the top to be sure the right one matches first.

After go-live

• Check the log after every change, and again a week later.
• Review zones on a schedule and after every network change.
• Remove old addresses you no longer own.
• Set alerts for admin sign-ins from unexpected places.
• Practice what to do if a bad blocklist entry locks people out.

Common mistakes

Good projects are decided on paper before they are decided in the console.

Roll out in phases

Where this idea shows up in daily working life.

Okta is used by organizations of many sizes around the world, and many of them use network zones in some form. The scenarios below are typical examples of how organizations in different fields apply the same ideas.

Lessons from real projects in the industry

Teams that report smooth zone projects share the same habits. They study logs first, start small, name zones clearly, keep an emergency path, and review zones when the network changes. Teams that report pain tend to trust home and shared addresses, block a country on a hunch, or forget to update an office address after a move. The lesson is that zones are a living map that needs a keeper.

Let us design a first set of zones from a blank page, step by step.

Imagine a made-up company called Brightwave, with two hundred staff. It has one head office, one warehouse, and a company VPN. Many people work from home two days a week. The company uses Okta for email, chat, a finance system and an admin console. Here is how a careful administrator might think.

Step 1: Name the places that are really under your control

Brightwave controls three places: the head office network, the warehouse network and the VPN. The administrator asks the network team for the public exit address of each. The answers are written down, along with the date and the person who confirmed them. Three IP zones are created, with clear names: “Brightwave HQ Egress”, “Brightwave Warehouse Egress” and “Brightwave VPN Egress”.

Step 2: Name the places you never want

The company has no staff or customers in some parts of the world. The logs show many failed sign-ins from there, and none that succeeded. The administrator makes a dynamic zone for those countries and another for anonymizing services. Before blocking, they put both into a rule that asks for the strongest proof for a few weeks. Only after confirming that no real person is affected do they move them to a blocklist.

Step 3: Write the rules from strict to relaxed

Step 4: Protect the way back in

The administrator creates two emergency accounts. They are protected with very strong proof and kept out of the admin console rule, because the first rule denies anyone outside the office or VPN. Their use is watched closely and tested every few months. This prevents the lockout that so often follows a rushed change.

Step 5: Test and watch

A pilot group of ten people tries the rules for two weeks. The administrator reads the log every day, looks for people who are treated differently from what was intended, and fixes the zones. Only then are the rules extended to the whole company.

Keep this chapter handy. Every word used in the guide is explained here.

Network words

Okta and security words