Vaultwardenの緊急アクセス設定とView・Takeoverの違い

Vaultwarden の緊急アクセスの概要

Vaultwarden の緊急アクセスでは、信頼する相手が、指定した待機期間の経過後に保管庫を閲覧したり、引き継いだりできます。サーバー側のスイッチは EMERGENCY_ACCESS_ALLOWED で、デフォルトで有効です。時間指定の処理は、1 時間ごとに実行される 2 つのジョブが担当します。1 つはリマインダーを送信し、もう 1 つは待機期間の終了後に申請を承認します。アクセス自体にメールは必要ありません。ただし、誰かがアクセスを申請したという警告にはメールが必要です。ここを計画に含める必要があります。

このガイドは、1 人で管理する管理者を対象にしています。サーバーを運用し、保管庫を守る本人でもあるケースです。サーバー設定、双方が Web vault で行う手順、View と Takeover の違い、待機期間が実際に終了するタイミングを説明します。最後に、保管庫を取り巻く運用計画を扱います。緊急アクセスは、必要なときにサーバーが稼働している場合にのみ役立つためです。

以下の動作は、2026 年 11 月 3 日時点の Vaultwarden のソースコードと .env.template から確認したものです。対象は main ブランチと、2026 年 11 月 1 日に公開された 1.37.5 release です。両者の間、または以前の 1.37.4 release との間に違いがある場合は、その旨を記載しています。1.37.5 release notes には、緊急アクセスに関する中程度の深刻度のセキュリティ修正が記載されています。また、web vault 2026.9.0 以降で緊急アクセスによってアカウントを引き継ぐには、この release が必要だと説明されています。古い release を使用している場合は、upgrade してください。

2 つの役割: 許可者と被許可者

許可者は、信頼する連絡先を指定するアカウント所有者です。被許可者は、その信頼する連絡先です。それぞれに自分のアカウントが必要です。Bitwarden のヘルプによると、連絡先は同じサーバー上にアカウントを持っている必要があります。セルフホスト環境では、bitwarden.com ではなく、自分の Vaultwarden が該当します。

Bitwarden は緊急アクセスをプレミアム機能として提供しています。Vaultwarden の緊急アクセス処理には、プレミアム機能かどうかの確認がありません。唯一の制御はサーバー設定 EMERGENCY_ACCESS_ALLOWED で、すべてのユーザーに一律で適用されます。

許可者は、連絡先ごとに次の 2 つのアクセスレベルのいずれかを選択します。

• 表示: 被許可者は、許可者の個人 vault にあるアイテムを読み取れます。
• 引き継ぎ: 被許可者は、許可者のアカウントの新しいマスターパスワードを設定し、許可者としてログインします。

許可者は、日数単位の待機時間も設定します。被許可者がアクセスを要求すると、許可者は承認または拒否できます。許可者が何もしない場合、待機時間が終了すると要求は承認されます。

サーバー側を有効にする: 3 つの設定

Docker Compose で VPS 上で Vaultwarden を実行するに従った場合は、既存の vaultwarden サービスの environment: ブロックに次の行を追加します。示している値はデフォルト値のため、明示的に記述しても動作は変わりません。ただし、次にファイルを読む人が設定内容を確認しやすくなります。

    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 は、ユーザーが緊急アクセスを使用できるかどうかを制御します。テンプレートでは、すべてのユーザーにグローバルに適用されると説明されています。src/config.rs のデフォルト値は true です。false の場合、緊急アクセスに関するすべての操作が Emergency access is not enabled. で失敗し、連絡先リストも空になります。2 つのスケジュールジョブも実行されなくなります。

EMERGENCY_NOTIFICATION_REMINDER_SCHEDULE は、承認者にリマインダーをメールで送信するジョブです。デフォルトでは、毎時 3 分に実行されます。

EMERGENCY_REQUEST_TIMEOUT_SCHEDULE は、待機時間が経過したリクエストを承認するジョブです。デフォルトでは、毎時 7 分に実行されます。

