Most account attacks are not clever. They are cheap, automated, and repeated millions of times. Defending against them one organization at a time is wasteful.

Attackers rarely target one company with a careful plan. More often they buy lists of stolen emails and passwords from earlier breaches and try them everywhere, hoping that people reused the same password. This is called credential stuffing. A close cousin, password spraying, tries a few very common passwords across a huge number of accounts, hoping that some people chose weak ones. Both attacks are noisy, automated, and come from addresses that attack many organizations at once.

Four reasons the feature earns attention

• Shared knowledge: Okta can spot attacking addresses by watching many organizations, which no single company could do alone.
• Early defence: suspicious requests can be recognized before a password guess is even checked against your users.
• Lower noise: blocking bad traffic early means fewer lockouts, fewer alerts, and fewer helpdesk calls.
• Low effort: the basic protection is quick to switch on compared with building your own detection.

What it is not

ThreatInsight is one layer, not a complete shield. It focuses on known bad addresses and patterns in sign-in traffic. It does not replace strong passwords, multi-factor authentication, sensible policies, or monitoring. An attacker using a fresh address, or a patient attacker using one correct stolen password, may pass through this layer. Think of it as a very good lock on the front gate, not the entire security system.

The business case in plain terms

Account takeover is expensive. A single compromised account can lead to stolen data, fraudulent payments, damaged trust, and long investigations. Even attacks that fail cost money: they fill logs, trigger lockouts, raise helpdesk tickets, and distract security staff. Stopping a large share of this traffic early, at low cost, is one of the best returns available in identity security. When you ask leaders for support, describe the problem in these terms rather than in technical ones.

Who benefits

Employees benefit from fewer lockouts and fewer strange prompts. Helpdesk staff handle fewer reset calls. Security analysts see cleaner logs where real signals stand out from the noise. Executives benefit from lower risk and fewer incidents. Naming these groups helps you explain the project to each of them in the terms they care about.

A small set of words appears again and again. Learn them once and the rest reads easily.

The balance between two kinds of error

Every protection faces a trade-off. If it is too strict, it turns away real people, which is a false positive. If it is too relaxed, it lets attackers through, which is a false negative. No setting removes both. Your job is to choose a sensible balance for your organization and to watch the result. This idea returns again and again in the rest of this guide.

Reputation, not proof

ThreatInsight judges addresses by reputation and observed patterns. It does not read minds. An address with a bad record is more likely to be malicious, but it may also be shared by many harmless users, such as a large company network or a mobile carrier. This is why careful configuration includes ways to exempt trusted networks.

