Secrets can be stolen, but habits are harder to copy. Behavior detection uses habits as a clue about who is really at the keyboard.

The Problem With Secrets Alone

A password is a secret. A code from a phone app is also a secret, valid for a short time. Secrets share one weakness: anyone who learns the secret can use it, and the system cannot tell the difference. Attackers have many ways to learn secrets. They send fake login pages that collect passwords and codes in real time. They buy lists of leaked passwords and try them everywhere. They steal session tokens from infected computers. They trick tired employees into approving a push notification at midnight.

Because secrets can be copied, a careful system looks for extra evidence. One of the best sources of evidence costs the user nothing, because it comes from how they already behave: where they sign in from, what device they use, how fast they seem to move around the world, and what network they come from.

Habits Are Hard to Fake

People are creatures of habit. An attacker in another country can copy a password, but cannot easily copy the victim’s home city, their usual laptop, or the rhythm of their week. Behavior signals do not prove identity. They shift the odds. A sign-in that matches history is probably genuine. A sign-in that breaks every habit at once deserves a second look.

What It Costs to Ignore Behavior

The name sounds grand, which invites wrong ideas. Let us set the boundaries clearly.

What It Is

Behavior detection in Okta is a way to define named behaviors, such as “the sign-in comes from a place the user has not used recently.” Each time someone signs in, Okta can evaluate those behaviors against that user’s recent history, and report whether the behavior was seen. Administrators then use that result as a condition in a policy rule. For example: “if the sign-in is from a new device, ask for an extra factor.”

What It Is Not

• It is not artificial intelligence reading minds. The built-in behaviors are straightforward comparisons with recent history, with a few adjustable settings.
• It is not a replacement for multi-factor authentication. It decides when to ask for more, not whether to ask at all.
• It is not a firewall. It evaluates sign-ins to Okta. It does not watch traffic inside your network.
• It is not perfect. It can miss clever attackers and can flag honest users, which is why tuning and fallback paths matter.
• It is not a complete risk engine. Okta has other signals, such as ThreatInsight, network zones, and device checks, that work alongside it. Their exact packaging varies, so confirm in current documentation.

Detection Versus Response

Two separate jobs are involved. Detection decides that a sign-in looks unusual. Response decides what to do about it. Okta’s behavior rules do the first job. Your policies do the second. Keeping these apart is useful: you can improve how you detect without changing how you respond, and you can try different responses for different groups.

A handful of terms carry the whole subject. We define each one in plain words, with an example from Brightline.

Why “Unusual” Is Not “Bad”

This distinction is the heart of the subject. Most unusual sign-ins are innocent: a new phone, a holiday, a coffee shop, a changed home internet provider. Most attacks are unusual, but not all unusual sign-ins are attacks. The goal is not to block everything unusual. The goal is to ask a little more of those who are unusual, so that honest people pass with a small nudge and attackers are stopped.

A few honest questions up front prevent weeks of rework. If you cannot answer one, that is your first task.

Okta offers several pieces that are easy to mix up. Knowing which does what keeps the design clear.

The Pieces

Okta may also offer risk scoring that combines several signals, and products evolve. The names and bundling can change, so always check which capabilities your edition includes.

Where Behaviors Are Used

Behavior results are used as conditions in policy rules. Depending on your Okta version and policy type, that can mean rules that govern access to a specific application, rules that govern the overall session, or other places that accept a behavior condition. In the policy rule, an administrator picks one or more named behaviors and decides what to do when they match.

flowchart LR
    SI["Sign-in attempt"] --> BR["Behavior rules: compare with user history"]
    SI --> NZ["Network zones: known or blocked places"]
    SI --> TI["ThreatInsight: hostile address signal"]
    SI --> DV["Device checks: managed or not"]
    BR --> POL["Policy rule evaluation"]
    NZ --> POL
    TI --> POL
    DV --> POL
    POL --> OUT["Allow, step-up, or deny"]
    POL --> LOG["System Log record"]
    

