How Password Managers Share Credentials Securely

Password managers are primarily understood as personal vaults, but most modern implementations also include a mechanism for sharing individual credentials or entire collections with other authenticated users. That sharing function is not a simple copy-and-paste operation routed through a server; it is a distinct cryptographic workflow that must move an encrypted secret from one user's key material to another's without ever producing a plaintext copy that the vault provider's infrastructure can read.

This piece covers that specific workflow — the cryptographic handshake between sender and recipient, the role of asymmetric key pairs, and the conditions under which the mechanism produces results that differ from what a user might expect. It is concerned with the machinery of secure sharing, not with the broader question of how a stored credential is encrypted at rest inside the vault.

How Credential Sharing Actually Moves an Encrypted Secret

Every account in a password manager that supports sharing is associated with at least two cryptographic layers. The first is the symmetric key used to encrypt the credential itself — typically AES-256 — which is derived from the account's master key material. The second is an asymmetric key pair: a public key and a private key. The public key is stored on the provider's servers; the private key is encrypted with the user's vault key and never leaves the user's devices in plaintext form.

When a sender initiates a share, the client application retrieves the recipient's public key from the provider's directory. The sender's local client then re-encrypts the symmetric key protecting the target credential using the recipient's public key. This operation is performed entirely on the sender's device. The resulting ciphertext — the symmetric key wrapped in the recipient's public key — is uploaded to the provider's server alongside the already-encrypted credential blob.

When the recipient next authenticates and syncs, their client downloads both the encrypted credential blob and the wrapped symmetric key. The client decrypts the wrapped symmetric key using the recipient's private key, which is itself only accessible after the vault has been unlocked with the recipient's master credentials. With the symmetric key recovered, the client can decrypt the credential blob and present the plaintext username and password locally. At no point in this sequence does the provider's server hold a plaintext version of either the credential or the symmetric key — it holds two nested ciphertexts.

This architecture is sometimes described as end-to-end encrypted sharing, a term that here has a precise meaning: the encryption boundary begins and ends at the two users' authenticated clients. The provider's role is limited to routing and storing opaque ciphertext. The underlying principle — encrypting a symmetric key with the recipient's public key — is a standard application of hybrid encryption, combining the efficiency of symmetric encryption for bulk data with the key-distribution advantages of asymmetric cryptography.

For collection-level sharing, where a folder of credentials is shared with a team or household, the same mechanism scales through a shared collection key. Each authorized member's copy of that collection key is individually wrapped with that member's public key. Adding a new member means generating a new wrapped copy of the collection key for them; removing a member means revoking their wrapped copy and, in a properly implemented system, rotating the collection key so that the removed member's previously held copy is no longer valid for future credential additions.

Cryptographic Components Involved in a Sharing Transaction

Asymmetric key pair (RSA or elliptic-curve). Each user account holds a public/private key pair. The public key is published to the provider's server and can be retrieved by any authenticated user in the same sharing ecosystem. The private key is encrypted with the user's vault key and is only decrypted locally, after successful vault unlock. Some implementations use elliptic-curve Diffie-Hellman (ECDH) key agreement rather than RSA encryption directly, but the structural role is the same: a public component for wrapping, a private component for unwrapping.

Symmetric credential key (AES-256). Each credential or collection is protected by its own symmetric key. This key is what actually encrypts and decrypts the credential data. It is short enough to be wrapped efficiently by asymmetric operations, which is why hybrid encryption is the standard pattern rather than encrypting the entire credential blob asymmetrically.

Key derivation and vault unlock layer. Before any sharing operation can proceed, the sender's vault must be unlocked — meaning the master key has been derived and the private key has been decrypted. How a master password derives an encryption key is a separate process involving a key derivation function such as PBKDF2, bcrypt, or Argon2, which produces the vault key that protects the private key at rest.

Provider's key directory. The server maintains a directory mapping user identities to their public keys. This directory is a critical trust point: if an attacker could substitute a malicious public key in the directory, the sender would wrap the credential key for the attacker rather than the intended recipient. Well-implemented systems use key verification mechanisms — such as key fingerprints that users can compare out-of-band — to reduce this risk, though not all consumer implementations expose this to users by default.

Transport layer (TLS). All communication between the client and the provider's server travels over TLS. This protects against network-level interception of the ciphertext blobs in transit, though TLS alone provides no protection against a compromised server, which is why the end-to-end encryption layer exists independently of transport security.