flowchart LR
    R["Sign-in request"] --> TI{"ThreatInsight
assessment"}
    TI -->|"looks normal"| N["Continue to policies"]
    TI -->|"looks suspicious"| M{"Mode?"}
    M -->|"Audit"| L["Log and continue"]
    M -->|"Enforce"| B["Block the request"]
    

Figure 1 shows the basic decision. A request arrives, ThreatInsight assesses it, and the outcome depends on the mode you chose. In audit mode, suspicious requests are noted and allowed to continue. In enforcement mode, they are refused. The rest of the guide is about choosing and tuning that mode.

Why the same attacker looks different from different places

An attacker can change addresses easily, using rented servers, hijacked devices, or anonymizing services. Because of this, no list of bad addresses can be perfect or permanent. Reputation shifts as sources are cleaned up, reassigned, or newly abused. This is why a shared, constantly updated view is more useful than a static list you maintain alone, and why you should expect occasional errors in both directions.

It sits at the front door of sign-in, before many other checks have a chance to run.

When someone tries to sign in, Okta runs a series of checks. It looks at where the request comes from, whether the account exists, whether the credentials are right, what the policies require, and whether extra proof is needed. ThreatInsight acts early in this chain, looking at the source of the request itself and how it fits with known attack patterns, before the person’s credentials are even evaluated in the usual way.

flowchart TD
    A["Sign-in request"] --> B["Network zone checks"]
    B --> C["ThreatInsight assessment"]
    C --> D["Account and password check"]
    D --> E["Behavior detection"]
    E --> F["Authentication policy"]
    F --> G["Multi-factor proof"]
    G --> H["Access granted or refused"]
    

Figure 2 shows a simplified view of the layers. The exact order inside Okta differs between releases and flows, so treat the picture as a guide to the idea of layering rather than as a precise schedule. Each layer catches different problems, and together they are stronger than any single one.

Which traffic is covered

ThreatInsight is concerned with sign-in related traffic, such as requests to authenticate people. The exact list of covered paths, including whether certain older or special sign-in routes are included, should be confirmed in the documentation for your release. If a path is not covered, other layers must protect it.

Why early checks are cheaper

Every sign-in request that reaches deeper layers costs effort: looking up the account, checking the password, evaluating policies, and writing records. Refusing an obviously hostile request at the front door saves that effort and keeps attack noise out of later logs. It also means fewer failed attempts are recorded against real accounts, which keeps lockout counts and risk scores cleaner.

Understanding the attacker’s habits explains why the feature works the way it does.

Credential stuffing

Attackers hold huge lists of email and password pairs stolen from other services. They try each pair against many sites automatically. Most attempts fail, but if even one in a thousand works, the attacker gains an account. The attack is cheap and tireless. Because the passwords are real ones that people have used, the attack can succeed even against careful companies if employees reuse passwords.

Password spraying

Instead of trying many passwords on one account, which triggers lockouts, the attacker tries one or two very common passwords on thousands of accounts, then pauses and repeats. The attempts per account are few, so simple lockout rules rarely notice. Across the whole organization, though, the pattern is clear.

Distributed attacks

Modern attackers spread their traffic across many addresses so that no single address looks busy. This is harder for a lone organization to detect, but ThreatInsight, which sees patterns across many organizations, can sometimes connect the dots.

flowchart LR
    LIST["Stolen credential lists"] --> BOT["Botnet or attack tool"]
    BOT -->|"many addresses"| ORG1["Organization A"]
    BOT --> ORG2["Organization B"]
    BOT --> ORG3["Your organization"]
    ORG1 -.->|"shared signal"| OK["Okta shared knowledge"]
    ORG2 -.-> OK
    OK -.->|"protects"| ORG3
    

Figure 3 shows why shared knowledge matters. The attacker uses the same tool against many targets. Evidence collected at the first targets helps protect the later ones, including yours.

How attackers choose targets

Attackers often prefer organizations that have weak or inconsistent defences, because their automated tools find easier wins there. Once a tool succeeds somewhere, it may be reused widely. Strong defences make your organization less attractive, and attackers move on. This displacement effect is a quiet benefit of layering protections, even though it is hard to measure directly.

Why stolen passwords still matter

People reuse passwords across services, so a breach at an unrelated website can hand attackers valid credentials for your systems. No sign-in feature can tell, from the password alone, that it was stolen. That is why extra proof beyond the password is so important, and why ThreatInsight should always be paired with it.

The most important choice is how much action to take when a request looks suspicious.

ThreatInsight offers a small number of modes that control what happens when it flags a request. The names and details should be confirmed in your console, but the ideas are consistent.

Why start in audit mode

Switching on blocking without any preparation is like putting a new, unfamiliar door policy into force at the busiest hour. You may turn away legitimate guests. A better approach is to run in audit mode first, read what would have been blocked, and check whether any of it is real people from your own networks or partners. When the evidence shows the feature mainly flags true attackers, move to enforcement.

How long to watch

A few weeks is usually enough to see the monthly rhythm of your organization: month-end work, shift changes, and seasonal peaks. Your own situation may call for longer or shorter, depending on traffic and risk. Record the date you started and the date you decide.

flowchart LR
    S["Start in
Audit mode"] --> R["Review log events
for several weeks"]
    R --> Q{"Flags look
like real attacks?"}
    Q -->|"no, real users flagged"| X["Add exemptions
and review again"]
    X --> R
    Q -->|"yes"| E["Switch to enforcement"]
    E --> W["Watch closely
for complaints"]
    

Figure 4 shows a gentle path. The loop between review and exemptions continues until the flagged traffic is clearly attackers. Only then does enforcement begin, with close watching afterwards to catch surprises.

Deciding who decides

The choice between audit and enforcement affects users, security, and the helpdesk. Do not leave it to a single administrator. Agree the decision with the security lead and a representative of the helpdesk, record what evidence was reviewed, and note any conditions, such as “enforce unless more than a stated number of real users are flagged”. A written decision is easy to revisit and easy to explain.

A note on wording

Okta may name the modes differently from this guide, and may add or retire options over time. When reading your console, match what you see to the ideas here: no action, record only, or record and refuse. If the console offers more nuanced choices, read their descriptions carefully and test them in a non-production setting before adopting them.

Zones tell Okta which networks you trust. Exempting them protects real people from false alarms.

A network zone is a named list of addresses or places. You may have one for your office networks, one for a partner’s addresses, and one for countries you never expect sign-ins from. Zones are used throughout Okta in policies. In ThreatInsight, they play a special role: you can mark certain zones as exempt so that traffic from them is not blocked by the feature.

Why exemptions are needed

Many legitimate users share a small number of public addresses. A large office may route all staff through a single address. A mobile carrier may put thousands of customers behind one address. If one bad actor uses the same shared address, a reputation-based system may flag it. Without exemptions, your own staff could be turned away because of a stranger.

What to exempt

• Office and campus addresses: the addresses your staff sign in from at work.
• Corporate VPN exits: remote staff often appear to come from a few shared addresses.
• Partner and vendor networks: trusted organizations whose staff sign in to your systems.
• Known automation: scripts and services with fixed addresses.

The cost of exempting

An exemption is a hole in the shield. Anything exempt bypasses this layer. Keep exemption zones as narrow as you can: specific addresses rather than huge ranges, and only networks you control or trust. Review them regularly, because networks change owners and trust fades.

flowchart TD
    REQ["Request arrives"] --> Z{"Source in an
exempt zone?"}
    Z -->|"yes"| SK["Skip ThreatInsight blocking"]
    Z -->|"no"| TI{"Flagged as
suspicious?"}
    TI -->|"no"| OK["Continue"]
    TI -->|"yes"| MODE["Apply audit or enforce"]
    SK --> OK
    

Figure 5 shows the effect. Requests from exempt zones skip the blocking step, and the rest are assessed normally. Keep in mind that exempt traffic still faces your other layers, such as passwords, behavior checks, and multi-factor proof.

Keeping zone lists accurate

Networks change often. Offices move, internet providers change, and partners switch suppliers. An address list that was correct last year may be wrong today, causing either blocked staff or accidental holes. Assign an owner in the network team to update zone contents when changes occur, and add a recurring task to verify them. Treat zones as living records, not one-time setup.

Zones can be fixed lists you write, or lists that Okta helps maintain based on behaviour.

Besides zones that you define by hand, Okta offers zones that describe types of source rather than fixed addresses. Some capture addresses commonly used by anonymizing services, such as proxies and anonymous routing networks. Others capture locations by country. Others use fixed blocklists that you maintain. Each of these can be used in policies to allow, block, or demand extra proof.

How they complement ThreatInsight

ThreatInsight relies on Okta’s view of the wider internet. Your own zones reflect what you know about your organization: where your people are, which countries you serve, which addresses attacked you last month. The two views together are stronger than either alone. For example, ThreatInsight may catch a new attacking address that your lists do not know, while your blocklist may hold an address that attacked only you.

Careful with country rules

Blocking whole countries is a blunt tool. It is useful if you truly have no users, partners, or travelers there, but it also affects people on holiday and attackers who simply use addresses elsewhere. Combine location rules with extra proof requirements rather than treating them as complete protection.

flowchart LR
    TI["ThreatInsight
shared knowledge"] --> DEC["Decision on request"]
    ZN["Your zones
trusted, blocked, location"] --> DEC
    POL["Policies
require extra proof"] --> DEC
    DEC --> OUT["Allow, challenge,
or block"]
    

Figure 6 shows that no single input decides alone. Okta’s shared view, your own lists, and your policies all contribute, and the outcome may be to allow, to challenge with extra proof, or to block.

Using blocklists wisely

A blocklist zone is a list of addresses you refuse outright. It is useful for addresses that have attacked you specifically. Keep entries recent, since addresses are often reassigned to innocent users after a time. Record the reason and date for each entry, and remove entries that have not been seen in a long period. A blocklist that only grows becomes a source of mistakes.

ThreatInsight looks at where a request comes from. Behavior detection looks at whether it fits the person.

Behavior detection compares a sign-in with the usual pattern for that person: their usual places, their usual devices, the speed of travel between sign-ins, and so on. If a person who always signs in from one city suddenly appears from a distant country within an hour, the behaviour is unusual. Behavior detection can feed policies that demand extra proof in such cases.

Two lenses on the same event

• ThreatInsight asks: “Is this source known for bad behaviour?”
• Behavior detection asks: “Is this unusual for this person?”

A request can pass one and fail the other. A known-bad address may try an account that has never logged in before, so behavior has nothing to compare. A clean-looking address may log in as a person from a place they have never been. Using both increases coverage.

flowchart TD
    A["Sign-in"] --> B{"Source reputation
ThreatInsight"}
    B -->|"bad"| X["Block or flag"]
    B -->|"ok"| C{"Fits person's usual pattern?"}
    C -->|"no"| Y["Require extra proof"]
    C -->|"yes"| Z["Normal sign-in"]
    

Figure 7 shows a sensible combination. Known-bad sources are handled early. Everyone else is checked against their usual pattern, and unusual cases are asked for extra proof rather than refused outright.

When both layers disagree

Sometimes the source looks fine but the behavior looks odd, or the other way round. Decide ahead of time how disagreements should be handled. A sensible default is that suspicious sources are blocked, while unusual behavior from clean sources triggers extra proof. Document this default in your policy so that exceptions are conscious choices rather than accidents.

The log is where ThreatInsight tells you what it saw and what it did.

Okta records events for sign-in activity, including events that note a suspicious request was detected and events that note a request was blocked. Exact event names and fields are listed in the documentation. Reading these records is how you decide whether to move from audit to enforcement, and how you investigate complaints.

What an event tells you

Questions to ask of the log

• How many suspicious requests do we see per day, and what is the trend?
• Do flagged addresses ever belong to our own staff or partners?
• Did any flagged address later have a successful sign-in?
• Which applications or accounts are targeted most?
• Are there bursts at particular times?

sequenceDiagram
    participant A as Attacker source
    participant O as Okta
    participant L as System log
    participant S as Security team
    A->>O: Many sign-in attempts
    O->>O: Assess source
    O->>L: Record suspicious or blocked events
    S->>L: Review events and trends
    S->>O: Adjust mode or zones
    

Figure 8 shows the feedback loop. Okta assesses and records. People review the records and tune the settings. Without the human step, the feature runs but does not improve.

Finding the story behind the numbers

A raw count of flagged requests says little by itself. Pair it with context: Was there a known breach in the news? Did a marketing campaign bring unusual traffic? Did a partner change their network? Notes next to the numbers turn a bare chart into an explanation, and they help future readers understand why a spike appeared and what was done about it.

A careful rollout protects real users while building confidence in the feature.

Communicate with the helpdesk

The helpdesk is the first to hear if real users are blocked. Give them a short note explaining what the feature does, what a blocked user may experience, who to escalate to, and how to check the log. Preparation turns possible chaos into a routine ticket.

flowchart LR
    Z["Map trusted networks"] --> A["Audit mode"]
    A --> V["Weekly review"]
    V --> T["Tune exemptions"]
    T --> D{"Ready?"}
    D -->|"no"| V
    D -->|"yes"| E["Enforce at quiet time"]
    E --> M["Monitor closely"]
    M --> R["Regular review"]
    

Figure 9 gathers the steps. Notice that review never ends. After enforcement, the loop continues at a gentler pace because networks, attackers, and organizations all change.

Choosing the quiet time

Switch to enforcement when the organization is least busy and the helpdesk is fully staffed, not before a holiday weekend or a major deadline. Announce the date internally. If something goes wrong, you want a calm day, not a crisis. Keep a clear rollback step, such as returning to audit mode, so that a problem can be contained within minutes.

Success measures for the rollout

Agree before starting how you will judge success. Examples are a drop in failed sign-ins per day, a drop in lockouts, no increase in real-user complaints beyond a small agreed number, and no failed scheduled jobs. Writing these measures down makes the final decision to continue, adjust, or pause far less emotional.

When enforcement blocks a real person, how they feel and what they can do matters.

A blocked request is refused before the credentials are evaluated in the usual way. The person may see a generic sign-in error, or the sign-in page may simply fail to proceed. They may think their password is wrong and try again, which only repeats the block. Clear communication helps: tell users in advance that sign-in problems from unfamiliar networks may occur, and tell them what to do.

Helping a blocked person

• Try another network: switching from a public or shared network to a known one can resolve it.
• Contact the helpdesk: who can check the log for the person’s time and address.
• Add an exemption if appropriate: if the network is trusted and stable, add it to an exempt zone narrowly.
• Wait: reputation can change, and blocks on shared addresses often clear on their own.

Avoid the temptation of broad exemptions

After a few complaints it is tempting to exempt a large range to make the noise stop. Resist this. Treat each complaint as evidence. Exempt narrow, verified networks only. Broad exemptions quietly remove the feature’s value.

flowchart TD
    C["Person reports blocked sign-in"] --> L["Helpdesk checks log
for time and source"]
    L --> Q{"Source trusted
and stable?"}
    Q -->|"yes"| EX["Add narrow exemption
with approval"]
    Q -->|"no"| AL["Advise another network
or wait"]
    EX --> DOC["Record in exemption register"]
    AL --> DOC
    

Figure 10 gives the helpdesk a predictable path. Each case ends with a record, so patterns can be reviewed later and exemptions can be audited.

Writing a friendly message

People handle problems better when they are told what to expect. Prepare a short note for staff that explains in plain words that sign-in may occasionally be refused from unfamiliar or shared networks, why, and whom to contact. Include a reassurance that their account has not been harmed. A calm message prevents panic and reduces repeat attempts that add noise to the log.

Not all sign-in traffic comes from people at keyboards.

Scripts, services, and integrations also authenticate to Okta, often from fixed addresses in data centers or cloud providers. Cloud provider addresses are shared by many tenants, some of whom may be attackers, so they can carry bad reputation. If your own legitimate automation runs from such addresses, it could be flagged.

Practical steps

• Know your automation: list every service that authenticates, with source addresses.
• Prefer stable addresses: where possible route automation through fixed, well-defined addresses.
• Exempt narrowly: add specific addresses of trusted automation to an exempt zone.
• Prefer strong credentials: use credentials that are hard to steal and limit their power.
• Watch for breakage: after enforcement, check that scheduled jobs still run.

flowchart LR
    SVC["Your automation
fixed address"] --> Z{"In exempt zone?"}
    Z -->|"yes"| OK["Runs normally"]
    Z -->|"no"| TI{"Address flagged?"}
    TI -->|"no"| OK
    TI -->|"yes"| FAIL["Job fails:
investigate and exempt narrowly"]
    

Figure 11 shows how a hidden dependency can bite. A job that worked for years can suddenly fail after enforcement begins because its cloud address has a poor reputation. Knowing your automation in advance prevents unpleasant surprises.

Documenting service sign-ins

For each service that signs in to Okta, record its owner, purpose, outbound addresses, credential type, and what happens if it fails. This record serves three purposes at once: it tells you what to exempt, it tells responders whom to call, and it highlights services that could be moved to stronger forms of credential. It is tedious to create and extremely valuable during an incident.

Seeing all the parts at once makes planning and troubleshooting easier.

A ThreatInsight setup involves several cooperating parts. Knowing who does what helps you place each control correctly and know where to look when something fails.

flowchart LR
    RQ["Requesters"] --> FR["Okta front door"]
    KN["Shared threat knowledge"] --> AS["Assessment"]
    FR --> AS
    ST["Your mode and exemptions"] --> AS
    ZN["Your network zones"] --> AS
    AS --> PO["Policies and proof"]
    AS --> LG["System log"]
    LG --> ST2["Streams to security tools"]
    ST2 --> AL["Alerts and dashboards"]
    

Figure 12 traces the flow. Requests reach the front door, where assessment combines Okta’s shared knowledge with your settings and zones. The result goes on to policies and is recorded in the log, which can be streamed to security tools for alerts and dashboards.

What you control and what you do not

You control the mode, the exemptions, your zones, your policies, and how you watch the results. You do not control Okta’s shared knowledge or how it scores sources. This means your work is mostly about fitting the feature to your organization, not about tuning its detection. Accept the shared knowledge as an input and concentrate on your side.

Dependencies you should know about

The feature depends on accurate information about where requests come from. If your traffic passes through proxies, gateways, or load balancers before reaching Okta, make sure the original address is preserved where the design allows. If every request appears to come from the same intermediate address, assessments and logs lose their meaning. Discuss this with your network team early, because it is easy to miss and hard to repair after the fact.

Where decisions are recorded

Every decision that matters leaves a trace in the system log. This includes who changed settings, which requests were flagged, and which were blocked. Treat the log as evidence, not just as a debugging tool. Teach the team to preserve relevant entries when an incident occurs, since retention is limited and old events eventually disappear.

The steps are few and simple. The care lies in the preparation and the watching.

Without giving screen-by-screen instructions, which change between releases, here is the general order of work. Follow your current documentation for exact clicks.

flowchart TD
    A["Confirm license and role"] --> B["Create exempt zones"]
    B --> C["Choose audit mode"]
    C --> D["Set up log review"]
    D --> E["Learn for several weeks"]
    E --> F{"Decision to enforce?"}
    F -->|"not yet"| E
    F -->|"yes"| G["Switch to enforce"]
    G --> H["Quarterly review"]
    

Figure 13 stresses that the setting itself is tiny compared with the surrounding work. The preparation before and the review after are where the real value is created.

Sizing the review effort

Reviewing logs can feel endless. Keep the work small by using saved searches that show only flagged requests from your own known networks, flagged requests followed by successful sign-ins, and counts by day. Three well-chosen views answer most of the questions you will have. Share these views with the team so that everyone looks at the same picture.

The hardest false positives come from addresses shared by many people.

Mobile carriers

Mobile networks often put thousands of devices behind a small number of public addresses. If one customer on that carrier has an infected phone sending attacks, the shared address may pick up a bad reputation, and unrelated customers can feel the effects. Your own employees on mobile data may suddenly find sign-in blocked for no reason they can see.

Corporate and personal VPNs

A company VPN is generally under your control and can be exempted. Consumer VPNs are shared by many strangers, some of whom may be attackers. Reputation for such addresses can fluctuate. Consider whether you want to allow staff to use personal VPNs to sign in, and communicate your decision.

Hotels, cafes, and airports

Public networks share an address among many guests. A sign-in from a hotel may behave unpredictably. Teach travelling staff to expect occasional extra steps and to contact the helpdesk if blocked, rather than trying again and again.

Cloud-hosted desktops and remote tools

Staff who work through cloud desktops or remote access services will appear to come from the provider’s addresses. Understand how those addresses look to Okta and whether they need to be exempted narrowly.

flowchart TD
    SRC["Shared address"] --> Q{"Under your
control?"}
    Q -->|"yes"| EX["Exempt narrowly"]
    Q -->|"no"| Q2{"Can you
trust it over time?"}
    Q2 -->|"yes"| EX
    Q2 -->|"no"| RP["Do not exempt:
rely on proof and helpdesk"]
    

Figure 14 gives a simple rule. Control and long-term trust justify an exemption. Neither one justifies one. For shared addresses you cannot trust, extra proof and a good helpdesk path are safer than a hole in the shield.

Teaching users about shared networks

A short, friendly guide for staff can prevent many tickets. Explain that public networks, hotel Wi-Fi, and personal VPNs are shared with strangers, and that sign-in may occasionally be refused or may ask for extra proof as a result. Suggest using the corporate VPN or mobile data from a trusted provider when travelling, and explain whom to contact. People are far more patient when they understand the reason.

Several features protect against repeated guessing. Understanding how they overlap prevents confusion.

Okta offers several protections against password guessing: account lockout after repeated failures, rate limits that slow excessive traffic, and ThreatInsight. They look at different things.

Reducing harmful lockouts

An attacker who knows a person’s login can deliberately trigger lockouts and thereby deny service. Blocking attacking sources earlier through ThreatInsight reduces the number of failed attempts that ever reach a person’s account, and therefore reduces lockouts. This is a quiet but real benefit.

flowchart LR
    ATK["Attack traffic"] --> TI["ThreatInsight
blocks known sources"]
    TI --> RL["Rate limits
slow floods"]
    RL --> LK["Lockout
per account"]
    LK --> MF["Extra proof
if password is right"]
    MF --> OK["Real user only"]
    

Figure 15 shows the stack. Each layer thins the attack traffic that reaches the next. By the time a request faces the last layer, only a tiny fraction of the original attack remains.

Sharing evidence across teams

Security, network, and helpdesk teams all see parts of the story. A short weekly summary that combines flagged counts, lockout counts, and ticket counts lets each team see how its numbers connect. When lockouts fall after a change in ThreatInsight settings, everyone can see the cause and effect, and support for continued investment grows.

Events are most useful when the right people see them quickly.

The system log keeps events for a limited time, and reading it by hand does not scale. Many organizations copy events to a central security tool where they can be stored for longer, searched alongside other data, and used to trigger alerts. Okta provides ways to stream or export events; confirm the available methods and limits in your release.

Alert ideas

• Spike in suspicious requests: a sudden rise compared with the usual daily count.
• Suspicious request followed by success: a flagged source that later signs in successfully is high priority.
• Our own addresses flagged: a trusted office or partner address appears in flagged events.
• Mode or exemption changes: anyone changing the mode or editing exempt zones.
• Sustained quiet: an unusual drop to zero can indicate the feature was disabled.

Keep alerts few and meaningful

Alerting on every flagged request creates noise that responders quickly ignore. Set thresholds based on measured normal levels, group related events, and route different alerts to the right owners. A short list of alerts that people trust is better than a long list that people mute.

flowchart LR
    LOG["Okta system log"] --> STR["Stream or export"]
    STR --> SIEM["Central security tool"]
    SIEM --> R1["Rule: spike"]
    SIEM --> R2["Rule: flagged then success"]
    SIEM --> R3["Rule: setting changed"]
    R1 --> ON["On-call responder"]
    R2 --> ON
    R3 --> ADM["Platform owner"]
    

Figure 16 shows a lean alerting design. Three rules cover the most important situations, and each goes to the person best able to act.

Keeping a history of decisions

Alongside the stream of events, keep a simple dated log of human decisions: when the mode changed, when exemptions were added or removed, and why. Events show what the system did; the decision log shows why you configured it that way. During audits and incident reviews, the second is often the one people want.

Problems come in two flavours: good users blocked, and bad traffic not caught.

A simple routine for a blocked person

flowchart TD
    P["Problem reported"] --> T{"Good user blocked
or bad traffic missed?"}
    T -->|"blocked"| B1["Find event and source"]
    B1 --> B2["Exempt narrowly or advise"]
    T -->|"missed"| M1["Review other layers"]
    M1 --> M2["Strengthen policy and proof"]
    B2 --> REC["Record outcome"]
    M2 --> REC
    

Figure 17 separates the two kinds of problem, which need different responses. For false positives, adjust exemptions. For misses, remember that ThreatInsight is only one layer and strengthen the others.

Learning from each ticket

Every blocked-user ticket is a small experiment. Record the address, the cause, and the resolution. After a few months, patterns appear: a particular hotel chain, a certain mobile carrier, a partner who moved offices. These patterns guide training, exemption choices, and communication, and they provide evidence for decisions about which networks to trust.

Three small stories show the thinking from problem to settled configuration. No code is needed to follow them.

Example 1: A first rollout at a mid-sized company

A company of two thousand staff has never used ThreatInsight. The security lead lists the networks staff use: two offices, a corporate VPN, and a partner agency that handles payroll. She creates narrow zones for each and switches on audit mode. During four weeks of review, the team sees several hundred flagged requests, nearly all from addresses in countries where the company has no staff. Two flagged requests come from the payroll partner’s address, which had been left out of the zones. The partner address is added as an exemption. At the end of the month, the team enforces, informs the helpdesk, and watches. Complaints in the first week number two, both from travelling staff on hotel Wi-Fi, who succeed after switching networks.

Example 2: A spray that no lockout noticed

An organization notices a few failed sign-ins on hundreds of accounts, one or two each, over several days. No account reaches the lockout limit, so no alarm sounds. The security analyst reviews ThreatInsight events and finds that the sources were flagged but only logged, because the organization stayed in audit mode after the trial and forgot to decide. After reviewing the evidence, the team enforces. The pattern stops reaching the sign-in step, and the number of failures per day drops sharply. The team adds a quarterly reminder so that the mode is never left undecided again.

Example 3: The nightly job that stopped

A finance system uses an automated service to sign in each night and fetch updates. The day after enforcement begins, the job fails. The log shows the service connects from a large cloud provider’s address that has been flagged. The team confirms the service is theirs, assigns it a fixed outbound address, and adds that single address to an exempt zone. They also move the service to a stronger form of credential and limit its permissions. The job resumes, and the exemption is recorded in the register with an owner and a review date.

flowchart TD
    N["Need: reduce attack noise"] --> M["Map trusted networks"]
    M --> A["Audit mode and review"]
    A --> T["Tune narrow exemptions"]
    T --> E["Enforce"]
    E --> W["Watch complaints and jobs"]
    W --> R["Record and review regularly"]
    

Figure 18 shows the shape shared by the stories. Each team mapped trusted networks, learned in audit mode, tuned narrow exemptions, enforced deliberately, and kept watching. The surprises, such as the partner address, the forgotten audit mode, and the cloud job, were handled calmly because the process expected them.

What the examples teach

The lessons from these stories are modest and practical. Prepare before you act, expect a few surprises, handle them calmly, and write down what you learn. None of the teams needed special tools or deep expertise in attacks. They needed a list of their own networks, a patient trial period, and a habit of reading the log.

A security feature has its own risks. Protect the settings that protect you.

Guard the configuration

An attacker’s view

A thoughtful attacker who gains administrator access might switch the feature to audit mode or add an exemption for their own address, quietly weakening defences before a larger attack. Alerts on configuration changes are the answer. They turn a silent change into a visible event.

Exempt does not mean trusted forever

Traffic from exempt zones still needs to pass passwords, extra proof, and policies. Do not relax other rules for exempt zones unless you have a strong reason. An office network can be compromised too, and a stolen laptop on a trusted address is still a stolen laptop.

Privacy of logs

Logs record addresses, places, and account names. These are personal data in many legal systems. Store them securely, limit who can read them, and keep them no longer than needed. Tell your privacy team how the feature and its logs are used.

flowchart TD
    A["Attacker gains admin access"] --> B["Switches mode to audit
or adds own address"]
    B --> C["Defence quietly weakened"]
    C --> D["Larger attack"]
    X1["Control: few admins"] -.-> A
    X2["Control: alert on changes"] -.-> B
    X3["Control: second-person approval"] -.-> B
    

Figure 19 pairs the attack steps with controls. Limiting administrators, alerting on changes, and requiring a second person all make the quiet weakening visible and difficult.

Protecting the administrators

The people who can change these settings are themselves targets. Require strong, phishing-resistant proof for administrator sign-in, use separate administrator accounts from everyday ones, and review who holds administrator roles regularly. A strong feature configured by a weakly protected administrator is only as safe as that administrator’s account.

Plan for the day it fails

No control works every time. Decide in advance what you will do if a large attack passes through, such as forcing extra proof for all users, tightening policies temporarily, or resetting passwords for affected accounts. A rehearsed plan turns a frightening event into a procedure, and the lessons learned improve every layer, including this one.

Good monitoring tells you whether the feature is helping and whether it is hurting.

What to measure

Helpful measures over time

• Trend of flagged requests: rising, falling, or steady, with notes on known events.
• Share from our own addresses: any flagged request from a trusted network deserves study.
• Flagged then succeeded: count of flagged sources that later signed in successfully.
• Lockout counts: expected to fall after enforcement.
• Helpdesk tickets: sign-in blocks per month and their causes.
• Exemption inventory: number, age, and owners of exempt zones.

Levels of attention

flowchart LR
    EV["Events"] --> DASH["Daily dashboard"]
    EV --> WK["Weekly review"]
    EV --> MON["Monthly report"]
    EV --> QTR["Quarterly audit"]
    DASH --> ACT1["Quick response"]
    WK --> ACT2["Tune exemptions"]
    MON --> ACT3["Management decisions"]
    QTR --> ACT4["Policy and setting changes"]
    

Figure 20 shows that monitoring is a set of rhythms, not a single screen. Fast loops handle incidents, slower loops handle tuning, and the slowest handle policy.

Sharing results with leaders

Leaders want a simple story. A one-page monthly summary with three numbers, flagged requests, blocked requests, and complaints, plus two or three sentences of explanation, is enough. Show trends rather than single months, and highlight decisions that need leadership input. Clear, short reporting keeps support for the program strong over time.

Test that good traffic flows, that settings behave as intended, and that your response paths work.

A test checklist

Be careful with realistic tests

Do not run simulated attacks or large volumes of failed sign-ins against your production organization without agreement from your security team and awareness of Okta’s rules for testing. Use a preview or test environment for experiments where possible, and keep tests small and well-announced.

flowchart LR
    T1["Trusted paths"] --> OK["Expected to succeed"]
    T2["Automation"] --> OK
    T3["Unknown path"] --> DEC["Flagged or guided"]
    OK --> VAL["Validated"]
    DEC --> VAL
    VAL --> GO["Go live"]
    

Figure 21 shows the three groups of tests. Trusted paths and automation must succeed. Unknown paths must behave as designed, whether that is flagged or guided to the helpdesk.

Repeating tests after change

Tests are not a one-time activity. After any change to network zones, policies, or companion controls, repeat the key checks for trusted paths and automation. Keep the test checklist in a shared place and note the date of the last run. Small, frequent checks catch problems when they are cheap to fix.

Security settings drift when no one owns them. Name the owners and the routines.

Routines

• Exemption register: every exemption has a reason, an owner, a date added, and a review date.
• Network list refresh: when offices or providers change, zone contents are updated.
• Quarterly review: mode, exemptions, alerts, and metrics are reviewed.
• Incident learning: after any significant incident, settings and runbooks are updated.
• Joiner and leaver for owners: when owners leave, their items are reassigned.

flowchart LR
    REQ["Exemption request"] --> REV["Security review"]
    REV --> APP["Second approval"]
    APP --> IMP["Implement narrow zone"]
    IMP --> REG["Register with owner and date"]
    REG --> RVW["Scheduled review"]
    RVW --> REM["Renew or remove"]
    

Figure 22 shows the lifecycle. The final step, renewal or removal, is the one most often forgotten, and it is where safety is regained.

Preparing for turnover

Security staff change roles. Keep the rationale for your mode and exemption choices in a shared document, not in someone’s memory. New owners should be able to learn in an afternoon what was configured, why, and what to review. Handover notes are a cheap defence against the slow decay that follows every reorganization.

ThreatInsight offers real value and has honest limits.

Key trade-offs

• Protection versus convenience: enforcement stops more attacks and may inconvenience some real users.
• Narrow versus broad exemptions: narrow ones protect the shield but create more requests to handle.
• Speed versus caution: enforcing early is faster; learning in audit mode is safer.
• Reputation versus context: shared knowledge is broad; your own policies add person-specific context.

Comparing cost and benefit honestly

The visible costs are small: some setup time, some exemption management, and occasional helpdesk contacts. The benefits are partly invisible: attacks that never reached your accounts, lockouts that never happened, and incidents that never occurred. Because prevented problems are hard to see, track the numbers over time so that the value is visible when budgets and priorities are discussed.

Teams that run ThreatInsight calmly reuse a handful of simple patterns.

flowchart TD
    P1["Audit, review, enforce"] --> OUT["Calm, layered, watched defence"]
    P2["Narrow owned exemptions"] --> OUT
    P3["Layered defence"] --> OUT
    P4["Change-alerted settings"] --> OUT
    P5["Fixed addresses for automation"] --> OUT
    

Figure 23 reminds us that the patterns reinforce each other. A careful rollout builds trust, narrow exemptions keep the shield strong, layers share the work, alerts guard the settings, and fixed addresses make automation easy to recognize.

Combining patterns into a standard

Many organizations turn these patterns into a short internal standard: a page that states the required mode, the exemption rules, the alert list, the review rhythm, and the owners. A standard avoids reinventing decisions for every environment and makes audits easy. Keep it short enough that people actually read it.

These habits look convenient at first and cause pain later.

Spotting anti-patterns early

Warning signs include exemptions with no owner, audit mode that has been on for months, alerts that nobody reads, and complaints that are answered by widening a range. If you notice any of these, pause and apply the better approach before the problem grows. Anti-patterns usually start as sensible shortcuts under time pressure, so be kind but firm when correcting them.

This chapter gathers the habits that separate calm programs from chaotic ones.

Best practices

Common mistakes

A short pre-enforcement routine

Before switching to enforcement, confirm that trusted zones are accurate, that automation has been listed and tested, that the helpdesk has its guide, that alerts are working, that a rollback is ready, and that leadership knows the date. This takes an hour or two and prevents most launch-day problems.

A short yearly review

Once a year, step back from the details. Ask whether the mode is still right, whether any exemptions can be removed, whether the alerts still reach the right people, whether staff and partners have changed their networks, and whether new attacks call for stronger companion controls such as phishing-resistant proof. Record the answers and the actions that follow.

Four fictional companies show how these ideas play out in practice.

flowchart LR
    I["Incident or finding"] --> L["Read the log"]
    L --> C["Contain the effect"]
    C --> F["Fix settings, lists, or process"]
    F --> T["Retest key paths"]
    T --> R["Update register and runbook"]
    

Figure 24 shows what the scenarios had in common. Each team read the log first, contained the effect, fixed the root cause, retested, and recorded the lesson so it would not be forgotten.

What the scenarios share

In every story, a small amount of preparation made a large difference: a partner inventory, a register with dates, an alert on setting changes, a briefed helpdesk. The cost of this preparation is measured in hours, while the cost of its absence is measured in blocked customers, delayed work, and successful attacks. This is the central lesson of the guide.

Quick answers to the questions beginners ask most often.

ThreatInsight is shared street knowledge for your front door. Use it patiently, configure it narrowly, and never mistake it for the whole security system.

We began with a nightclub door team that remembers troublemakers from other clubs. We saw how credential stuffing and password spraying work, why shared knowledge helps, and where ThreatInsight sits among zones, behavior detection, lockout, and extra proof. We explored audit mode and enforcement, exempt zones, dynamic and blocklist zones, event reading, rollout strategy, user experience, and the special cases of shared networks and automation. We covered architecture, streaming and alerts, troubleshooting, security of the settings, monitoring, testing, ownership, patterns, and pitfalls.

The craft lies in a few steady habits: know your normal, map trusted networks, learn in audit mode, enforce on purpose, exempt narrowly with owners and review dates, layer your defences, alert on changes, and review regularly. Confirm Okta-specific details in your own console and the official documentation.