これらのスケジュールは通常の crontab の行ではありません。6 つのフィールドがあり、最初のフィールドは 秒 です: SEC MIN HOUR DAY-OF-MONTH MONTH DAY-OF-WEEK。つまり 0 7 * * * * は、毎時 7 分の 0 秒を意味します。テンプレートには、サーバーのタイムゾーンに関係なく、スケジュールは常に UTC (協定世界時) で処理されるとも記載されています。

これらのジョブを無効にする設定が 2 つあります。スケジュールを空の値にすると、そのジョブだけが無効になります。JOB_POLL_INTERVAL_MS を 0 にすると、サーバー上のすべてのスケジュールジョブが無効になります。デフォルト値は 30000 です。これは、スケジューラーが 30 秒ごとに実行対象のジョブを確認することを意味します。タイムアウトジョブが実行されない場合、時間の経過によってリクエストが承認されることはありません。その場合、承認者がクリックしたときだけ承認されます。承認者はクリックできない本人であるため、これは緊急アクセスの目的に反します。

DOMAIN には、vault を開くときに使用するアドレスを指定する必要があります。テンプレートでは、メール内のリンクがこの設定に依存すると説明されています。そのため、誤った DOMAIN で招待を送信すると、招待されたユーザーは誤った場所に誘導されます。

変更を適用し、コンテナから設定を確認します。

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

docker compose up -d は、環境変数が変更された場合にコンテナを再作成します。2 つ目のコマンドでは true と 0 7 * * * * が表示されるはずです。変数の値が表示されない場合、その変数はコンテナ内で設定されていません。そのため、Vaultwarden は組み込みのデフォルト値を使用します。

SMTP なしで緊急アクセスは機能しますか？

アクセス自体は機能しますが、警告は機能しません。答えは wiki ではなく、ソースファイル src/api/core/emergency_access.rs にあります。wiki の SMTP Configuration ページは新しいユーザーへの招待を扱っているだけで、緊急アクセスについては何も説明していません。

ソースでは、各手順が状態変更をデータベースに保存します。メールが送信されるのは、メールが有効な場合だけです。メールが有効と見なされるのは、SMTP_FROM が SMTP_HOST または USE_SENDMAIL のいずれかとともに設定されている場合です。メールを無効にすると、各手順は次のように動作します。

• 既存ユーザーを招待する。 ソースのコメントには if mail is not enabled immediately accept the invitation for existing users と記載されています。連絡先は直ちに承認済みになります。ただし、招待者は引き続き相手を確認する必要があります。
• アカウントを持たないアドレスを招待する。 INVITATIONS_ALLOWED が無効の場合、招待は Grantee user does not exist: に続いてアドレスが表示されて失敗します。有効の場合、Vaultwarden はそのアドレス用の仮ユーザーを作成しますが、招待は自動的には承認されません。そのため、招待する前に招待先ユーザーに登録してもらうのが適切です。
• 確認、要求、承認、拒否。 状態変更は保存され、メールは送信されません。
• タイムアウト時の承認。 スケジュールされたジョブが予定どおり要求を承認します。メールは送信されません。
• リマインダー。 リマインダージョブは何も送信しません。

したがって、メールがなくてもプロセス全体は機能します。代わりに、通知がありません。Bitwarden のヘルプでは、要求が行われると招待者にメールが送信されると説明されています。サーバー上でそのメールが届くのは、メールが機能している場合だけです。メールがなければ、要求が待機時間いっぱい残り、気付かないまま承認に変わる可能性があります。

メールを設定していても、動作しない場合があります。メール送信前に要求が保存されるため、SMTP サーバーの障害でタイマーが止まることはありません。要求のカウントダウンは続きます。メールを正しく設定し、テストしてください。自己ホストアプリからリレー経由でメールを送信するでは SMTP 側を扱っているため、このガイドでは繰り返しません。Vaultwarden が読み取る変数は SMTP_HOST、SMTP_FROM、SMTP_PORT、SMTP_SECURITY、SMTP_USERNAME、SMTP_PASSWORD です。

