What are the real privacy trade-offs between LastPass and 1Password for team password sharing?

What each product actually does with your team's secrets

Both LastPass and 1Password market themselves as zero-knowledge: the plaintext of a password never reaches the vendor's servers, and encryption and decryption happen in the client — browser extension, desktop app, or mobile app. That shared claim hides the part that matters for a RevOps team sharing credentials to Salesforce, HubSpot, Outreach, and a dozen vendor dashboards: *what material is required to unlock the vault, and who else can assemble that material.*

LastPass derives your vault key from your master password using PBKDF2 with a large iteration count, then stores the resulting encrypted vault blob server-side so it syncs across devices. The company does not store your master password, but for business tiers it supports admin-initiated master password reset, implemented through a super-admin key escrow mechanism configured at the account level. When that feature is on, an authorized admin can put a user back into their vault without the user remembering anything. That is genuinely useful — a rep locked out on a Monday morning is back into the shared sales-tools vault in minutes — and it is also, precisely, a second path to the plaintext that exists outside the user's head. Whether you consider that a privacy defect depends on whether you trust your own admin accounts and LastPass's controls around that escrow.

1Password's model adds a second factor to the key derivation itself. When you create an account, the client generates a 128-bit Secret Key locally. Your account encryption key is derived from the combination of your master password *and* that Secret Key; the Secret Key is never transmitted to 1Password's servers during authentication, and the server only ever holds a blob it cannot open. The design consequence is blunt: 1Password has no escrow, no admin override that recovers the raw account key, and no configuration toggle that creates one. The offsetting mechanism is Account Recovery, where an administrator can send a recovery invitation that re-establishes a user's access — a workflow whose security rests on the team's own recovery keys and the admin's account, not on a vendor-held copy of your key.

The privacy comparison, stated honestly, is not "one is encrypted and the other isn't." It is: LastPass gives your organization a lever that can reopen a locked vault, and any lever that exists can be pulled by whoever controls it. 1Password removes that lever from the vendor and hands a narrower version of it to your own admins. If your threat model includes a compromised vendor or a compromised super-admin, that difference is the whole ballgame. If your threat model is mostly "reps forget passwords and deals stall," the lever is a feature.

There is also a track-record difference you cannot argue away. LastPass disclosed a serious incident in 2022 in which an attacker obtained a backup of customer vault data. Critically, the URLs and other metadata fields in those vaults were *not* encrypted — only the password, username, and secure-note fields were. For a sales organization, unencrypted URL metadata is not harmless: it enumerates every SaaS tool, partner portal, and internal admin console the team touches, which is a competitive-intelligence and targeting map even without a single cracked password. Vaults protected by a strong, high-iteration master password remain computationally out of reach; vaults protected by a short reused password, or by an account still sitting on a legacy low iteration count, do not. 1Password has not disclosed a comparable vault-data exposure; it did report being affected by the 2023 Okta support-system compromise, which touched its own corporate identity tooling rather than customer vault contents.

Sharing models, permissions, and what a shared item leaks

Team password sharing is where the two products diverge in daily practice, and the differences are more about blast radius than cryptography.

LastPass business plans center on shared folders. You create a folder, drop credentials in, and assign users or groups with read, write, and hide-password permissions. The hide-password option is worth understanding precisely: it lets a user autofill a credential without revealing the plaintext in the UI. That is a real control for a shared marketing-automation login you don't want screenshotted into Slack — but it is a UI-level restriction, not a cryptographic one. The client necessarily has the decrypted value to perform the fill, so a motivated user with developer tools can retrieve it. Treat it as friction against casual copying, never as a boundary against a determined insider.

