企業の証明書ウォレット運用｜スマホ紛失・異動・退職のとき何を止め、何を残すか

ある会社が、社員証や資格証をスマホの証明書ウォレットで配り始めました。取引先の証明も、同じウォレットで扱います。配り始めてまもなく、情報システム部には3つの連絡が届きました。

• 営業の社員が、スマホをなくした
• 別の社員が、兼務のまま部署を移った
• 委託先の担当者との契約が終わった

どれも、ウォレットの中の何を残し、何を止めるかを決めなければなりません。スマホをなくした社員の社員証は、止めるべきか。異動した社員の資格証は、残してよいのか。

要になるのは、アプリ選びではありません。こうした出来事のたびに、残すものと止めるものを自動で決められるよう、台帳を分けておくことです。人、ウォレット、端末、鍵の4つを別々に管理します。

最初から全社に広げると、問題が起きたときに、技術の障害なのか業務ルールの不備なのかを見分けられません。そこで、まずは証明書1種類、端末の条件2つ、例外3つ（紛失・異動・退職）から始めます。以下では、この会社の情報システム部が、この3つの例外を順に通していく流れで見ていきます。

VCの基礎は「Verifiable Credentialsとは」、発行者・検証者を含む全体設計は「DID・VCの導入設計」で解説しています。

まず、人・ウォレット・端末・鍵の台帳を分ける

「1人に1台のスマホ」を前提にすると、扱えない場面が出てきます。兼務、共有の業務端末、私物端末の業務利用（BYOD）、複数の拠点、休職、委託契約の終了などです。

そこで、少なくとも次の4つを、それぞれ別の識別子と状態で管理します。お互いの対応には、有効期間を持たせます。

分けておけば、1つの出来事で全部を止めずに済みます。

• 主体：端末が壊れただけなら、在籍の状態はそのまま
• ウォレット：資格が失効しただけなら、ウォレットは使える
• 端末：異動しただけなら、端末を初期化しない場合がある
• 鍵：提示用の鍵を更新しただけなら、その人を退職扱いにしない

OpenID4VCI 1.0 Final（証明書を発行する手順の仕様）は、ウォレットを次のように定義しています。証明書と利用者の鍵を受け取り、保存し、提示し、管理するもの。置き場所も1つではありません。手元の端末、自社で運用するリモートサービス、第三者のリモートサービスが認められています。

1人が複数のウォレットを持つことも、1台の端末を複数人が使うこともあるわけです。だから「ウォレットID」を、スマホの端末IDや従業員番号で代用しません。こうした多対多の対応を、履歴として持っておきます。

ウォレットの状態は、どんな出来事で切り替えるか

ウォレットの状態を「使える」「使えない」の2つだけにすると、表せない場面が出ます。申請中、端末の追加、再発行中、隔離、廃止した後の監査などです。

この会社では、状態を次の7つで動かします。製品の仕様ではなく、企業の運用で最低限要る例です。

申請中 → ひも付け済み → 利用中 → 制限中 → 復旧待ち → 無効 → 廃止

状態を切り替えるきっかけは、ウォレットの外で起きる出来事です。人事の発令、MDM（端末管理）からの通知、セキュリティ監視（SOC）の事故通知、利用者の申請といった出来事です。同じ出来事の通知が2回届いても、冪等に1回分だけ処理します。各状態で許すこと・許さないことは、後半の「実装する人向けの詳細」に表でまとめています。

使い始めるには、アプリを配るだけでなく5つのひも付けが要る

アプリを入れてもらっただけでは、それが誰の、どの端末の、どの鍵なのかが決まっていません。そこで入社や契約開始のときは、次の5つのひも付けを終えてから「利用中」にします。

1. 人のひも付け：人事・取引先の正本と利用者を、用途に必要な確かさで対応させます。
2. 管理者のひも付け：上長、業務の責任者、セキュリティ管理者のうち、誰が発行と例外を承認するかを決めます。
3. 端末のひも付け：MDMへの登録、暗号化、画面ロック、OSの最低版、侵害検知の合否を記録します。
4. 鍵のひも付け：ウォレットが作った公開鍵、鍵の保管部品、利用者の認証方式を確かめます。鍵の用途は、発行・提示などに限ります。
5. 証明書のひも付け：対象の証明書をその鍵に結びつけます。受け取りの成功と失敗は、発行者の側で追います。

4の鍵の証明は、鍵が本物で、安全な部品に守られていることを発行者に伝える仕組みです。ただし、それが通っても、端末が会社のポリシーを守っているとは限りません。利用者がいまも在籍しているとも限りません。MDMの判定、人の状態、ウォレット・鍵の証明は、別々の判定結果として残します。

ウォレットでのログインと証明書の提示を、業務システムの権限につなぐ流れは「VC提示でログインする設計」で扱います。

