結論：MFAの例外は「一番価値の高い鍵」を開けたまま全社に施錠する行為である

多要素認証（MFA）を全社に導入しながら、「役員は操作が面倒」「緊急時にログインできないと困る」という理由で役員や管理者アカウントだけ免除する——この例外運用は、セキュリティ対策の中でも最も典型的な自己矛盾である。攻撃者はアカウントを平等には狙わない。決裁権限・送金指示・全社データへのアクセス権を持つアカウントほど価値が高く、優先的に狙われる。つまりMFAの免除リストは、攻撃者から見れば「最も価値の高い標的が、最も弱い認証で守られている」一覧表にほかならない。

  • MFAの防御効果は「全アカウントに例外なく適用されている」ことを前提に成立する。一つの例外がそのまま侵入口になる。
  • 役員・管理者は権限が大きいぶん、なりすまされたときの被害が一般社員の比ではない。免除の優先順位は本来逆である。
  • 例外は一つ認めると増殖する。「役員が免除なら部長も」という前例の連鎖で、統制全体が崩れる。
  • サイバー保険の2026年要件では、VPN・リモートデスクトップ・SaaSのすべてでMFAが求められ、管理者にはSMSより強い認証手段が求められる。例外運用は保険の前提も崩す。
  • 「面倒」「緊急時」という免除理由には、認証アプリ・ハードウェアキー・リカバリ手順という代替策がある。例外ゼロは運用設計で実現できる。

この連載「セキュリティ対策の失敗図鑑」は、中堅・中小企業が陥りやすいセキュリティ対策の失敗を一類型ずつ分解している。第8回となる本稿が扱うのは、アカウントの「認証強度」に例外を作る失敗である。退職者アカウントや共有IDの放置を扱った第7回：退職者アカウント・共有ID放置が「存在してはいけないアカウントの管理」の話だったのに対し、本稿は「存在してよいアカウントを、どれだけ強い認証で守るか」に例外を作る失敗を扱う。アカウントの棚卸しが済んでいても、残したアカウントの認証に穴があれば結果は同じである。また、対策にお金を出さない失敗は第9回：セキュリティ投資の予算ゼロ査定で扱うが、MFAの例外は予算の問題ではなく運用判断の問題である点で切り口が異なる。入口となる機器側の脆弱性放置は第3回：VPN機器のパッチ先送りで扱った。

なぜ「役員だけ免除」が最悪の選択になるのか

攻撃者は権限でターゲットを選ぶ——免除の優先順位は逆転している

MFAを免除する判断は、たいてい社内の力関係で決まる。「役員に操作の手間をかけさせられない」「経営層からクレームが来た」という理由で、情報システム部門が押し切られる。だがこの判断は、攻撃側の論理とちょうど逆向きである。

攻撃者にとってアカウントの価値は、その権限の大きさで決まる。一般社員のアカウントを取っても見える範囲は限られるが、役員アカウントを取れば機密資料・人事情報・取引先とのやり取りに届き、役員名義のメールで送金指示や請求書の差し替えを指示するなりすましも成立しやすい。システム管理者のアカウントなら、設定変更・アカウント作成・ログ消去まで可能になる。つまり「最も守るべきアカウント」と「最も狙われるアカウント」は同一であり、そこだけ認証を弱くする例外運用は、防御の優先順位を正確に裏返した状態を作る。

「面倒」「緊急時に入れないと困る」という理由の中身

免除を求める理由はほぼ二つに集約される。一つは操作負担である。ログインのたびにコードの入力を求められるのは煩わしい、出張先でSMSが届かない、デバイスを持ち歩きたくない——という不満だ。もう一つは可用性への不安である。深夜や障害時に「認証が通らずシステムに入れない」事態を恐れて、管理者アカウントを素通しにしておきたいという発想である。

どちらの理由も、感情としては理解できるが、論理としては成立しない。操作負担は認証手段の選び方でほぼ解消できるし、緊急時のアクセスは「認証を外す」のではなく「厳格に管理されたリカバリ手順を用意する」ことで担保すべきものだからである。後述するとおり、免除以外の解決策は揃っている。にもかかわらず免除が選ばれるのは、技術の制約ではなく、社内で「役員に手間を求める」ことを避けたいという組織の力学による。だからこそこの失敗は、ツールの問題ではなく統制の問題である。

