# Security settings

Instance-wide security settings live on **Instance** › **Security**. They apply to every organization on your server.

- To see the page, you need the **View security settings** permission.
- To change anything on it, you need **Manage security settings**. Without it, the page is read-only and says so at the top.

Each settings card has its own **Save** button, and a **Discard** button appears while it has unsaved changes. Saving changes on this page is a high-risk action, so Blink may ask you to confirm with a passkey or code.

## Join codes

A join code is what a customer types to join a Support session. Under **Join codes**, choose:

- **Format**: **Digits** (easiest to read out over the phone) or **Letters and digits**. Codes with letters leave out I, L, O and U, so nothing reads as 1 or 0, and case does not matter.
- **Length**: 6 to 12 characters for digits, 5 to 10 for letters and digits. The default is 9 digits.

The **Preview** shows an example code and how many different codes the format allows. Longer codes are harder to guess. Select **Save format**.

Codes already given out keep working until they expire.

## Sign-in lifetime

**Sign-in lifetime (days)** sets how long one console sign-in lasts. After it, the browser has to sign in again with password and second factor, however active it was. Choose 1 to 365 days; the default is 30.

A shorter value also applies to sign-ins that are already running.

## IP and country rules

The **IP and country rules** card decides where the console can be used from: sign-in, the API and live viewing. When it has entries, every user, the Owner included, needs an address or country listed there, and changes apply at once. Blink won't save a rule that would lock you out from the address you are connecting from.

See [Restrict access by IP address and country](/configure/ip-and-country-rules/).

## Confirming high-risk actions

Some actions need a fresh passkey or code from the person signed in, so a stolen sign-in alone can't do them: opening a terminal, Backstage tools as SYSTEM, a Safe Mode reboot, Install Access, changes to roles, members, users and two-factor, changes on the Security page, changes to an organization's agent IP rule, revoking or deleting a device, and changes to the instance identity and keys.

Under **A confirmation lasts**, choose one:

- **Once per sign-in**: the sign-in itself counts. People are asked again only after signing in with a recovery code.
- **For a number of minutes**: 1 to 1440 minutes. People are asked again once their last confirmation is older. This is the default, set to 15 minutes.
- **For a number of actions**: 1 to 100. People are asked again after that many high-risk actions. Set it to 1 to ask every time.

The line under the choices sums up the setting in one sentence.

:::note
Loosening this setting raises an owner alert. See [Owner alerts and webhooks](/configure/alerts/).
:::

## Fleet limits

Fleet limits cap how many of these one person may start in any hour, across every organization and device:

- **Access sessions per hour** (default 60)
- **Reboots per hour** (default 20)
- **Chats started per hour** (default 60): chats with a device's signed-in user before a session. See [Chat before you connect](/use/chat/#chat-before-you-connect).

Past a limit, the next one is refused and the instance owners get an alert. Enter `0` for no limit. Loosening a limit also raises an owner alert.

## Chat

The **Chat** card sets how long a [secret message](/use/chat/#secret-messages) waits to be opened. It appears when your plan includes **Secret messages**.

Under **Secret messages expire after**, choose **5 minutes**, **15 minutes** (the default) or **60 minutes**. Technicians can pick another lifetime for each secret they send; secrets from the customer always get this one. The change applies to secrets sent after you save.

A secret message can be viewed once and is never stored.

## Rate limits

Rate limits protect the public parts of Blink from guessing and abuse. The **Rate limits** table has one row for each of:

| Route | Counts |
|---|---|
| **Join codes** | failed codes |
| **Sign-in** | attempts; wrong passwords ban |
| **Two-factor** | attempts; wrong codes ban |
| **Device enrollment** | attempts; unknown keys ban |

For each route you can set:

- **Per address**: the budget for one address (an IPv4 address, or an IPv6 /64).
- **Per network**: the budget for one network (a /24 or a /48). It must be at least the per-address budget.
- **Global alert**: a server-wide count of failures that only raises an alert in the activity log. It blocks nobody. It must be at least the per-network budget.
- **Window (s)**: the time window the budgets count in, 10 seconds to 1 day.
- **Lockout (s)**: how long a ban lasts, 10 seconds to 30 days.
- **Per account** (Sign-in and Two-factor only): a count and its own window in seconds. Wrong passwords per email and address lock that email from that address. Wrong two-factor codes per user lock the account until the window ends, from every address except allowlisted ones.

How they behave:

- Failures that use up a budget ban the address or network for the lockout.
- Sign-in, two-factor and enrollment also turn away attempts past the budget until the window ends, without a ban, because successful attempts count there too.
- Sign-in and two-factor failures are kept across server restarts.

:::tip[Enrolling many devices from one site]
Enrollment counts every attempt from an address. If you enroll many devices from one network at once, add that network to the [allowlist](#allowlist) first.
:::

### Agent connections

The **Agent connections** table limits connections from **Support agents**, **Access devices** and **Terminals** that have not yet proved who they are: how many may be open per address and on the server, how many failures per minute are allowed, and how long a failing address is blocked. When your server restarts, every agent reconnects at once, so keep these caps generous.

Select **Save limits** to save both tables, or **Restore defaults** to go back to the built-in values. If a field is out of range, it is highlighted; hover over it to see the allowed range.

## Bans

The **Bans** card lists the addresses and networks refused right now, with the reason, the **Source** (the route whose limit banned it, or **Manual**), when the ban expires, and how many requests it has refused.

- A ban from a rate limit refuses only that route.
- A manual ban refuses every route.

To ban an address or network yourself:

1. Under **Bans**, enter the **Address or network**, for example `203.0.113.7` or `203.0.113.0/24`.
2. Optionally enter a **Reason**.
3. Under **For**, choose **1 hour**, **1 day**, **7 days**, **30 days** or **Until removed**.
4. Select **Ban**.

To end a ban early, select **Lift** on its row. Select the refresh icon to update the list.

:::caution
Be careful not to ban your own office network. If your team is locked out by a rate limit, an instance administrator signed in from elsewhere can lift the ban.
:::

## Allowlist

The allowlist holds trusted networks, such as your office. Addresses on it are never banned and are not counted per address or per network. The global alert and the server-wide caps still count them.

The allowlist only exempts addresses from rate limits and bans. Who may use the console at all is decided by the [IP and country rules](#ip-and-country-rules).

1. Under **Allowlist**, enter the **Address or network**, for example `198.51.100.0/24`.
2. Optionally add a **Note**, such as the office name.
3. Select **Add**.

To take a network off the list, select **Remove** on its row. The list holds up to 200 entries.

## Support session timeout

A Support session stays open after the technician closes the viewer, so they can come back to it. Under **Support sessions**, set **End after no viewer for (minutes)** to end a session automatically when nobody has watched it for that long. The customer sees the session end.

Enter `0` (never) to keep sessions open until someone ends them. The maximum is one week (10080 minutes).

## Network settings

The last cards on the page, **Media connections** and **TURN relay**, control how screen, audio and input traffic reaches your server when a direct connection is blocked. On Blink Cloud, these are managed for you and show **Managed by Blink Cloud**. If you run Blink on your own server, see [Install](/install/) for the network setup.