How to secure your accounts in 2026

But complexity rules can produce passwords like Password123!, which attackers expect.

So in 2026, use a password manager for unique random credentials, target 15 or more characters when passwords are required, prefer passkeys or security keys, and keep a breach-response plan for reused or exposed credentials.

These password security best practices for 2026 start with removing reuse and protecting the accounts that reset everything else. You’ll set up the minimum viable system, choose between passwords and passphrases, rank MFA by phishing resistance, examine passkey limits, and follow a breach procedure.

In this article

• Start with this five-step security setup
• Length beats forced complexity
• A passphrase is useful only when it is random
• Let a password manager do the repetitive work
• MFA is a ladder, not a checkbox
• Passkeys resist phishing, not every kind of compromise
• After a breach, contain the account before investigating it
• Remove these habits from your security routine
• Your 2026 priority order

Start with this five-step security setup

So if you only have one afternoon, work in this order:

1. Install and configure a password manager. Protect its primary account with a long, unique secret and phishing-resistant MFA.
2. Replace reused and exposed passwords. Start with email, financial accounts, work systems, cloud storage, and anything that can reset other passwords.
3. Use a long secret where a password is required. Aim for 15 or more randomly generated characters. Use a randomly generated passphrase when memorisation matters.
4. Add phishing-resistant MFA. Use passkeys or hardware security keys for email, financial services, work systems, and your password manager.
5. Save recovery codes securely. Store them separately from the account and device they protect, then test that you can recover access.

And Maya has reused MayaRiver!2024, with small variations, for personal email, shopping, and her password manager. Her shopping account sends a breach alert. Email has SMS 2FA; the manager has no MFA.

So she should secure the manager and email first. Then she should replace the reused secrets everywhere. If your manager doesn’t have phishing-resistant MFA, the setup is unfinished.

NIST SP 800-63B Revision 4 defines Authentication Assurance Levels AAL1, AAL2, and AAL3. Applications assessed at AAL2 must offer a phishing-resistant option. AAL3 requires a phishing-resistant authenticator with a non-exportable authentication key. These requirements belong to NIST’s assurance framework; they don’t mean every consumer website is formally assigned an AAL.

Length beats forced complexity

Secondary summaries of Revision 4 describe a shift toward longer passwords, easier use, compromised-credential screening and passwordless authentication. The detailed password rules in the full standard should be checked before publication; the supplied landing page doesn’t expose every numeric requirement.

The StrongDM summary reports this distinction:

• Eight characters is the minimum floor.
• Fifteen or more characters is the sensible personal target, particularly for privileged accounts.
• Passwords should be screened against known compromised credentials.
• Password changes should follow suspected compromise rather than an arbitrary calendar.

But NIST does not say every password in every system must be 15 characters. A website may enforce a different limit or policy. Use the longest random secret the service accepts, and avoid any credential found in a breach database.

A complexity rule doesn’t make a predictable pattern safe. Winter2026!, Winter2027!, and Winter2028! are variations an attacker can test as a group. Length helps, but the useful combination is length, randomness, and uniqueness.

So generate a long secret and use it once. Let the service screen it against exposed credentials.

A passphrase is useful only when it is random

A passphrase and a password are formats. Security comes from randomness and length.

A manager-stored character password works well because you don’t need to remember it. A randomly generated multi-word passphrase suits the secrets you must type or recall. A phrase based on your dog, a lyric, or a familiar sentence has much less useful randomness.

Consider:

Summer2026!Blackhawk

It contains a season, a year, punctuation, and a known name. It looks busy while following an obvious construction pattern.

Use a password manager’s random passphrase generator, or another trustworthy generator that selects words independently. Don’t assemble the phrase yourself.

Four random words can provide substantial search space, but the result depends on the generator’s word list and selection method. The formats can’t be compared by length alone; the generator and search space decide the result.

Use this rule:

• Manager-stored secret: choose a long, random password.
• Memorised secret: choose a long, randomly generated passphrase.
• Hand-crafted phrase: assume it is weaker than it feels.

