Password Policy and Managers for Teams

Password policy is one of the most visible security controls and, historically, one of the most misguided. For years organisations forced arbitrary complexity rules and frequent rotation, producing predictable patterns that helped attackers more than defenders. Modern guidance, reflected in standards such as the NIST digital identity guidelines, reverses much of that folklore in favour of longer passphrases, screening against known-breached passwords, and letting people keep credentials until there is evidence of compromise. For teams, the story does not end at policy: a shared password manager, phishing-resistant multi-factor authentication, and clear detection signals turn a policy document into a working control. This article covers all of that from a defensive perspective, with an emphasis on what actually reduces the risk of account takeover rather than what merely looks strict on a compliance form.

What good password policy looks like now#

Modern policy favours length over composition. A minimum of at least twelve characters, and ideally support for passphrases up to sixty-four or more, produces far more entropy than a short string peppered with mandatory symbols. Crucially, screen every new or changed password against a list of known-compromised and commonly used passwords, rejecting matches, because the real risk is not that a password lacks a special character but that it has already appeared in a breach corpus. Abandon mandatory periodic rotation; forced expiry drives users toward incremental, guessable variations and provides little benefit. Instead, rotate on evidence of compromise. Allow the full character set, including spaces and Unicode, and never truncate silently, so that strong passphrases actually work.

Why forced complexity and rotation backfired#

Composition rules and frequent expiry were intended to increase entropy and limit the window of a stolen credential, but human behaviour subverted both. Faced with a demand for an uppercase letter, a digit, and a symbol, people converge on the same transformations, so the added entropy is far smaller than it appears. Faced with monthly rotation, they choose a base word and increment a suffix, which an attacker who has one password can often predict. The net effect was passwords that felt strong to the policy engine but were weak against a motivated adversary, plus a heavy usability tax that pushed people toward reuse and sticky notes. The modern approach accepts human nature instead of fighting it.

The case for a team password manager#

A password manager is the single most impactful tool for team credential hygiene because it removes the reason people reuse passwords: memory. With a manager, every account can have a long, unique, random credential that no human needs to recall, which neutralises credential-stuffing across services. For teams, a business-grade manager adds shared vaults with per-item access control, so a credential can be granted to a role and revoked when someone leaves, and provisioning tied to your identity provider so that offboarding removes access everywhere at once. It also provides an auditable record of who can see which secret, and it discourages the worst habits: passwords in spreadsheets, in chat messages, or in source code.

Attack surface and where credentials leak#

Understanding where credentials leak tells you what to defend. The dominant paths are reuse of a password exposed in an unrelated breach, phishing that captures the password and sometimes a one-time code, malware that scrapes stored or typed credentials, and secrets committed to code repositories or shared in plaintext channels. A team password manager plus phishing-resistant authentication addresses the first two directly: unique passwords defeat reuse, and hardware-backed or passkey-based authentication resists phishing because there is no shared secret for the victim to hand over. Secret scanning in repositories and a policy against plaintext sharing address the last two. The master password and the manager's own recovery flow become high-value targets and must be protected accordingly.

Detection signals for credential abuse#

Credential attacks are noisy if you are watching. Impossible-travel logins, where the same account authenticates from distant locations within an implausible time, suggest a stolen credential. A spike in failed authentications across many accounts from few sources indicates credential stuffing; a spike across one account indicates targeted brute force. Successful logins immediately following a wave of failures deserve scrutiny. Authentication from new devices or new geographies, logins outside normal hours, and multi-factor prompts that the user did not initiate, sometimes in rapid succession as prompt-bombing, are all signals. Watch for use of legacy authentication endpoints that bypass multi-factor, and alert on changes to the password manager's own configuration, recovery settings, or export activity, which can indicate an attacker consolidating access.

Hardening controls that make policy real#

Policy only matters when enforced by controls. Deploy phishing-resistant multi-factor authentication, ideally passkeys or hardware security keys, especially for administrators and anyone with access to sensitive systems; this is the highest-value hardening step and blunts the impact of any single stolen password. Enforce breached-password screening at set and change time. Store password verifiers with a strong, slow, salted hash such as argon2id or bcrypt at an appropriate cost, never plaintext or fast hashes. Rate-limit and progressively delay authentication attempts, and lock or step up after abnormal patterns rather than after a fixed low count that enables lockout abuse. Disable legacy protocols that skip multi-factor. Bind the password manager to your identity provider so joiners and leavers are handled automatically, and protect the master credential and recovery path with their own strong second factor.

Common pitfalls#

