Digital Identity Security Checklist: 25 Steps to Protect Every Online Account

Overview

A secure online identity is not defined by one strong password or a single security product. It is the combination of authentication, recovery, device hygiene, privacy settings, session control, third-party access, and an accurate understanding of what each account can do.

Use this checklist as a practical baseline for important email, financial, social, developer, cloud, and work accounts. Start with the identities that control other accounts, such as your primary email, password manager, identity provider, domain registrar, and administrator accounts. Then work through lower-risk services.

Record the date of each review, the account owner, the recovery methods in use, and any follow-up action. Do not store passwords, recovery codes, private keys, or access tokens in the checklist itself. A simple inventory can be kept in a protected document or an approved identity-management system.

Checklist by scenario

For every important account

1. Identify the account owner. Confirm whether the account belongs to an individual, team, service, or organization. Avoid shared personal logins where a delegated role or separate user account is available.
2. Use a unique password or passkey. Never reuse a password between services. Prefer a passkey or another passwordless method when the service supports it and the enrollment process is trusted.
3. Store credentials securely. Use a reputable password manager or an approved enterprise credential system rather than browser notes, spreadsheets, email drafts, or chat messages.
4. Enable multifactor authentication. Prefer phishing-resistant methods where available. If the only option is an authenticator app, hardware key, or one-time code, enable the strongest practical method and understand its recovery process.
5. Review active sessions. Sign out devices, browsers, and locations you no longer recognize or use. For application owners, review session duration, idle timeouts, and logout behavior in the session management guide.
6. Check recent security activity. Look for unfamiliar sign-ins, changed settings, new devices, password resets, or authentication-factor changes. Treat unexplained activity as an investigation, not merely a notification to dismiss.
7. Confirm account notifications. Ensure alerts for sign-ins, password changes, recovery changes, and administrator actions reach a monitored address or security workflow.
8. Remove unused devices. Delete old phones, laptops, browsers, and applications from the account’s trusted-device list after verifying that they are no longer needed.

For recovery and continuity

9. Verify recovery email addresses. Use an address that is active, protected by strong authentication, and not dependent on the account being recovered.
10. Review recovery phone numbers. Remove old numbers and confirm that the remaining number is appropriate for the account’s risk level. Do not treat a phone number as the only recovery option for a critical identity.
11. Generate and protect recovery codes. Store codes offline or in an approved secure vault. Do not leave them in an unlocked notes application or an unprotected screenshot.
12. Test recovery without creating unnecessary risk. Confirm that you know the recovery path and that contact details work. Avoid repeatedly initiating resets on a live production account unless the service documents a safe test method.
13. Define an emergency owner. For work or team accounts, identify who can respond if the primary owner is unavailable. Document the process without exposing secrets.
14. Plan for device loss. Know how to revoke a lost device, replace an authenticator, disable a session, or use backup authentication. Keep instructions accessible to the authorized account owner.

For profile exposure and online personas

15. Audit public profile fields. Remove unnecessary personal details such as private phone numbers, home addresses, personal schedules, or answers that could help someone guess recovery information.
16. Separate public and private identities. Use distinct contact details, usernames, and profile boundaries where appropriate. A consistent professional persona can build trust, but unnecessary cross-linking can also make accounts easier to map.
17. Review profile links and QR codes. Check that links point to the intended destination, use HTTPS where appropriate, and do not expose private documents or unrestricted contact data. See the guide to sharing a professional profile with QR codes.
18. Check impersonation signals. Search for unfamiliar accounts, domains, or profile copies using your name, organization, or professional handle. Use an independent channel when verifying that a profile really belongs to someone; the profile verification checklist provides a starting point.
19. Standardize identity details. Keep names, role descriptions, profile images, and links accurate across important professional accounts. Consistency should support verification without revealing more information than necessary.

For applications, teams, and cloud services

20. Inventory third-party access. Review connected applications, OAuth grants, browser extensions, integrations, and service accounts. Remove anything unused or owned by a former employee.
21. Apply least privilege. Give users, applications, and tokens only the permissions needed for their task. Separate read, write, billing, deployment, and administrative roles where possible.
22. Set token controls. Define expiry, rotation, audience, scope, and revocation procedures. For implementation details, review refresh-token practices and the guide to JWT signing algorithms.
23. Protect signing and encryption keys. Keep private keys out of source code, tickets, logs, screenshots, and public repositories. Use a managed secret store or key-management process approved for the environment.
24. Document verification dependencies. For systems using OpenID Connect, record the issuer, discovery endpoint, accepted algorithms, key-rotation expectations, and claims used for authorization. The OIDC discovery and JWKS reference can help developers review these dependencies.

What to double-check

After completing the checklist, review the connections between controls. A protected account can still be exposed through a weak recovery address, an old browser session, or a third-party application with excessive permissions.

• Recovery independence: Can an attacker who controls one account use it to recover another?
• Authentication coverage: Are MFA or passkeys enabled on the accounts that control domains, email, code, billing, and administration?
• Session visibility: Can you identify and revoke active sessions, refresh tokens, and personal access tokens?
• Permission boundaries: Does each user or integration have more access than its job requires?
• Public exposure: Do profile pages, avatars, QR links, repositories, and contact details reveal information that is unnecessary for the intended audience?
• Verification behavior: Are people trained to verify sensitive requests through a separate trusted channel rather than relying on a display name, avatar, or email address?

For developers, never paste a live JWT, private key, password, or production token into an online decoder or debugging utility. A JWT decoder can help inspect structure, but decoding is not the same as validating a token’s signature, issuer, audience, expiry, or permissions. Treat all identity tokens as secrets unless you have confirmed that the data is safe to disclose.

Common mistakes

• Using SMS or email as the only protection: These channels may be useful as part of recovery, but critical accounts should have stronger available controls.
• Leaving old access active: Former devices, contractors, test applications, and abandoned integrations often remain in account settings.
• Confusing visibility with verification: A polished avatar, verified-looking badge, or matching username does not prove ownership.
• Keeping recovery codes in the same place as the device: If a lost device and its unlocked notes are together, the backup may not provide meaningful protection.
• Overlooking non-human identities: Service accounts, CI/CD credentials, API keys, bots, and automation tokens also need owners, scopes, expiry, and revocation procedures.
• Changing passwords without investigating: A password reset may not remove active sessions, OAuth grants, forwarding rules, or stolen tokens.
• Publishing too much professional information: A trusted online persona should be useful and consistent, but it should not expose private contact or recovery details.

When to revisit

Run this checklist before seasonal planning cycles, annual access reviews, major product launches, role changes, or migrations to a new identity provider. Revisit it immediately after a suspected compromise, lost device, phishing event, employee departure, domain change, or change to a critical integration.

A practical cadence is to review high-risk administrator and recovery accounts more often than ordinary accounts, while checking public profiles and third-party connections whenever workflows or tools change. Set a calendar reminder and assign an owner; an unassigned review is easy to postpone.

End each review with three actions: remove one unnecessary access path, strengthen one authentication or recovery control, and record one decision that the next reviewer can understand. If you find unexplained sign-ins, exposed secrets, or unauthorized changes, preserve relevant evidence, revoke affected access, rotate credentials or tokens, and follow your organization’s incident process. Security improves through small, documented checks repeated over time—not through a single audit that is never revisited.