Start with three plain ideas: a threat, an insight, and a gate.

A threat is something that may harm you. In sign-in security, the most common threat is an automated program that tries many passwords against many accounts. An insight is a useful piece of knowledge, gained by looking at lots of data. ThreatInsight is therefore a feature that uses knowledge about attackers to protect your sign-in page.

Okta serves a very large number of organizations. That gives it a wide view of how sign-in attempts behave across all of them. When a single internet address starts firing off suspicious sign-in attempts at many places, patterns appear that no single company could see alone. ThreatInsight uses these patterns to decide which addresses look malicious, and lets you log or block their requests.

In short, ThreatInsight answers three questions. Is this address behaving like an attacker? What should Okta do about it? And what should you be told?

Three questions this guide answers

Everyday phrases and what they really mean

Security teams use short phrases that confuse newcomers. When someone says “the IP was flagged”, they mean ThreatInsight judged that internet address to be behaving like an attacker. When they say “pre-authentication”, they mean before any password is checked. When they say “false positive”, they mean a harmless sign-in that was wrongly treated as a threat. Knowing these three phrases makes most documentation much easier to read.

Stolen passwords are sold and reused on a huge scale. Attackers use programs to try them everywhere.

Every year, large collections of usernames and passwords leak from breached websites. Attackers buy or download these lists. Because many people reuse passwords, a pair that worked on one website may work on another. An attacker does not have to be clever. They only have to be patient, and let a program try the list against your sign-in page, thousands of times, from many addresses.

This kind of attack is dangerous for two reasons. First, it looks like ordinary sign-in traffic, only more of it. Second, even a tiny success rate is worth the effort. If one in a thousand attempts works, an attacker with a million attempts gets a thousand accounts. Without help, a company sees only the noise, and finds out about the successes when it is too late.

What goes wrong without a lookout

Why this matters even for small teams

Some teams believe automated attacks only target large companies. In truth, attackers aim at everyone, because the programs do not care who owns the sign-in page. A small business with twenty users is attacked by the same tools as a bank, only less often. Switching on a lookout takes minutes, and can save days of cleanup.

A short vocabulary list makes the rest of this guide much easier to follow.

Threat detection has its own words. Most of them describe what attackers do, or how a defense responds. The table below puts each term next to a simple picture.

Three attacks, one idea

Credential stuffing, password spraying, and brute force look different, but they share one idea: guess credentials by machine, at scale. Chapter 4 explains how each one looks in the log, and why a lookout that sees many sign-in pages at once is good at spotting them.

Common misunderstandings

A few more words you will hear in meetings

Colleagues may say “reputation” when they mean how trustworthy an internet address appears, based on its past behavior. They may say “botnet” when they mean a large collection of hijacked computers that attackers control and use to send traffic from many addresses at once. They may say “residential proxy” when they mean traffic relayed through ordinary home connections, which makes attackers look like normal households. And they may say “signal” when they mean any clue that helps a system judge whether traffic is hostile.

None of these words is hard. Each names a piece of the picture you will see in this guide. When a new term appears, ask whether it is about the attacker, the address, or the defense. Placing the word usually reveals what it means and which part of this guide to open.

To trust a lookout, it helps to know what it is looking for. Here are the three common patterns.

Automated sign-in attacks fall into a few families. They differ in how many accounts they target and how many passwords they try for each one. Knowing the shape of each helps you read logs, and understand why a defense that watches many sites at once has an advantage.

Why attackers use many addresses

A smart attacker spreads the attempts across thousands of internet addresses, so that no single address looks busy. This defeats simple rules such as “block an address after five failures”. It is also why a view across many organizations is so useful. An address that tries only a few times against your site may have tried against hundreds of others at the same moment, and that wider pattern gives it away.

Why speed and scale matter

Thinking like an attacker for a moment

It helps to picture the attack from the other side. An attacker has a list of stolen credentials and a program that can try them. Their goals are simple: try as many combinations as possible, avoid being blocked, and find the few that work. Every defense you add makes some part of this harder. Blocking addresses forces them to find new ones. Requiring a second proof makes a stolen password worth far less. Locking accounts forces them to slow down.

Attackers are practical. They go where the defense is weakest. If your sign-in page is protected but an old application accepts direct logins, they will try the old application. If your sign-in page filters bad addresses but needs no second proof, they will look for clean addresses. Seeing the world this way helps you decide where to spend your effort, and reminds you that the goal is to make attacking you more costly than attacking someone else.

