Password Manager Security: What an Audit Actually Checks

A password manager is the one service whose compromise hands over everything else, and it is also the one service users cannot audit themselves. That asymmetry is why the useful questions are not "is it secure" but "what exactly does the vault protect against, what does it explicitly not protect against, and which settings decide whether a stolen backup is readable in a week or in a century".

This guide describes what a password manager audit tests in 2026 - from the key derivation parameters that decide the fate of an encrypted vault, through the browser extension that runs with access to every page, to the administrative recovery path that quietly bypasses the encryption model. It is written for the person choosing a manager for a team, the administrator who inherited one, and the assessor who has to state where the protection actually ends.

One framing first, because it prevents most of the arguments that follow. A password manager is a strong control against one class of failure - password reuse and weak memorised credentials - and a weak control against another: an endpoint that is already compromised. An honest audit says both, and a vendor that claims otherwise is selling reassurance rather than encryption.

What a password manager audit actually tests

Five questions decide the outcome, and each has an answer that can be evidenced rather than asserted. First, what key derivation function and parameters protect the vault, and are they the default or something the user has to change? Second, does the provider hold anything that would let them decrypt a vault, including recovery keys, escrow or server-side secrets? Third, what can the browser extension and the mobile app do on the device - read the page, write to the clipboard, inject scripts, capture screenshots, autofill into any origin? Fourth, what does the recovery and administrative path allow, and who can approve it? Fifth, when the provider itself was breached, what did the disclosure say, how fast was it, and did the protections hold for the users who had the defaults?

Each question maps to a test that takes minutes rather than days. For the first: create a test account, export the vault, and read the KDF header - most formats record the cipher, the iteration count and the salt in plaintext precisely so a client can decrypt later. For the second: read the cryptographic architecture documentation and look for the word escrow; if zero-knowledge is claimed, check whether the claim survives a password reset that preserves the vault, because a server that can re-wrap the vault key after a reset holds a key. For the third: install the extension and read its manifest permissions rather than its marketing page. For the fourth: try the emergency access flow on a test account and record what it asks for and what it bypasses. For the fifth: read the incident write-ups, not the press release.

The output is a short list of properties with evidence, plus the residual risks that remain after them. What it is not is a product comparison, because the answer depends on the threat the reader actually faces: a journalist protecting sources and a mid-size company protecting shared operational credentials need different properties from the same category of tool, and the settings that matter for one are irrelevant to the other.

The threat model most users get wrong

Two failures dominate the realistic risk picture, and they point in opposite directions. The first is vault exfiltration: an attacker obtains the encrypted vault, either from the provider's storage or from a device backup, and then attacks the master password offline at whatever speed the derivation function allows. The second is endpoint compromise: malicious code runs on a device where the vault is already unlocked, and no encryption model in the world helps, because the plaintext is on screen.

People worry about the first and are usually defeated by the second. A stolen vault is a cryptography problem with a measurable answer - the attacker's cost is a function of the master password's entropy and the work factor - while a compromised endpoint is an operational problem that ends with the attacker reading the vault through the same interface the user does. That is why the questions that matter most in practice are about extension permissions, auto-lock timeouts, clipboard behaviour and which devices hold an unlocked session, and why those sections come later in this guide rather than at the end.

The related identity questions - what happens when a session token leaks rather than a password - are covered in zero trust security. Two more failure modes belong in the model because they are specific to the category. Supply chain: the manager ships an extension or app that updates automatically, so a compromised build or a malicious update reaches every customer at once, which is a distribution risk that ordinary software shares but with a worse payload. Phishing of the master password: a fake vault login page harvests the one credential that unlocks everything, and the only durable defence is a phishing-resistant second factor bound to the legitimate origin rather than a code the user types.

Key derivation: the number that decides whether a stolen vault is readable

A vault is encrypted with a key derived from the master password, and the derivation function exists to make guessing expensive. The relevant parameters are the function, the work factor and the salt, and the setting that matters is the one applied to existing accounts rather than the one advertised for new ones. This is not a theoretical concern: it is the exact mechanism that decided which LastPass customers were exposed after the 2022 breach, when encrypted vault data for roughly 33 million users left the provider's storage.

