Blocked User Accounts

Viewing Blocked Accounts

The blocked account register lists accounts currently banned after failed sign-ins.

Where to find it

Architect Panel → Security:

• Blocked User Accounts — accounts banned automatically or manually
• Disabled User Accounts — accounts disabled administratively — a different thing
• Blocked IP Addresses — the address-level register

What an entry records

• The account, by the platform's three-part identity — sign-in method, unique identifier and domain.
• The time it was blocked.
• A manual flag.

The three-part identity matters here: it distinguishes the same person arriving by different sign-in methods, so an account banned on one route is identifiable without ambiguity.

Blocked and disabled are different lists

This is the single most useful thing to know when handling a lock-out.

• Blocked — a security response to failed attempts. Usually automatic and temporary, with no reason recorded because there is nothing to record beyond "too many failures".
• Disabled — an administrative decision, held separately with a reason, a source, who changed it and when. It does not expire.

A leaver is disabled. Somebody who mistyped their password is blocked. They present identically to the user and are resolved completely differently.

Check three things on a lock-out

1. Is the account blocked?
2. Is their address blocked?
3. Is the account disabled?

Checking one and stopping is why lock-outs get reported as unresolved after somebody has already "fixed" them.

Reading the list

The same account appearing repeatedly is the pattern worth attention — a targeted account, a shared account, or a stale saved credential retrying somewhere. All three deserve action; none is fixed by clearing the block.

Automatic entries clear themselves

Leave them unless somebody is waiting. Ten minutes passes faster than a support ticket.

Worked example

A user reports being locked out for two days. The blocked account list is empty and the address list shows nothing — because the account had been disabled when they moved departments and their old role was closed. Two minutes in the right list, after twenty spent in the wrong ones.

Recommendations

• Check blocked, address and disabled — all three.
• Learn the blocked/disabled distinction and teach it to your service desk.
• Follow up repeatedly blocked accounts.
• Leave automatic blocks to expire unless somebody is waiting.

Unblocking an Account

Clearing a ban restores access immediately. The question is whether that is the right response.

Where to find it

Architect Panel → Security:

• Blocked User Accounts — where a ban is cleared
• Disabled User Accounts — where a disabled account is re-enabled instead

Architect Panel → Configuration:

• Site Settings — usually the better answer

Verify who you are talking to first

An unblock request is an access request, and it arrives by telephone or e-mail from somebody claiming to be the account holder. That is precisely the shape of a social engineering attempt — the attacker triggers the lock-out themselves, then calls to have it cleared.

Use whatever identity check you would use before a password reset. If you do not have one, that gap matters more than anything else in this article.

Ask why they failed

Before clearing anything:

• Forgot the password — reset it. Unblocking alone means they will fail again and re-ban within minutes.
• Password recently changed — something else is probably still using the old one.
• They were not trying — somebody else was. That is an incident, not a lock-out.

The third answer changes what you do entirely, and you only get it by asking.

Usually reset rather than unblock

The commonest cause is a forgotten password, and the ban is a symptom. Resetting fixes the cause and the ban lapses on its own.

Check whether it is a ban at all

If the account is disabled rather than blocked, unblocking does nothing. Re-enabling a disabled account is a separate, more considered decision — the reason it was disabled is recorded, and it should be read before reversing it.

Look for a stale credential

An account banning itself repeatedly, especially overnight, is almost always something automated still using an old password — a mail client, a mobile app, a script, an integration. The user is often unaware.

Clearing the ban fixes nothing here; the retry loop re-bans within minutes. Find the client.

Repeated unblocking is a signal

If the same account needs clearing regularly, stop clearing and investigate. Recurring manual intervention almost always means a stale credential, a shared account, or somebody being targeted — and each has a real fix.

Note what you did

Who asked, how you verified them, what you found and what you did. This is the record that matters if the request turns out not to have been genuine, and it takes a sentence.

Worked example

An account bans itself every twenty minutes overnight. The helpdesk clears it three times before anybody asks why. The user changed their password a week earlier and a tablet mail client still holds the old one, retrying continuously. Signing the tablet in properly ends it — after three unblocks that each lasted twenty minutes.

Recommendations

• Verify identity as rigorously as for a password reset.
• Ask why they failed before clearing anything.
• Reset the password rather than just unblocking.
• Investigate the third repeat instead of clearing it again.