Okta provides a small set of ready-made behaviors. Here is what each one asks, when it helps, and where it can mislead. Names and availability can vary, so confirm in the admin console and current documentation.

Result Values

When Okta evaluates a behavior for a sign-in, the outcome is typically one of a few states: the behavior was detected, it was not detected, or there was not enough information to tell. That third state matters. A brand-new account has no history, so almost everything looks new. Good designs plan for the “not enough information” case rather than ignoring it.

Let us open the box and name the parts that cooperate when a sign-in is judged.

flowchart TD
    U["User signs in"] --> CC["Context collector"]
    CC --> BE["Behavior evaluator"]
    HS["Per-user history store"] --> BE
    BE --> PE["Policy engine"]
    ZN["Network zones"] --> PE
    GRP["Group and app context"] --> PE
    PE --> AF["Authentication flow: allow, step-up, deny"]
    AF --> HS
    PE --> EL["Event logger: System Log"]
    EL --> SIEM["Security monitoring tools"]
    

The feedback arrow from the authentication flow back to the history is important. Each completed sign-in becomes part of the user’s future baseline. That means the baseline adapts as habits change, but it also means a patient attacker who gets in once can begin to look normal.

The cleverness of behavior detection is in a simple idea: remember the last few sign-ins, and compare the new one with them.

The Lookback Window

For each behavior, Okta looks back over a number of the user’s previous sign-ins, not forever. The number is a setting, with a default and a maximum, which you should check in current documentation. If the window is small, the baseline is short-lived, so a place visited three months ago looks new again. If the window is large, the baseline is generous, so an attacker’s earlier success may blur into the user’s normal pattern.

Step by Step: Is This Device New?

How Velocity Works

Velocity is a different kind of test. Instead of asking “have I seen this?”, it asks “could the person have physically got here?” Okta estimates the distance between the previous sign-in’s location and the current one, divides by the time between them, and compares the speed with a threshold. If the implied speed is faster than a plane could travel, the behavior is detected. The threshold is a setting, and Okta has documented a default near typical airliner speed. Confirm the current value.

Velocity depends on location estimates from network addresses, which are approximate. A mobile network may route traffic through a gateway in a distant city. A company VPN may exit in another country. These cases can make honest users look like teleporters, which is why Velocity should rarely be the only reason to deny access.

Let us follow Priya’s Saturday-night attacker through the system, step by step, and see where the rules do their work.

sequenceDiagram
    participant A as Attacker
    participant O as Okta sign-in
    participant B as Behavior evaluator
    participant P as Policy engine
    participant L as System Log
    participant M as Monitoring tool
    A->>O: Enter Priya password
    O->>B: Evaluate behaviors for Priya
    B-->>O: New location, new device, velocity detected
    O->>P: Evaluate rules with behavior results
    P-->>O: Rule says deny and notify
    O-->>A: Access blocked
    O->>L: Record behaviors and decision
    L->>M: Stream event
    M-->>M: Raise alert for security team
    

The Lifecycle of One Behavior Result

One subtle point: whether a failed or blocked attempt becomes part of the baseline is a detail of the product, and it matters. If blocked attempts were added to the baseline, an attacker could “train” the system by trying repeatedly. Check current documentation about what counts as history, and design on the safe side by assuming only successful sign-ins should shape trust.

A behavior rule on its own does nothing. It becomes useful only when a policy rule reads it and acts. This chapter shows how to build those policy rules sensibly.

How a Policy Rule Reads a Behavior

A policy is an ordered list of rules. Okta checks the rules from top to bottom and applies the first one whose conditions all match. A condition can be a group, a network zone, a device state, an application, or a behavior. So a rule might read: “For members of the Employees group, when the sign-in is on a new device, require a second factor of the strongest type.” Below it, a general rule might read: “For members of the Employees group, otherwise, allow with the standard factor.”