Web vault で正しい順序に設定します

Vaultwarden は Bitwarden の Web vault を提供するため、以下のラベルは Bitwarden のヘルプページに基づいています。ビルドによっては、表示が多少異なる場合があります。

1. 被付与者が、まずあなたのサーバー上で自分のアカウントを作成します。 正確な vault URL を伝えます。これはあなたの DOMAIN と同じ URL です。被付与者自身のアカウントで 2 段階ログインを有効にするよう依頼します。そのアカウントがあなたの vault への入口になるため、同じように慎重に管理する必要があります。
2. 付与者が連絡先を追加します。 Settings、Emergency access、Add emergency contact の順に進みます。被付与者の Email を入力し、User access（View または Takeover）を選択し、Wait time を選んでから Save を選択します。
3. 被付与者が承認します。 メールが有効な場合は、招待メールを開いて Become emergency contact を選択します。Bitwarden のヘルプによると、招待の有効期間は 5 日間です。メールが無効で、既存のアカウントがある場合は、サーバーが代わりに承認します。
4. 付与者が確認します。 連絡先に Needs Confirmation と表示されたら、その連絡先の横にあるメニューを開き、Confirm を選択します。vault にフィンガープリントのフレーズが表示されます。電話または対面で、互いにそのフレーズを読み上げます。1 語ずつ完全に一致していなければなりません。不一致の場合、想定していたものとは異なるアカウントを信頼しようとしています。

後からアクセスレベルや待機時間を変更するには、Settings、Emergency access の順に進み、連絡先のメールアドレスを選択します。連絡先を削除するには、その連絡先の横にあるメニューを開き、Remove を選択します。

アクセスが必要になったら、被付与者は Settings、Emergency access の順に進みます。Designated as emergency contact の下にある付与者を見つけ、メニューを開いて Request Access を選択します。付与者には Trusted emergency contacts の下にリクエストが表示され、同じメニューから Approve または Reject を選択できます。

表示と引き継ぎ

表示では、読み取り専用アクセスが付与されます。Vaultwarden では、表示ハンドラーが付与者本人が所有するアイテムを読み込みます（Cipher::find_owned_by_user）。組織内のアイテムは付与者ではなく組織に属するため、表示されないことがあります。共有アイテムが組織内にある場合は、被付与者もその組織に追加するか、重要なアイテムのコピーを個人 vault に保管してください。

引き継ぎは、より強力な操作です。被付与者は新しいマスターパスワードを設定し、その後、あなたとしてログインします。Bitwarden のヘルプによると、これによりマスターパスワードが置き換えられ、2 段階ログインの方法が削除されます。Vaultwarden のソースでも同じ処理が行われ、付与者のアカウントに登録されたすべての 2 段階ログイン方法が削除されます。また、付与者が Owner ではないすべての組織から付与者を削除します。そのため、引き継ぎによって、他のユーザーが利用している共有アクセスが機能しなくなる可能性があります。

承認後にアクセスを取り消す方法も異なります。付与者は Reject によって表示の付与を終了できます。引き継ぎの付与は、メニューから取り消せません。Bitwarden のヘルプによると、元に戻すには新しいマスターパスワードでログインし、連絡先が知らないパスワードに変更するしかありません。

ほとんどの場合、適切な選択は表示です。被付与者はすべてのパスワードとメモを読み取り、それらを使って操作できます。誰かがあなたのアカウントを継続して使用する必要がある場合に限り、引き継ぎを選択してください。たとえば、家族用 vault を維持するために、そのアカウントの組織所有権が必要な場合です。

VPS プロバイダーのログイン情報、SSH (secure shell) key の場所、Vaultwarden の管理者認証情報を、個人 vault のアイテムとして保管してください。これにより、表示アクセスを付与した被付与者は、パスワードだけでなくサーバーにもアクセスできます。

