Vaultwarden-Plus v1.36.3: Organization Account Recovery — without breaking zero-knowledge

Every operator who runs Vaultwarden for a team eventually hits the same wall: a member forgets their master password. In a zero-knowledge system that's supposed to be a dead end by design — the server can't just "reset" what it never had access to.

Bitwarden solves this upstream with Organization Account Recovery: enrolled members hand the org an encrypted recovery blob, and an admin can trigger a recovery that forces a password reset — all without the server ever seeing a plaintext password or vault key. That capability has been on the operator wishlist for Vaultwarden for a long time.

As of v1.36.3, it's integrated into Vaultwarden-Plus.

What actually shipped

• Admin-triggered recovery for enrolled organization members, driven through the official Web Vault Admin Console.
• Forced password-reset flow for the affected member on next login (update-temp-password).
• Support for both legacy and V2 password payloads, plus 2FA-only recovery requests.
• A Web Vault adapter that handles the older /reset-password path and the current /recover-account calls, so official-client compatibility stays intact.

The part I care about most: the security model didn't move

Account recovery is exactly the kind of feature that's easy to ship badly — by quietly weakening the threat model. So the hard constraint was: zero-knowledge stays zero-knowledge.

The server still never stores plaintext master passwords, plaintext vault keys, plaintext org private keys, passkey PRF secrets, trusted-device material, or decrypted vault contents. Recovery only works when org policy, enrollment, authorization, and a valid recovery payload all line up — and credential mutation stays fail-closed if a request is malformed or incomplete. Recovery material, tokens and mail links are never logged.

In other words: an admin can get a locked-out colleague back into their vault, but "admin" never becomes "can read everyone's passwords."

Operator notes

• No database or config migration required — drop-in for existing deployments.
• You'll need SMTP / sendmail / SES configured for recovery notification mail.
• The bundled Web Vault is intentionally pinned to 2026.4.1 (validated against this recovery flow); upgrades beyond it wait until an upstream artifact is available and separately validated.
• Validated end-to-end on an isolated stack (SQLite + Maildev): policy → enrollment → admin recovery → forced reset → completion.

Try it

services:
  vaultwarden:
    image: forgejo.sabolowitsch.org/stefansa/vaultwarden-plus:1.36.3
    container_name: vaultwarden
    restart: unless-stopped
    environment:
      DOMAIN: "https://vw.domain.tld"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 127.0.0.1:8000:80   # TLS terminates at your reverse proxy

Release & full notes: https://forgejo.sabolowitsch.org/StefanSA/vaultwarden-plus/releases/tag/v1.36.3

If you run Vaultwarden for an organization, I'd love to hear how you currently handle lost-master-password situations — and whether this matches what you'd need. 🔐