In most companies the password policy was written once and never revisited. Yet the recommendations have changed fundamentally, and some familiar requirements are now considered harmful — including the most popular one.
El cambio obligatorio cada 90 días es contraproducente
This is the major revision of recent years, written into the NIST guidance and adopted across the industry. The logic is simple: a person forced to change a password four times a year does not invent four new ones — they make the smallest possible change.
“Summer2026!” becomes “Autumn2026!”, then “Winter2026!”. The password is formally new, predictability has grown, and the employee has stopped taking passwords seriously and written it on a sticky note.
What to do instead. Change passwords on events: a service breach, the departure of someone with access, a lost device, a suspicion of compromise. Plus automatic checking of new passwords against breach databases — that catches a real problem rather than a calendar.
No exijas a los usuarios cambiar la contraseña por calendario. El cambio programado empuja a la gente hacia modificaciones predecibles de contraseñas que ya usa.
NIST SP 800-63B, directrices de identidad digital
Qué conviene exigir
Length rather than “complexity”. Demanding a capital, a digit and a symbol produces “Password1!” — formally compliant, actually terrible. Require at least twelve characters, better fourteen, without a mandatory composition.
A breach-database check. When a password is set, the system should reject combinations already seen in leaks. That single measure achieves more than every composition rule combined.
A ban on reusing the corporate password on external services. You cannot verify it, but the rule should be written down and explained.
A second factor on everything reachable from outside: email, VPN, admin panels, cloud services.
Un gestor de contraseñas para el equipo
Without one a unique-password policy is unachievable, and staff will work around it one way or another.
A team manager offers what a personal one cannot: shared vaults per department, granting access without sending the password, revoking access in one action when someone leaves, and a log of who accessed what.
That last point is often the decisive argument for management: without it, after someone leaves nobody knows which passwords need changing, so either all of them are changed or none.
Entregar accesos a los nuevos
A temporary password. Whoever issued it knows it too, so a change at first login is mandatory. Login-and-password pairs are convenient to prepare in a batch and export as CSV.
Delivery. Not by email or messenger — why exactly is covered separately. Shared vault access or a one-time link.
A personal account for everyone. A shared “department” account removes any way of telling who did what and turns a departure into a password change for everybody.
An offboarding checklist. Revoke access, change shared passwords, remove the second factor from their device, check mail forwarding. This is what gets forgotten most often.
Qué no hacer
Blocking paste in the password field. It breaks password managers and pushes people towards passwords they can type, meaning short ones.
Capping length at twelve or sixteen characters. That is usually a sign the password is stored incorrectly.
Banning special characters. You get the same result by allowing more length instead of narrowing the alphabet.