保留中の申請は、実際にはいつ承認されるのか

待機期間は、連絡先ごとに設定する整数の日数です。Bitwarden のヘルプでは、最小値は 1 日とされています。1.37.5 release 以降、および main ブランチでは、Vaultwarden は 1 日から 90 日の範囲外の値を Emergency access wait time is out-of-bounds! で拒否します。1.37.4 release 以前では、handler にこのチェックがありません。そのため、これらの release では Web vault の選択肢だけが値を制限します。

被付与者が Request Access を選択すると、Vaultwarden はその時刻を記録します。期限は、その時刻に待機日数を加えた時刻です。承認は期限ちょうどには行われません。timeout job が次に実行され、期限を過ぎていることを検出した時点で行われます。デフォルトのスケジュールでは、この job は UTC の毎時 7 分に実行されます。そのため、承認は期限から約 1 時間後になることがあります。

3 日間の待機期間を例にします。被付与者が月曜日の 14:20 UTC にアクセスを申請したとします。期限は木曜日の 14:20 UTC です。木曜日の 14:07 に実行された job は、期限がまだ将来であることを確認し、申請を処理しません。15:07 の job が申請を承認します。メールが有効な場合、付与者には待機期間終了のメールが届き、被付与者には承認メールが届きます。

リマインダー job は、1 時間ごとに実行されるスケジュールから想像するほど頻繁には通知しません。期限前の最後の 1 日だけ、付与者にリマインダーを送信します。送信は 1 日につき最大 1 回です。1 時間ごとに警告を送り続ける仕組みではありません。申請自体が通知として扱われるため、申請から 24 時間が経過するまでリマインダーは送信されません。待機期間が 1 日の場合、この時点は期限そのものです。1.37.5 および main では、リマインダー job は期限を過ぎた申請を処理しません。そのため、待機期間が 1 日の場合はリマインダーがまったく送信されず、申請メールだけが警告になります。1.37.4 では、待機期間が 1 日の場合、期限ちょうど、または期限直後にリマインダーが送信されることがあります。timeout job が申請を承認する数分前になる場合もあります。

待機中、付与者はいつでも操作できます。Approve は、待機期間がどれだけ経過したかを確認せず、すぐに機能します。Reject を選択すると、連絡先は confirmed に戻ります。被付与者は信頼済み連絡先のままであり、後から再び申請できます。Bitwarden のヘルプにも同じ説明があります。申請を拒否しても、被付与者は削除されません。

待機期間は、以下の脅威モデルを考慮して選択してください。メールを確認できない可能性がある最長期間よりも長くする必要があります。インターネットを利用できない休暇も、入院期間も含めて考えます。

フロー全体を 1 回テストする

本当の緊急事態が起きてから、メールが壊れていることに気付かないでください。自分で管理できる 2 つ目のアカウントを使って、テストを実施します。

1. 読めるメールアドレスを使い、サーバーにテストアカウントを登録します。
2. 本来のアカウントから、View と 2 日間の待機期間を設定して、テストアカウントを連絡先として追加します。これは、リマインダーを送信できる最短の待機期間です。確認します。
3. テストアカウントから Request Access を選択します。本来のアドレスに、まもなく申請メールが届くはずです。届かなければ、メールが機能していません。まず迷惑メールフォルダーを確認してください。
4. 申請を Reject します。テストアカウントから再度申請します。今回は何も操作しません。
5. 待機期間の 2 日目に、リマインダーが 1 回届くはずです。期限から約 1 時間以内に、テストアカウントで View モードの保管庫を表示できるはずです。
6. テスト連絡先を削除します。

手順 5 が実行されない場合は、EMERGENCY_REQUEST_TIMEOUT_SCHEDULE が空でないこと、および JOB_POLL_INTERVAL_MS が 0 ではないことを確認してください。

サーバーより長く存続する計画