No single defense is enough. ThreatInsight is one layer, and works best beside the others.

Security professionals describe good protection as layers, like the skins of an onion. Each layer stops some attacks and passes others to the next. ThreatInsight is an early layer. It stops a lot of automated traffic at the outer gate. The layers behind it, such as strong passwords, second proofs, and policies, handle what gets through.

What ThreatInsight is best at

What it does not do

ThreatInsight does not know whether a password is correct, since it acts before that check. It does not stop a person who has legitimately stolen a valid password and a valid second proof, and arrives from a clean address. It does not replace strong authentication. Think of it as a very good filter at the entrance, not as the vault door.

Here is the full picture of how sign-in traffic, ThreatInsight, and your policies fit together.

Sign-in requests arrive at Okta from many places on the internet. Before Okta looks at any password, it can check where the request came from. ThreatInsight compares the address with its knowledge of malicious behavior. If the address looks dangerous, and you have chosen to block, the request is stopped. Otherwise the request continues to your normal rules and password check. In every case, the decision is written to the System Log.

flowchart LR
  subgraph Internet["Internet"]
    U["Real employees"]
    A["Automated attackers"]
  end
  subgraph OktaZone["Okta"]
    TI["ThreatInsight check on the address"]
    POL["Sign-in policies and rules"]
    PW["Password and second proof"]
    LOG["System Log"]
  end
  APP["Protected applications"]
  U --> TI
  A --> TI
  TI -->|"Looks normal"| POL
  TI -->|"Looks malicious, enforce mode"| LOG
  POL --> PW
  PW -->|"Success"| APP
  TI --> LOG
  PW --> LOG

The parts, one by one

Why the order matters

Because the address check comes first, a blocked request never reaches the password check. This protects accounts from being locked by attackers, and saves effort. It also means the check relies only on information about the request, such as where it came from, not on anything the attacker typed.

ThreatInsight does not guess at random. It weighs signs of attacker behavior, and gives each address a level.

Okta does not publish the exact recipe, which is sensible, since attackers would study it. But the general idea is clear. Okta looks at sign-in behavior across many organizations and notices addresses that show the marks of automated attacks. Examples include a very high rate of failed attempts, attempts against very many different usernames, and patterns that real people do not produce.

Kinds of signals, in general terms

flowchart TD
  R["Request from an address"] --> S{"Does the address show attacker signals?"}
  S -->|"No"| N["Treat as normal traffic"]
  S -->|"Yes"| L{"How high is the threat level?"}
  L -->|"Lower"| LO["Record it, take no extra action"]
  L -->|"High"| M{"Which mode did you choose?"}
  M -->|"Audit mode"| AU["Record only"]
  M -->|"Enforce mode"| EN["Record and block the request"]

Threat levels in plain words

The exact levels and what each one triggers depend on your settings and on Okta’s current design. Treat the table as a way of thinking. Higher confidence of attack leads to firmer action.

The most important choice is how firmly ThreatInsight should act. There are two broad modes.

In the first mode, often called audit or log-only mode, ThreatInsight records the traffic it considers malicious but takes no action. The requests continue as if nothing happened. This mode is a way to see what ThreatInsight would find, without any risk of blocking anyone by mistake.

In the second mode, often called enforce mode, ThreatInsight records the traffic and also blocks requests from addresses it rates as high threat. The blocked requests never reach the password check. This mode gives real protection, and is the one that most organizations eventually use.

A gentle path from audit to enforce

A lookout can only watch the doors it can see. Knowing which doors are covered avoids false comfort.

ThreatInsight evaluates sign-in requests that come to Okta. This includes the main sign-in page that people use, and, depending on your edition and settings, other ways of signing in that go through Okta, such as certain interfaces that programs use, or sign-ins checked against a company directory through Okta. The exact list of covered paths has changed over time, so always confirm it in current documentation.

Questions to ask about coverage

Doors outside Okta

ThreatInsight protects the door that is Okta. It cannot protect doors that do not pass through Okta. If an application also accepts logins directly, an attacker may attack that door instead. Make a list of all the ways into your critical systems, and check each one is either behind Okta or protected by its own defenses.

