Vaultwarden emergency access, set up right

Vaultwarden emergency access in short

Vaultwarden emergency access lets a person you trust read your vault, or take it over, after a wait period that you choose. The server switch is EMERGENCY_ACCESS_ALLOWED, which is on by default. Two hourly jobs do the timed work. One sends you a reminder, and the other approves the request when the wait is over. The access itself works without email. The warning that someone has asked for access does not, and that is the part you need to plan for.

This guide is for a solo admin. You run the server, and you are also the person whose vault matters. It covers the server settings, the steps in the web vault for both people, View versus Takeover, and how the wait period really ends. The last part covers the plan around the vault, because emergency access only helps if the server is still running when someone needs it.

All behaviour below was read from the Vaultwarden source code and .env.template on 3 November 2026. That means the main branch and the 1.37.5 release, which was published on 1 November 2026. Where they differ from each other or from the earlier 1.37.4 release, the text says so. The 1.37.5 release notes list a medium-severity security fix for emergency access and say the release is required for web vault 2026.9.0 and later to take over an account through emergency access. If you run an older release, upgrade.

Two roles: grantor and grantee

The grantor is the account owner who names a trusted contact. The grantee is the trusted contact. Each one needs their own account. Bitwarden's help says the contact must have an account on the same server. On a self-hosted box that means your Vaultwarden, not bitwarden.com.

Bitwarden sells emergency access as a premium feature. The Vaultwarden emergency access handlers have no premium check. The only gate is the server switch, EMERGENCY_ACCESS_ALLOWED, and it applies to every user at once.

The grantor picks one of two access levels per contact:

• View: the grantee can read the items in the grantor's individual vault.
• Takeover: the grantee sets a new master password for the grantor's account and logs in as the grantor.

The grantor also picks a wait time in days. When the grantee asks for access, the grantor can approve or reject. If the grantor does nothing, the request is approved after the wait time ends.

Turn on the server side: three settings

If you followed running Vaultwarden on a VPS with Docker Compose, add these lines to the environment: block of your existing vaultwarden service. The values shown are the defaults, so writing them out changes nothing. It does make the behaviour visible to the next person who reads the file.

    environment:
      DOMAIN: "https://vault.example.com"
      EMERGENCY_ACCESS_ALLOWED: "true"
      EMERGENCY_NOTIFICATION_REMINDER_SCHEDULE: "0 3 * * * *"
      EMERGENCY_REQUEST_TIMEOUT_SCHEDULE: "0 7 * * * *"

EMERGENCY_ACCESS_ALLOWED controls whether users can use emergency access at all. The template says it applies globally to all users, and the default in src/config.rs is true. When it is false, every emergency access action fails with Emergency access is not enabled. and the contact lists come back empty. Both scheduled jobs also stop doing anything.

EMERGENCY_NOTIFICATION_REMINDER_SCHEDULE is the job that emails reminders to grantors. The default runs every hour, 3 minutes past the hour.

EMERGENCY_REQUEST_TIMEOUT_SCHEDULE is the job that approves requests whose wait time has passed. The default runs every hour, 7 minutes past the hour.

These schedules are not normal crontab lines. They have six fields, and the first one is seconds: SEC MIN HOUR DAY-OF-MONTH MONTH DAY-OF-WEEK. So 0 7 * * * * means second 0 of minute 7 of every hour. The template also says the schedules are always in UTC (coordinated universal time), whatever time zone the server uses.

Two settings can switch these jobs off. Setting a schedule to an empty value disables that one job. Setting JOB_POLL_INTERVAL_MS to 0 disables every scheduled job on the server. Its default is 30000, which means the scheduler checks for due jobs every 30 seconds. If the timeout job does not run, no request is ever approved by the clock. Approval then only happens when the grantor clicks it. That defeats the purpose of emergency access, because the grantor is exactly the person who cannot click.

DOMAIN must match the address you open the vault from. The template says email links depend on it, so an invitation sent with the wrong DOMAIN points the grantee at the wrong place.

Apply the change and check that the container sees it:

docker compose up -d
docker compose exec vaultwarden printenv EMERGENCY_ACCESS_ALLOWED EMERGENCY_REQUEST_TIMEOUT_SCHEDULE

