Password Policy

Passwords still protect many business accounts, so a policy should tell users what to do and tell administrators how systems enforce it. Saying "use a strong password" without practical rules is not enough.

A fictional company requires a long, unique password for each work account, and employees use an approved password manager rather than keeping a spreadsheet of secrets. Current NIST digital-identity guidance for centrally verified passwords sets a minimum of 15 characters when the password is the only factor, and it permits a minimum of eight when used as part of multifactor authentication.

These are NIST requirements for systems within its scope, not an automatic law for every organisation, so a fictional service asking users to set a single-factor password checks the current standard and its own risk profile before setting a minimum. Length helps resist guessing, but it is not a cure for phishing, because an attacker can trick someone into entering even a long password on a false site, so appropriate multifactor authentication and user training are needed as well.

NIST says systems should accept long passwords and should not force mixes of uppercase, symbols and numbers, since people often satisfy rigid rules predictably. A fictional employee who changes "Welcome" to "Welcome1!" to meet a symbol rule gains little protection, and a memorable phrase can be more usable than a short cryptic string.

Block common and compromised passwords at creation, because NIST specifies checking a proposed password against a blocklist of known, expected or breached choices, and explain a rejection without revealing sensitive information. Do not make people change passwords on a fixed calendar merely for its own sake, because NIST says not to require periodic changes but to force a change when compromise is evidenced, although a local regulator or contract might impose extra duties.

A fictional company that sees a stolen credential in an incident report resets that account, checks sessions and investigates rather than waiting for the next scheduled rotation. Unique passwords prevent one breached service from opening another, and shared accounts make attribution and revocation hard, as a fictional team found when a member left a shared inbox and nobody knew which activity was theirs, so give each person an account where practical.

A password manager can generate and store unique values, but the manager itself needs appropriate controls and recovery planning, and master secrets should never be sent in ordinary chat. System administrators must handle stored credentials safely, so services should not keep readable password lists or email existing passwords back to users, and NIST specifies salted, iteratively hashed verification secrets for central verifiers.

A fictional website that emails a customer their existing password shows unsafe storage, and the provider should review the design immediately. Set sensible rate limits and monitor suspicious attempts, remembering that lockouts that are too easy to trigger can deny legitimate users access, and give new staff accessible instructions and tools so they know how to report suspected phishing or lost credentials without fear of blame.

Password reset is part of the policy, because an easy-to-guess security question can undo a strong password, so recovery should verify the requester appropriately and log changes, and a help desk receiving an executive reset request should follow identity checks, not the caller's claimed urgency. Review privileged and service accounts separately, since a fictional integration with one broad secret should be split into narrower permissions held in approved secret management, and test the real user experience, including NIST's recommendation to permit paste and autofill, because a password policy is an operational control, not a poster, and should be reviewed when standards, threats and technology change.