Order Is Everything

Because the first match wins, the order of rules decides the outcome. A broad rule placed too high will swallow everything and the careful rules below it will never run. Put the most specific and most protective rules first, and the general fallback last. Always leave a clear catch-all at the bottom so that nobody falls through to an unintended default.

flowchart TD
    S["Sign-in with behavior results"] --> R1{"Rule 1: admin group AND any behavior detected?"}
    R1 -->|"Yes"| A1["Require phishing-resistant factor, short session"]
    R1 -->|"No"| R2{"Rule 2: any user AND velocity detected?"}
    R2 -->|"Yes"| A2["Deny and notify security"]
    R2 -->|"No"| R3{"Rule 3: any user AND new device or new location?"}
    R3 -->|"Yes"| A3["Require extra factor"]
    R3 -->|"No"| R4["Rule 4: default allow with standard factor"]
    

Common Response Choices

Default settings are a starting point. Tuning is how you fit the rules to your own people, and it is where most of the value, and most of the mistakes, are found.

The Main Dials

The Strictness Trade-off

Stricter rules catch more attackers but challenge more honest people. Relaxed rules annoy fewer people but let more attackers slip by. Nothing removes this trade-off. What you can do is choose a different point on the line for different groups: strict for administrators and finance staff, relaxed for low-risk content apps.

A Safe Tuning Loop

Let us walk through the work of an administrator who wants to ask for an extra factor on a new device. Menu names change between versions, so follow the idea and confirm exact labels in your own console.

Naming and Documentation

Good names save hours later. A rule called “Rule 7” tells nobody anything. A rule called “Tier 1 apps: step-up on new device or country” explains itself. Add a description naming the owner, the purpose, the date created, and the date to review. Treat each rule as a small product that others will have to understand.

A single warning light can mislead. Several lights together tell a clearer story. Smart rule design combines signals so that each covers the weakness of another.

Why Combine

New IP alone is noisy because home internet addresses change. New device alone is noisy because people buy phones. But new IP plus new device plus a location far from any previous one is rarely a coincidence. Combining raises confidence without raising the false alarm rate.

Useful Combinations

Trusted Context Lowers Suspicion

Combining works in the friendly direction too. If a sign-in comes from a company-managed laptop, or from a known office network, a new-IP flag becomes much less worrying. A good policy lets trusted context override a mild behavior signal, so that employees on managed devices are rarely bothered, while unmanaged devices face more questions.

A sign-in is not one moment. It starts a session that may last hours, and a good design thinks about the whole span.

Three Points of Decision

Why Use More Than One

Suppose Priya’s attacker gets past entry because he looked normal. At the payments application, a stricter policy notices that the session started from a new device and demands a fresh strong factor. Even if the front door was weak, the second door catches him. Layers matter because no single decision is perfect.

Session Length as a Risk Dial

Behavior results can influence how long a session lasts. A sign-in that matches history may keep a normal session length. A sign-in with a mild flag may get a shorter one, so the user is asked again sooner. This limits how long a stolen session is worth anything, at little cost to the honest user.

flowchart TD
    E["Entry to Okta: behavior-based session policy"] --> S["Session starts with length based on risk"]
    S --> A1["Open low-risk app: allow"]
    S --> A2["Open critical app: new check if behavior flagged"]
    A2 --> ACT["Sensitive action: ask again"]
    

Not every application deserves the same protection. A tiered design keeps the strongest rules where the damage would be greatest.

Sort Applications and People

Begin by sorting applications into tiers by how much harm a stolen account could do. Then identify groups of people whose accounts are especially valuable, such as administrators, finance, and executives. Rules are then assigned by tier.

flowchart LR
    APPS["Applications"] --> T1["Tier 1: strict behavior rules"]
    APPS --> T2["Tier 2: moderate behavior rules"]
    APPS --> T3["Tier 3: log and light rules"]
    T1 --> ADM["Admins, finance, executives"]
    T2 --> STAFF["General staff"]
    T3 --> ALL["Everyone"]
    