The history is instructive because it shows how defaults freeze. LastPass raised its default PBKDF2 iteration count over a decade - from 500 in June 2012, to 5,000 in February 2013, to 100,100 from February 2018 - but accounts created earlier kept the value they were created with unless the user changed it manually. Security researcher Wladimir Palant's analysis, published in the wake of the disclosure, put the cracking cost of a vault at those settings in concrete terms for late-2022 hardware: roughly a year on a single consumer GPU at 500 iterations with a moderately strong password, about a decade at 5,000, and on the order of two centuries at 100,100. The same vault, protected by a weak password, at 500 iterations, was the worst case in that population - and it was a case the provider had known about since 2018.

Current guidance has moved. OWASP's password storage guidance recommends Argon2id for new designs, and where PBKDF2-HMAC-SHA256 is required - FIPS-constrained environments, for example - lists 600,000 iterations as the minimum work factor. The audit test is therefore not "does it use PBKDF2" but "what are the parameters on my vault, what are they on the vault of the least-technical user in the organisation, and did the provider migrate existing vaults or ask anyone to rotate".

Two practical consequences follow. Users should raise the iteration count if the product exposes the setting, accept that it will log every device out and require re-authentication, and understand that the improvement is real but bounded - it multiplies the attacker's cost, it does not make a dictionary password safe. Administrators should treat "the provider upgraded its default" as a statement about new accounts, and ask for the migration record, because the interesting number is the distribution of parameters across the existing population rather than the value in the release note.

Zero-knowledge claims and what they actually mean

"Zero knowledge" describes an architecture in which the provider stores only ciphertext and holds no key material that would let it decrypt a vault. It is a real property when it holds, and it is frequently stated loosely. The audit test is structural: where is the vault key generated, who can re-wrap it, and what happens during a password reset that preserves the vault contents?

A provider that can restore an account's vault after the user forgot the master password has, by definition, some way to reach the key. That is not automatically wrong - most consumer products do exactly this, because losing every password on a forgotten passphrase is a support catastrophe - but it changes the model from "the provider cannot read your vault" to "the provider can, under controls". Those controls are the thing to assess: who can initiate the reset, whether it requires identity verification the attacker cannot forge, whether it is logged, whether the customer can disable it, and whether the organisation can hold its own key.

For a business deployment the question becomes a procurement requirement rather than a curiosity. If the vault holds credentials that would compromise the company - root accounts, payment provider keys, recovery codes for the identity provider - the answer should be verifiable, written into the contract, and tested on a test account before rollout. A product where the answer is unclear is not unusable; it is a product whose risk has to be accepted explicitly, by a named person, in writing.

Master password policy: length, uniqueness, and the rotation trap

The master password is the single credential that must never be reused, never typed into anything but the manager, and never short. The useful guidance is almost the opposite of what most corporate password policies still require: a long passphrase, written down somewhere physically safe if that helps the person remember it, and no periodic rotation, because rotation produces incremental variants of the same weak password.

NIST's digital identity guidance moved in this direction years ago and the current revision, SP 800-63B-4, formalises it for verifiers: composition rules that force character classes and periodic expiry are discouraged in favour of length minimums, blocklists of compromised and common passwords, and rate limiting. A password manager's master password sits outside that framework in one respect - it protects a local artefact rather than an online account, so the offline guessing cost is what matters - and inside it in another: the provider's own login should enforce a sensible minimum, a compromised-password check and throttling.

For a team, the policy that works is short enough to be remembered: at least four randomly chosen words or sixteen characters, unique to the vault, never stored in the vault itself, and changed only when there is a reason - a suspected exposure, a lost device, or a provider incident that may have exposed the encrypted vault. Anything more elaborate gets written on a sticky note or downgraded to something memorable and weak, which is worse than a documented four-word passphrase.

MFA on the vault, and why a TOTP code is not enough