Timing is the quiet strength of ThreatInsight. Acting early changes what an attack can do.

Most defenses wait until the attacker has typed a password, then decide whether it is right. That is useful, but late. By then the system has already spent effort, may have counted a failure against a real account, and may have confirmed to the attacker whether a username exists. ThreatInsight acts before all that. It looks at the address first, and stops a request that comes from a high-threat source.

sequenceDiagram
  autonumber
  participant A as Attacker program
  participant T as ThreatInsight
  participant O as Okta sign-in
  participant L as System Log
  participant E as Real employee
  A->>T: Sign-in attempt from a high-threat address
  T->>L: Record the detection
  T-->>A: Request blocked before any password check
  E->>T: Sign-in attempt from a normal address
  T->>O: Pass the request on
  O->>E: Ask for password and second proof

What early blocking saves

A short comparison

Sometimes honest traffic looks like attacker traffic. Exemptions protect the places you know are safe.

A network zone is a named list of addresses, such as your offices or your company VPN. ThreatInsight lets you exempt such zones, which tells it not to act on traffic from those addresses. This is useful because some honest sources produce behavior that resembles an attack, such as a large office where thousands of people share a single outward address.

When an exemption makes sense

The cost of an exemption

An exempt zone is, by design, outside ThreatInsight’s protection. If an attacker gains a foothold inside an exempt network, such as a compromised office computer, ThreatInsight will not act against that traffic. So exemptions should be few, narrow, and reviewed. Keep the list as short as honest need allows.

The switch is simple. The plan around it is what makes the change calm.

Enabling ThreatInsight is usually a small setting change. But a good rollout still involves several teams. The identity team owns the setting. The network team knows the trusted address ranges. Security reviews the results. The help desk deals with any user complaints. A short plan makes sure each team knows what is happening.

A rollout in simple stages

Who needs to know

What to measure before you begin

Before you switch anything on, take a baseline. Count the failed sign-ins per day, the lockouts per week, and the help desk tickets about sign-in problems. Note which hours are busiest, and which addresses your honest traffic comes from. These numbers give you a picture of normal, and let you tell later whether ThreatInsight has made a difference.

A baseline also protects you from false conclusions. If lockouts fall after enforcement, you can show by how much. If they do not fall, you can look for another cause. Without a baseline, every change is a guess, and every report is a story rather than a measurement.

For nearly everyone, ThreatInsight is invisible. For a few, it may cause a surprise. Prepare for both.

When ThreatInsight works as intended, ordinary employees notice nothing. Their sign-ins come from ordinary addresses and are passed on to the normal checks. Attackers see their requests blocked, and employees see fewer lockouts, since attacker guesses no longer count against their accounts.

Who might notice

Good support scripts

When a person says “I cannot sign in”, the help desk should know to check the log for a ThreatInsight event along with the usual causes. If the person was blocked, a clear message and a quick fix keep trust high. The script can be short: confirm identity, check the event, move the person to a trusted network or add an exemption if justified, and note what happened.

Training the help desk

The help desk is the human face of the feature. A short training session pays off. Show staff how to open the System Log, how to search for a person or an address, and how to recognize a threat event. Walk through one blocked-user case from start to finish, and let each person practice. Give them a one-page cheat sheet with the safe fixes and the rules for exemptions, including the rule that no exemption is added without identity checks and a second approval.

Staff who feel prepared stay calm when a manager calls about a blocked executive. They fix the problem quickly, and they avoid the shortcuts that attackers hope for. A trained help desk is itself a defensive layer.

Every detection leaves a line in the diary. Here is how to find and read it.

Okta’s System Log is the record of events in your account. When ThreatInsight rates an address as a threat, it writes an event. The event names the address, the threat level, and whether the request was only recorded or was blocked. Because the check happens before the password step, the event can also appear without any person being named, since no username may have been evaluated.

What a detection event can show

A simple reading routine

A flagged address is a clue, not a verdict. A calm routine turns the clue into a decision.

When you see a cluster of detection events, ask three questions. Who is the address? How far did the traffic get? And do any of my people or systems depend on it? The answers decide whether you need to do anything at all, or whether ThreatInsight has already done the job.

An investigation routine

Possible conclusions

Any filter sometimes stops an honest visitor. Knowing why helps you fix it quickly and calmly.

