A policy can demand symbols and frequent changes while employees still reuse a predictable password pattern. It can also recommend an authenticator without explaining how someone recovers access after losing a phone. Effective authentication needs to work across the account's lifecycle, not just pass a setup screen.
Authentication has a full lifecycle
A setup rule needs supported methods and a recovery process that people can actually use.
Begin with the applications and identity providers the organization actually uses. Identify the accounts with consequential authority, permitted methods, and exceptions. Check applicable requirements with the responsible owner before changing policy or promising a universal rule.
Make passwords distinct and manageable
Where passwords are still needed, use long, unique values suited to the service, supported by an approved password vault. Protect the vault and its recovery arrangements. Staff should not need to keep an unprotected spreadsheet or use the same credential across many services to remember their work.
Current NIST authentication guidance rejects mandatory character mixtures and arbitrary periodic changes within its scope, while requiring action when compromise is evident. It also addresses screening against common or compromised values. Apply relevant obligations and product constraints explicitly rather than copying a dated recipe.
This does not mean an exposed password should remain unchanged. It means the reason for changing it matters and that a predictable scheduled variation is not a substitute for distinct credentials and appropriate protection.
Choose the method, not just the app
Multifactor authentication combines distinct factor types. Entering two passwords is not the same arrangement. A one-time code, push approval, and FIDO/WebAuthn credential can differ significantly in their resistance to phishing and relay.
Use the MFA guide to plan coverage and user support. Choose passkeys or other phishing-resistant methods where supported and appropriate for the application and role. A physical token is not automatically phishing-resistant merely because it is hardware; the method it implements matters.
Test enrollment and normal use on representative devices. Include shared workstations, remote workers, accessibility needs, and people who cannot use personal phones. Confirm the actual business tenant's supported arrangement instead of assuming a consumer-account feature announcement applies unchanged.
Give recovery the same attention
Define how support verifies the requester, replaces a lost authenticator, and limits temporary access. Record who can authorize an exception and when it expires. A convenient recovery bypass can undo the protection of a strong everyday sign-in method.
The user credentials guide connects those tasks with directory administration, roles, and departures. Review access and recovery contacts when responsibilities change. Keep administrative and service identities identifiable and assigned to accountable owners.
Have a second support person carry out a controlled recovery exercise from the instructions. Check that required alerts reach an owner and that obsolete methods can be removed. Completion should mean authorized staff can obtain and maintain access safely, with the remaining limitations understood. A password rule is one part of that service, not the whole result.