Multi-factor authentication on the vault login protects against a stolen master password, and the type of factor decides how much. A one-time code copied from an authenticator app is phishable in real time: a proxy page collects the password and the code and replays both before the window closes. That attack is well documented, cheap to run and routinely successful, which is why a code-based factor should be treated as a speed bump rather than a wall.

Phishing-resistant factors are bound to the origin cryptographically. FIDO2 security keys and passkeys built on the Web Authentication standard are the ones that hold: the credential will not authenticate to a look-alike domain, so the proxy attack that defeats a code simply fails. Where a provider supports passkeys or security keys for vault login, enabling them is the single highest-value change most users can make, and it is worth preferring a product that supports them over one that does not.

The test in an audit is specific: can the vault login be completed with a hardware key or a passkey, is the factor required on every new device rather than once per device, and can an administrator enforce it for the whole organisation rather than trusting each user to opt in? A product where the answer to the last question is no is a product where the organisation's MFA policy is a request, not a control.

The endpoint is the weakest link: extensions, permissions and autofill

A browser extension that fills passwords on every site is, in capability terms, a key to everything: it can read the page, inject content, observe form submissions and access the stored vault. The permission list in its manifest is the honest description of that capability, and it is worth reading before installation - not the marketing page, the manifest.

What to look for is the difference between the access a manager needs and the access it asks for. Filling a password on a page requires script execution in that page's context; it does not require reading every tab, capturing the clipboard continuously, or reaching all browsing history. An extension that requests host permissions for all sites and additionally asks to read and change all data should be justified by a published architecture that explains why, and a manager that fills only on the pages where a matched credential exists should be preferred where that is implementable.

Autofill itself is a security decision with a usability price. Aggressive autofill fills into any field that looks like a login, including on domains the user did not intend, and it enables the classic attack where a hidden iframe on a legitimate page collects a filled credential for a domain the attacker controls. Conservative autofill requires a click per field, which users find annoying and which is the reason many products err toward convenience. The audit question is which behaviour the product defaults to, whether the setting can be changed at all, and whether iframe filling is restricted to same-origin frames.

The clipboard deserves its own line because copying a password out of the vault moves it into a shared buffer that other applications read. Good implementations clear the clipboard after a timeout, refuse to copy on platforms where that is unreliable, and offer a drag-and-drop or direct-fill path that avoids the clipboard entirely. Bad implementations leave the password in the clipboard until something else overwrites it, which on a shared workstation can be hours.

Export, backup and administrative recovery: the underestimated paths

Every password manager can export the vault to a file, because users demand portability and vendors need a migration path. That export is the single most dangerous feature in the product: it produces a plaintext or weakly encrypted copy of every credential, it is created by hand at a moment of urgency, and it is routinely left in a download folder, emailed to a new laptop, or committed to a repository by mistake.

The same principle applies to the code that consumes these credentials: secure software development covers keeping secrets out of the build rather than only out of the browser. The controls that make this survivable are procedural as much as technical. Exports should be rare, recorded, and deleted after use; where the product supports an encrypted export format, use it, and store the file with the same protection as the master password rather than with a password in the same email. For organisations, the export path is also an exfiltration path for an insider under duress, so the audit should ask whether exports are logged and whether they can be disabled or gated for the admin group.

Recovery runs the same risk from the other direction. Administrative recovery of a departed employee's vault, emergency access for a colleague, and inheritance features for a family member all exist to prevent permanent loss, and each of them is a designed bypass of the encryption model. The test is whether each one requires multiple independent approvals, whether it is time-delayed, whether it notifies the vault owner, and whether it can be turned off for the accounts that hold the highest-value secrets.

A practical rule for a business: the vault of the person who can reset everyone else's passwords should not have emergency access configured to anyone, and the recovery of any vault holding production credentials should require two administrators plus a recorded business reason. That is more friction than most teams want until they have had one incident in which an account takeover used exactly this path.

Shared vaults, groups and the permissions nobody reviews

Shared vaults are where a password manager stops being a personal tool and becomes infrastructure, and where the default permissions are almost always too generous. The common pattern is a folder per team with a handful of administrators, an unclear list of members, and credentials for systems that left the team months ago still readable by everyone who ever joined.

