Password Policy Best Practice for Businesses

A modern password policy asks for long, unique passwords rather than complicated ones, uses a password manager so people never have to remember them, blocks known-bad passwords, requires multi-factor authentication, and drops forced periodic changes unless a compromise is suspected. This reflects guidance from national cyber security bodies such as the UK's NCSC and from NIST, and it is the opposite of the old rule of eight characters with a symbol that changes every ninety days. Here is how to turn that into a policy your staff will actually follow.

This article is general guidance, not a formal standard. Check current advice from Ireland's National Cyber Security Centre and your own regulatory obligations when writing your policy.

Why the old rules failed

Traditional policies demanded a mix of upper case, lower case, digits and symbols, and a forced change every few months. People responded predictably: Summer2026! becomes Autumn2026!. The complexity rules produced passwords that were hard to remember but easy for attackers to guess, because attackers know the same habits. Forced rotation made it worse, since people made tiny changes or wrote passwords on sticky notes. Meanwhile the real threats, such as reuse of a password across sites and phishing, were barely addressed.

The principles of a good policy

Favour length over complexity

Length does most of the work. Three or four random, unrelated words strung together is easier to remember and typically stronger than a short complex string. The NCSC has long promoted this three-random-words approach. Words must be genuinely random, not a quote, lyric or the name of your dog.

Make every password unique

Reuse is the biggest practical weakness. When one website is breached, attackers try the same email and password everywhere else. A unique password per account contains the damage to a single service. Humans cannot remember dozens of unique long passwords, which is why you need a password manager.

Provide a password manager

A password manager generates, stores and fills strong unique passwords. Staff only need to remember one long master passphrase, protected with MFA. Choose a business-grade product that supports shared vaults for team credentials, admin oversight, and removal of access when someone leaves. Provide it centrally rather than leaving staff to choose their own.

Block bad passwords instead of enforcing composition rules

Where your systems allow, check new passwords against lists of commonly used and previously breached passwords, and reject matches. Also reject passwords that contain the company name, the username or obvious patterns. This catches weak choices far better than demanding a symbol.

Do not force routine changes

Change a password when you have a reason: a suspected phishing click, a breach notice, a departing colleague who knew a shared credential, or a device loss. Routine expiry without cause tends to reduce security. Keep the ability to force resets quickly when needed.

Add MFA everywhere it matters

A password alone, however strong, can be phished. MFA is the safety net. Our multi-factor authentication rollout guide covers how to deploy it in stages.

Prepare for passkeys

Passkeys remove the shared secret altogether. They are bound to the real website, so a fake login page gets nothing. Where a service offers passkeys, enabling them for staff is a good step. Expect a mixed environment for several years, with passwords plus MFA for some systems and passkeys for others.

A policy template you can adapt

Area	Suggested rule
Minimum length	12 to 14 characters or more for standard accounts; longer for administrators (rule of thumb)
Composition	No mandatory symbol or case rules; passphrases encouraged
Uniqueness	Never reuse a work password anywhere, including personal accounts
Storage	Company-provided password manager only; no spreadsheets, sticky notes or browser notes
Blocklist	Reject common, breached and company-related passwords where supported
Rotation	Change only on suspected compromise, role change or departure of someone with knowledge
MFA	Required on email, admin, finance and remote access; strongly encouraged everywhere
Sharing	No shared personal passwords; use shared vaults or delegated access for team accounts
Lockout	Throttle or temporarily lock after repeated failed attempts
Reporting	Staff report suspected compromise immediately, with no blame

Service accounts and developers

Passwords used by software, such as database credentials or API keys, are a separate problem. Never hard-code them into source code or commit them to a repository. Store them in a secrets manager or in protected environment configuration, give each application only the permissions it needs, rotate them when staff with access leave, and monitor for exposure. This is also a topic in our guide to the secure software development lifecycle.

Rolling out the policy

1. Choose and procure the password manager, and configure admin controls and recovery.
2. Enable MFA on the password manager itself and on email.
3. Run a short onboarding session: how to create a master passphrase, how to import existing logins, how to generate new passwords.
4. Migrate the highest-risk accounts first, then everything else over a few weeks.
5. Remove old password habits: delete shared spreadsheets and stop accepting passwords by email or chat.
6. Review after a quarter and adjust where people struggle.

Building a passphrase people can remember

Give staff a simple method. Pick three or four unrelated words, ideally chosen by a random generator rather than by looking around the room, and join them with spaces or hyphens. Avoid famous phrases, song lines and anything connected to you, such as a team name, street or birthday. Add a rule that the master passphrase for the password manager is typed from memory regularly, so it sticks. For devices, a short PIN combined with hardware protection and lockout is acceptable, because the device limits the number of guesses. The important distinction is between secrets that can be attacked offline at high speed, which need length, and secrets protected by rate limits, which can be shorter. Explaining that distinction in one paragraph of your policy helps people understand why the rules differ between systems.

Common mistakes

• Writing a policy nobody can follow. If following it means memorising twenty complex passwords, people will cut corners.
• Keeping forced 90-day rotation by habit. It generates predictable patterns and support tickets without much benefit.
• Allowing the browser to store everything with no master protection. Use a managed solution with proper controls.
• Using the same master passphrase elsewhere. It must be unique and never used for any other service.
• Ignoring recovery. Decide how a forgotten master passphrase or a lost device is handled, and who can authorise it.
• Relying on security questions. Answers such as a mother's maiden name are findable. Treat them as extra passwords and store random answers in your manager.

What to do after a breach notice

If a service tells you that credentials were exposed, change the password on that account straight away, change it anywhere else it was reused, check for suspicious sign-ins or forwarding rules in email, and confirm MFA is enabled. A password manager makes this quick because you can see which accounts used the affected credential.

Next steps

A password policy is a small document with a large effect, provided it is backed by tools that make the secure choice the easy one. Our cybersecurity solutions include authentication and security audits, and we can review how credentials are handled across your systems and suggest practical improvements.