CoolFocus 5 sign-ins run through a dedicated identity platform rather than a password system we built ourselves. That buys you a set of protections that are maintained by specialists, updated as attack patterns change, and applied to every organization automatically.
This article explains what runs on its own, so you know what is already covered — and separates it from the settings that are yours to configure.
Nothing in the first section needs setup. For the controls you do manage, skip to What your organization controls.
After a series of consecutive failed sign-in attempts, an account is locked and further attempts are refused for a cooldown period. This is what defeats brute-force password guessing: an attacker gets a handful of tries, not millions.
The threshold and the cooldown are set at the platform level and apply to every organization.
There is no unlock button inside CoolFocus. A locked staff member either waits out the cooldown or contacts [email protected]. An administrator in your organization cannot clear a lockout from the Users screen.
Traffic patterns that look automated are met with an interactive challenge before an account can be created. This keeps scripted account-creation attempts from reaching the sign-up flow at all.
If someone types an email address into the sign-in form, the response does not tell them whether that address belongs to a real account. This is called user enumeration protection, and it matters more than it sounds: without it, the sign-in form becomes a free directory lookup. An attacker could confirm which of your staff have logins — and, by extension, who works at your organization — before ever attempting a password.
Passwords are compared against a continuously updated database of credentials exposed in public data breaches. A staff member cannot choose a password that is already circulating in a breach list, and if an existing password later turns up in one, they are prompted to reset it.
This addresses the single most common way accounts are compromised: not someone guessing a password, but someone reusing a password that was already stolen from an unrelated website.
Passwords must be at least eight characters, and long passphrases are encouraged. There is no forced mix of symbols and digits, and no mandatory expiry every 90 days.
That is deliberate, and it reflects a genuine reversal in security guidance. NIST's current recommendations moved away from complexity rules and scheduled rotation because both reliably backfire — they push people toward predictable substitutions (Password1!, then Password2!) and toward writing passwords down. Length and breach-checking protect an account far better than punctuation requirements do.
A strength indicator flags weak-but-permitted choices as staff type.
When a password sign-in arrives from a browser that has not been seen before, an additional verification step can be required — a code sent by email or text — even though the password was correct.
This specifically defeats credential stuffing: an attacker who bought a working email-and-password pair from a breach dump still cannot get in from their own machine. It applies to password-based sign-ins.
The protections above are the floor. These are the controls you can tighten yourself:
Multi-factor authentication — any staff member can add a second factor to their own login, and an administrator can require it for everyone in the organization. See Multi-factor authentication (MFA).
IP address restrictions — limit sign-ins to approved network locations, such as office-only access. See IP Address Access.
User groups — control which areas each person can open, and whether they can view, add, edit, or delete. See User Groups: What Staff Can Open and Change.
Data access rules — where your plan includes them, limit which individual records a group can see. See Data Access Rules.
Security Log — review successful sign-ins, failed sign-ins, logouts, and denied IP addresses. See Security Log.
User Logs — a timeline of staff sign-in activity, record access, and changes. See User Logs.
No. These are configured at the platform level and apply uniformly to every organization on CoolFocus, which is what lets us keep them aligned with current guidance rather than frozen at whatever each organization chose years ago. If a written policy of yours requires something specific, contact [email protected] so we understand the requirement.
No — and this is the important distinction. Everything on this page reduces the chance that someone obtains a working password. MFA is what protects the account when someone already has one. They solve different halves of the same problem, and MFA is the half you control.
Wait out the cooldown period, or contact [email protected]. Administrators cannot clear a lockout themselves.
If the cause was a forgotten password rather than an attack, the password reset link on the sign-in screen is usually the faster route.
No. This article covers staff logins to CoolFocus. The Client Portal signs clients in through a separate flow with its own verification, configured under the Client Portal settings.