1Password organizes sharing around vaults, with permissions granted per vault to groups or individuals across a granular set: view items, view and copy passwords, view item history, create, edit, archive, delete, manage. There is no per-item permission inside a vault — the vault *is* the permission boundary — which pushes teams toward more, smaller vaults. A typical RevOps layout looks like: one vault for CRM admin credentials restricted to two ops leads, one for sequencing and dialer tools shared with the whole SDR org, one for billing and vendor-portal logins shared with finance and ops, and per-project vaults for anything temporary. 1Password also offers item sharing via expiring links, which generate a URL that can be limited to specific email addresses, capped by view count, and set to expire — useful for handing a single credential to an agency or a candidate without provisioning them a seat.

The leak surface most teams miss is identical in both products: shared items keep working after the person leaves. Revoking a user's vault or folder access removes future retrieval, but it does nothing about the password they copied into a personal notes app three months ago. Neither vendor can rotate an upstream credential for you. This is why the honest privacy comparison between the two is smaller than the comparison between "we rotate shared credentials on offboarding" and "we don't." A team on either product that never rotates has a worse effective posture than a team on the other product that rotates within 24 hours of a departure.

Both products also support SCIM-based provisioning and SAML SSO on business tiers, which changes the picture again. With SCIM, deprovisioning in your IdP suspends the vault account automatically, closing the window between HR termination and manual revocation — a window that in most sales orgs is measured in days, not minutes. Note the architectural wrinkle: because 1Password's account key is derived client-side, SSO unlock works differently from a conventional SAML integration; the identity provider authorizes the device, and the credentials needed to decrypt are handled through 1Password's own key exchange rather than the IdP holding anything that unlocks your data. That preserves the no-vendor-decryption property under SSO, which is the specific thing an auditor will probe.

Choosing between them for a specific team

The decision is rarely "which product is better." It is "which failure mode can this organization actually absorb." The tree below is the version I would walk a RevOps lead through in a 20-minute call.

Read the tree as a set of gates rather than a scoring model. The first gate is binary and non-negotiable: if a compliance obligation or an internal policy says no party outside the user may hold a path to plaintext, LastPass's admin reset must be disabled — and once it is disabled, you have given up the main operational advantage you were buying it for, which usually means you should have bought 1Password. The second gate matters because both products' privacy properties degrade to the same weak point without SSO and SCIM: a stale account nobody remembered to remove.

The third gate, lockout tolerance, is where real organizations split. A 200-rep sales floor with 40% annual attrition and a help desk that already handles password resets has a genuine, quantifiable case for the LastPass model. A 25-person ops team selling into regulated buyers, where a single audit question can stall a six-figure deal, has an equally genuine case for being able to answer "can your vendor decrypt your vault?" with a flat no rather than a configuration explanation.

The numbers that actually move the decision

Pricing on both sides is published per user per month, billed annually, and changes often enough that you should confirm on the vendor's own pricing page before you model it — but the *shape* of the cost is stable and worth understanding, because the license fee is rarely the expensive part.

The cost that dominates is time. Onboarding a user to LastPass is an email invite, set a master password, done — call it five minutes of the new hire's time. Onboarding to 1Password adds the Emergency Kit step: the user must save the PDF containing their Secret Key somewhere durable and separate from the vault itself, and if you do this properly you verify they did it. Realistically that is ten to fifteen minutes. Take the pessimistic end: a ten-minute delta per hire. At 100 hires a year, that is roughly 17 hours of aggregate onboarding time annually — about two working days spread across the whole company. Framed that way, the friction argument gets much weaker than it sounds in a vendor bake-off, because two days a year is not a hiring bottleneck. Where it genuinely bites is a mass migration: moving 300 existing users to 1Password means 300 Emergency Kits generated, distributed, and stored in the same few weeks, and that is a project with a plan, not a Tuesday.

The other number worth putting on the table is iteration count, because it determines whether a stolen LastPass vault is a nuisance or a catastrophe. LastPass raised its default PBKDF2 iteration count over time, and accounts created years ago could remain on far lower legacy settings until re-derived. If you are on LastPass today, checking and raising the iteration count on every account is the single highest-leverage thing you can do, and it costs nothing. Combine that with a genuinely strong master password — a long passphrase, not a nine-character pattern — and the offline-cracking math moves from "feasible with a GPU rig" to "not worth anyone's electricity." A vault key derived from a weak password at a low iteration count is the actual vulnerability the 2022 disclosure exposed; the architecture was the amplifier, not the root cause.

