Account Banning

How Account Banning Works

Failed sign-ins are counted against the account as well as the address. Both rules run, and either can trigger.

Where to find it

Architect Panel → Security:

• Security Settings — Enable User Account Banning, Attempts, Monitoring Period and Ban Length
• Blocked User Accounts — accounts currently banned
• Blocked IP Addresses — the address-level equivalent

The rule

The same three settings as address banning, applied to the account: Attempts (ships at 10), Monitoring Period (600 seconds) and Ban Length (600 seconds). It is enabled by default.

What it catches that address banning misses

An attacker rotating through addresses defeats the address rule completely — each address stays under the threshold. But if they are working against one account, the failures accumulate against that account regardless of where they came from.

This is the important complement. Address banning stops crude attacks from one source; account banning stops distributed attacks on one target. Neither covers the other, which is why both are on.

What neither catches

Credential stuffing — one password tried against thousands of accounts — stays under both thresholds. Each account sees one failure and each address may see only a few.

Nothing in this pair of settings addresses that. Two-factor authentication and passkeys do, which is the honest recommendation rather than tightening these numbers.

Banned is not disabled

Worth being precise, because the two are separate and produce the same complaint:

• Banned — automatic, temporary, a security response to failed attempts. Clears itself.
• Disabled — an administrative decision, recorded with a reason and who made it, and it stays until reversed.

Check which one you are looking at before acting. Unbanning a disabled account achieves nothing, and enabling a banned one is unnecessary.

Denial of service against a person

Account banning has a genuine downside: anybody who knows a username can lock that person out by failing to sign in as them repeatedly. A short ban keeps that to a nuisance; a long one turns it into a weapon.

This is the reason to keep account ban lengths shorter than address ban lengths, which is the opposite of the instinct.

Watch for repeatedly banned accounts

One account banned again and again is either somebody being targeted or somebody with a saved password that is now wrong — an old mobile client retrying every few minutes will do it indefinitely. Both are worth a conversation.

Worked example

An administrator's account is targeted from dozens of addresses. No single address reaches the address threshold, but the account reaches its own after ten attempts and bans repeatedly. The pattern is visible in the blocked account list, prompting the organisation to require a second factor for administrators — which ends the exposure properly rather than by tuning.

Recommendations

• Keep both rules enabled. They cover different attacks.
• Keep account bans shorter than address bans.
• Distinguish banned from disabled on every lock-out report.
• Investigate repeatedly banned accounts rather than clearing them.

Tuning Account Banning

The settings look identical to the address ones. The reasoning behind them is not.

Where to find it

Architect Panel → Security:

• Security Settings — the three account banning settings
• Blocked User Accounts — the effect
• Two-Factor Authentication — the control that actually solves this

The asymmetry that matters

With address banning, a longer ban costs the attacker a lot and a legitimate user very little.

With account banning it is the reverse. A long ban on an account is a long lock-out for its owner — and because anybody who knows a username can trigger it deliberately, a long account ban hands out a denial-of-service tool for free.

So: lengthen address bans, keep account bans short.

Sensible ranges

• Attempts — 5 to 15, as with addresses.
• Monitoring Period — 5 to 30 minutes.
• Ban Length — 5 to 15 minutes. Rarely longer.

Do not disable it to stop the complaints

If lock-outs are generating support volume, the causes are usually a saved credential somewhere retrying, a shared account several people use, or a password policy people cannot comply with. Each has a proper fix.

Turning the rule off removes the symptom and the protection together, and it is the change most likely to be regretted.

Shared accounts are the usual culprit

An account several people use will trip the rule constantly, because a failure by any one of them counts against all of them. It is also poor practice for every other reason — the audit trail cannot attribute anything.

Repeated bans on one account are often the first visible symptom of account sharing, and worth following up as such.

When an account is being targeted

Tuning is not the answer. In order of usefulness: require a second factor on that account, check whether the username is unnecessarily guessable, and look at whether the address-level rule can be tightened for the administrative surface specifically.

Consider the administrative surface separately

Administrator accounts are what attackers want and are few enough that stricter settings cost little. Where you can apply a stricter posture to that surface, do — and leave the general settings suited to the people who will actually trip them.

Review after changing

Watch the blocked account list and your support volume for a week. Both react quickly, and a change that produces neither effect probably did not need making.

Worked example

A helpdesk reports frequent lock-outs. Rather than raising the attempt count, the team looks at the blocked account list and finds three accounts responsible for most of it — two shared between staff, one with a stale credential in an old mobile app. The shared accounts are split into individual ones and the app is reconfigured. Lock-outs fall away without a single setting being changed.

Recommendations

• Keep account bans short — 5 to 15 minutes.
• Never disable the rule to reduce support calls.
• Look at which accounts are being banned before touching thresholds.
• Answer a targeted account with a second factor, not with tuning.