A wrong rule can lock out a whole company on a Monday morning. Safe rollout is about making mistakes small and reversible.

A Staged Plan

What to Test

• Known-good cases. Regular sign-in from the usual place and device should pass without extra steps.
• Mild anomalies. New device alone should lead to the expected step-up, and the user should be able to complete it.
• Strong anomalies. A simulated far-away sign-in should reach the deny or strong step-up rule.
• Emergency access. Sealed break-glass accounts must still work. Rules should be written so they cannot lock administrators out of the system.
• Users with no history. New hires should get a friendly path, not a wall.

If honest people are repeatedly challenged for no good reason, they will resent the system and find ways around it. A behavior program lives or dies on how gracefully it treats the innocent.

Why Honest People Get Flagged

Designing a Kind Experience

• Prefer a challenge to a block. A step-up that the honest user can complete in seconds is much cheaper than a lockout and a ticket.
• Explain the reason. A short message such as “We noticed a new device, so we need one more check” removes confusion.
• Remember good devices. After a successful step-up, let the user mark the device as familiar so they are not asked again each day, within your risk limits.
• Provide a fast fallback. If a user cannot complete the step-up, give them a clear path to the help desk with identity checks.
• Give help desk staff visibility. A one-page guide showing how to read the log entry and verify the person.
• Feed back. Track frequent false positives by cause and fix the rule, not the user.

flowchart TD
    FLAG["User challenged by behavior rule"] --> OK{"Completes step-up?"}
    OK -->|"Yes"| PASS["Signed in; remember device if allowed"]
    OK -->|"No"| HELP["Contact help desk"]
    HELP --> VER["Verify identity with strong checks"]
    VER --> RES["Reset factor or unlock account"]
    RES --> REV["Record cause and review rule if common"]
    PASS --> REV
    

Rules make more sense when you can picture the attacker. Here are common attack shapes and what the behavior signals look like for each.

Reading the Table Honestly

Notice the row on insider misuse: behavior detection can do little there. The insider signs in from the usual place with the usual device. This is not a flaw in the idea. It is a reminder that no single control covers all threats, and that governance and activity monitoring fill gaps that sign-in checks cannot.

Knowing what a control cannot do is as important as knowing what it can. These are the places where behavior detection is weak.

Where It Struggles

• Attackers who blend in. Using a VPN exit in the victim’s city, or malware on the victim’s own computer, makes the sign-in look familiar.
• Location accuracy. Network address location is approximate and sometimes wrong, especially on mobile networks and corporate proxies.
• Thin history. New employees and rare users have little baseline, so signals are either noisy or silent.
• Shared infrastructure. Many people behind one office address or cloud desktop pool blur the picture.
• Only sign-in time. The rules look at the moment of authentication, not at what a user does afterward inside an application.
• Baseline poisoning. An attacker who succeeds once may become part of the user’s normal history.
• Not every flow is covered. Some protocols or older applications may not pass through the same policy evaluation. Confirm which flows your rules apply to.

A few wrong beliefs cause most of the disappointment. Clearing them up early saves effort.

An attacker who takes over an administrator gains the power to change the rules themselves. Admin accounts deserve the strictest behavior policy in the company.

Why Admins Are Different

A normal account can read some data. An administrator can create accounts, change policies, switch off protections, and read logs. Attackers aim at administrators first, and when they succeed, every other control is in danger. Admin sign-ins are also few and predictable: the same people, from the same devices, at similar times. That predictability makes behavior rules unusually accurate for administrators, with a low false alarm rate.

A Strict Pattern for Admin Sign-In

• Require a phishing-resistant factor every time, not just when behavior is unusual.
• Treat any detected behavior as a reason to deny or require approval from a second administrator.
• Allow admin sign-in only from managed devices or named networks.
• Use short sessions and ask again before sensitive actions.
• Use dedicated admin accounts that never read email or browse the web.
• Alert security immediately on any admin sign-in that triggers a behavior.