Your email or password-manager primary secret may be the exception to “store everything and forget it.” Make it memorable through random words, then protect it with strong MFA and separate recovery methods.

Let a password manager do the repetitive work

Calling a password manager optional in 2026 is bad advice. Reuse is the predictable alternative.

For Maya, the manager replaces MayaRiver!2024, MayaRiver!2024!, and the other variations with unrelated generated secrets. The shopping-site breach then exposes one credential instead of a pattern that also threatens email and the vault.

A suitable manager should meet a clear minimum bar:

Criterion	What to check
Protection model	Can you read the provider’s documentation about whether it can decrypt vault contents, how encryption works, and what it can access?
Device coverage	Does it support your operating system, browser, and phone? Test the devices you use every day.
Passkey support	Can it store and use passkeys for the accounts where you need them?
Exposure alerts	Does it identify reused credentials and warn when saved credentials appear in known public breach data?
Recovery and export	Do you understand how to export your vault, recover access, use emergency access, and proceed if your primary device disappears?
Secure sharing	If you need to share credentials, can you do so without sending passwords through chat or email?
Vault MFA	Can you protect the manager account with a passkey or security key?

Treat the manager’s primary account as a recovery-control account: its compromise can expose every stored credential. Protect its recovery methods separately. Recovery is the boring part, and it’s where many otherwise good setups fail.

Audit recovery channels as carefully as login methods. An attacker who controls your recovery email, phone number, or recovery codes may bypass the strongest authentication factor.

Check the domain before accepting autofill. A compromised browser or endpoint can still expose what you type or approve. Keep the manager, browser, and operating system current.

MFA is a ladder, not a checkbox

SMS is a fallback, not a destination for an email, bank, work, or vault account.

For ordinary accounts, phishing resistance rises from SMS and email codes to authenticator apps, push approval, passkeys and hardware security keys. The middle of that ladder is messy. Well-designed number-matching push can outperform a poorly implemented TOTP setup. Both remain weaker against phishing than a properly implemented passkey or security key.

1. SMS or voice codes: better than a password alone, but exposed to phishing, account-recovery abuse, and phone-number attacks.
2. Email codes: dependent on the security of your email account, which often controls other resets.
3. TOTP authenticator apps: independent of the phone network, but a phishing site can still ask for the current code.
4. Push notifications: convenient, but repeated prompts can create approval fatigue. Number matching and clear context help.
5. Passkeys and hardware security keys: the strongest mainstream options because authentication is tied to the legitimate site or service.

Microsoft Learn’s phishing-resistant MFA guidance identifies social engineering, man-in-the-middle attacks, and MFA bombing as ways attackers defeat traditional MFA. The same guidance reports that 92% of Microsoft employee productivity accounts use phishing-resistant authentication methods. That is Microsoft’s internal statistic, not a universal industry measurement.

Properly implemented passkeys bind authentication to the site origin. A phishing page can collect a password and an OTP; it normally can’t obtain a valid passkey response for its own domain.

The guidance says Entra ID users enabled for SMS or voice authentication are scheduled to be automatically enabled for passkeys from September 1, 2026. Microsoft-provided SMS and voice delivery is scheduled to retire on February 1, 2027. Verify those dates against the live documentation before using them in a workplace migration plan.

Passkeys resist phishing, not every kind of compromise

Passkeys are the best mainstream login option we have. The August research concerns implementation failures and compromised devices. Passwords have not become the better choice.

On August 21, 2026, The Hacker News reported three research efforts involving passkey implementations and surrounding systems. The reported attack paths involved endpoint storage, synchronisation, session handling, or identity-provider validation.

The report described a SpecterOps “Pass-the-Passkey” demonstration involving Windows-stored YubiKey signatures and Entra ID validation. It reported the issue as CVE-2026-34348, with a CVSS score of 6.5, and said Microsoft addressed it in July 2026 updates.