On the 1Password side, the number that matters is the Secret Key's 128 bits of entropy, combined with the master password. Because the Secret Key is randomly generated and never typed during normal use, it is not phishable in the way a master password is and not obtainable by a keylogger watching you type. The practical consequence is that an attacker who steals 1Password's encrypted blob and guesses your master password still has nothing, because they lack a value that never traversed the network. That is the concrete, non-marketing version of the architectural claim.

Finally, model the rotation cost, because it applies regardless of vendor. If a departing rep had access to 15 shared credentials, and rotating each one takes 10 minutes including updating the shared item and notifying the team, that is 2.5 hours per departure. At 40% attrition on an 80-person GTM org — 32 departures a year — you are looking at roughly 80 hours annually of rotation work. That number, not the license fee, is what should drive you toward smaller vaults with tighter membership: fewer people per shared secret means fewer secrets to rotate per exit.

Rolling it out without creating the gaps you were trying to close

The migration sequence below is the one that avoids the two classic failures: a long period where credentials exist in both systems, and a set of users who have vault access but no working recovery path.

Step one is the one teams skip and then regret. Before you touch either product, export what you have and read it. You will find credentials for tools nobody uses, service accounts tied to a person who left, and at least one shared admin login where an individual account would do. Migration is the cheapest moment you will ever get to delete those, and every one you delete is a privacy problem that no longer needs a technical control.

Classification should produce three tiers, not twenty. Tier one: credentials that grant access to customer data or money movement — CRM admin, billing portals, payment processors. These get their own vault, membership of two or three named people, and mandatory rotation on any membership change. Tier two: operational tools where exposure is embarrassing but not regulatory — sequencing platforms, enrichment vendors, scheduling tools. These can be shared at the team level. Tier three: low-sensitivity logins for content sites and free tools, which can sit in a broad shared vault and stop consuming your attention.

The export files created during migration are the sharpest short-term risk in this whole exercise. A CSV of your entire credential inventory in plaintext, sitting in a Downloads folder, defeats every architectural advantage either vendor offers. Handle it accordingly: generate exports on a single machine, use them immediately, delete them with the file removed from the trash the same session, and do not email or Slack them under any circumstance. If the migration will span days, do it in per-vault slices rather than one master export.

Testing recovery before you scale is non-negotiable, and it is a different test in each product. On LastPass, if you intend to rely on admin reset, verify that a designated recovery admin can actually restore a locked-out test user, and confirm that the reset generates an alert that a human reads — an escrow capability nobody monitors is the worst of both worlds. If you have decided to disable admin reset for compliance reasons, verify that too, and document it, because "we turned it off" is a claim an auditor will ask you to evidence. On 1Password, confirm that account recovery is enabled for the group, that at least two administrators can initiate it, and that a test user with a deliberately forgotten master password can be brought back. Write the runbook while it is fresh; the day you need it, the person who set it up will be on a plane.

The final rotation step is the one that converts a migration into an actual security improvement. Every credential that lived in the old system should be assumed to have been copied somewhere by someone. Rotate tier one immediately, tier two over the following month, and accept that tier three may never get rotated — that is a reasonable, explicit risk decision rather than an oversight, as long as you have written it down.

Ongoing, run a quarterly access review: list every vault or folder, list its members, and have the owner confirm each one still needs access. Pair it with a stale-item purge for credentials nobody has retrieved in six months. Both products give you enough activity reporting on business tiers to drive this — LastPass through its admin console reporting, 1Password through its activity log and Insights reporting — and the review is worth more to your actual privacy posture than the architectural difference you spent three weeks debating.

Related questions