flowchart TD
    AS["Admin sign-in"] --> D{"Managed device or named network?"}
    D -->|"No"| DEN["Deny and alert"]
    D -->|"Yes"| BH{"Any behavior detected?"}
    BH -->|"Yes"| SEC["Alert security and require second admin approval"]
    BH -->|"No"| PR["Phishing-resistant factor"]
    PR --> SH["Short session"]
    

Real workforces are not neat. Travelers, remote workers, contractors, and shared kiosks each break assumptions that behavior rules quietly make.

Group-Based Rules

Because policy rules can target groups, you can give each population its own sensible setting. A travelers group can have a more forgiving location rule and a stricter device rule. A contractors group can have a lighter behavior rule but a stronger default factor. This keeps the overall design simple while respecting differences.

Pre-Announced Travel

Some companies allow staff to register trips in advance, which temporarily widens the allowed locations for that person. This reduces false alarms but must be time-limited and logged, or it becomes a new weakness.

Behavior detection produces evidence in every sign-in. Reading it turns the feature from a silent filter into a learning system.

What the Logs Contain

Okta’s System Log records sign-in and policy evaluation events. Entries for sign-ins and policy evaluation usually include details about the client, the location, the device, and which behaviors were evaluated with their results. The exact field names and event types can change, so inspect real events in your own org and confirm in current documentation. Send logs to a long-term store or security monitoring tool, because the built-in retention period is limited.

Metrics Worth Tracking

Alerts Worth Having

• Any administrator sign-in with a behavior detected.
• A sudden rise in detections across many users, which may signal an attack campaign or a broken network change.
• Step-up failures from many users from the same address range.
• A behavior rule or policy rule edited, created, or deleted.
• The same user with detections from several countries in a short time.

flowchart LR
    SL["Okta System Log"] --> ST["Streaming or export"]
    ST --> SIEM["SIEM or log platform"]
    SIEM --> DASH["Dashboards: detections, step-ups, denies"]
    SIEM --> ALR["Alert rules"]
    ALR --> SOC["Security team"]
    DASH --> TUNE["Monthly tuning review"]
    

The same idea works differently when the users are customers instead of employees. The goals shift from protection against targeted attackers to protection against mass automated abuse, without harming sign-up and conversion.

Okta offers a separate product line for customer identity. Its features and behavior options may differ from the workforce product, so verify what is available before designing. The principle stays the same: look at context, measure unusualness, and add friction in proportion.

Lessons for Customer Scenarios

• Customers sign in rarely, so baselines are thin, and many first-time-looking sign-ins are honest. Lean on other signals such as address reputation and attempt rates.
• A single bad outcome may be a lost customer, so prefer a gentle challenge to a hard block.
• Bots send huge numbers of attempts, so rate limits and address reputation matter as much as per-user behavior.
• Staff who access customer systems should still follow the strict workforce patterns.

When an alert fires, the analyst needs a calm, repeatable routine. A written playbook turns a stressful moment into a checklist.

The Questions to Ask, in Order

Detecting a threat at 3 a.m. is only useful if something happens next. Automation can take the first, safe steps while humans wake up.

Safe Automated Reactions

Where Automation Comes From

Okta supports event hooks and a no-code automation tool called Workflows, and log streaming to external tools lets a security platform run its own responses. Features and limits change, so confirm in current documentation. Whatever you use, apply the same guardrails: cap how many accounts one run can change, prefer reversible actions such as suspension over deletion, log every automated action, and give each flow an owner.

sequenceDiagram
    participant O as Okta
    participant W as Automation flow
    participant U as User
    participant S as Security team
    O->>W: Event: risky sign-in blocked for Priya
    W->>U: Message: was this you?
    W->>S: Alert with details
    U-->>W: No, not me
    W->>O: End sessions and require password reset
    W->>S: Update case: user confirmed attack
    