An audit of the sharing model answers four questions. Who can create a shared vault, and is that restricted to administrators? When someone leaves a group, are their access rights removed automatically or does someone remember? Can a member re-share a credential with a person outside the group, and is that logged? Is there an expiry on access to the highest-value items, so that a contractor's access to a production database does not outlive the engagement?

The answers are usually a mix of "the product supports it" and "nobody configured it". That gap is the finding, and it is closed by treating the manager's sharing settings as part of the access review cycle rather than as a user preference: quarterly, with the same rigour as the cloud IAM review, and with the same output - a list of who holds what, and a decision on each.

Business controls: SSO, provisioning and the offboarding moment

For an organisation, the most valuable property of a password manager is not encryption, it is the ability to remove access at the moment a person leaves. That requires the vault to be tied to the identity provider rather than to a personal account, so that disabling the identity disables the vault, and it requires provisioning to be automated so that the group membership which grants access to a shared vault is derived from the directory rather than maintained by hand.

The controls to test are concrete. Does the product support SAML or OIDC single sign-on and enforce it, so that a user cannot bypass the workforce identity and log in with a password? Does it support SCIM provisioning and de-provisioning, and is the de-provisioning tested - remove a test user in the directory and verify that access to every shared vault is gone within minutes, not at the next sync? Are administrative roles separated, so that the person who manages users is not the same person who can export vaults? Are audit events exported to the same place as the rest of the estate's logs, or do they live in a portal nobody opens?

Those questions matter more than the encryption parameters for one reason: an organisation's realistic loss is not a cryptographic break, it is an account that should have been disabled and was not. A vault whose access dies with the directory account is a control; a vault with a local password that a departing employee keeps in a browser profile is a liability with a licence fee.

Vendor questions that produce a usable answer

Procurement questionnaires ask whether the vendor is "secure" and receive a certification list. The questions below produce something an assessor can act on, and each one has an answer that can be checked rather than believed. Ask them in writing, and ask for the artefacts rather than the summary.

Cryptography: which cipher protects the vault, which key derivation function and work factor, and what is the minimum applied to existing accounts? Request the technical documentation of the vault format, not the marketing description. Key custody: does the provider hold, escrow or generate any key material capable of decrypting a vault, and under what conditions is it used? Recovery: what are the administrative recovery paths, who can approve them, and can a customer disable them? Client trust: what permissions do the browser extension and the mobile app request, and are third-party scripts loaded into the vault web application? That last question is a reliable indicator, because a script from a third-party domain running in the vault's origin can read what the page can read.

Assurance: when was the last independent penetration test of the client applications and the vault API, was it scoped to the cryptographic implementation, and will they share the executive summary under NDA? A SOC 2 Type II report is useful for operational controls and says almost nothing about whether the vault format is sound; both are needed and they are not substitutes. Incident history: what breaches has the provider disclosed in the last five years, what was exposed, and what changed as a result? A vendor with a disclosed incident and a documented, specific response is often a better bet than a vendor whose history is a blank page, because the first has been tested and the second has not.

Two questions are worth adding for regulated environments. Where is vault data stored, and can the customer choose a region? And can the customer hold its own encryption key, so that the provider's storage alone is insufficient to decrypt? The second is rare in consumer products and increasingly expected in enterprise deals.

Incident history as evidence: what the LastPass case actually shows

The 2022 LastPass breach is the reference case for the category, and the useful reading of it is specific rather than dramatic. An attacker compromised a developer account in August 2022, moved through the provider's infrastructure over months, and by December had taken customer account data and encrypted vaults - reported at the time as affecting roughly 33 million users. The encryption held in the sense that the vaults were not decrypted at the provider; the exposure was of ciphertext, and the security of each vault then depended on the parameters and master password of that individual account.