docker compose up -d recreates the container when its environment has changed. The second command should print true and 0 7 * * * *. If it prints nothing for a variable, that variable is not set in the container, so Vaultwarden uses its built-in default.

Does emergency access work without SMTP?

Yes for the access itself, and no for the warnings. The answer comes from the source file src/api/core/emergency_access.rs, not from the wiki. The wiki's SMTP Configuration page covers invitations to new users and says nothing about emergency access.

In the source, every step saves its state change to the database. Email is sent only when mail is enabled. Mail counts as enabled when SMTP_FROM is set together with either SMTP_HOST or USE_SENDMAIL. With mail off, the steps behave like this:

• Invite an existing user. The source comment reads if mail is not enabled immediately accept the invitation for existing users. The contact moves straight to accepted. The grantor still has to confirm them.
• Invite an address with no account. If INVITATIONS_ALLOWED is off, the invite fails with Grantee user does not exist: followed by the address. If it is on, Vaultwarden creates a placeholder user for that address, but the invitation is not accepted automatically. This is a good reason to have the grantee register before you invite them.
• Confirm, request, approve, reject. The status changes are saved, and no email goes out.
• Timeout approval. The scheduled job approves the request on time. No email goes out.
• Reminder. The reminder job sends nothing at all.

So without mail, the whole process works. The cost is silence. Bitwarden's help says the grantor is emailed when a request is made. On your server that email only exists if mail works. Without it, a request can sit for the full wait time and turn into an approval that you never heard about.

Mail can also be configured but broken. The request is saved before the email is sent, so a failing SMTP server does not stop the clock. The request still counts down. Set up mail properly and test it. Sending mail from self-hosted apps through a relay covers the SMTP side, which this guide does not repeat. The variables Vaultwarden reads are SMTP_HOST, SMTP_FROM, SMTP_PORT, SMTP_SECURITY, SMTP_USERNAME and SMTP_PASSWORD.

Set it up in the web vault, in the right order

Vaultwarden serves the Bitwarden web vault, so the labels below come from Bitwarden's help pages. Your build may word them slightly differently.

1. The grantee creates their own account on your server first. Give them the exact vault URL, which is the same as your DOMAIN. Ask them to turn on two-step login for their own account. Their account is the way into yours, so it deserves the same care.
2. The grantor adds the contact. Go to Settings, then Emergency access, then Add emergency contact. Enter the grantee's Email, choose User access (View or Takeover), choose a Wait time, and select Save.
3. The grantee accepts. With mail on, they open the invitation email and select Become emergency contact. Bitwarden's help says the invitation is valid for five days. With mail off and an existing account, the server accepts it for them.
4. The grantor confirms. When the contact shows Needs Confirmation, open the menu next to them and choose Confirm. The vault shows a fingerprint phrase. Read it to each other on a phone call or in person. It must match word for word. A mismatch means you are about to trust a different account than the one you think.

To change the access level or the wait time later, go to Settings, then Emergency access, and select the contact's email. To remove a contact, open the menu next to them and choose Remove.

When the time comes, the grantee goes to Settings, then Emergency access. They find the grantor under Designated as emergency contact, open the menu and choose Request Access. The grantor sees the request under Trusted emergency contacts and can choose Approve or Reject from the same menu.

View versus Takeover

View gives read-only access. In Vaultwarden, the view handler loads the items that the grantor owns personally (Cipher::find_owned_by_user). Items in an organization belong to the organization, not to the grantor, so expect them to be missing. If your shared items live in an organization, add the grantee to that organization as well, or keep a copy of the critical items in your personal vault.

Takeover is much stronger. The grantee sets a new master password and then logs in as you. Bitwarden's help says this replaces your master password and removes your two-step login methods. The Vaultwarden source does the same: it deletes every two-step login method on the grantor's account. It also removes the grantor from every organization where the grantor is not an Owner. A takeover can therefore break shared access that other people rely on.

Revoking access after approval also differs. The grantor can end a View grant with Reject. A Takeover grant cannot be undone from a menu. Bitwarden's help says the only way back is to log in with the new master password and change it to one the contact does not know.

For most people, View is the right choice. The grantee can read every password and note and act on them. Choose Takeover only when someone must keep using your account, for example because they need its organization ownership to keep a family vault running.

