Vaultwarden → 1Password Business
Vaultwarden ↔ 1Password Business: integration to migration path.
Vaultwarden deploys alongside your live 1Password Business tenant and takes over one cohort at a time — there is no flag day and no org-wide cutover. Every user moves at the pace of a single ~30-minute self-service event, and in-vault TOTP seeds carry across automatically, so no one re-credentials their downstream sites.
The one honest exception is a single vault-unlock factor re-enrolment per user, staggered on their first Vaultwarden login — never a mass reset. We say so up front, because the rest of this only matters if you can trust it.
The idea
Run both vaults side by side. Retire 1Password last.
The topology that makes this zero-disruption: Vaultwarden runs as a parallel production vault for one cohort at a time, with Organizations and Collections that mirror that cohort's existing 1Password vault layout, while the 1Password tenant stays the system of record for everyone else. Both browser extensions live during the parallel-run window — Vaultwarden pinned, autofill-on-load disabled on both sides to stop wrong-vault fills. Cohort by cohort, each group soaks for at least 30 days before its 1Password vaults are set read-only, and only when every cohort has cleared do we retire the contract.
The phases
Seven steps. Each one reversible.
Baseline & inventory
We read-only enumerate every 1Password vault, item, attachment, Group ACL, SSO Unlock state, 1P Connect consumer and Family linked account. Dormant users are flagged for the long-tail cohort. Nothing changes.
Stand up Vaultwarden HA
Vaultwarden goes live in your cloud (HA Postgres, multi-AZ, encrypted backups, SIEM pulling the Events API) with Org Policies set and a tested break-glass account. A single canary organisation proves export/import. No production user authenticates yet.
Pilot cohort (IT + SecOps)
Up to 25 white-glove pilot users run the 1pux importer, migrate attachments, and enrol a Vaultwarden vault-unlock factor. Their 1Password seat stays live for a 14-day soak. Both extensions installed, Vaultwarden pinned.
Engineering waves
Engineering migrates in opt-in waves of 50–200, communicated 14 days ahead. Team vaults export via script; personal vaults are the user's responsibility. After a 14-day parallel run, migrated 1Password vaults go read-only, not deleted.
Knowledge-worker waves
Marketing, sales, ops and finance migrate on the same wave runbook with group training and extra hand-holding on extension UX. 1Password retains only executives, assistants, dormant and Family holdouts.
Executive + long-tail
Executives and assistants migrate 1:1 white-glove. Dormant accounts run through a forced-reset cohort with a cold snapshot held 30 days. Family linked accounts are resolved as a parallel workstream — discontinue, convert or accept the cost.
Retire 1Password Business
Once 1P holds zero active vaults, the account goes read-only for a 30-day evidence window. Watchtower-replacement cron and any 1P Connect cutover are already proven. Then the account is deleted and the contract is not renewed.
Feature parity
Where Vaultwarden matches, and where it doesn't.
| Capability | Vaultwarden | 1Password Business | Parity |
|---|---|---|---|
| Vault storage model | Vaultwarden Organizations / Collections | 1P Accounts / Vaults | At parity |
| Login / item storage | Login, Card, Identity, Secure Note items | 1P Login / Card / Identity / Secure Note | At parity |
| TOTP in vault | otpauth:// URI, portable both directions | 1P native one-time-password field | At parity |
| Attachments | Org attachments via a premium-flag env var | 1P document / attachment items | Partial |
| Time-bound sharing | Vaultwarden Send (text/file, optional password/expiry) | 1P Item Sharing | At parity |
| KDF / key custody | Argon2id (t=3/m=64MiB/p=4) or PBKDF2-SHA256 600k | PBKDF2-SHA256 650k + 128-bit Secret Key | Partial |
| Two-Secret Key Derivation | None — master password alone decrypts export | 1P Secret Key (device-held second factor) | SaaS only |
| Breach monitoring | On-demand HIBP report; cron + HIBP replacement | 1P Watchtower (continuous, proprietary feed) | SaaS only |
| SSO Unlock | None — master password always required | 1P SSO Unlock (Trusted Devices) | SaaS only |
| SCIM provisioning | No first-party SCIM (community projects only) | 1P SCIM bridge | SaaS only |
| Org policy engine | Master-pw complexity, 2FA-required, lock-on-idle, export-disable | 1P Business Policies (+ geo/device fingerprint) | Partial |
| Machine-to-machine secrets | None at the same UX (migrate to OpenBao/Vault) | 1P Connect / Secrets Automation | SaaS only |
| Audit log | Org Events /api/events, customer retention | 1P Events API + Splunk app | At parity |
| Travel Mode | None | 1P Travel Mode | SaaS only |
| Compliance / SOC 2 | Customer-owned (self-hosted) | Inherited 1P SOC 2 | SaaS only |
| Cost model | $0 licence; infra + ops | ~$8/user/mo | Partial |
What we're honest about
The caveats most vendors leave out.
No SSO Unlock equivalent
If you rely on 1Password SSO Unlock (Trusted Devices), Vaultwarden does not match it — the master password is always required to decrypt the vault. This is the single largest deal-killer. We survey it in Phase 0 and give you three honest options: accept the master-password regression with a hardware-key WebAuthn factor, front Vaultwarden with an OIDC proxy that gates login but not decryption, or move to Bitwarden Enterprise cloud instead. Exec sign-off before Phase 1.
Watchtower monitoring stops
1Password Watchtower continuously scans your items against HIBP plus a proprietary feed and pushes alerts. Vaultwarden offers on-demand reports only. Before retirement we stand up a cron + HIBP + Slack replacement and prove it fires on a known-bad test item — but the proprietary feed has no open-source equivalent, and we say so.
Secret Key protection is lost
1Password's Two-Secret Key Derivation means a stolen export plus the master password still cannot decrypt without the device-held Secret Key. Vaultwarden's export is decryptable with the master password alone if the KDF parameters are known. We compensate with Argon2id, a hardware-key WebAuthn factor at unlock, an HIBP check at master-password creation and a 14-character minimum — and we document the residual delta rather than hide it.
You own uptime and support
1Password Connect machine-to-machine secrets, Travel Mode and 24×7 user support all disappear. Connect consumers must move to OpenBao or HashiCorp Vault before Phase 6, your helpdesk absorbs every reset, and self-hosting means Vaultwarden being down is logins being down. That is why we run it as managed: HA across nodes and zones, a tested break-glass path, and a DR runbook with a recovery-time target.
Why this beats a flag day
Reversible per cohort. Soaked before you commit.
Every cohort's cutover rolls back in under 15 minutes while the parallel run is live — uninstall the Vaultwarden extension or restore the 1Password vaults to writable, and the user is exactly where they started with no data loss, because their 1Password vault is never touched until late. No cohort advances to retirement until it has soaked for at least 30 consecutive days with zero 1Password unlock events, and the 1Password contract is only cancelled after that evidence window passes for the whole estate. You are never betting the company on one big cutover.
See whether your 1Password estate migrates cleanly.
A 30-minute call with a senior security engineer. We inventory your vaults, find the SSO-Unlock and 1Password Connect dependencies that decide the path, and tell you honestly what cohort-by-cohort migration looks like for your environment — before you commit to anything.
Map my migration →