Password manager hacked? What an encrypted vault can and can’t protect

A password-manager breach does not automatically mean someone can read every password in your vault. First separate four things an attacker might have obtained: account records, an encrypted copy of your vault, a way to sign in, or a device that had already unlocked the vault. Those cases have different consequences.

A password manager’s everyday security benefit still matters: it can give each site a different password, so a password stolen from one service cannot simply be reused at another. NIST’s 2025 Digital Identity Guidelines , which address digital identity services, explain that distinct passwords help prevent password-stuffing. After a breach notice, the useful question is specific: which data and access paths were exposed?

What an encrypted vault does — and doesn’t — tell you

Many cloud password managers encrypt vault contents on your device before syncing them. A copy of that encrypted data is not the same as a readable list of passwords. Exactly what a provider encrypts, what keys it needs and how account recovery works depends on its design.

The differences are visible in providers’ own technical documents. The 1Password Security Design White Paper, release 0.5.2 on 5 March 2026 , describes a key-derivation design that combines an account password with a Secret Key held by the user. The paper says data held by the service cannot be used to test guesses against the account password. Bitwarden’s security white paper describes vault data being encrypted on the client before it reaches the server, with keys derived using a key-derivation function.

Those are each provider’s descriptions of its own system, not an independent comparison or a guarantee that every part of a service is immune to compromise. “Encrypted” and “zero knowledge” are useful starting points, not a complete answer. Check which vault fields are encrypted, what account information remains visible to the provider, how login differs from vault decryption, whether sessions can be revoked, and what an administrator or recovery contact can do.

Four breach scenarios, four different responses

Someone copied encrypted vault data

If an attacker obtained only encrypted vault data, the provider’s key design and the secrets needed to decrypt it determine what the attacker can do. A long, unique master passphrase matters where the design depends on one. Some services also use a separate high-entropy secret. Keep recovery information somewhere safe outside the vault, so losing access to the vault does not also lose its only recovery route.

Ask the provider whether the incident included encrypted vault contents, a password-verification value, a decryption secret or recovery material. If the company confirms that only encrypted data was copied and no unlocking secret or active session was exposed, follow its incident instructions before resetting every password you own. If the scope is unclear, treat it as unknown and prioritise your most important accounts while you get clarification.

Someone stole the account password or an active login

A stolen password can let an attacker attempt to sign in. Turn on the strongest independent multi-factor authentication (MFA) the provider offers. A security key or passkey can resist phishing; an authenticator code is still useful when stronger options are unavailable. The CISA and FBI’s account-protection guidance advises phishing-resistant MFA for important accounts.

MFA and vault encryption protect different paths. For example, Bitwarden describes two-step login as an extra check for online account access, while vault data is decrypted locally on the device. Revoke unknown devices and active sessions through the provider’s official account settings. Change the manager’s master password from a device you trust if it may have been exposed.

Changing a master password may not be the same as rotating the key that encrypts existing vault data. Bitwarden documents key rotation as a separate operation; other services may work differently. Ask the provider whether its incident response calls for a key rotation or another recovery action.

An unlocked or compromised device exposed the vault

Encryption protects stored data while the required key is unavailable. It cannot keep secrets hidden from malware or an attacker who can use an already-unlocked client. Bitwarden’s security paper says its encryption key is held in memory while the app is unlocked, and warns that malware such as a keylogger can capture secrets entered on a compromised device.

Lock the vault when you step away, use a short automatic lock timeout, and keep your operating system and trusted password-manager apps updated. These steps reduce exposure; they do not undo access that already happened. If a device may have been compromised, use another trusted device to revoke sessions and change the most important saved passwords after securing the affected machine.

Recovery or shared access was involved

Recovery features and work or family administrators can provide a legitimate way back into an account, but they are another authorised access path. Check who can request access, who can approve it, what the process restores, and whether the action is logged. Keep recovery codes separate from the vault they recover.

There is no universal rule that recovery should be disabled. Choose a recovery arrangement you understand and can use, especially for a work account with an organisation’s own policy. The provider’s current documentation should explain the exact trade-off.

If you receive a breach notice

1. Verify the notice. Don’t use a sign-in link in an unexpected email or message. Open the provider’s app or type its known website address yourself. CISA’s account-protection guidance recommends going directly to the site to check an alert.
2. Read what was accessed. Look for the affected dates and whether the notice names account details, encrypted vault data, passwords, recovery information, or active sessions. “Encrypted” alone doesn’t tell you whether an unlocking secret was also exposed.
3. Secure the manager account from a trusted device. Revoke sessions and unknown devices. Change the master password if it may have been exposed, enable MFA, and follow the provider’s instructions about key rotation or account recovery.
4. If readable vault data or an unlocked device may have been exposed, use a trusted device to change saved passwords on the accounts that matter most first: primary email, financial services, cloud storage and work accounts. Make each new password unique, turn on MFA where available, and review those services’ recent sign-ins and recovery details.
5. If the provider confirms a storage-only copy of encrypted data, use its incident guidance and ask any remaining questions about keys or sessions. You can make a measured decision without assuming that every saved password was already read.

Prepare before you need the recovery plan

Use a long, unique master passphrase and never reuse it for another account. Enable the strongest MFA available for the manager, and keep its recovery code somewhere separate. Set the vault to lock automatically, protect the device that unlocks it, and decide how you would get back in if your phone, computer or second factor disappeared.

A password manager can limit the damage from a password stolen at one website, but it does not remove the need to secure the account and device that unlock the vault. After a breach, identify what the attacker actually obtained before choosing what to reset.

Sources and further reading

• NIST SP 800-63B-4: Digital Identity Guidelines
• 1Password Security Design White Paper, release 0.5.2
• Bitwarden Security Whitepaper
• CISA and FBI: Protecting Accounts from Iranian Cyber Actors

The product examples are based on public documents available by 9 March 2026. During an actual incident, follow the provider’s current notice and recovery instructions.