Where Credential Sharing Breaks Down or Produces Unexpected Results

Key directory substitution. The security of the entire sharing model depends on the authenticity of the recipient's public key as retrieved from the provider's directory. If the directory is compromised — through a server-side breach, a misconfiguration, or a malicious insider — a sender could wrap the credential key for an attacker's public key without any visible indication that something is wrong. The encrypted credential would then be decryptable by the attacker rather than the intended recipient. This is a structural limitation of any system that relies on a centralized key directory without independent key verification.

Key rotation on member removal. When a member is removed from a shared collection, implementations vary in whether they rotate the collection key. If the collection key is not rotated, the removed member retains a working decryption key for all credentials that existed in the collection at the time of their removal. They cannot decrypt credentials added after their access was revoked (since those would be encrypted under the new key), but historical credentials remain accessible to them. This outcome surprises administrators who assume that revoking access retroactively invalidates all decryption capability.

Device sync lag. The sharing transaction completes server-side when the sender uploads the wrapped key. The recipient's client does not receive the credential until it next syncs. On a device that has been offline or has sync disabled, the shared credential may not appear for an extended period. The mechanism by which a vault syncs across devices is independent of the sharing cryptography and introduces its own timing and conflict-resolution considerations.

Emergency access and escrow patterns. Some password managers implement an emergency access feature that allows a designated contact to request access to a vault after a waiting period. This feature typically uses the same asymmetric wrapping mechanism, but it introduces a time-delay override that can be exploited if the account owner does not notice and reject an unauthorized emergency access request during the waiting window. The cryptographic mechanism is sound; the failure mode is social and procedural rather than mathematical.

Autofill context does not carry sharing metadata. Once a shared credential is present in a recipient's vault, the autofill subsystem treats it identically to any credential the recipient generated themselves. The way autofill matches credentials to a site depends on stored origin data, not on provenance. If a shared credential's stored URL does not match the site the recipient is visiting, autofill will not surface it, regardless of how recently it was shared.

What Security Audits and Standards Show About Sharing Implementations

Third-party security audits of password manager sharing features typically assess two distinct layers: the cryptographic design and the implementation. A design audit examines the key-wrapping protocol on paper — whether hybrid encryption is used correctly, whether the key derivation chain is sound, and whether the key directory has integrity protections. An implementation audit examines the actual code for vulnerabilities such as timing side-channels, incorrect random number generation, or failure to clear plaintext key material from memory after use.

Audits can confirm that a published cryptographic design is mathematically sound, but they cannot confirm that the server-side key directory has not been tampered with at a given moment in time, nor can they confirm that a future software update will not introduce a regression. An audit is a point-in-time assessment of the version reviewed; it does not constitute a continuous assurance over the product's lifetime.

The FTC has noted in its guidance on data security that companies collecting and storing sensitive consumer data — a category that includes credential vault providers — are expected to implement reasonable security measures appropriate to the sensitivity of the data. This framing is relevant to sharing features because the key directory and the server-side ciphertext storage represent a concentration of sensitive data that, if breached, could expose the metadata of sharing relationships even when the credential content itself remains encrypted.

CISA's guidance on credential management emphasizes the importance of unique, complex credentials and of limiting credential reuse — goals that sharing features can technically support or undermine depending on implementation. A sharing feature that delivers the same credential to multiple users without rotation means that a compromise of any one recipient's vault exposes the credential for all recipients. Audits rarely assess this organizational risk dimension, focusing instead on the narrower cryptographic correctness of the sharing transaction itself.

No published audit standard specifically addresses the key rotation behavior on member removal described in the friction section above. This gap means that a product can pass a cryptographic audit while exhibiting the key-retention behavior that surprises administrators, because the behavior is technically correct within the design — it is the design choice itself that carries the risk.

The cryptographic architecture of credential sharing in a password manager is well-established and grounded in decades of hybrid encryption practice; the structural risks in deployed systems tend to arise not from mathematical weakness but from the gap between what the protocol specifies and what a user or administrator assumes about access revocation, key directory integrity, and the timing of sync operations.

Note: This explains how digital privacy and security tools work technically. It is not legal or cybersecurity advice, and it is not a substitute for a reader's own judgment about a real security concern. Check the cited sources for current guidance.