緊急アクセスは Vaultwarden の中にあります。Vaultwarden は、誰かが料金を支払っている VPS 上で稼働し、誰かが更新しているドメインを使用しています。あなたがいなくなれば、次の請求書を支払う人はいません。プロバイダーがサーバーを停止または削除すると、Vaultwarden も消え、設定した緊急連絡先もすべて失われます。ドメインの更新も同じです。ドメインの有効期限が切れると、サーバーが稼働していても、受益者が保存した URL からサーバーにアクセスできなくなります。支払いが滞ってから停止や削除が行われるまでの期間は、プロバイダーやレジストラによって異なります。使用しているプロバイダーとレジストラの請求ポリシーを確認し、内容を書き留めてください。

そのため、書面の計画には「緊急アクセスを依頼する」だけでは不十分です。Vaultwarden なしでも受益者が確認できる場所に、次の項目を記載してください。

• VPS の料金を支払える人。 プロバイダーのアカウントログイン情報、またはアカウントに追加した別の人の情報と、来月期限切れにならない支払いカード。
• ドメインを更新できる人。 レジストラのログイン情報、自動更新の有効化、更新日。
• バックアップの場所と、そのパスワードの場所。 Vaultwarden 内にしか存在しないパスワードで暗号化されたバックアップは、Vaultwarden が失われたときに役に立ちません。VPS 上の Vaultwarden のバックアップと復元では、バックアップ自体について説明しています。計画には、バックアップの保存場所と、そのパスワードをサーバー外のどこに保管しているかを記載してください。
• 受益者自身のアカウントと Vaultwarden の URL。 これらは問題が起きる前に用意しておく必要があります。あなたがいなくなった後に初めて URL を知った受益者は、登録して確認を受ける機会を逃しており、登録受付が終了している可能性もあります。
• 付与されているアクセスレベルと待機期間。 待機期間が通常の手順であることを理解してもらう必要があります。そうしないと、1 日後に諦めてしまう可能性があります。

別の問題として、あなたに依存する人々にとってセルフホスティングが適切かどうかも検討する必要があります。Vaultwarden と Bitwarden のサーバーの比較では、この判断について説明しています。ホスト型の Bitwarden アカウントは、VPS の請求が未払いになっても停止しません。

チェックインスイッチで不在を検知する

緊急アクセスは、誰かが依頼するまで待機します。ログインしなくなっても、それを検知しません。その役割を担うのがデッドマンスイッチです。最近の例として、Death Plan Switch があります。これはソロ管理者向けのセルフホスト型デッドマンスイッチで、noted.lol が 24 October 2026 に紹介しました。

記事の説明によると、週に 1 回チェックイン用リンクがメールで届き、ページ上のボタンを押す必要があります。リンクを開くだけではチェックインとして扱われません。チェックインを逃すとリマインダーが送信され、その後 3 日が経過すると、指定した近親者に連絡します。誰も応答しない場合は、あらかじめ作成したメッセージを指定した相手に送信します。最後に成功したチェックインから処理が完了するまで、最大 13 日かかります。メッセージには、パスワードではなく情報の保管場所を記載します。

これは緊急アクセスとよく適合します。メッセージには、次のように記載できます。「パスワードは https://vault.example.com, の Vaultwarden にあります。そこで自分のアカウントにログインし、緊急アクセスを申請して、7 日間待ってください。」著者は、スイッチを保護対象のサービスとは別にホストすることを推奨しています。これは重要です。同じ VPS 上にスイッチを置くと、未払いの請求によって同時に停止するためです。著者は、このツールを新しく、ベストエフォート型のものとも説明しています。そのため、計画の他の部分と同じようにテストしてください。

脅威モデル: 緊急アクセスで防げることと、防げないこと

緊急アクセスは、特定の問題だけを防ぎます。あなたが死亡するか、行動できない状態になり、信頼する相手があなたのパスワードを必要とする場合です。マスターパスワードをどこにも書き留めずに、この問題を解決できます。また、予期していなかったリクエストを拒否するための待機時間も確保できます。