Does disabling LastPass admin master password reset make it equivalent to 1Password?

Closer, not equivalent. Disabling the reset removes the escrow lever, but 1Password's Secret Key still means the server-side blob is unopenable even with a guessed master password. You also lose the recovery convenience that justified choosing LastPass.

Can either vendor read our shared folder or vault names?

Metadata handling differs, and this is a real question to ask in a vendor review. The 2022 LastPass disclosure confirmed that URL fields in vault records were not encrypted. Ask each vendor, in writing, exactly which fields are encrypted and which are not.

What happens to shared credentials when someone is terminated?

Revoking vault access stops future retrieval but does not invalidate anything already copied. Deprovision through SCIM to suspend the account immediately, then rotate every credential the person could reach — starting with anything touching customer data or payments.

Is a browser's built-in password manager enough for a small team?

Not for shared credentials. Browser managers are built for individual use, offer no vault-level permission model, no audit trail, and no revocation. Once two people need the same login, you need a product with sharing and access-removal semantics.

FAQ

Can LastPass or 1Password see our team's passwords?

Neither vendor stores plaintext passwords; both encrypt and decrypt in the client. The meaningful difference is that LastPass business plans can be configured with admin-initiated master password reset, which creates an escrow path back into a user's vault. 1Password's Secret Key is generated on the device and never sent to the server, so no equivalent vendor-side path exists.

Which one holds up better in a SOC 2 or vendor security review?

1Password tends to answer the "can the vendor decrypt customer data" question more cleanly, because the answer is architectural rather than configuration-dependent. LastPass can satisfy the same requirement by disabling admin reset, but you then have to evidence that the setting is off and stays off, which is more work to demonstrate.

How should service accounts and automation get credentials?

Not from a shared human vault. Both vendors offer purpose-built paths for programmatic access — 1Password through Connect and its service account model, LastPass through its admin API and CLI tooling. The principle is the same either way: automation should hold a scoped, rotatable token, never a copy of a human's master credential in an environment variable.

Does the LastPass breach mean we must migrate immediately?

Not automatically. Assess your own exposure: check every account's PBKDF2 iteration count, confirm master passwords are long passphrases, and rotate anything sensitive that was in the vault before the incident window. If those checks come back clean and admin reset is appropriately restricted, staying is defensible. If they don't, migrate — but rotate first, because migrating a compromised credential just moves it.

Is 1Password's Secret Key a burden for non-technical sales reps?

It's one extra step at signup: save the Emergency Kit somewhere durable and separate from the vault. Reps generally never touch it again, because it's stored on the device after first use. The failure mode is teams that let people skip saving it — enforce the step during onboarding and it's a non-issue.

Should we pick based on price?

Rarely. Per-seat pricing between the two is close enough that a 100-seat difference in annual cost is smaller than the cost of one credential-rotation fire drill. Decide on your recovery tolerance and your audit obligations, then check current published pricing to confirm the loser isn't dramatically cheaper for reasons you should understand.

Sources

• LastPass: Notice of Recent Security Incident (2022)
• 1Password Security Design White Paper
• 1Password Support: About your Secret Key
• 1Password Support: Recover accounts for team members
• LastPass Support: Business admin documentation
• NIST Special Publication 800-63B: Digital Identity Guidelines
• OWASP Password Storage Cheat Sheet
• CISA: Use Strong Passwords
• IBM Cost of a Data Breach Report

Related on PULSE

• [What are the privacy concerns with using AI chatbots like ChatGPT in the workplace?](/knowledge/q14503)
• [Which 2027 data privacy update is blocking your RevOps team from tracking buying committee members?](/knowledge/q16377)
• [What data privacy concerns in 2027 are causing buying committees to slow down due diligence?](/knowledge/q16497)
• [How does vendor consolidation in 2027 affect your data privacy compliance for outbound?](/knowledge/q16449)
• [What are the bonus-vs-base trade-offs in sales comp in 2027?](/knowledge/q12678)