It also described Unit 42 research into synced passkeys in Google Password Manager on Chrome for Windows. The reported “Golden Pass-ta-key” scenario targeted the Security Domain Secret, described as a 32-byte key protecting synced passkeys. The report said Google removed the secret from device logging, while it remained in process memory during re-registration, and that it couldn’t be rotated or revoked.

A third report, from Dirk-jan Mollema, examined malware inside a compromised Windows session. The account said the malware could use a Windows Hello for Business key without a fresh PIN or biometric prompt, while an Entra WebAuthn challenge remained valid for five minutes.

I can’t establish from this reporting that one passkey storage model is universally safest. The studies concern particular implementations and attack paths. The practical rule is firm enough: patch the device, keep browsers current, use least privilege, revoke suspicious sessions, and reject unexpected prompts.

Phishing resistance helps against the fake login page. It doesn’t make an infected laptop trustworthy.

After a breach, contain the account before investigating it

The supplied research doesn’t provide a universal consumer recovery procedure, so this checklist is editorial guidance. Provider-specific recovery steps, financial-reporting deadlines, and workplace incident rules still need verification.

1. Use a clean, trusted device. If you have evidence of malware, remote access, or an unknown browser extension, stop using that device for recovery until it has been assessed or reset.
2. Change the affected password immediately. Generate a new, unique secret. Don’t edit the old one by changing its year or punctuation.
3. Change every reused variation. Search the manager for the old base password, close variants, and accounts sharing the same email and secret.
4. Revoke active access. Sign out other sessions and remove remembered devices. Revoke app passwords and delete suspicious OAuth connections.
5. Replace weak MFA. Add a passkey or security key. If unavailable, use a TOTP authenticator rather than SMS where possible.
6. Inspect recovery settings. Check recovery addresses, phone numbers, forwarding rules, delegated access, recent logins, and newly created app passwords.
7. Contact the right organisation. Use an official website or statement, not a link in an unexpected message. Contact your bank or employer if money or identity data may be involved. Contact the provider about work access.
8. Preserve evidence. Save alerts, timestamps, login notifications, and suspicious messages before deleting them.
9. Expect follow-up phishing. Attackers may impersonate support staff after the first breach. Don’t approve unexpected prompts or use unsolicited recovery links.

The compromise-triggered reset principle is supported here through secondary reporting; verify the full NIST text before publishing it as a direct standard requirement.

Don’t declare the incident contained until active sessions, recovery methods, reused credentials, and MFA have all been checked.

Remove these habits from your security routine

• Stop rotating passwords every 60 or 90 days without evidence of compromise. Change them after a breach, suspicious activity, accidental disclosure, or provider instruction.
• Stop decorating one password. A capital letter, !, or current year creates a predictable sequence.
• Stop reusing your email password. Email controls resets for many other accounts.
• Stop treating all MFA as equivalent. SMS and push help, while passkeys and security keys resist phishing more effectively.
• Stop storing recovery information beside the thing it recovers. Separate recovery codes from the vault and primary device.
• Stop assuming passkeys excuse an unpatched device. Recent reporting found weaknesses around implementations, sessions, and endpoints.
• Stop using a short memorable password for a high-value account. Password-reset accounts deserve a long random secret or randomly generated passphrase.

Scheduled password changes create predictable variations when no compromise has occurred. Change the credential when the risk changes.

Your 2026 priority order

Today: protect personal email, financial accounts, work systems, and the password manager. Replace reused credentials first, especially any password shared with email.

This week: add passkeys or hardware security keys to high-value accounts. Replace SMS wherever stronger MFA is available, and store recovery codes separately.

This month: audit recovery addresses and phone numbers. Check old accounts, browser-saved passwords, active sessions, and the devices holding your authenticators. Remove accounts you no longer use.

After any alert: use a clean device when necessary, contain the affected account, revoke sessions, replace reused credentials, and check recovery controls before you investigate further.

Unique generated credentials, phishing-resistant MFA, and separate recovery paths beat clever password composition. That is the setup to build.