A password manager is more than a digital notebook. It combines encryption, key derivation, authentication, browser integration and recovery mechanisms to make unique credentials practical across devices. Understanding these components helps you evaluate products without relying on vague promises that a vault is “unhackable.”

What a password manager actually does

A password manager is a system for storing account credentials in an encrypted vault and retrieving them when they are needed. The convenient part is familiar: it can generate unique passwords, recognize login forms, and fill credentials into a browser or app. The important part is less visible. The system must transform a secret that a person can remember into cryptographic keys, protect the resulting data, and synchronize changes without unnecessarily exposing the contents of the vault. Those jobs are related but not interchangeable. A polished autofill interface says little by itself about the quality of the encryption implementation. Likewise, a strong encryption algorithm cannot protect a device that is already controlled by an attacker.

The central design goal is to make password reuse unnecessary. Without a manager, people often choose between memorizing many passwords and reusing a few. Reuse means that a breach at one service can create opportunities for attackers at unrelated services. A manager can create a long, random credential for each account and remember it on the user’s behalf. This does not make every account invulnerable. Phishing, malware, weak recovery procedures, and compromised email accounts remain serious risks. It does, however, change the economics of everyday password hygiene: unique credentials become practical rather than burdensome.

A vault may hold more than passwords. Many products store notes, recovery codes, payment details, passkeys, or identity information. Each additional category increases convenience but also raises the stakes of protecting the vault. A sensible setup therefore begins with a threat model: which information must be stored, which devices need access, who may recover an account, and what happens if the provider or the user’s own devices become unavailable.

From master password to encryption key

Most password managers begin with a master password, sometimes called an account password or vault password. That phrase is entered by the user but should not be used directly as an encryption key. Human-selected phrases vary widely in unpredictability, while cryptographic algorithms expect keys of a particular size and structure. A key derivation function bridges the gap. It processes the password, usually together with a unique salt and deliberately expensive computation, to derive material suitable for protecting encryption keys or verifying the password.

Common approaches include Argon2id and PBKDF2, although exact implementations differ by provider and version. A salt prevents identical passwords from automatically producing identical stored verification values across users. A costly derivation step makes large-scale guessing more expensive. Neither property turns a short, predictable password into a strong secret. If an attacker obtains encrypted vault data and can attempt offline guesses, the strength of the master password and the derivation parameters both matter. The correct question is not simply whether a provider advertises a famous algorithm, but how that algorithm is configured and how the entire authentication and key-management process works.

Some services combine the master password with an additional secret generated on the device. This can strengthen resistance to attacks against stolen server-side data, but it also changes recovery requirements. Losing that additional secret may complicate signing in on a new device. Other products rely on device-bound keys, hardware-backed protection, or account recovery mechanisms. These are architectural choices with trade-offs, not universal guarantees. Users should understand which secrets are required for a fresh installation before assuming that knowing the master password will always be enough.

Inside an encrypted vault

Once key material is available, the manager encrypts the vault contents before storing them locally or uploading them for synchronization. Modern designs generally use authenticated encryption, which aims to protect confidentiality and detect unauthorized changes. AES-GCM and constructions based on ChaCha20-Poly1305 are examples of established authenticated-encryption approaches. A product’s security relies on its verified configuration, correct nonce handling, and ongoing key management, which require validation beyond marketing specifications.

The term zero knowledge is often used to describe services that do not possess the secrets needed to decrypt a customer’s vault. It is a useful architectural objective, but it needs careful interpretation. A provider may still know an account email address, subscription status, device metadata, or timing information. Depending on the design, some vault metadata may be visible even when password values are encrypted. Furthermore, a provider that controls application updates could potentially deliver malicious code to an endpoint. Independent audits, reproducible design explanations, and a credible incident-response history therefore matter alongside zero-knowledge marketing claims.

Encryption at rest also has limits. When a vault is unlocked, the application must access usable secrets in memory to show or fill them. Malware running with sufficient privileges on the device may capture those secrets, intercept a master password, or manipulate the browser. Full-disk encryption, operating-system updates, device locks, and cautious extension permissions remain part of the security model. A password manager is a component of device security, not a replacement for it.

How synchronization works across devices

Cloud-synchronized managers usually encrypt vault data on the client and send encrypted records to a server. The server stores updates and distributes them to authorized devices. This model can offer rapid access across phones, laptops, and tablets, but it introduces questions about device enrollment, conflict resolution, authentication, and recovery. A stolen provider database should ideally expose encrypted vault records rather than plaintext passwords; the extent of protection depends on the implementation and on the secrets attackers can also obtain.