A false positive is a harmless request wrongly treated as a threat. ThreatInsight looks at addresses, and an address is not a person. Many people can share one address, and one person can use many addresses. When an address that honest people share also hosts attackers, honest users may be caught in the net.

Where false positives come from

Reducing the harm

ThreatInsight and network zones solve related problems in different ways. Together they cover more ground.

A network zone is a list of addresses that you define. You may create a zone for your offices, for a partner, or for addresses you want to block outright. ThreatInsight, by contrast, is a judgment made by Okta about addresses you may never have heard of. You provide the known, Okta provides the unknown. Using both gives a sturdier defense than either alone.

A sensible division of work

Anonymizing services

Some network zones can be set up to recognize addresses that belong to anonymizing services, which hide the real source of traffic. Attackers favor such services, but so do privacy-minded honest people. A rule can ask for stronger proof from them, rather than blocking outright. ThreatInsight may also treat some of them as threats, depending on their behavior.

ThreatInsight reduces the number of attacks. A second proof limits the damage of the ones that get through.

Sign-in policies decide what proof a person must give. They may require a password and a second proof, depending on the person, the device, and the place. These rules apply after ThreatInsight lets a request through. If ThreatInsight blocks a request, the policy never runs for it. If ThreatInsight lets it pass, the policy decides how hard the next steps are.

How the two work together

Why a second proof is still essential

Imagine an attacker with a valid username and password, arriving from a clean address that ThreatInsight does not flag. ThreatInsight cannot help here. Only a second proof, such as a phone approval or a security key, stops this attacker. This is why the two defenses complement each other. One reduces the flood, and the other protects against the few drops that get through.

ThreatInsight judges addresses. Behavior and risk signals judge what a person does. Each sees something the other misses.

Beyond addresses, Okta can look at patterns in a person’s own behavior. Where such features are available in your edition, rules can react to a new device, a new location, or an unlikely travel jump. This is a different kind of knowledge from ThreatInsight’s. One watches the attacker’s address across the world. The other watches the pattern of one person’s life.

A team of lookouts

Used together, these lookouts overlap in useful ways. An attacker who passes one may be caught by another. A well-designed policy asks, in order: is this address a known threat, is this person behaving normally, and does the situation meet our own rules?

Not everything that signs in is a person at a keyboard. Programs and partners need a plan too.

Some sign-ins come from programs, such as scripts that check accounts, integrations from partners, or directory connectors. These sources are legitimate, but they behave unlike humans: they sign in often, at regular times, from fixed addresses. A strict filter may mistake them for attackers if their address or pattern looks unusual.

Kinds of non-human traffic

Handling them safely

A detection that nobody sees helps nobody. Plan how the right people hear about what matters.

ThreatInsight writes events to the System Log. By itself, that is a quiet record. To make use of it, you can search it by hand, send events to a central security tool, or set alerts for the patterns that matter. Which you choose depends on the size of your team and how quickly you need to react.

Ways to hear about detections

Patterns worth an alert

Keep alerts few and meaningful

Most detections are harmless background noise, the daily rattle of automated tools. Alerting on each one would drown the team. Start with a short list of patterns that signal real danger, and tune them until each alert deserves attention. Add more only when the team can keep up.

A few simple numbers show whether the lookout is earning its place, and help you explain it to others.

Leaders ask whether a security tool is worth its effort. A handful of plain measures can answer that. Most can be pulled from the System Log, and tracked from month to month. The point is not perfect precision, but a clear trend that shows the benefit.

Useful measures

Reporting simply

A short monthly note is enough. State the number of blocked requests, the change in lockouts, the number of honest users affected, and any notable incident. Add one sentence on what you plan to adjust next. This keeps sponsors informed, and builds the habit of review.

Instead of memorizing errors, learn a method: find the event, read the address, and ask what changed.

Most ThreatInsight questions are versions of “why was this person blocked?” or “why was this attack not stopped?”. The method for both is to open the System Log, find the relevant events, and compare them with your settings. Always ask what changed recently, since many surprises follow a mode change, a new zone, or a move of offices.

Walkthrough 1: A real person was blocked

Walkthrough 2: Many honest users blocked at once

Walkthrough 3: An attack was not blocked

Walkthrough 4: Detections appear from your own network

If detection events name an address inside your own network, treat it seriously. It may be a misconfigured tool, a forgotten script with an old password, or a compromised computer. Find the machine, check what it is doing, and fix the cause before considering an exemption.

