Forced ninety-day changes, three special characters, no repeats — most password rules were written from intuition and make passwords weaker. The current guidance says something close to the opposite.
A password policy sets out what passwords people must use and how they are managed. Most policies in circulation date from an era of guessing rules that turned out to be wrong, and they persist because they sound rigorous: expire every ninety days, one uppercase, one number, one symbol, no reuse of the last twelve. Every one of those has been re-examined by the bodies that originally recommended them, and several are now advised against.
The reason is behavioural. Complexity rules push people towards a predictable pattern — a word, a capital at the front, a number and an exclamation mark at the end — and forced expiry pushes them towards incrementing it. The rules produce passwords that are hard for humans to remember and easy for software to guess, which is precisely backwards.
The most valuable line in a password policy is the one about reuse across services. A unique password everywhere means a breach of some forum from four years ago stays a breach of that forum; reuse means it becomes a breach of your email. That single rule outperforms every complexity requirement ever written, and it is only realistic if everyone has a password manager.
Auditors, certification checklists and vendor defaults still ask for ninety-day expiry, and it is common to be required to implement something the evidence no longer supports. If you are being audited against a standard that mandates it, comply and note the reasoning; if you are writing the policy freely, write the version that produces stronger passwords rather than the version that looks stricter.
Ettex Teams holds who has access, and the passkey option removes the password from the login entirely where it is used — which is the direction all of this eventually goes. The neighbouring documents are access control policy for who may reach what, information security policy for the overall frame, and two factor authentication for the second factor this policy assumes.
Being clear: we do not provide a password manager, do not enforce a password policy across your other services, and do not screen credentials against breach databases. Those are functions of a dedicated manager and of each service you use; the policy is the decision, and the decision is yours.
No, on current guidance. Scheduled expiry produces incremented, predictable passwords and more reset requests. Force changes on evidence of compromise instead.
Twelve to fifteen characters as a minimum for people, longer for administrative and shared accounts. Length does far more than character-class requirements.
Not particularly. They push people towards a predictable pattern. Screening against known-breached passwords achieves much more than requiring a symbol.
In practice, yes. Unique passwords per service is the single most effective rule and is unrealistic without one.
Turning on two-factor authentication is the single highest-value security change most small teams can make. Which second factor you pick decides whether it stops the attack that actually happens.
Phishing awareness is sold as training and works as design. The teams that get hit least are not the best educated — they are the ones where reporting is easy and the dangerous actions have a second check.
An access control policy sets who may reach what, who approves it, and how access is taken away. The removal half is where nearly every small company is quietly exposed.