例外は増殖する——統制が崩れるメカニズム

例外運用の本当の怖さは、最初の一件では終わらないことにある。役員の免除が認められると、次は「役員と同じ画面を見る秘書も」「決裁を代行する部長も」「忙しい営業責任者も」と申請が続く。前例がある以上、断る論理は立てにくい。免除リストは増え続け、やがて誰がなぜ免除されているのかを把握する者がいなくなる。

こうなるとMFAは「適用されている人もいる仕組み」に格下げされ、統制としては機能しない。監査やセキュリティ点検で「MFA導入済み」と回答していても、実態は権限の大きい順に穴が開いている。例外を管理する台帳も、定期的な見直し期限もないまま免除が永続化していれば、それはもはや例外ではなく、認証ポリシーが二重化した状態である。例外を認めるかどうかの判断基準・承認者・有効期限・棚卸しの仕組みを設計していない組織では、例外は必ず増殖する。

サイバー保険2026の要件から見る——例外が「保険の前提」を崩す

例外運用の重さは、社内の論理だけでなく外部の基準からも測れる。サイバー保険2026年の引受条件厳格化で整理したとおり、2026年、国内大手損保各社はサイバー保険の引受条件を一斉に厳格化した。EDR・MFA・バックアップの3点セットが新規加入・更新の事実上の前提条件となり、満たせない企業は加入そのものが困難に、満たしていても保険料が従来の2〜3倍に跳ね上がるケースが出ている。

このうちMFAの要件は、例外運用と正面から衝突する内容になっている。

  • VPN・リモートデスクトップ・SaaSのすべてでMFAが必須とされる。
  • 管理者アカウントはSMSではなく、認証アプリまたはハードウェアキーが求められる。
  • フィッシング耐性のあるMFAが望ましいとされる。

注目すべきは、管理者アカウントに「より強い」認証が求められている点である。保険の引受基準は、権限の大きいアカウントほど厳格に守るという、攻撃側の論理を踏まえた設計になっている。役員・管理者だけMFAを免除する運用は、この基準のちょうど逆を行く。「全社MFA導入済み」と申告しながら役員・管理者に免除があれば、引受審査の前提と実態が食い違うことになり、保険でリスクを移転するという経営判断自体が成り立たなくなる。インシデント後に補償の場面で実態を問われるリスクを考えれば、例外運用は「保険料を払いながら保険の前提を自ら崩す」行為だといえる。

例外ゼロで運用するための代替策

免除を求める理由には、それぞれ対応する代替策がある。「MFAを外す」以外の選択肢を示せれば、社内の力学にも対抗しやすい。

免除を求める理由例外を作らない代替策
毎回のコード入力が面倒認証アプリのプッシュ承認やパスキー等、ワンタップで完了する方式に変える。信頼済み端末の再認証間隔を業務実態に合わせて調整する
SMSが届かない・海外出張が多いSMSをやめ、通信状況に依存しない認証アプリまたはハードウェアキーに切り替える（管理者には保険要件上もSMS以外が求められる）
デバイスを持ち歩きたくないハードウェアキーを鍵束に付ける運用や、業務端末自体を認証要素とする方式を検討する
緊急時にログインできないと困る免除ではなく緊急用アクセス手順を整備する。リカバリコードの封緘保管、緊急用アカウントの分離・通常時ロック・使用時の即時通知と事後レビューをセットにする
役員に操作を教える手間がかかる導入時に役員向けの個別セットアップ支援を行う。初期設定の30分を惜しんで恒久的な穴を作らない

ポイントは二つある。第一に、操作負担への不満は認証方式の選定で解消するのが筋であり、認証そのものを外す理由にはならない。第二に、緊急時アクセスは「例外」ではなく「手順」として設計する。緊急用の経路は、使われたら必ず検知・記録され、事後に正当性をレビューされる前提で初めて許容される。誰にも知られず使える素通しの口とは別物である。

こうした認証強度の設計は、場当たりの製品導入ではなく、「すべてのアクセスを検証する」という方針の中に位置づけると一貫させやすい。考え方の全体像はゼロトラストセキュリティ導入ガイドで整理しているが、MFAの例外ゼロはその最初の一歩に当たる。