Whoever can edit the rules can quietly switch off the protection. The rules need guarding just like the accounts they protect.

Good Habits

• Few policy admins, each with a dedicated account and strong factors.
• Written design describing each rule, its purpose, its owner, and its review date.
• Peer review for every change, with a record of who approved it.
• Configuration export kept in version control or a safe archive, so changes can be compared and restored.
• Regular access review of who can edit policies and zones.
• Sealed emergency accounts excluded carefully from behavior rules, protected with strong controls, monitored, and tested on a schedule.

Behavior detection uses information about where and how people sign in. That is personal data, and handling it respectfully is both a legal and an ethical matter.

What Data Is Involved

Network addresses, approximate locations, device characteristics, and times of sign-in are all personal data in many jurisdictions. Collecting them for security is generally an accepted purpose, but you should still apply the usual principles: collect what you need, use it for the stated purpose, keep it only as long as necessary, and protect it.

Practical Responsibilities

• Be transparent. Tell employees what is observed during sign-in and why, in the acceptable use or privacy notice.
• Limit access to logs. Only security and a few administrators should read detailed sign-in records.
• Set retention. Keep detailed records as long as security needs and policy allow, then delete.
• Check regional rules. Works councils, data protection laws, and employment rules in some countries restrict employee monitoring. Involve legal and privacy teams.
• Avoid unfair patterns. If rules challenge certain groups far more often, such as staff in regions with poor location data, examine whether the rule is fair and fix it.
• Do not repurpose. Sign-in data collected for security should not become a tool for measuring productivity or attendance.

Behavior evaluation happens during sign-in, so it must be quick and dependable. This chapter covers how the feature behaves at scale and what to plan for when something goes wrong.

Scale Considerations

• Evaluation is per sign-in. Okta runs it as part of the authentication path. You do not size servers for it, but you should be aware of sign-in surges at the start of shifts and after holidays.
• History is bounded. Because Okta looks back over a limited number of sign-ins, the work per sign-in stays small.
• Log volume grows. Streaming every event to a monitoring platform can be costly. Filter to the event types you need.
• Rate limits. Automation that calls Okta APIs can hit rate limits during an attack wave. Design flows to back off and retry.
• Many orgs. If you run several Okta orgs, behavior settings do not travel between them. Keep a baseline document or configuration export so they stay aligned.

Failure Scenarios

An honest balance sheet helps you decide how much to rely on behavior rules and where to add other controls.

Main Trade-offs

Behavior detection is one of the clearest practical examples of a famous security idea: never trust, always verify.

The Idea in Plain Words

Old security thinking said that anyone inside the office network could be trusted. Zero Trust says nobody is trusted merely because of where they are. Every request is judged on identity, device, context, and risk, each time. Behavior rules supply the context part: they let the system keep asking, quietly, whether this request fits what is known about the person.

How Behavior Fits the Pillars

Nobody gets the perfect rule set on day one. A simple path shows where you are and what to do next.

The First 90 Days

flowchart LR
    A["Level 2: strong factors"] --> B["Observe: log-only behaviors"]
    B --> C["Pilot: step-up for small group"]
    C --> D["Roll out in waves by tier"]
    D --> E["Monitor and tune monthly"]
    E --> F["Automate first response"]
    

Good habits to copy, and common mistakes to avoid.

Patterns That Work

Anti-Patterns

Most failed behavior projects do not fail on big ideas. They fail on small details that nobody wrote down.

A short list to check before launch and again every quarter.

Design

• Applications and groups are sorted into risk tiers, each with a matching policy.
• Behaviors are combined with network zones, device checks, and strong factors.
• Rule order is documented, with specific rules above general ones and a clear default at the bottom.
• Special groups such as travelers, contractors, and kiosks have deliberate settings.