Local-first managers can instead store a vault file on a chosen device or allow the user to synchronize that file through a storage service. This provides greater control over where copies reside, but it transfers more responsibility to the user. A file copied incorrectly, overwritten during simultaneous edits, or omitted from backups can create real availability problems. The distinction between cloud and local storage is therefore not simply secure versus insecure. Both approaches can be designed responsibly, and both can fail through poor configuration or neglected maintenance.

A useful evaluation exercise is to disconnect a device from the internet and test which operations still work. Can existing entries be read? Can a new password be saved? Will conflicting edits be reconciled later? What happens if the account is locked or the provider experiences an outage? Also check how new devices are approved. Some managers require an existing trusted device, a recovery code, or an additional secret. These controls can protect against account takeover while making emergency access harder if they have not been documented in advance.

Autofill: convenience with boundaries

Autofill works by matching a stored login entry to the website or application requesting credentials. Browser extensions may inspect page addresses and form fields; mobile integrations rely on operating-system facilities that identify the requesting app or website. Accurate matching helps prevent accidental disclosure to an unrelated site. Yet the quality of matching rules varies, and some login flows use multiple domains or unusual embedded forms that complicate recognition.

A good manager should make the destination visible before filling a credential. Similar-looking domains, misleading subdomains, and internationalized domain names can fool people who rely on a logo or page design alone. Autofill can reduce some phishing mistakes when it refuses to match a fake domain, but it is not a complete anti-phishing defense. A user can still copy and paste a password into a fraudulent page, approve a malicious authentication prompt, or be deceived by a fake support conversation. Treat unexpected requests to reveal or export vault contents as warning signs even when the page looks professional.

Extensions also create a privileged connection between the browser and sensitive information. Install them only from the provider’s verified distribution channels, keep them updated, and review the permissions they request. On shared computers, avoid leaving an unlocked vault available to other users. Automatic locking after inactivity is helpful, although an overly aggressive timeout can encourage unsafe workarounds. The right configuration balances a realistic household or workplace routine against the consequences of unattended access.

Password managers and passkeys are not the same thing

A password manager stores secrets that are typically typed or filled into a service. Passkeys use public-key cryptography: a private key remains with the user’s authenticator while the service stores a corresponding public key. During sign-in, the authenticator signs a challenge for the intended service. Properly implemented passkey authentication is resistant to the familiar trick of collecting a reusable password on a lookalike website, because the credential is bound to the relying party rather than a string that can be entered anywhere.

Password managers increasingly act as passkey providers, storing or synchronizing passkey credentials alongside passwords. That can simplify moving between devices, but the underlying passkey and the password-manager account have distinct security properties. Some passkeys are bound to a particular device or hardware security key; others can be synchronized through an ecosystem or credential manager. Recovery and export support differ, and interoperability is still an important purchasing consideration. Users should test how a passkey created on one device will be used after replacing that device.

A passkey does not automatically eliminate every account-recovery weakness. A service may continue to offer password fallback, email recovery, or support-assisted resets. Attackers often target the easiest available path. For this reason, account security must be assessed as a whole: primary sign-in, fallback methods, email account protection, and recovery contacts. For a comprehensive analysis of public-key authentication, see the dedicated brixn.net guide on passkeys; this section focuses specifically on how password-manager architecture handles their storage and synchronization.

Recovery is part of security design

The strongest encryption is of little practical use if a legitimate owner permanently loses access to essential accounts. Recovery therefore deserves attention before a vault is populated. Depending on the product, options may include recovery codes, a trusted device, an emergency contact, a family administrator, or a provider-managed recovery flow. These methods differ greatly in what they can restore. Resetting access to a subscription account is not necessarily the same as recovering the cryptographic keys needed to decrypt an existing vault.

Write down the recovery process in plain language and store the required material separately from the device used every day. A paper copy kept in a secure location may be appropriate for a household; a business may need documented administrative procedures and separation of duties. Avoid putting every recovery code inside the very vault it is meant to recover. Test the procedure with a noncritical account or a spare device, and confirm whether recovery requires a previously approved device that might not be available after theft or fire.

Emergency access also raises questions of trust. Giving a relative a vault password may expose more information than intended. Some services support delegated access with a waiting period or restricted sharing. Consider whether a household needs access to utility accounts, insurance details, or other practical records without sharing personal messages or financial credentials. Security improves when the recovery plan is specific enough to work during a real emergency, rather than relying on the vague assumption that customer support will unlock everything.

Sharing, families and organizations

