Maintenance
Account email, password, passkey, multifactor, recovery, session, device, and alert checklist
Account security checklist for email, passwords, passkeys, MFA, backup authenticators, recovery, sessions, trusted devices, connected apps, and alerts.
What to take away
- Review one account from a known device and manually verified address.
- Confirm recovery before changing or removing authenticators.
- Test a backup method in a separate session.
- Inspect post-login access, not only the password and MFA page.
- Record evidence and unknowns without storing secrets in the checklist.
Use Pass, Partial, Fail, Not applicable, or Unknown. Stop routine review and follow the provider's recovery process if the account already contains an unfamiliar password, authenticator, administrator, forwarding rule, payment, or active session.
Account identity and email
- The official sign-in address or app is known.
- The username and primary email are current.
- Primary email has its own unique authentication and recovery.
- Alternate notification routes are controlled and monitored.
- Public contact email is separated from recovery email where risk justifies it.
- Old aliases and addresses do not silently receive resets.
Password
- The password is unique to this account.
- It is generated or long enough to resist practical guessing.
- It is stored only in the intended protected manager.
- The service allows safe password-manager filling and paste.
- Known exposure or reuse triggered a prompt change.
- Periodic change is not creating predictable passwords without a policy or compromise reason.
NIST's discussion of password strength explains why length, blocklists, password managers, rate limiting, and resistance to offline attack matter, and why arbitrary composition and routine forced changes can have poor results. Its requirements apply to covered verifiers, not directly to every consumer account.
Password security checklist
- Password unique to this account
- Generated or long enough to resist guessing
- Stored only in protected manager
- Service allows safe manager filling and paste
- Known exposure or reuse triggered change
- Periodic change not creating predictable passwords
Passkeys and cryptographic methods
- Enrolled passkeys and keys have recognizable names.
- Device-bound and synchronized behavior is understood.
- Platform or manager account security is included in the model.
- Lost devices can be removed from the credential ecosystem.
- A separately stored backup exists for a high-value account.
- Compatibility and accessibility have been tested.
Multifactor authentication
- MFA is enabled when offered.
- Different factor types are used rather than two knowledge secrets.
- The strongest practical supported method is primary.
- Unexpected push prompts and verification codes are rejected.
- Phone-number methods include carrier-account protection.
- Enrollment QR codes and shared seeds are not left in photos or downloads.
Recovery
- Recovery email and phone are current and protected.
- Backup codes are stored securely and independently.
- Recovery contacts remain appropriate and know their limited role.
- Identity-proofing or support steps are understood before a crisis.
- A recovery event sends an independent notification when supported.
- Obsolete recovery methods are removed only after replacements work.
NIST's authenticator event management guidance covers binding, loss, compromise, invalidation, multiple authenticators, recovery methods, and notifications in its federal digital identity context. It supports treating recovery as an authenticated lifecycle event, not a weak side door. It does not prescribe a consumer provider's exact process.
Sessions and trusted devices
- Active sessions and devices are reviewed by date and context.
- Unfamiliar or stale sessions are terminated.
- "Remember this device" status is limited to controlled devices.
- Global sign-out is available or the support route is known.
- Password change behavior for existing sessions is understood.
- Shared devices do not retain the session.
Connected access
- Third-party apps and delegated users are current.
- App passwords, API tokens, and integrations are necessary.
- Mail forwarding, filters, and delegates are recognized.
- Publishing, payment, advertising, and administrator roles are correct.
- Removed people lose all related tokens and recovery routes.
- Connection removal is tested where consequences are high.
Devices and alerts
- Devices use current software, screen locks, and storage protection.
- Lost-device location and erase controls are configured and understood.
- Sign-in, recovery, password, authenticator, export, and payment alerts are enabled where offered.
- Alerts are verified through known channels rather than message links.
- Notification contact changes trigger their own review.
- The response card lists official contacts without reusable secrets.
Closeout
- Primary and backup sign-in methods passed a controlled test.
- Recovery access was confirmed without triggering an unnecessary reset.
- Old methods, sessions, and tokens were removed.
- Exceptions have an owner, reason, and review date.
- The next review trigger is recorded.
Common questions
Should a backup code be stored in the password manager?
It can be protected there, but a second offline location may help if the manager is the account being recovered.
Should every old session be terminated?
End sessions you no longer use or cannot identify. Preserve evidence first if compromise is suspected.
Is one security key enough?
It can authenticate strongly, but losing the only key can cause lockout. Register a separate backup when the service allows it.
Does an account pass this checklist permanently?
No. Devices, providers, methods, recovery details, and threats change. Review after material events and on a schedule.
