Password Manager Vault Breach Response Playbook

When a password manager provider loses encrypted vault data, every secret in it moves from protected to protected-for-now, and the attacker can keep guessing offline for years. The 2022 LastPass breach showed what that means in practice: an encrypted vault backup was copied, some fields such as website URLs were not encrypted, and the strength of each user's master password and key derivation settings decided how long their secrets stayed safe. This template gives [Organisation] a ready-to-adopt playbook for a breach at its password manager provider, or a compromise of its own self-hosted vault. It focuses on what to rotate first, because nobody can rotate thousands of credentials at once. It is for identity, security operations and IT teams. For individual leaked credentials see the Leaked Credential Response Playbook.

How to use this template

Replace placeholders in square brackets, such as [Organisation], [Identity lead] and [72 hours].
Separate two scenarios: provider breach (vault data or provider systems taken) and tenant compromise (an administrator or user account in your own tenant taken over). Sections note where the steps differ.
Work from the provider's facts: what was taken, which fields were encrypted, and which key derivation settings applied. Record each provider statement with its date, because disclosures are often updated, as LastPass's were between August and December 2022.
Prepare the inventory now: section 3 needs to know which vaults and shared folders hold which classes of secret. Without it, triage becomes "rotate everything", which never finishes.

1. Scope and triggers

1.1 In scope: enterprise password managers (cloud-sync and self-hosted), shared and personal work vaults, secure notes, stored files, one-time password seeds held in the manager, and any integrations (directory sync, SSO federation, API keys for the manager itself).

1.2 Triggers:

Trigger	Example	Initial severity
Provider discloses theft of encrypted vault data	Provider incident notice, regulator notice, press	Critical
Provider discloses access to systems but not vaults	Source code or development environment taken	High: monitor for updates, review client integrity
Administrator account in [Organisation]'s tenant compromised	Unexpected policy change, new admin, export event	Critical
User master password or device compromised	Infostealer infection on a device with an unlocked vault	High for that user's vault and shared folders
Unusual vault activity	Mass export, new device enrolment, failed unlock spikes	High until explained

2. Roles and contacts

Role	Responsibility	Contact
Incident lead	Severity, decisions, tracking rotation progress	[Identity lead]
Password manager administrator	Tenant settings, logs, forced resets, policy changes	[Name]
Secret owners	Rotation of each credential class (cloud, network, finance, SaaS admin)	[Owners register]
Security operations	Monitoring for use of vault credentials, phishing campaigns	[SOC on-call]
Vendor management	Provider communications, contract obligations	[Name]
Legal and communications	Notification decisions, staff and customer messaging	[Names]
Provider	Incident facts, technical indicators, account-specific advice	[Account manager, security contact]

3. Detection and triage

3.1 Establish the facts

Which data was taken: vault contents, account metadata, MFA seeds, federation keys, backups, source code?
Which fields were unencrypted? LastPass reported that website URLs were stored unencrypted while usernames, passwords, secure notes and form-fill data were AES-256 encrypted. Unencrypted URLs tell an attacker which vaults are worth cracking first.
Which key derivation settings applied to [Organisation]'s accounts? LastPass's default was 100,100 PBKDF2 iterations at the time; OWASP now recommends 600,000 iterations for PBKDF2-HMAC-SHA256, and Bitwarden's current default is 600,000. Older accounts may have lower values.
Did federation (SSO) protect the vault key? LastPass told Federated Login business customers that no additional action was needed, which shows why the login model matters to triage.

3.2 Prioritise by value and exposure

Priority	Secret class	Rotate within
P1	Cloud root and administrator accounts, identity provider admin, domain admin, break-glass accounts, cryptocurrency and payment credentials, code signing and CA keys, production database credentials	[24 hours]
P1	One-time password seeds and recovery codes stored in the manager	[24 hours] (re-enrol MFA)
P2	Service account passwords, API keys and tokens, SSH keys, network device credentials, SaaS admin accounts, shared folders used by IT	[72 hours]
P3	Individual user SaaS accounts behind SSO, low-privilege shared accounts	[14 days]
P4	Personal or low-value entries with no business access	Advise users

Raise any vault by one priority level when its master password was short, reused or set before current policy, when its iteration count is below current guidance, or when the account was not federated. Non-human credentials stored as secure notes (API keys, service account passwords, connection strings) are usually the highest-value and least-rotated entries; see the Secrets Management Guide.

4. Containment

Tenant compromise: disable compromised admin and user accounts, revoke their sessions and trusted devices, remove unknown administrators, and block vault export by policy.
Raise protection on the remaining vault: enforce MFA on every account (NCSC advises MFA on all cloud-sync password managers), raise key derivation settings to current guidance, and require master password changes where policy was weak. Note that changing the KDF does not rotate the underlying vault key in some products; Bitwarden documents that vault data is not re-encrypted, so a stolen copy remains as crackable as before. Containment for stolen data therefore means rotating the secrets, not the master password.
Brief users about phishing: attackers who hold account metadata will phish users with convincing provider-branded messages. LastPass warned customers that it would not ask for master passwords by phone, email or text.
Increase monitoring on P1 and P2 systems for logins using vault-stored credentials, especially from new locations.