ThreatInsight is a security control. A weak design turns it into a false sense of safety.

ThreatInsight reduces a large and noisy class of attacks, but it is not a complete defense. Attackers adapt. They rotate addresses, slow down, and use clean connections. A careful design assumes that some attacks will get through, and prepares the other layers to handle them.

The main risks

Protective habits

Watching sign-in traffic means handling facts about people’s connections. Doing it respectfully is both right and practical.

ThreatInsight works with internet addresses and patterns of sign-in behavior. Addresses can be personal data in some places, since they may point to a household or a person. A fair design uses such information only for the stated purpose of protecting accounts, keeps it only as long as needed, and tells people what is collected and why.

Principles to follow

Fairness in practice

A filter based on addresses can fall unevenly. People in places with shared or unusual connections, such as some mobile carriers or regions with limited internet access, may be flagged more often. Track whether honest users are being blocked in patterns, and offer an easy way to get help. A quick, kind fix keeps trust high, and reveals weaknesses in the design.

No design is perfect. Here is an honest scorecard for ThreatInsight.

Key trade-offs in plain words

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

Keeping the setup healthy as the company changes

Companies change constantly. Offices open and close, providers swap addresses, new partners appear, and new applications start signing in. Each change can quietly make an exemption out of date, or create a new source of honest traffic that looks unusual. Build the habit of asking, whenever something changes in the network, whether the ThreatInsight exemptions and zones need an update.

A short quarterly review keeps the setup honest. Read the exemption list aloud, check that each entry still has an owner and a reason, and remove what is no longer needed. Check the mode, the recent detections, and the numbers in your monthly note. Small, regular care prevents the slow drift that turns a good design into a risky one.

When auditors visit, they ask how you protect sign-in against automated attacks. ThreatInsight is part of the answer.

Compliance means following rules set by law, customers, or the company itself. Many security frameworks expect companies to detect and limit brute-force and credential-guessing attacks, to monitor for suspicious sign-in activity, and to keep records. Governance is the set of habits and records that let you show these things clearly.

Evidence auditors often ask for

Governance habits that help

Here are four common situations where ThreatInsight earns its place. The companies are fictional teaching examples.

Public facts that give context

Security agencies and standards bodies around the world warn about credential stuffing and password spraying, because reused and stolen passwords remain one of the most common causes of breaches. Okta, founded in 2009, built its business on connecting people to applications securely, and ThreatInsight is one of the ways it uses its wide view to help customers. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

Okta ThreatInsight is a lookout at the front gate of your sign-in page. It uses knowledge gathered across many organizations to spot addresses that behave like automated attackers, and lets you record or block their requests before any password is checked. Used well, it cuts noise and lockouts, and gives your team a clear view of the attacks that never reached the door.

A mental model to carry with you

When any ThreatInsight question lands on your desk, sort it into one of four buckets. The first bucket is source: which address, and what does it look like? The second bucket is mode: was it only recorded, or also blocked? The third bucket is exceptions: is the address inside a trusted zone or an exemption? The fourth bucket is aftermath: did anything from that source succeed, and what do the other layers say?

Most confusing situations turn out to be a mix-up between buckets. An honest person who is blocked usually has a source or exception problem, such as a shared address that needs review. An attack that was not stopped is usually a mode problem, such as staying in audit mode. A worrying quiet success is an aftermath problem, answered by searching the log for sign-ins from the same source. Naming the bucket first tells you which setting to read and which search to run.

This model also helps when you explain the feature to others. Managers care about mode and aftermath because they are about risk. Support teams care about source and exceptions because they explain complaints. Network teams care about exceptions because they own the addresses. A good identity architect speaks to all of them and keeps the runbooks written down.

A final word on the people behind the sign-ins

Behind every sign-in attempt is either a real person trying to get on with their work, or a program run by someone who wants in. A good defense lets the first group through quickly and kindly, and turns the second group away without fuss. Security that gets this balance right earns trust, and keeps working for years.

For ThreatInsight, this means three promises. First, make the common path smooth, so that honest people barely notice the lookout. Second, make the hostile path firm, so that automated attackers meet a closed gate. Third, make the whole design easy to explain, so that a new colleague can read it in an afternoon and understand why each choice was made.