例外をゼロにする運用は、次の周期で回すと定着しやすい。導入初月は役員・管理者の100%適用を確認し、30日後に免除設定と緊急用アカウントの使用履歴を確認する。以後は月1回、MFA未適用アカウント、SMSのみの管理者、期限切れ例外、退職者・異動者の強権限アカウントを棚卸しする。四半期ごとにはサイバー保険の申告内容と実設定を突き合わせ、申告と現実のずれを残さない。

点検の具体策（チェックリスト）

自社の例外運用を、次の観点で棚卸ししたい。

  • MFAの適用状況を「対象者の所属・役職」ではなくアカウント単位の一覧で確認したか。
  • 役員・管理者・特権アカウントに免除・除外設定がないか、設定画面の実態で確認したか（台帳上の建前ではなく）。
  • 免除・例外が存在する場合、その理由・承認者・有効期限が記録されているか。
  • 例外の棚卸しを定期的に行い、期限切れの例外を失効させる仕組みがあるか。
  • 管理者アカウントの認証手段がSMSではなく、認証アプリまたはハードウェアキーになっているか。
  • VPN・リモートデスクトップ・SaaSのすべてにMFAが適用されているか（社内システムだけで満足していないか）。
  • 緊急時アクセスが「免除」ではなく、使用が検知・記録・レビューされる手順として設計されているか。
  • サイバー保険の申告内容（MFA導入状況）と運用実態が一致しているか。

一つでも答えに詰まる項目があれば、MFAは「導入済み」ではなく「導入したつもり」の状態である。とくに役員・管理者の免除は、設定画面を開けば数分で確認できる。本稿を読んだその日に確認する価値がある。

関連記事

よくある質問

Q1. 役員が「面倒だ」と強く言う場合、現場はどう対応すればよいか。

認証を外すのではなく、操作負担の小さい認証方式を提示するのが筋である。プッシュ承認やパスキー、ハードウェアキーなら日々の負担はワンタップ程度に抑えられる。あわせて「役員アカウントこそ最も狙われ、なりすまされたときの被害が最大になる」という攻撃側の論理と、サイバー保険の引受要件という外部基準を示すと、個人の好みではなく経営リスクの問題として議論できる。導入時に役員向けの個別セットアップ支援を行うのも有効である。

Q2. 緊急時にMFAが通らずシステムに入れなくなるのが心配だが、免除以外に方法はあるか。

ある。緊急時アクセスは免除ではなく手順として設計する。リカバリコードを封緘して保管する、通常時はロックした緊急用アカウントを分離して用意する、使用されたら即時に通知され事後にレビューされる仕組みにする、といった方法である。誰にも知られず使える素通しの口を常設するのと、使えば必ず記録が残る緊急経路を備えるのとでは、リスクがまったく異なる。

Q3. すでに役員・管理者の免除が複数存在している場合、何から手を付けるべきか。

まず免除の全量をアカウント単位で洗い出し、理由・承認者・期限を確認する。次に権限の大きい順、つまり特権管理者・役員から免除を解除していく。解除と同時に、操作負担の小さい認証方式への切り替えと個別のセットアップ支援をセットにすると反発を抑えやすい。最後に、今後の例外について承認基準・有効期限・定期棚卸しのルールを定め、例外が増殖しない仕組みを作る。

Q4. サイバー保険にはすでに加入しているが、MFAの例外があると問題になるのか。

問題になり得る。2026年の引受条件厳格化では、VPN・リモートデスクトップ・SaaSすべてでのMFAと、管理者アカウントへのSMS以外の認証手段が求められており、更新時には新しい条件が適用されるのが一般的である。申告した整備状況と実態が食い違っていれば、引受審査の前提が崩れる。更新時期を待たず、申告内容と設定の実態を突き合わせて確認しておきたい。

MFAの例外運用は、設定画面を確認すればその日に発見できる一方、是正には認証方式の選定・緊急時手順の設計・例外管理ルールの整備が伴う。役員にも適用できる負担の小さい認証基盤の設計や、サイバー保険の要件と自社の実態の突き合わせから着手したい場合は、無料相談で現状の適用状況一覧を持ち込んでいただければ、例外ゼロまでの道筋を一緒に整理する。

出典