端末の中での認証では、2つの操作を区別します。スマホのロック解除と、ウォレットの起動・承認（activation）です。NIST SP 800-63C-4 Subscriber-Controlled Walletsは、ウォレットの鍵で署名するときに、起動のための要素（activation factor）を求めています。そしてそれを、端末のロック解除とは別の操作としています。

同じ指紋や顔を使う場合でも、区別は必要です。ウォレットが意図した提示を承認したことを、画面と監査記録で分けて示します。

異動・兼務のときは、何を見直すか

部署が変わっても、本人の属性や別部門の資格は引き続き要ります。ウォレットを丸ごと消すと、それまで消えてしまいます。一方、何も変えなければ、前の部署の権限が残ります。

そこで異動の通知を受けたら、ウォレット、端末、鍵を一律に作り直しません。見直すのは、証明書の種類と、受け取る側（検証者）の業務権限の差だけです。出来事（入社・異動・退職＝joiner/mover/leaver）ごとに、残すものと変えるものは次のとおりです。

それぞれ、完了したと言えるのは次の記録がそろったときです。

• 入社・契約開始：5つのひも付けと、利用開始の通知
• 異動・兼務：前の権限が拒否され、新しい権限が最小限だけ与えられたこと
• 休職・一時停止：停止の期限、解除の承認、通知
• 退職・契約終了：失効の反映、端末の返却・消去、残っている鍵がないこと

業務権限は、異動のたびに変わります。証明書の中に長く固定すると、古い権限が残り続けます。そこで、情報の新しさをどう保つかを、リスクに応じて選びます。短い有効期限、失効の状態、オンラインでの判定のどれかです。

証明書の失効とステータスリストの方式は「VCの失効設計」で詳しく扱います。ここで見ているのは、その手前です。ウォレットの運用の出来事から失効の依頼を確実に出し、完了した時刻を見張るところまでです。

スマホをなくしたら、復元より先に古いスマホを締め出す

鍵のバックアップを、新しいスマホへコピーする方法もあります。ただ、コピーできる鍵は、どこに残っているかを把握しにくいものです。捨てた端末に鍵が残ったり（latent key）、複製の範囲が広がったりします。だから、コピーできたことをもって復旧完了とはしません。NIST SP 800-63B-4も、次のものを脅威に挙げています。

• 捨てた端末に残る鍵
• 端末の間での、行き過ぎた同期
• 安全性の低い同期の仕組み

この会社で営業の社員がスマホをなくしたときは、次の順で進めます。

1. 紛失の申告を1件の事故として受け付け、古いウォレットを「復旧待ち」（RECOVERY_PENDING）にします。
2. 管理のセッション、通知用のトークン、端末の証明書、提示用の鍵を無効にします。証明書の一時停止や失効が要るかは、発行者に知らせます。
3. 本人か担当者を確かめます。手元の認証器、回復コード、管理者による確認、必要なら本人確認のやり直しを使います。
4. 新しいスマホで新しい鍵を作り、MDM・鍵の証明・ウォレットのポリシーを確かめ直します。
5. 証明書を新しい鍵に出し直します。古いウォレットでは拒否され、新しいウォレットでは見せられることを確かめます。
6. 本人とセキュリティ監視の担当に、復旧を知らせます。古いスマホが見つかっても、自動で使える状態に戻しません。

NIST SP 800-63B-4のAccount Recoveryは、回復を普段の認証と区別しています。新しい認証器を結びつけたら、利用者に知らせるという考え方です。

会社の運用では、仕事を分ける工夫も要ります。ヘルプデスクの担当者1人が、本人確認、古いウォレットの停止、新しいウォレットの承認をすべてこなせないようにします。どこまで分けるかは、リスクに応じて決めます。DIDそのものの鍵を更新・復旧する場合の権限の分け方は「DIDの鍵更新とアカウント復旧」を参照してください。

ブロックチェーンに置くものはあるか

人事の状態、端末の準拠、秘密鍵、個人の属性、提示の履歴は、変更・削除・アクセス制御が要る情報です。会社の正本DB、MDM、KMS、SIEM（ログの監視基盤）で管理する方が向いています。ウォレットの運用に、ブロックチェーンは必須ではありません。

情報ごとの置き場所は次のとおりです。

ブロックチェーンに置けるかどうかは、情報ごとに次のとおりです。

• 証明書の本文・個人属性：原文は置かない
• 秘密鍵・回復用の秘密、端末・所属・提示履歴：置かない
• 発行者の鍵・信頼情報：運営する組織をまたいで一緒に確かめる場合に候補
• スキーマ・ポリシーの版：改ざんを見つけるためのハッシュだけが候補

公開の台帳にハッシュを置いても、証明できないことがあります。元データが正しいか、ウォレットの持ち主は誰か、発行する権限があるか、です。

1つの会社か、契約のもとで運営する組織が、署名付きのレジストリと監査ログを維持できるなら、通常のDBとPKIで足ります。候補にするのは、独立した複数の組織が1つの運営者を信頼できず、共通の更新履歴を確かめたい場合だけです。そのときも置くのは、機密でない参照とハッシュです。