Rollout

• New rules start in log-only mode and move to enforcement in small waves.
• A rollback plan exists and the people who can use it are named.
• Emergency accounts are sealed, monitored, and tested.
• Staff receive a short, clear message about what they may see and why.

Operations

• Logs are streamed to a monitoring platform with alerts on admin detections and rule changes.
• Metrics have an owner and a monthly review meeting.
• The help desk has a guide and a strong identity-check process.
• Automation has caps, logs, and owners, and starts with notifications.

Protection of the System

• Policy administrators are few and use strong, dedicated accounts.
• Policy and zone changes are reviewed and exported for comparison.
• Exceptions are registered with an owner and end date.
• Legal and privacy teams have approved the data use and retention.

Behavior rules, network zones, ThreatInsight, and device checks overlap a little but are not the same. Picking the right one for each question keeps designs simple.

The table shows that behavior rules answer a narrow question well: is this normal for this person? They are weaker at answering questions about the device’s health or the address’s reputation, which other signals handle better. Good designs use each tool for what it does best and combine the answers in policy.

A Simple Decision Habit

• Write the question in one plain sentence before choosing a signal.
• If the answer depends on one person’s history, reach for a behavior rule.
• If it depends on where the traffic comes from in general, use zones or reputation.
• If it depends on the machine, use device checks.
• If it is about who may use the application, use groups and assignments.

Let us put the pieces together by designing one complete rule set for Brightline, step by step, the way a working team would.

Step 1: State the Goals

Brightline wants to stop account takeover on its payment, customer data, and admin systems, keep day-to-day friction low for 4,000 employees, and show auditors that sign-in risk is managed. These goals are written down first because they tell you what to trade off when rules conflict.

Step 2: Define the Context Tools

The team defines network zones for its three offices and its VPN exit addresses. It marks company laptops as managed. It creates three groups: Administrators, Finance, and Everyone else. It lists applications into three tiers.

Step 3: Write the Rules for the Strictest Tier

Step 4: Write the Rules for the Middle Tier

Step 5: Keep the Lowest Tier Light

For the intranet and learning portal, the team enables no challenge based on behavior. It logs behavior results so the data can inform tuning, and only requires extra proof when Velocity and a new device appear together.

Step 6: Add Monitoring and Review

Alerts are created for admin detections and rule changes. A monthly meeting reviews the key metrics. A quarterly review asks whether networks, offices, or VPN providers have changed.

flowchart TD
    G["Goals: stop takeover, low friction, audit proof"] --> C["Context: zones, managed devices, groups, tiers"]
    C --> R1["Tier 1 rules: strict"]
    C --> R2["Tier 2 rules: moderate"]
    C --> R3["Tier 3 rules: light"]
    R1 --> M["Monitoring and alerts"]
    R2 --> M
    R3 --> M
    M --> T["Monthly tuning and quarterly redesign"]
    T --> C
    

Stories from the fictional Brightline Credit Union show the rules at work. All figures are illustrative, chosen to show the method and not to describe a real organization.

Worked Numbers: Honest Users Versus Attackers

Suppose Brightline has 4,000 employees, each signing in about 20 times a month, which is 80,000 sign-ins. In log-only mode, the team counts how often each behavior is detected.

If every New IP detection triggered a challenge, roughly 9,600 challenges a month would land on honest users, and nearly all would be pointless. Using only device and country-level location for step-up leads to about 3,000 challenges, and Velocity combined with another signal might add only a few dozen denials for human review. The attack traffic hides in a small part of these numbers, so rules that pick that small part cleanly are worth far more than rules that fire often. These counts are invented for illustration, so measure your own.

A quick reference for the words used in this guide. Keep it handy when reading logs or talking to colleagues.

Behavior detection gives your sign-in system the shopkeeper’s instinct: a correct secret is not enough if everything else about the visit looks wrong. Used with care, it protects people quietly and stops attackers loudly.