次の問題は防げません。

• サーバーが消失すること。 未払いの請求書や期限切れのドメインによって、vault とそれへのすべての連絡手段が失われます。バックアップのないディスク障害でも同じことが起きます。これを対象にするのは、前のセクションで説明した計画だけです。
• grantee アカウントが侵害されること。 grantee としてログインできる人は誰でも、アクセスをリクエストできます。期限内にリクエストを拒否しなければ、選択した View または Takeover の権限が付与されます。Takeover では、two-step login も削除されます。可能な場合は View を使用し、最長の不在期間より長い待機時間を選択し、grantee に two-step login を使用させてください。
• 通知を一度も確認しないこと。 SMTP が壊れていると、リクエストはタイムアウトによって承認され、誰も異議を申し立てません。自分のメールボックスが、期限切れになったばかりのドメイン上にある場合も同じです。Vaultwarden のメールは、同じサーバーやドメインに依存しないアドレスへ送信し、上記の訓練を実行してください。
• VPS の root 権限を持つ相手。 緊急アクセスは vault 内の機能です。誰がサーバーやそのバックアップに到達できるかについては、何も対策しません。自分の VPS 上で Vaultwarden を安全に運用する方法で、この点を説明しています。
• Organization のアイテム。 View で表示されるのは、grantor 自身のアイテムだけです。Organization 内の共有アイテムには、別の計画が必要です。

FAQ

Vaultwarden の緊急アクセスは、SMTP を設定しなくても機能しますか？

はい。Vaultwarden のソース（src/api/core/emergency_access.rs）では、メールが有効かどうかにかかわらず、招待、確認、申請、承認、拒否、時間経過による承認の状態がすべて保存されます。メールが無効な場合、既存ユーザーへの招待は直ちに承認されます。失われるのはすべてのメールです。申請が行われたことを許可者に知らせるメールも含まれます。そのため、許可者が知らないまま申請が承認に進む可能性があります。

保留中の緊急アクセス申請は、正確にはいつ承認されますか？

期限を過ぎた後にタイムアウトジョブが実行された場合にのみ承認されます。期限は、申請時刻に待機日数を加えた時刻です。ジョブは EMERGENCY_REQUEST_TIMEOUT_SCHEDULE で設定され、デフォルトでは 0 7 * * * *（UTC の毎時 7 分）です。デフォルト設定では、待機期間の終了から最大で約 1 時間後に承認されます。そのスケジュールが空の場合、または JOB_POLL_INTERVAL_MS が 0 の場合、時刻による承認は行われません。

Vaultwarden の View と Takeover の違いは何ですか？

View では、許可者が個人で所有するアイテムに対して、信頼された連絡先に読み取り専用アクセスを付与します。Takeover では、連絡先が新しいマスターパスワードを設定し、許可者としてログインできます。Vaultwarden では、Takeover によって許可者の 2 段階ログイン方式がすべて削除され、許可者が Owner ではないすべての組織から削除されます。許可者は Reject によって View を終了できます。Takeover を取り消すには、マスターパスワードを再度変更する必要があります。

Vaultwarden サーバーで緊急アクセスを無効にするにはどうすればよいですか？

コンテナの環境変数で EMERGENCY_ACCESS_ALLOWED を false に設定し、docker compose up -d を実行します。この設定はすべてのユーザーに適用されます。以後、緊急アクセス操作は Emergency access is not enabled. で失敗します。緊急アクセスのジョブも停止するため、設定が無効な間は保留中の申請は承認されません。

緊急連絡先にも Vaultwarden アカウントが必要ですか？

はい。Bitwarden のヘルプによると、信頼された連絡先は同じサーバー上にアカウントを持っている必要があります。ここでいうサーバーは、使用している Vaultwarden です。招待する前に登録してもらい、vault の URL を伝えてください。アカウントがなく、INVITATIONS_ALLOWED が無効な場合、招待は Grantee user does not exist: で失敗します。