What a Password Manager Does—and Which Risks Remain
A password manager stores credentials in a vault and lets you retrieve them when needed. Its most direct benefit is reducing reliance on passwords that are easy to remember and reuse: you can assign different passwords to different services without having to memorise them all. The National Cybersecurity Alliance explains the role of these tools and presents them as a way to make signing in more securely easier. That does not make any password manager, by itself, a guarantee against account theft. Source: National Cybersecurity Alliance. The practical advantage is therefore not that risk disappears, but that one common source of exposure—reused or easily guessed passwords—becomes easier to address. A manager can also make it more realistic to use a different credential for each account, because you do not have to remember every one. Consider that benefit alongside what the tool cannot control: the security of the account used to access it, the device on which you open it, and the recovery choices you make. A sound decision starts with separating those parts rather than treating the product as a complete security solution.
The important question is not only where passwords are stored, but what happens if someone gains access to the manager account, if you lose your second factor, or if the service becomes unavailable. The device from which you open the vault matters too: a compromised computer can expose credentials as you enter them, even if the provider protects stored data. A password manager reduces some password-related risks, but it does not eliminate risks involving the device, the account, or the user. This distinction is useful when weighing claims about security. Strong protection for stored data does not, on its own, prevent someone from watching a login on an infected device; likewise, secure sign-in does not tell you how a lost account can be recovered. Think through each point separately, including whether you can access the vault on the devices you actually use and whether you understand the consequences of losing a factor. The manager is one layer in a broader set of habits, not a substitute for them.
It is worth distinguishing a documented property from an absolute guarantee. Terms such as “encryption,” “zero knowledge,” and “enterprise-grade security” need context: which data do they cover? At what point is data encrypted? What can the provider recover? What happens if you forget the master password? Marketing information can suggest questions, but it cannot replace a technical explanation, a recovery policy, or an audit report that lets you understand what was reviewed. Look for statements that define the protected data and explain the roles of the provider and account holder. If a page uses a label without explaining its scope, do not infer that every category of information receives the same treatment. Nor does the presence of an audit label tell you which components were examined or whether the findings concern the version you would use. Treat unclear details as unresolved questions; do not turn promotional language into a technical conclusion.
Criteria for Comparing Documented Security
Start by looking for technical product documentation, not just a promotional page. Check whether it describes how the vault is protected, what information falls outside that protection, and which credentials are needed to decrypt the data. If the explanation does not let you understand the security model, do not fill in the gaps with assumptions: record them as open questions and consider whether the provider gives clear, current answers. A useful explanation should make it possible to tell what is protected, what the user needs to supply, and what the service says it can or cannot do. Read the relevant material as a description of a system rather than as a collection of reassuring terms. If an important part is absent, that absence is itself something to weigh when deciding whether you are comfortable relying on the product.
Also review how sign-in is protected. Multifactor authentication can add a barrier to the account, but its effectiveness depends on the available options and how access is recovered. NIST guidance on authentication, SP 800-63B, explicitly states that it was superseded by revision SP 800-63-4 in August 2025. The earlier edition is therefore useful here to illustrate why references need to be checked for currency, not to present its recommendations as the current guidance. Source: NIST SP 800-63B. When comparing authentication options, note not only whether an additional factor is offered but also what happens when it is lost or unavailable. A recovery route can be essential in practice, yet it should be understood as part of the account’s security design rather than assumed to be harmless or universally available. Confirm what the provider documents and avoid treating an older standard as current simply because it remains accessible online.
Audits: Scope, Date, and Limits
If a provider advertises an audit, look for the report or at least a verifiable description of who conducted it, when it took place, which components were reviewed, and what was left out. An audit is a bounded review; it does not certify that a product is invulnerable or show that every future version will retain the same properties. A commercial article about password audits can help explain the subject, but it is not the same as an independent report on a particular product. Bitwarden, resource on audit logs. Do not confuse the existence of activity logs with a security audit of the software: they are different controls with different objectives. Activity records may be relevant to monitoring or compliance, whereas an audit concerns the components and questions actually examined. Neither label should be stretched beyond its documented meaning. Check whether the report is available to read, whether its date is clear, and whether the version or scope matches what you are considering. If the provider offers only a broad statement, treat it as a claim to investigate rather than proof of comprehensive review.
Export and Recovery: Avoid Depending on a Single Way Out
Before importing your credentials, find out whether you can export them and in what format. Check whether the export includes all the categories you care about—for example, secure notes as well as passwords—and whether it requires an additional authentication step. Official Chrome help documents importing and exporting passwords and passkeys in Google Password Manager for Android; it is a useful reference for confirming that particular options can depend on the platform. Source: Google Chrome Help. Export is not an abstract checkbox: consider whether the resulting information can be used if you move to another tool, and whether the documented process covers the records that matter to you. Do not assume that two products handle every category in the same way. Read the instructions for the platform you actually use, because availability and steps may differ. Establishing these details before importing a full vault can help you avoid discovering a practical limitation only when you need to move or recover your information.
An export may create a readable file and is therefore sensitive. Do not leave it in an unprotected synchronised folder or email it as if it were an ordinary document. If you export in order to migrate, limit who can access the file, avoid keeping unnecessary copies, and securely delete it when you are finished. Also check whether the provider explains how to remove local data or sign out of devices you no longer control. Treat the file as a temporary concentration of credentials: its protection matters while it exists, even if your usual vault is encrypted. Plan where it will be created, who can reach that location, and when it will be deleted. Sending the file through a channel that retains copies can undermine the care taken elsewhere. After migration, do not assume that closing the application removes every copy; follow the available instructions for sessions and local data, and consider any devices that are no longer in your possession.
Account Recovery
Ask what options exist if you lose the master password, phone, or authentication key. Do not assume support can recover the vault: a policy that prevents the provider from decrypting the data may limit recovery, even if it benefits privacy from third parties. Look for a concrete explanation of what can be recovered, what data could become inaccessible, and which steps you should prepare before an emergency. If there is family or business recovery, find out who can initiate it and what authorisation is required; the name of the feature does not explain its actual permissions. Consider the trade-off before relying on the account. A recovery process may depend on another person, administrator, device, or preconfigured method, so its existence alone does not establish that it will meet your needs. Read what the provider says about the route and its limits, and prepare in advance if the documented process requires action before access is lost. This is part of assessing whether you can maintain access responsibly, not merely a question to postpone until something goes wrong.
Free, Paid, or Built into the System
There is no reliable rule that a subscription is automatically more secure than a free tool, or that an integrated manager is necessarily inadequate. Compare features and conditions you can verify: availability on your devices, synchronisation, authentication options, export, recovery, support, and documentation. Also check whether the free version imposes limits that affect your actual use, such as the number of devices or access to features you need. A price does not explain how a vault is protected, and an included feature does not by itself show that it lacks useful safeguards. Instead, compare the specific capabilities and limitations that matter to your circumstances. Note whether you can use the product across the systems you rely on and whether its documented recovery and export processes fit your expectations. These are concrete checks; assumptions about a whole category are not.
An integrated manager can be convenient when you already use a particular ecosystem and want to minimise additional installations. The trade-off may be greater dependence on that provider’s account and devices; confirm how you can access credentials from other systems and what export alternatives exist. An independent product may offer more options, but it also adds another account, another application, and another policy that you need to keep up to date. These are points to compare, not a universal verdict on either category. Think about how you would sign in if you changed devices, how you would move your data if your needs changed, and which account or platform would be involved in recovery. Convenience, portability, and the number of accounts you maintain can all matter, but the answer depends on your own use. Verify the actual product’s documented behaviour rather than assuming it from its label.
For teams and organisations, add criteria that are not usually priorities for individual use: permission management, central administration, activity review, user onboarding and offboarding processes, and the ability to export or recover data in line with internal policies. Commercial guides to business managers show that configuration can include administrative and deployment tasks; they should not be read as independent proof of a product’s quality or security. ManageEngine Password Manager Pro, quick start guide. An organisation should compare how responsibilities are assigned and whether the controls correspond to its own processes. A feature name does not, by itself, tell you who can exercise a permission or how a departure is handled. Check the documented setup and determine what the organisation would need to administer and maintain. These considerations are additional to the security questions that apply to an individual vault; they do not replace review of the product’s technical documentation or recovery model.
A Checklist Before You Choose
Before opening an account, look for answers to these questions in official documentation and, where appropriate, identifiable external reports:
- Does the provider explain what is encrypted and who can access the data?
- Which authentication methods are available, and how is the account recovered?
- Is there verifiable information about audits, their scope, and their date?
- Can you export the data you need in a usable form?
- What limits apply to free and paid versions and to your devices?
- Is there a clear procedure for signing out sessions or removing a lost device?
If an answer is essential to you and is missing from the documentation, ask the provider before importing your entire vault. Work through the questions for the actual plan and platform you intend to use. A general statement about a product may not answer whether a particular feature is available to you or what conditions apply. Keep the distinction between what is documented, what is independently reviewed, and what remains unclear. If you cannot establish an answer to a requirement you consider critical, that uncertainty should affect your decision rather than being filled with an assumption. The checklist is intended to expose practical gaps before you depend on the service, not to certify that a product is safe merely because every box appears to have an answer.
Run a small test before moving everything. Create a non-critical entry, verify that it synchronises across the devices you actually use, and confirm that you can export or recover it through the documented process. This check is not a security audit and does not prove that the product is free of flaws; it only helps identify practical compatibility or usability problems before you depend on the tool. Choose a test record that does not expose an important account, and follow the published instructions rather than improvising a migration. Check whether the result is available where you expect it and whether the process makes sense to you. A small trial can reveal a mismatch between your devices and the advertised workflow, but it cannot replace reading the technical documentation, reviewing recovery, or considering device security. Treat its value as limited and useful: it helps you test ordinary operation before a larger change.
During migration, temporarily keep access to the previous manager until you have verified that the necessary credentials are present and working. Change reused passwords, starting with your primary email and accounts that can reset other passwords. Avoid carrying out the entire migration on a device you suspect is compromised. The transition is also part of security: an inadequately protected export or an incomplete vault can create more exposure than the one you intended to reduce. Verify critical entries before closing the old route, and avoid assuming that a successful import means every record transferred as expected. Keep the exported file protected during the process and remove unnecessary copies when the migration is complete. These steps do not make a compromised device safe, which is why the device itself remains part of the decision. A careful sequence helps limit the period in which credentials are scattered across tools or depend on an unverified copy.
How to Interpret Promises and Make a Decision
Assess each statement according to the evidence behind it. An official page is appropriate for confirming which features the manufacturer says it offers, but it is not an independent verification of those features. A standard helps explain general recommendations, although it may have been superseded or may not apply directly to a consumer product. An external analysis can add context, but check its date, method, and whether it evaluated the version you are considering. The source should match the conclusion you draw from it: a product page supports a statement about what the manufacturer declares, while an identifiable report may support a narrower statement about what was reviewed. Avoid treating a source as stronger or broader than it is. A clear evidence trail helps you compare claims without converting them into guarantees.
Privacy does not necessarily mean that the provider processes no data. Even when vault contents are encrypted, account, activity, or billing data may be subject to different policies. Read the privacy policy and the terms on retention and deletion; check what information is required to register and what controls you have over it. ENISA’s information on digital identity and data protection provides a broad institutional framework, but it does not replace documentation for each manager. Source: ENISA. Distinguish the contents of the vault from the information needed to run an account or provide a service. Do not assume that one statement about encryption answers every question about information handling. Review what the provider says about the categories it collects and how long information is retained or deleted, to the extent that the documentation explains this. The point is not to infer a particular practice, but to check the relevant policy rather than treating privacy as a single all-or-nothing label.
You do not need to find a perfect option to make an informed decision. Prioritise the requirements you genuinely need, rule out products whose documentation does not let you assess important risks, and prepare a safe method for recovery and migration. The best choice is the one you can understand, configure, and maintain, not the one that accumulates the most security language in its advertising. If your needs change, revisit export, compatibility, and recovery options before becoming tied to a single account or platform. Keep the decision proportionate: compare the claims and processes that affect your use, and note uncertainties that remain. A manager is something you will have to keep using and maintaining, so clarity and practical fit matter alongside its stated protections. Rechecking the relevant details when circumstances change can help you avoid discovering too late that a device, recovery route, or export option no longer suits your needs.