Password policies are one of the most misunderstood areas of cybersecurity in the small business space. Most organizations are still following guidance that was outdated several years ago — creating friction for employees without meaningfully improving security. If your organization still requires password changes every 90 days, enforces complexity rules that produce passwords like “P@ssw0rd1,” or our personal favorite “COMPANY_NAME123!” or has no visibility into whether employee credentials have appeared in a breach database, this article is worth your time.
Why 90-Day Rotation Backfires
Mandatory periodic password rotation — requiring changes every 60 to 90 days — was the dominant IT security guidance for a long time. The logic was intuitive: frequent changes limit exposure if a password is compromised. The problem is human behavior. When employees are forced to create new passwords on a schedule, they don’t generate genuinely new credentials. They increment: Password1 becomes Password2 becomes Password3. They append the current month and year. They make the minimum change to satisfy the requirement while keeping something familiar.
The result is a predictable rotation pattern that attackers specifically account for when they have an older credential from a previous breach. The 90-day policy hasn’t reduced exposure — it’s created passwords that are easier to anticipate. NIST’s current guidance (NIST SP 800-63B) explicitly recommends against forced periodic rotation for exactly this reason. The security research community reached consensus on this several years ago.
What Current NIST Guidance Actually Recommends
- Length over complexity: Long passphrases (16+ characters) provide more security and are more usable than short passwords with arbitrary character class requirements. A phrase like “PurpleElephantJumpsHigh” is harder to crack than “X#9pQ!2k” and far easier for a human to remember.
- No arbitrary complexity requirements: Rules like “must include uppercase, number, and special character” produce predictable substitution patterns and don’t significantly improve security. Remove them.
- Change only when compromised: Passwords should change when there’s actual evidence of compromise — a breach database hit, a detected phishing event, a suspicious login. Not on a calendar schedule.
- Screen against breached databases: New passwords should be checked against known-compromised credential lists and rejected if they appear. Microsoft Entra ID does this automatically for Microsoft 365 environments.
- MFA everywhere: Regardless of password quality, MFA should be the default on all accounts with access to business systems or sensitive data.
Password Managers for Teams: Why They Matter
A business password manager solves several security problems simultaneously. We personally love Bitwarden. It generates genuinely strong, unique passwords for every account — eliminating credential reuse, which is the root cause of most credential stuffing attacks. It stores credentials securely and makes them accessible without memorization. And it provides administrative visibility into team password hygiene: which accounts have weak passwords, which have reused credentials, and which haven’t been updated since a known breach.
Team-focused password managers like 1Password for Teams or Bitwarden Business also allow secure sharing of shared credentials — eliminating the “password on a sticky note” problem — and provide audit logs of who accessed what. The per-user annual cost is modest. The security and operational improvement is substantial.
Breach Monitoring: Knowing Before the Attacker Does
Credentials from data breaches are sold on criminal markets and used for automated attacks within hours of a breach going public. If one of your employees registered for a third-party service using their work email address, and that service was subsequently breached, those credentials are likely in a breach database right now — and automated tools are attempting them against your Microsoft 365 login.
We monitor for our managed clients’ email domains against breach databases continuously. When a credential appears in a known breach, we alert the client and initiate a password reset for that account. This is the correct trigger for a password change — not a quarterly calendar reminder.
How We Implement Password Policy Across Microsoft 365
For Microsoft 365 environments — the majority of our client base — we configure password policies through Microsoft Entra ID to align with current NIST guidance: eliminate forced rotation, enforce minimum length, screen against Microsoft’s breach intelligence database, require MFA on all accounts, and enable anomalous sign-in risk detection. The result is a policy that is simultaneously more secure and less annoying than the legacy approach — a genuine win on both dimensions.
If you’d like to update your organization’s password policies to current standards, reach out at Contact Us.