Password sharing is common when several people manage a streaming account, a household service, or a small business. Sending credentials through ordinary chat messages is convenient but difficult to revoke or audit. A manager with shared collections can provide a more controlled approach, particularly when each person has a separate account and access can be removed centrally. However, sharing a stored password does not always prevent a recipient from copying it. For important services, individual user accounts with role-based permissions are preferable whenever the service supports them.

Families should distinguish shared household credentials from private credentials. Children may need help managing accounts without receiving access to adults‘ banking or email. Emergency arrangements should identify who can access which records and under what circumstances. Businesses face additional requirements: onboarding, offboarding, administrative recovery, audit records, and policies for accounts that cannot yet support single sign-on. A personal password manager can be excellent for one person but unsuitable for a team that needs access controls and reliable staff transitions.

Before paying for a family or business plan, test the real workflow. Can a shared entry be updated without generating duplicate copies? Is access removed promptly when a member leaves? Are there clear roles for owners and administrators? Does the product allow secure sharing with someone who does not use the same manager? Features listed in marketing materials matter less than whether they prevent the everyday practice of keeping one shared master password on a note beside the computer.

Evaluating security claims and audits

A credible product should explain its security architecture clearly enough for an informed reader to distinguish encryption, authentication, and recovery. Public documentation should identify the broad cryptographic design, supported authentication factors, update policy, and response to reported vulnerabilities. Independent security assessments can add confidence, but an audit is a snapshot of a particular scope and time. It does not certify that every future version or connected service is free of vulnerabilities.

Open-source code allows outside inspection and may improve transparency, but source availability alone does not guarantee a secure build, timely fixes, or safe defaults. Closed-source products can also implement strong controls and commission serious independent testing. Evaluate evidence rather than treating either licensing model as a substitute for engineering quality. Look for clear security advisories, responsible disclosure channels, and a record of communicating incidents without minimizing their consequences.

Cost matters, but the most expensive plan is not necessarily the safest. Free tiers may cover individual use well, while paid plans often add family sharing, advanced recovery, storage, or administrative features. Compare total costs over several years, including the difficulty of leaving the service. A manager that exports credentials in a documented format can reduce dependence on a single provider. Export features are useful precisely because they can create dangerous plaintext files, so the procedure for handling those files must be understood before migration day.

Moving from one manager to another

Migration is a common moment for accidental exposure. Many managers offer export files in CSV or another portable format. CSV exports are often unencrypted and may contain every password in readable text. Create them only on a trusted, updated device, avoid shared folders and automatic cloud backup locations, and delete the file securely according to the operating system’s capabilities once the import has been verified. Do not email the export to yourself or leave it in the downloads folder indefinitely.

Start by checking whether the destination supports the source format, including notes, custom fields, attachments, and passkeys. Password imports are not always complete, and passkey portability can differ substantially from password portability. After import, inspect a representative selection of accounts, especially email, banking, recovery accounts, and services with multiple usernames. Verify that the destination can generate and save new credentials before removing the old manager. Keep the old vault available for a limited transition period if that can be done safely, then revoke unused sessions and remove obsolete extensions.

A gradual rollout is often better than an abrupt switch. First secure the primary email account, because it is commonly used to reset other accounts. Next address financial services and accounts that store payment details, then social, shopping, and less critical accounts. Replace reused passwords with unique generated ones as each account is reviewed. This order gives the largest immediate reduction in account-takeover risk while limiting the chance of locking yourself out of everything at once.

A practical setup checklist

Begin by choosing a manager whose recovery model and supported devices match your actual needs. Create a long, unique master passphrase; randomly selected words generated through a suitable method can be easier to remember than a short string of substitutions. Enable a strong second factor for the manager account where supported, preferably a phishing-resistant method. Store recovery material separately and verify it before relying on the vault for critical accounts.

Install official apps and browser extensions, then set a sensible automatic lock. Check how the product identifies websites before allowing autofill. Import existing credentials cautiously, identify duplicates, and prioritize replacing reused passwords. For every important account, record whether a passkey or hardware security key is available and whether weaker recovery methods remain enabled. A manager cannot compensate for an email account that an attacker can reset with an easily guessed security question.

Finally, schedule a periodic maintenance review. Confirm that devices still receive security updates, remove access for devices no longer owned, review shared entries, and test recovery instructions. If a provider announces an incident, read the actual scope of the event rather than assuming either that all vaults were exposed or that encryption made the incident irrelevant. A well-chosen password manager reduces repetitive work, but its greatest value comes from a disciplined combination of unique credentials, protected devices, and a recovery plan that has been tested.