That is the mechanism worth teaching: a breach of a zero-knowledge provider converts an online attack into an offline one, for every customer at once. What follows is decided by settings chosen years earlier, by users who had no way to know they mattered. The provider had increased its default iteration count over time - 500 in 2012, 5,000 in 2013, 100,100 from 2018 - without forcing existing accounts onto the stronger setting, so long-standing customers could still be protected by the weakest one. Researchers published cracking-cost estimates against those values, and the practical advice that followed was the same one this guide gives: raise the iteration count if the product allows it, use a long passphrase, and enable a phishing-resistant second factor.

The governance lesson is about time. Defaults set in one era persist into another, and a provider that improves defaults for new accounts has improved nothing for the population that already exists. When assessing any product in this category - and any encryption product generally - ask what the migration did to existing data, and treat a silent migration as the strongest possible answer and an unanswered question as a finding.

Metrics that show whether the manager is working

Adoption is easy to claim and hard to prove, and the numbers that prove it are not the ones most programmes report. Four are worth measuring, and each has a denominator that makes it honest. Coverage of the identity inventory: the share of workforce accounts that authenticate through the password manager's SSO path, measured against the directory rather than against the licence count. Vault health: the share of stored credentials that are unique, above a length threshold, and not present in a known-compromised set - a feature most products report per user and few organisations aggregate. Reuse exposure: for the accounts that matter most, how many share a password with any other account. Incident rate: the number of credential-stuffing attempts that succeeded, which should trend toward zero as reuse falls, and which is the only number a board will recognise.

The trap to avoid is treating enrolment as the outcome. A licence count measures procurement, and a trained-user count measures attendance; neither says anything about whether the person who reset the shared admin password last month stored it somewhere other than a chat message. The audit test that catches this is simple and unpopular: pick five production systems, ask for the credential, and see where it is and who can read it.

Migrating without re-creating the problem

Migration is where most password manager programmes quietly fail. Importing an old export into a new product moves every credential, including the duplicates, the dead accounts and the shared passwords that made the old arrangement unsafe. Without a cleanup pass, the new manager becomes a well-encrypted copy of the old problem.

A workable sequence: export from the old tool, delete the export the moment the import is verified, then work through the credentials that matter - production systems, financial accounts, the identity provider itself - rotating each to a unique generated password and deleting every duplicate as it is rotated. That is a finite job for the critical set and an infinite one for the long tail, so scope it deliberately: the critical set first, then the accounts that carry money or reputation, then the rest as users touch them.

Delete the imported export rather than archiving it, because a plaintext vault file on a network share is a worse outcome than the messy situation it replaced. If a record of the migration is needed for compliance, keep a hash and a date, not the contents.

Passkeys and the manager's changing job

Passkeys, built on the Web Authentication standard, replace the shared secret with a key pair bound to the origin, which removes both the reuse problem and the phishing problem for the sites that support them. Their spread changes the manager's role from storing secrets to holding credentials - the private key and its sync - rather than to filling a password field.

The vendor-side view of the same migration - how a provider's own development practice protects the client that holds your keys - is set out in our supply chain attack prevention guide. That transition has two implications for an audit. First, passkey sync is now part of the vault's security model: the private key travels between devices through the provider's synchronisation, and the questions about key custody and encryption apply to it exactly as they do to a password. Second, the migration is uneven, and a manager that supports passkeys for the sites that offer them while still storing passwords for the rest is doing its job - the audit should check the first half rather than assume the second.

For users, the practical guidance is unchanged in shape: use the strongest factor the site supports, prefer a passkey or a hardware key over a code, and keep the recovery codes for both the manager and the identity provider somewhere that is not the manager. The last point is the one that most often turns a good setup into a locked-out account.

Where an audit legitimately stops: the lawful boundary

Assessing a password manager means testing accounts you control and reading documentation the vendor publishes. It never means attacking a provider's production service, probing a commercial product's API without written authorisation, testing a colleague's vault, or attempting to decrypt data you obtained outside a sanctioned engagement. Those acts are criminal in most jurisdictions regardless of intent, and a vendor's bug bounty programme defines the only legitimate route for testing their systems - within its published scope, on the assets it lists.