Store your VPS provider login, your SSH (secure shell) key location and your Vaultwarden admin credentials as items in your personal vault. Then View access gives the grantee the server as well as the passwords.

When is a pending request actually approved?

The wait time is a whole number of days, set per contact. Bitwarden's help says the minimum is one day. Since the 1.37.5 release, and on the main branch, Vaultwarden rejects any value outside 1 to 90 days with Emergency access wait time is out-of-bounds!. Release 1.37.4 and earlier do not have that check in the handler, so on those releases only the choices in the web vault limit it.

When the grantee selects Request Access, Vaultwarden records the time. The deadline is that time plus the wait days. Approval does not happen at the deadline itself. It happens when the timeout job next runs and finds that the deadline has passed. With the default schedule, the job runs at 7 minutes past each hour (UTC), so approval can come up to about an hour after the deadline.

Here is an example with a 3-day wait. The grantee requests access at 14:20 UTC on Monday. The deadline is 14:20 UTC on Thursday. The job at 14:07 on Thursday finds the deadline still in the future and skips the request. The job at 15:07 approves it. With mail on, the grantor gets a timed-out email and the grantee gets an approved email.

The reminder job is quieter than its hourly schedule suggests. It sends the grantor a reminder only during the last day before the deadline, and at most one per day. It is not a stream of hourly warnings. The request itself counts as a notification, so a reminder can only go out once 24 hours have passed since the request. With a 1-day wait, that point is the deadline itself. On 1.37.5 and main, the reminder job skips any request whose deadline has passed, so a 1-day wait gets no reminder at all, and the request email is the only warning. On 1.37.4, a 1-day wait can produce a reminder at or just after the deadline, a few minutes before the timeout job approves the request.

During the wait the grantor can act at any time. Approve works immediately, with no check on how much of the wait has passed. Reject moves the contact back to confirmed. The grantee stays a trusted contact and can request again later. Bitwarden's help says the same: rejecting a request does not remove the grantee.

Choose the wait time with the threat model below in mind. It must be longer than the longest time you might not read your email. A holiday without internet counts, and so does a stay in hospital.

Test the whole flow once

Do not wait for a real emergency to find out that the email is broken. Run a drill with a second account that you control.

1. Register a test account on your server with an email address you can read.
2. From your real account, add the test account as a contact with View and a 2-day wait. That is the shortest wait that leaves room for a reminder. Confirm it.
3. From the test account, select Request Access. Your real address should get the request email shortly. If nothing arrives, mail is not working. Check your spam folder before anything else.
4. Reject the request. Request again from the test account. This time, do nothing.
5. You should get one reminder during the second day of the wait. Within about an hour after the deadline, the test account should see your vault in View mode.
6. Remove the test contact.

If step 5 never happens, check that EMERGENCY_REQUEST_TIMEOUT_SCHEDULE is not empty and that JOB_POLL_INTERVAL_MS is not 0.

The plan has to outlive the server

Emergency access lives inside your Vaultwarden. Your Vaultwarden lives on a VPS that someone pays for, at a domain that someone renews. If you are gone, nobody pays the next invoice. When the provider suspends or deletes the server, the vault goes with it, and every emergency contact you set up goes too. Domain renewal works the same way. If the domain lapses, the URL your grantee saved no longer reaches the server, even if the server still runs. Providers and registrars wait for different lengths of time after a missed payment, so read your own provider's and registrar's billing policy and write down what you find.

So the written plan needs more than "ask for emergency access". It needs these items, kept somewhere the grantee can reach without your vault:

• Who can pay for the VPS. The provider account login, or a second person added to the account, and a payment card that will not expire next month.
• Who can renew the domain. The registrar login, auto-renew turned on, and the renewal date.
• Where the backup is, and where its password is. A backup encrypted with a password that only exists inside the vault is useless when the vault is gone. Backing up and restoring Vaultwarden on a VPS covers the backup itself. The plan must say where the backup is stored and where its password is kept outside the server.
• The grantee's own account and the vault URL. These must exist before anything happens. A grantee who first learns the URL after you are gone has missed the chance to register and be confirmed, and may find that signups are closed.
• Which access level they have and how long the wait is. They need to know that the wait is normal, so they do not give up after one day.

