pam_faillock locks a local account after repeated failed logins. Its defaults are 3 failures within 15 minutes and a 10 minute lock. Keep lock times short, because the PAM manual itself warns that permanent lockouts make accounts an easy denial of service target.
Where the settings live
The Linux-PAM manual calls /etc/security/faillock.conf the preferred way to configure the module. The file uses a simple name = value format with # comments. The example in the manual is:
deny=4
unlock_time=1200
silent
You still need the module wired into your PAM stack for authentication, which depends on the distribution, so follow your distribution's tool or docs for that part and test it.
The settings that matter
- deny=n: deny access when consecutive failures in the recent interval exceed n. Default 3.
- fail_interval=n: the window, in seconds, in which failures must happen. Default 900.
- unlock_time=n: seconds until access is re-enabled. Default 600. A value of 0 means never, until you reset it with the
faillockcommand. - even_deny_root: lets root be locked too.
root_unlock_time=nsets a separate unlock time and implieseven_deny_root. - admin_group=name: members of this group are treated like root for those two options.
- local_users_only: track only users in
/etc/passwdand ignore centralized users from AD, IdM or LDAP. The manual says this prevents a double lockout, where a user is locked out locally and in the central system. - dir=/path: where failure records live, default
/var/run/faillock.
Two cautions from the manual
First, the default directory is usually cleared on boot, so a reboot re-enables access. If you do not want that, set a different dir.
Second, the manual says it is usually undesirable to permanently lock out users, because they can become an easy denial of service target unless usernames are random and kept secret. An attacker who knows a username can lock it just by guessing wrong. So:
- Keep
unlock_timein minutes, not forever. - Consider
even_deny_rootcarefully on remote machines: locking root out of a host you can only reach by SSH is painful. Keep console access and a second admin account. - Prefer keys over passwords for SSH, as covered in requiring a key and a second factor, so there is less to guess.
Silent mode and user enumeration
The silent option stops informative messages to the user. The manual notes that without it, the behavior differs for existing and non-existing users, which can reveal which accounts exist. Silent mode reduces that signal.
Operating it
Use faillock --user name to see failures and faillock --user name --reset to clear them. Watch the log lines the module writes through syslog, unless you set no_log_info, and send alerts when the same account locks repeatedly, since that suggests guessing. See authentication events to log.
Safeguard offers policy and compliance evidence automation if you need to show account lockout controls are set, and there is a free scan at gold.safeguard.sh/scan.
Quick check
What are the faillock defaults?
Deny after 3 consecutive failures within 900 seconds, with a 600 second unlock time.
Why not lock accounts forever?
Anyone who knows the username can trigger the lock with bad guesses, which turns the control into a denial of service tool.
Sources
Last reviewed: 19 October 2026.