The same boundary applies inside an organisation. An administrator with legitimate access to shared vaults should not read a colleague's personal credentials, and an assessment that does so has exceeded its scope even where the product permitted it technically. Written authorisation should name the accounts, the systems and the time window, and it should state whether the assessor may attempt recovery flows, unlock other users' vaults with administrative rights, or export data - because each of those is a real test and each needs to be granted explicitly.

For individuals, the equivalent discipline is simple: use the tool on your own accounts, verify the vendor through published material, and treat any request to test someone else's manager - including a partner's, an employer's or a client's - as requiring that owner's explicit permission in writing.

A thirty-day hardening sequence

The changes that matter most can be made in a month without new tooling, and doing them in this order means each one is verifiable before the next depends on it.

Days 1 to 3: read the parameters. Create a test account, export the vault, and read the KDF header. Confirm the function, the work factor and the salt, then raise the iteration count if the product exposes the setting and accept the re-login. Record the before and after values - that record is the baseline for everything later.

Days 4 to 8: fix the master credential. Replace the master password with a long passphrase that exists nowhere else, store the recovery kit offline, and enable a hardware key or passkey for the vault login. Verify that a new device requires the factor rather than trusting the setting description.

Days 9 to 14: audit the clients. Read the extension's manifest permissions on every browser in use, set autofill to a mode that requires a gesture, confirm the clipboard clears, and set auto-lock to minutes rather than hours. Do the same on mobile, including whether the app allows screenshots of the vault.

Days 15 to 21: close the sharing gaps. List every shared vault with its members and its administrators, remove anyone who has left the group, disable or gate exports for the admin group, and configure emergency access deliberately - on the few accounts that need it, off everywhere else.

Days 22 to 30: bind it to the directory. For an organisation, enforce SSO, enable provisioning, and test de-provisioning with a throwaway account. Then measure: coverage against the directory, vault health, and the five-production-systems test. Whatever the numbers say is the honest starting position, and it is a better one than the licence count.

What a good outcome looks like

The end state is not a product recommendation; it is a set of properties that hold together. A vault protected by a derivation function strong enough that a stolen copy is not the end of the story, on parameters applied to every account rather than to new ones. A master credential that exists in one place, with a phishing-resistant factor in front of it. Clients whose permissions match what they do, on devices that lock. A sharing model that a reviewer can read in five minutes and that dies when a person leaves. Recovery paths that are deliberate, logged and rare.

None of those properties requires a specific vendor, and none of them is proved by a certificate. They are proved by the artefacts described in this guide: the exported header, the manifest, the member list, the audit log, the de-provisioning test. An organisation that can produce those on request has done the work; one that can produce a procurement summary has done the paperwork.

The findings that come up most often, ranked by cost

Across the categories described above, the same findings recur, and they are worth naming so that an assessment can start by looking for them. The order below is by the cost of the failure rather than by the ease of the fix.

Default parameters inherited from an older product generation. The vault is protected strongly for accounts created this year and weakly for the accounts created five years ago, which are often the ones holding the oldest and most reused credentials. Fix: raise the setting per user, and prefer vendors that migrate rather than notify.

A code-based second factor where a phishing-resistant one is available. The vault login is protected by a factor that a proxy page defeats in real time, and the organisation believes it has MFA. Fix: hardware keys or passkeys, required on new devices, enforced through the identity provider where possible.

An extension installed from a second browser profile or an old laptop. The manager is deployed, the user also installed it on a personal device signed into the same vault, and the auto-lock on that device is off. Fix: review the device list in the admin console, which most products expose and almost no one reads.

Plaintext export in a download folder. Someone migrated, exported, and never deleted. Fix: search for the export filename across file shares and mail, delete what is found, and rotate every credential it contained - because the file was readable for as long as it existed.

Shared vault membership that outlives the engagement. Contractors and former employees retain read access to credentials for systems they no longer touch. Fix: derive membership from the directory, review quarterly, and expire access to the highest-value items.

None of these needs a new tool, and each is found in an afternoon. That is the argument for doing the assessment before buying anything: the highest-value findings in this category are configuration and process, and they cost nothing but attention.