Platform, Security & Integrations / Security

Brute-Force Login Protection

Automatically. If a login attempt fails repeatedly from the same source — the classic sign of a hacker trying to guess a password (called fail2ban-style protection, after the widely used technique it’s based on — see Glossary) — that source gets temporarily or permanently blocked, before it can do any damage.

Why does this matter for a phone system specifically?

A phone system that gets broken into isn’t just a data risk — it can be used to place expensive international or premium-rate calls at your expense (see Toll Fraud Prevention), or to eavesdrop on business calls. Automated login protection is one of the first lines of defense against both.

Does this require anyone to actively monitor logins?

No — it runs continuously and automatically in the background. There’s no dashboard someone has to watch or manual step to trigger a block; suspicious login patterns are caught and shut down in real time.

What counts as a “repeated failed attempt”?

The system tracks failed login attempts by source and applies escalating restrictions — a handful of failures triggers a temporary block, and a persistent pattern of failures can result in a longer or permanent block, tuned to stop automated attacks without accidentally locking out an employee who simply mistyped their password once or twice.

Does this work alongside a firewall, or instead of one?

Alongside. Brute-force protection stops repeated login guessing specifically; a Firewall & IP Allow/Block Lists control broader network access. Used together, they cover both “who’s allowed to even reach the system” and “what happens if someone who reaches it tries to break in.”

Is this something we have to configure?

It’s active by default, with sensible settings out of the box. Businesses with specific security requirements can adjust thresholds, but there’s nothing you need to turn on to get baseline protection.