## Rule overrides

Security engine decisions were previously all-or-nothing — changing a rule affected every user in the environment. **Rule overrides** let you skip or force a security rule action for specific users, tenants, or IP addresses, without changing the global rule configuration. Teams get fine-grained control where it matters most, while the rule still fires normally for everyone else.

### How overrides work

Overrides are configured **per security rule**, not globally. When a supported rule is triggered during authentication, Frontegg evaluates that rule's overrides **before** applying the rule's default action.

1. Overrides are checked in **priority order** (top to bottom in the portal).
2. The **first override whose conditions all match** wins — its action is applied and evaluation stops.
3. If **no override matches**, the rule runs with its normal global configuration.


**Logic within a single override:** every condition must match (**AND**).

**Logic across overrides:** each override is an independent match path (**OR**). Priority decides which one wins when more than one could match.

### Supported rules

Rule overrides are available in phase one for:

- Suspicious IP
- Breached password
- Device fingerprint
- Bot detection


Other security rules do not support overrides yet. On the **Security rules** page, the **Overrides** column shows how many override rules each supported policy has (`-` means overrides are not available for that rule).

![overrides-table](/assets/overrides-table.3c54995027fb12053b1c3c3e9c133ee14be3e65064c2c92adcce1e7008f74d57.36f325d1.png)

### Override actions

An override can force any action that the underlying rule already supports — and nothing more.

| Rule | Allow | Challenge | Block | Lock |
|  --- | --- | --- | --- | --- |
| Suspicious IP | Yes | Yes | Yes | Yes |
| Bot detection | Yes | Yes | Yes | Yes |
| Breached password | Yes | Yes | Yes |  |
| Device fingerprint | Yes | Yes |  |  |


For end-user impact of each action, see the corresponding rule guide:

- [Suspicious IPs](/ciam/guides/security-center/security-rules/suspicious-ip)
- [Bot detection](/ciam/guides/security-center/security-rules/bot-detection)
- [Breached password](/ciam/guides/security-center/security-rules/breached-password)
- [Device fingerprint](/ciam/guides/security-center/security-rules/device-fingerprint)


### Targeting conditions

Each override defines one or more conditions. When **all** conditions in an override match, the override action is applied.

#### Available attributes

| Attribute | Available on | Description |
|  --- | --- | --- |
| **User email** | All four supported rules | The email address of the user attempting to authenticate |
| **Tenant ID** | All four supported rules | The tenant (account) the user belongs to |
| **IP address** | Suspicious IP only | The IP address the request originates from |


#### Operators

| Attribute | Operators |
|  --- | --- |
| **User email** | Is in list, Contains, Ends with |
| **Tenant ID** | Is in list, Contains |
| **IP address** | CIDR match (Suspicious IP only) |


You can invert any condition with **NOT** — the override applies when the condition does **not** match (for example, NOT Tenant ID is in list `tenant-abc` targets every user except those in that tenant).

#### CIDR match

Available only on **Suspicious IP**. Matches the request IP against one or more values you provide. Each value can be:

- A **single IP address** — for example, `203.0.113.45` or an IPv6 address
- An **IP range in CIDR notation** — for example, `203.0.113.0/24` matches every address from `203.0.113.0` through `203.0.113.255`


You can add multiple values to one condition. The condition matches if the request IP matches **any** of them.

Supported formats are the same as tenant IP restrictions: IPv4, IPv6, and CIDR notation.

#### Limits

| Limit | Value |
|  --- | --- |
| Overrides per rule | Up to 10 |
| Conditions per override | 1 to 5 |
| Values per condition | Up to 100 |
| Override name length | Up to 255 characters |


### Configure overrides in the portal

1. Open the **Frontegg portal**.
2. Go to **[ENVIRONMENT] → Configurations → Security → Security rules**.
3. Click **Manage** on a supported rule.
4. Open the **Override rules** tab.
5. Click **Add new rule** and configure:
  - **Name** — a display name for the override
  - **Conditions** — attribute, operator, and value (use **+ And** to add more conditions)
  - **Action** — Allow, Challenge, Block, or Lock (depending on the rule)
6. **Reorder** overrides to set evaluation priority — the first matching rule wins.
7. Click **Save changes**.


If no override rule matches, the engine applies its configured default action.

![overrides-config](/assets/overrides-config.2175db25bcde3fe48251c82faa06fecd6864db73e2860b89bb5338c67f2b961d.36f325d1.png)

Permissions
Users with an `Admin` role in the Frontegg account can configure security rules and overrides from the **Security rules** page within any environment.

### Examples

**Allow QA test accounts on bot detection**

Create an override on **Bot detection** with action **Allow** and a user email condition: `Ends with` → `@yourcompany-qa.com`. Bot detection still blocks other users according to the global rule.

**Challenge a specific tenant on breached password**

Create an override on **Breached password** with action **Challenge** and a tenant ID condition: `Is in list` → your tenant ID. Users in that tenant are challenged instead of receiving the global Block action.

**Allow a trusted office IP on suspicious IP**

Create an override on **Suspicious IP** with action **Allow** and an IP address condition: **CIDR match** → `203.0.113.0/24` (or a single IP such as `203.0.113.45`). Requests from that range bypass the global Block action; all other suspicious IPs are still handled by the rule.

### Overrides vs. bot detection ignored emails

**Bot detection** also supports an **Ignored emails** list on the rule itself, which lets specific email addresses bypass bot detection entirely.

Use **ignored emails** for a simple allow-list of test accounts. Use **overrides** when you need finer control — for example, forcing Challenge or Block for specific tenants, or combining multiple conditions (such as tenant ID and email) in one override.