5. Eradication

Rotate in priority order and track each credential as rotated, retired or accepted-risk with an owner and date.
Re-enrol MFA for any account whose TOTP seed or recovery codes were stored in the manager, and prefer phishing-resistant methods for P1 accounts. See the Phishing-Resistant MFA Guide.
Retire rather than rotate where possible: replace static API keys and shared admin passwords with federation, short-lived tokens or a privileged access tool.
Reset integrations with the password manager itself: directory sync credentials, SCIM tokens, API keys for the manager and any federation keys the provider advises resetting.
Remove secrets that never belonged there: production keys and private keys found in vaults move to a secrets manager or HSM.

6. Recovery

Confirm all P1 and P2 credentials are rotated, and that dependent services work. Rotation of service credentials can break production: stage it, and keep a documented rollback (the previous credential disabled, not deleted, until the service is confirmed healthy).
Decide whether to stay with the provider, based on its disclosure quality, root cause and remediation. NCSC advises judging providers by how they handle vulnerabilities and disclosure.
If migrating, export under controlled conditions, import into the new product, and securely delete export files.
Continue monitoring for use of old credentials for at least [12 months], because offline cracking continues long after the breach. Investigators linked cryptocurrency thefts in 2024 and 2025 to the 2022 LastPass data, though LastPass said it had no conclusive evidence connecting them. See the LastPass Breach 2022.

7. Communication and notification

Staff: what happened, what [Organisation] is rotating centrally, what each user must do for their own entries, and how to spot phishing.
Leadership: rotation progress by priority, accepted risks, provider decision.
Customers and partners: needed if their credentials (for example shared portal accounts or API keys they issued to you) were stored in the affected vaults.
Regulators: legal assesses whether personal data in vaults or metadata triggers notification. In the LastPass case the UK ICO fined LastPass UK Ltd £1.2 million in December 2025, so regulators may also be investigating the provider.
Provider: request account-specific findings in writing; LastPass contacted a minority of business customers directly with tailored steps.

8. Post-incident review

Record time to first P1 rotation, time to complete P1 and P2, number of secrets with no known owner, and number found that should have been in a secrets manager. Review master password policy, key derivation settings, MFA coverage, federation, and contract terms on breach notification timing. Feed results into third-party risk reviews of the provider. See the Third-Party Risk Management Guide.

Implementation guidance

Preparation

Tag shared folders and entries by secret class so that P1 and P2 lists can be produced in minutes.
Keep an owner for every shared folder and every non-human credential stored in the manager.
Set and audit key derivation settings, master password policy and MFA across the tenant; NCSC lists vault access, new device enrolment, master password resets and failed unlocks as events worth logging.
Store break-glass credentials outside the primary password manager so that a provider incident does not lock you out. See the Break-Glass Account Guide.

Decision guidance

Situation	Approach
Encrypted vaults taken, strong master passwords, federated login	Rotate P1 secrets and MFA seeds as a precaution; monitor; rotate others on normal cycles
Encrypted vaults taken, non-federated, older KDF settings	Full P1 to P3 rotation programme
Admin account in tenant compromised	Treat every vault the admin could reach or reset as exposed in plaintext
Provider systems breached, no vault data	Monitor disclosures, verify client updates, rotate manager integration keys

Where identity fits

The slowest part of most vault breach responses is not human passwords, which users can change themselves, but the non-human credentials that administrators parked in shared folders: service account passwords, API keys, database connection strings and cloud access keys. They have no self-service reset, often no recorded owner, and rotating them can break production. Treat each one as a non-human identity with an owner, a consumer list and a rotation method before the next incident. See the NHI Ownership Guide.

Evidence to preserve

Tenant audit logs (logins, exports, policy and admin changes) for at least [90 days] before the disclosure date, exported before any reset.
Provider notices and correspondence, each with its date.
The rotation tracker, showing each credential, owner, action and completion time.

Small and large organisations

Small organisations: the P1 list may be twenty accounts. Rotate them the same day and move MFA seeds out of the manager.
Large organisations: automate rotation for service credentials through a secrets manager or PAM tool, and use the manager's reporting to track user-level changes.

Metrics

Time to complete P1 rotation.
Percentage of P2 credentials rotated within target.
Percentage of vault entries with an owner and secret class tag.
Percentage of accounts meeting current KDF and MFA policy.
Number of non-human credentials found in vaults that have since moved to a secrets manager or PAM tool.

Framework mapping

Framework	Reference
NIST CSF 2.0	PR.AA-01, GV.SC-08, RS.MI-01, RS.CO-02
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management, SR-8 Notification Agreements, IR-4
MITRE ATT&CK v20	T1555.005 Password Managers, T1110.002 Password Cracking, T1566 Phishing

Password Manager Vault Breach Response Playbook: Prioritise and Rotate Your Most Valuable Secrets