障害や提供事業者の撤退に、どう備えるか

本番の前に、正常な発行と提示が通るだけでは足りません。少なくとも次の障害をわざと起こし、復旧までの時間と、処理しきれていない件数を測ります。

• 発行の応答がタイムアウトした後に送り直しても、証明書が二重に発行されない。
• MDMが一時止まっている間、最後の準拠状態をいつまでも信じ続けない。
• 提供事業者や状態情報の配信が止まったとき、証明書の種類ごとの既定が働く。「通す（fail-open）」か「止める（fail-closed）」か。
• 鍵が漏れたとき、対象の鍵、ウォレット、証明書、提示先を検索し、必要な範囲だけ止められる。
• 人事の通知が遅れても、順番が逆になっても、重なっても、退職者の権限が戻らない。
• 提供事業者が撤退したとき、利用者と証明書の一覧、ポリシー、監査記録を書き出し、別のウォレットへ出し直せる。

2026年4月公開のデジタル庁「行政機関におけるVC・DIWの活用にあたる検討事項リスト（案）」も、同じ点を検討事項に挙げています。

• ウォレット提供事業者が撤退するときの互換性
• 端末の紛失・交換のときの再発行
• 発行者が撤退するときの継続

書き出せるだけでは足りません。別の環境で確かめ、出し直せることを、定期的に演習します。

最初の1歩：証明書1種類・端末2条件・例外3つで試す

最初から全社員、全資格、全端末を対象にすると、困ったことが起きます。技術の障害なのか、業務ルールの不備なのか、見分けられないのです。

そこで、この会社はまず範囲を絞ります。1種類の証明書を選び、端末は2つの条件で試します（会社支給の管理端末と私物端末など）。そこに紛失・異動・退職の3つの例外を通し、次の条件を満たしてから広げます。

• 人・ウォレット・端末・鍵の今の状態と履歴を、1つの共通IDで追える。
• 異動で要らない権限だけが外れ、続けて使う証明書と端末は意図どおり残る。
• 紛失の申告から古いウォレットが拒否されるまでの時間と、新しいウォレットが使えるまでの時間を、別々に測れる。
• 退職の通知が遅れても重なっても、証明書と管理のセッションが元に戻らない。
• 提供事業者が止まっている間の業務の代わりの手段がある。復旧後に残った処理をやり直しても、冪等に1回分で済む。
• 端末の返却時に鍵が消えたことを確かめる。監査情報には、保持の期限と削除の責任者がある。

実装する人向けの詳細

ここからは、この会社で実際にウォレット管理の仕組みを組む担当者向けの話です。

7つの状態と、各状態で許さない操作

前半で触れた「使える」「使えない」の2値（activeとdisabled）では表せない場面を補う、最小の例です。

状態変更で残す項目と、再実行のしかた

状態を変えるときは、次の項目を保存します。

• event_id、対象ID、旧状態、新状態
• 理由コード、承認者
• 発生時刻、記録時刻、ポリシーの版

タイムアウトの後に同じ申請をやり直すときは、先に結果を照会します。ウォレットの作成、鍵の生成、証明書の発行のそれぞれです。まだ反映されていないと確かめられるまで、二重に発行しません。

紛失時に無効にする対象

紛失の手順2で止めるのは、具体的には次の4つです。

• 管理のセッション
• プッシュ通知用のトークン
• 端末の証明書
• 提示用の鍵

XTELAができること

私たちは、企業向けウォレットの要件整理から、主体・端末・鍵・証明書の状態モデル、発行・提示API、MDMやIdPとの連携、障害注入を含むPoCと実装仕様までを設計・開発しています。貴社の証明書を1種類選び、紛失・異動・退職の3つの例外を最初から通す形で、本番に耐えるかを確かめられます。技術構成の整理はお問い合わせからご相談ください。

主要参考資料

• W3C Verifiable Credentials Data Model v2.0（W3C Recommendation、2025年5月15日）
• W3C Bitstring Status List v1.0（W3C Recommendation、2025年5月15日）
• OpenID for Verifiable Credential Issuance 1.0 Final（2025年9月）
• OpenID4VC High Assurance Interoperability Profile 1.0 Final（2025年12月24日）
• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST SP 800-63C-4: Subscriber-Controlled Wallets
• NIST Key Management Guidelines
• デジタル庁 トラスト（デジタル・アイデンティティ等）
• デジタル庁 行政機関におけるVC・DIWの活用にあたる検討事項リスト（案）

資料の確認日と注意

W3C、OpenID Foundation、NIST、デジタル庁の一次資料は2026年9月24日に確認しました。ここでの内容は一般的な技術・運用設計の解説です。個人情報保護・労務・本人確認義務・証明の法的効力に関わる判断は、弁護士と連携して確認してください。