The first pitfall is clinging to outdated rules, forced rotation and baroque complexity, that modern guidance has retired, because they cost usability and buy little security. The second is silent truncation or a restrictive character set that quietly weakens the strong passphrases users try to set. The third is deploying a password manager but allowing exceptions, shared logins in spreadsheets or chat, that undermine the whole point. The fourth is treating multi-factor as a monolith when weak factors such as SMS are phishable and prompt-bombable, whereas passkeys and hardware keys are not. The fifth is ignoring the recovery flow, which is often the weakest link, so an attacker who cannot phish the password simply resets it. The sixth is enforcing policy on humans while leaving service accounts and API keys with static, unrotated, over-privileged secrets.

A team rollout checklist#

Set a length-first policy: at least twelve characters, passphrases allowed to sixty-four or more, full character set, no silent truncation. Screen every password against a breached-password list at set and change time. Drop mandatory rotation; rotate on evidence of compromise. Roll out a business password manager integrated with your identity provider, with shared vaults and per-role access, and migrate every shared and personal work credential into it. Mandate phishing-resistant multi-factor for all users and require it for administrators. Harden the master credential and recovery flow. Instrument the detection signals above and route them to your monitoring. Extend the same discipline to service accounts and API keys, giving them unique, rotated, least-privilege secrets stored in a secret manager.

Extending the discipline to non-human identities#

Human accounts get the attention, but service accounts, API keys, CI/CD tokens, and machine credentials are where much of the real risk now lives, precisely because nobody logs in to them and nobody remembers them. Attackers prize them because they are frequently static, over-privileged, and exempted from the multi-factor and rotation rules applied to people. Bring them under the same policy: store every non-human secret in a dedicated secret manager rather than in configuration files or environment variables committed to a repository, scope each one to the least privilege it needs, and give it a defined owner and expiry. Rotate them on a schedule and immediately on any suspicion of exposure, and wire that rotation so it does not depend on a human remembering. Prefer short-lived, automatically issued credentials — workload identity federation or signed tokens — over long-lived static keys wherever the platform supports it, so that a leaked secret expires on its own rather than remaining valid indefinitely in an attacker's hands.

Rolling out without breaking productivity#

The fastest way to make a good policy fail is to impose it in a way that fights daily work, because people route around friction and the workarounds are exactly the behaviours you were trying to eliminate. Sequence the rollout so the easier, safer path arrives before the restriction: deploy and populate the password manager, prove it saves time through browser autofill and shared vaults, and only then retire the spreadsheets and shared logins it replaces. Communicate the reasoning rather than issuing decrees, because staff who understand why rotation is gone and why length beats symbols become allies instead of adversaries. Provide a smooth path for the hard cases — legacy systems that reject long passphrases, shared operational accounts, break-glass credentials — so they are handled deliberately rather than quietly excepted. Measure adoption, not just deployment: a manager installed on every laptop but used by half the team is a control on paper only, so track vault usage and close the gap with support rather than blame.

FAQ: Are passwords going away in favour of passkeys?#

They are being displaced for interactive human logins, and that is a positive trend, because passkeys are phishing-resistant by design and remove the shared secret entirely. Where you can offer passkeys, prefer them. In practice, however, passwords will persist for years across legacy systems, service accounts, and recovery paths, so you still need sound password policy and a manager even as you adopt passkeys. Treat the two as complementary: move interactive logins to passkeys where possible, and apply modern password hygiene everywhere passwords remain, rather than waiting for a future in which they have fully disappeared.

FAQ: Is storing all our passwords in one manager not a single point of failure?#

It concentrates risk, but it concentrates it onto something you can defend far better than the alternative, which is reuse and plaintext sprawl across dozens of unmonitored places. A reputable manager encrypts each vault so that the provider cannot read your secrets, and you protect the master credential with a strong passphrase and a phishing-resistant second factor. The realistic comparison is not manager versus perfect memory; it is manager versus reused passwords in spreadsheets and browsers. On that comparison the manager wins decisively, provided you harden its master credential and recovery flow as the high-value targets they are.

Conclusion#

Modern password practice for teams is simpler and stronger than the folklore it replaces: favour length over complexity, screen against known breaches, stop forcing rotation, and give everyone a password manager so that unique credentials become effortless. Wrap that in phishing-resistant multi-factor authentication, protect the master credential and recovery flow, and instrument the detection signals that reveal credential abuse. Extend the same rigour to the non-human accounts that attackers love precisely because they are forgotten. Done together, these steps turn password policy from a usability tax that people route around into a control that genuinely raises the cost of attack.