Password manager breach response: what to do in the first 24 hours

A password manager breach is the worst-case scenario for your credential security. It is also survivable if you act in the right order and don’t panic. This guide is the playbook to run in the first 24 hours after you hear that your vendor was compromised — or that your own vault has been exposed.

The pattern matters more than the specific vendor. The 2022-2023 LastPass incident, in which encrypted vault backups were exfiltrated and later targeted with offline attacks, is the case study most users will recognise; the response steps below apply equally to any future incident involving 1Password, Bitwarden, Dashlane, KeePassXC sync providers, or browser-based managers.

First: confirm whether you are actually affected

Before you rotate hundreds of passwords, confirm two things.

1. Is the breach real, and what was taken?

Read the vendor’s official incident notice — not a tweet, not a forum post. Reputable vendors publish a dedicated post-incident page with a timeline. The LastPass breach disclosure is the model for what to look for: dates, what data classes were involved (metadata, encrypted vault, plaintext fields), and the assumed attacker capability (LastPass incident notice ↗).

The three things you need to know:

• Was the encrypted vault itself exfiltrated, or only metadata?
• Which fields inside the vault were encrypted, and which were stored in plaintext (URLs are frequently plaintext)?
• What KDF and parameters were used to derive your encryption key from your master password?

2. Are your accounts in scope?

Some incidents affect only a subset of users — a specific region, a specific product tier, or accounts created in a specific window. Vendors usually publish a tool to check. If they have not, assume you are affected.

Triage your master password

If the attackers have your encrypted vault, the only thing standing between them and your plaintext credentials is your master password and the KDF.

Ask the honest question: would your master password survive an offline attack from a well-resourced adversary running GPU-accelerated cracking against the published KDF parameters?

• A 20+ character random passphrase or string with Argon2id is, in practice, not crackable.
• A short, memorable, or reused master password with low PBKDF2 iteration counts is at significant risk. NIST SP 800-63B explicitly calls out memorised secrets as a single point of failure and recommends both length and slow KDFs precisely for this scenario (NIST SP 800-63B §5.1.1 ↗).

If your master password is weak, you are now in a race. Assume the worst and move to rotation.

Rotate in priority order, not alphabetical order

You cannot change every password in an afternoon, and you should not try. Rotate in tiers.

Tier 1: identity and recovery accounts (first 2 hours)

These are the accounts that can be used to recover everything else. If any of them fall, the rest of the rotation is meaningless.

1. Primary email account — the recovery destination for almost everything you own. Rotate the password, then immediately review forwarding rules, filters, and OAuth-connected apps for anything you did not create yourself.
2. Backup email account — same treatment.
3. Mobile carrier account — SIM-swap is the most common follow-on attack after a credential leak. Set a port-out PIN if your carrier supports it.
4. Domain registrar — for anyone who owns a domain. A compromised registrar gives the attacker your email DNS.

For each of these: rotate the password, then audit active sessions and revoke any you do not recognise.

Tier 2: financial and high-impact accounts (first 6 hours)

Banks, brokerages, payment processors (PayPal, Stripe), cryptocurrency exchanges, and any account that holds funds or payment methods. CISA’s joint advisory on identity-based attacks notes that financial accounts are the dominant monetisation target after credential exposure (CISA AA24-241A ↗).

Tier 3: high-value services (first 24 hours)

Cloud storage, code hosting (GitHub, GitLab), work accounts, social media with significant reach, and any service that contains personal data you would not want exposed.

Tier 4: everything else (over the following weeks)

Forums, retail accounts, newsletter signups. These are low-impact in isolation, but rotate them eventually — credential stuffing tools will keep trying these combinations for years.

Re-key the vault itself

Once your high-priority accounts are rotated, address the vault.

1. Change your master password to a fresh, long, random value. Do not reuse the old one or a variation.
2. Verify the KDF settings. Most modern vendors default to either Argon2id or PBKDF2 at 600,000+ iterations. If you are still on older defaults (10,000 PBKDF2 iterations was common in legacy deployments), update them now.
3. Rotate the account email if the breach included account email addresses — this is the address attackers will target with phishing for the next several years.
4. Force-log-out all sessions from every device and re-authenticate. This invalidates any session tokens an attacker may have captured.

Do not forget TOTP seeds and passkeys

The thing many people miss after a vault breach is that TOTP seeds and passkeys stored in the same vault are also compromised if the vault was decrypted.

For any account where you stored the TOTP seed in the breached vault:

• Disable 2FA on the account.
• Re-enrol 2FA with a fresh seed, stored either in a different authenticator app, a hardware key, or in the new vault.

For passkeys: if the passkey credentials were stored in the breached vault, delete them at the relying-party (Google, GitHub, etc.) and re-enrol. This is one reason hardware-bound passkeys on a security key are more resilient than software-synced ones in a vault — see the passkeys explained guide for a fuller treatment.

Watch for the second wave

Credential exposure is rarely a single event. Expect, in the weeks after:

• Targeted phishing referencing your real account names, sometimes including breach details to establish credibility.
• SIM-swap attempts against your registered mobile number.
• Credential stuffing against accounts you forgot to rotate.

Enrol your primary email in HaveIBeenPwned ↗ notifications if you have not already, and keep checking it for the next 12 months.

The historical pattern with breached vault data — exemplified by the months-long monetisation cycle that followed the LastPass incident ↗, where exfiltrated encrypted vault backups were targeted with offline cracking for years — is that exposed data is sold, re-sold, and used in waves for years. Treat the response as a 12-month posture change, not a one-day task.

When to switch vendors

A breach is not automatically a reason to leave a vendor. Look at how they handled it:

• Was disclosure timely and detailed?
• Did they publish the technical scope, including KDF parameters and which fields were plaintext?
• Did they ship concrete remediation (default KDF upgrades, URL encryption, mandatory password rotation prompts)?

A vendor that responds well is often safer afterwards than competitors who have not yet been tested. A vendor that minimises, delays, or obscures the scope is a vendor to leave. The Bitwarden vs 1Password comparison covers the architectural differences that matter if you do decide to migrate, and the browser passwords vs dedicated manager post addresses what the realistic fallback options are.

The pre-breach work that pays off here

Almost everything in this playbook is faster if you did the work in advance:

• A 20+ character master password with Argon2id buys you weeks of safety margin while you rotate.
• TOTP seeds stored outside the password vault (in a separate authenticator app) means you do not have to re-enrol every site’s 2FA.
• An offline-printed list of your top-tier accounts means you do not have to remember which 30 services to rotate first while panicking.
• A pre-set port-out PIN with your carrier removes the SIM-swap risk window entirely.

If you do not have these in place yet, today is a good day. Start with the password security fundamentals guide and work outward.

See also

• Passkeys explained
• Password security fundamentals
• Bitwarden vs 1Password (2026)
• Browser passwords vs dedicated manager