A separate question is whether self-hosting is the right choice for the people who depend on you. Vaultwarden versus Bitwarden's own server covers that decision. A hosted Bitwarden account does not stop when your VPS invoice goes unpaid.

A check-in switch notices that you are gone

Emergency access waits for someone to ask. It does not notice that you have stopped logging in. A dead man's switch does that job. One recent example is Death Plan Switch, which noted.lol covered on 24 October 2026 as a self-hosted dead man's switch for solo admins.

As described there, it emails you a check-in link once a week, and you must press a button on the page. Opening the link alone does not count. After missed check-ins it sends reminders, then contacts a nominated next of kin after three days. If nobody responds, it sends prewritten messages to the people you chose. The whole process takes up to thirteen days from the last successful check-in. The messages are meant to say where information lives, not to carry passwords.

That fits well with emergency access. The message can say: my passwords are in Vaultwarden at https://vault.example.com, so log in to your own account there, request emergency access, and wait 7 days. The author recommends hosting the switch separately from the services it protects. That matters here, because a switch on the same VPS stops on the same unpaid invoice. The author also calls it new and a best-effort tool, so test it like any other part of the plan.

Threat model: what emergency access protects against, and what it does not

Emergency access protects against one specific problem. You are dead or unable to act, and someone you trust needs your passwords. It solves this without writing your master password down anywhere. It also gives you the wait time to refuse a request you did not expect.

It does not protect against these:

• The server disappearing. An unpaid invoice or a lapsed domain removes the vault and every contact with it. A failed disk with no backup does the same. Only the plan in the previous sections covers this.
• A compromised grantee account. Anyone who can log in as your grantee can request access. If you do not reject the request in time, they get View or Takeover, whichever you chose. With Takeover they also remove your two-step login. Use View where you can, choose a wait time longer than your longest absence, and make sure the grantee uses two-step login.
• A notification you never see. If SMTP is broken, the request times out into approval and nobody objects. The same happens when your own mailbox is on the domain that just lapsed. Send your Vaultwarden mail to an address that does not depend on the same server or domain, and run the drill above.
• Someone with root on the VPS. Emergency access is a feature inside the vault. It does nothing about who can reach the server or its backups. How secure Vaultwarden is on your own VPS covers that side.
• Organization items. View shows the grantor's own items only. Shared items in an organization need their own plan.

FAQ

Does Vaultwarden emergency access work without SMTP configured?

Yes. In the Vaultwarden source (src/api/core/emergency_access.rs), invites, confirmation, requests, approval, rejection and the timed approval all save their state whether mail is enabled or not. An invite to an existing user is accepted at once when mail is off. What you lose is every email, including the one that tells the grantor a request was made. A request can therefore reach approval without the grantor ever knowing.

When exactly is a pending emergency access request approved?

Only when the timeout job runs after the deadline, which is the request time plus the wait days. The job is set by EMERGENCY_REQUEST_TIMEOUT_SCHEDULE, which defaults to 0 7 * * * * (7 minutes past every hour, UTC). With the defaults, approval comes up to about an hour after the wait ends. If that schedule is empty, or JOB_POLL_INTERVAL_MS is 0, requests are never approved by the clock.

What is the difference between View and Takeover in Vaultwarden?

View gives the trusted contact read-only access to the items the grantor owns personally. Takeover lets the contact set a new master password and log in as the grantor. In Vaultwarden, a takeover also deletes all of the grantor's two-step login methods and removes the grantor from every organization where they are not an Owner. The grantor can end View with Reject. Takeover can only be undone by changing the master password again.

How do I turn off emergency access on my Vaultwarden server?

Set EMERGENCY_ACCESS_ALLOWED to false in the container's environment and run docker compose up -d. The setting applies to every user. Emergency access actions then fail with Emergency access is not enabled. Both emergency access jobs stop as well, so no pending request is approved while the setting is off.

Does my emergency contact need their own Vaultwarden account?

Yes. Bitwarden's help says the trusted contact must have an account on the same server, which for you means your Vaultwarden. Have them register before you invite them, and give them the vault URL. If they have no account and INVITATIONS_ALLOWED is off, the invite fails with Grantee user does not exist:.