🙋 はじめに
Salesforceを使っていて、ログイン画面の認証まわりの設定を、なんとなく「推奨だから」で済ませていないでしょうか。
私もそうでした。あるとき「2026年から、管理者などはフィッシング耐性のあるMFAが必須になる」という話を聞き、最初は「フィッシング耐性MFA…？ いつものMFAと何が違うんだろう」という状態でした。
調べてみると、話はそれほど複雑ではありません。ポイントは「MFAならどれでも安全、ではない」という点です。そして、何が安全で何が足りないのかは、認証の強さを定めた世界的な基準であるNISTのガイドラインと並べると、整理できました。
この記事では、Salesforceの2026年の変更点と、その背景にあるNISTの考え方を、できるだけ専門用語を避けてまとめます。私自身の調べものの備忘録なので、同じように「結局どう備えればいいの？」と思った方の役に立てばと思います。
なお本記事は、2026年7月中旬時点で確認した公開情報にもとづく実設定体験のまとめです。適用日は後述のとおり一度改定されており、今後も変わる可能性があるため、運用前には必ずSalesforce公式の通知を確認してください。
🎯 要点（先に結論）
- 2026年6〜7月から、Salesforceは管理者などの特権ユーザーに「フィッシング耐性MFA」を順次必須化します。未登録だとログインできなくなります。
- フィッシング耐性MFAとは、偽サイトに誘導されても突破されない認証のことです。具体的にはパスキーか、物理セキュリティキー（YubiKeyなど）が該当します。
- 認証の強さを表すNISTの基準でいうと、同期パスキーはAAL2、物理キーはAAL3です。フィッシング耐性はどちらも満たします。
- なので、Salesforce対応だけが目的なら、同期パスキー（AAL2）で十分です。全員にYubiKey（AAL3）を配る必要はありません。
🏛️ そもそもNISTって何？
まず、今回のキーワードになるNISTに軽く触れておきます。
NIST（米国国立標準技術研究所）は、アメリカの政府機関です。計測やIT、セキュリティといった幅広い分野で「標準」や「ガイドライン」を作っているところ、とイメージしてもらえれば十分です。
セキュリティの世界では、NISTが出した文書が事実上の世界基準になることがよくあります。今回関係するのは、本人確認とログイン認証のルールをまとめたSP 800-63シリーズです。元はアメリカ政府機関向けですが、内容がしっかりしているので、民間企業も自社のセキュリティ設計のものさしとして広く参考にしています。
このシリーズの最新版が、2025年7月に最終版が公開されたSP 800-63-4です。旧版の63-3を置き換えるもので、この記事ではこの最新版を基準に話を進めます。
🔐 MFAと「フィッシング耐性」
MFAのおさらい
MFA（多要素認証）は、パスワードだけでなく「もう1つの要素」を組み合わせてログインする仕組みです。スマホに届く確認コードや、認証アプリの承認ボタンなどがよく使われています。パスワードが盗まれても、もう1つの要素がないとログインできないので安全、という考え方です。
MFAなら何でも安全、とは限らない
ところが、MFAの種類によっては突破されてしまうことが分かってきました。狙われるのはフィッシングです。フィッシングとは、本物そっくりの偽サイトに誘導して、入力した情報をだまし取る攻撃を指します。
確認コードや承認ボタンには、共通した弱点があります。どちらも「コード」や「承認」という、人が手で中継できてしまう情報をやり取りしている点です。攻撃者は本物そっくりの偽サイトを用意し、利用者が入力したパスワードもコードも、その場で本物のサイトへ横流しできてしまいます。
コード方式は、利用者と本物のサイトのあいだに偽サイトをはさむ攻撃に弱い、ということです。
フィッシング耐性MFAとは
一方、パスキーや物理セキュリティキー（YubiKeyなど）は、認証するときに「いまアクセスしているサイトのアドレス（ドメイン）」が本物かどうかを自動でチェックします。偽サイトは本物とアドレスが違うため、そもそも認証情報が渡されず、攻撃が成立しません。
偽サイトに誘導されても突破されない性質を持つMFAを、フィッシング耐性MFAと呼びます。Salesforceが今回求めているのは、この性質をもつMFAです。
🪪 認証の強さ：AAL2とAAL3
ここからが認証の強さの話です。
NISTは認証の信頼度をAAL（認証の保証レベル）という段階で表します。数字が大きいほど厳しく、上のレベルは下のレベルの条件をすべて含みます。今回関係するのはAAL2とAAL3です。
ここで一番大事なのは、同じパスキーでも「鍵を持ち出せるかどうか」でレベルが変わる点です。
同期パスキーは、スマホやPC、クラウド（iCloudキーチェーンやパスワードマネージャーなど）にコピー・同期されるタイプです。複数の端末で同じ鍵が使えて便利で、Touch IDやWindows Helloで使うものの多くがこれにあたります。
物理キーは、YubiKeyのように1個の機器の中に鍵が閉じていて、外に取り出せないタイプです。
この「鍵を同期して持ち出せるか、1個の機器に固定されているか」が、AAL2とAAL3を分ける境目になります。
| 観点 | AAL2 | AAL3 |
|---|---|---|
| 要求 | 2要素。フィッシング耐性の選択肢を用意していること | フィッシング耐性に加え、持ち出せない鍵が必須 |
| 鍵の持ち出し | コピー・同期できる | できない（機器の中に固定） |
| 該当する方式 | 同期パスキー | 物理キー、取り出せないパスキー |
| 代表例 | Touch ID、Windows Hello、iCloudキーチェーン | YubiKeyなどのFIDO2キー、ICカード（PIV） |
☁️ Salesforceが求めているもの
本題のSalesforceに戻ります。
2026年に強制されること
Salesforceは2026年、これまで「推奨」だったセキュリティ設定を、順番に「強制」へ切り替えていきます。認証まわりは大きく2段階に分かれます。
| 要件 | 対象 | Sandbox | 本番 |
|---|---|---|---|
| 全従業員ユーザーのMFA必須化 | 組織内の全ユーザー | 2026/7/6に再開（当初6/22） | 2026/7/20（段階適用） |
| 特権ユーザーのフィッシング耐性MFA必須化 | 管理者など特権ユーザー | 2026/6/22 | 2026/7/1（適用済み） |
このうち全従業員向けのMFA必須化は、いったん停止され、日程が組み直されました。
原因は登録フローの不具合で、すでにセキュリティキーを登録済みのユーザーが新しいキーの登録を重ねて求められる、というものです。Sandboxは当初の6月22日から7月6日に再開し、本番は7月20日を維持しつつ、より緩やかな段階適用に変わりました。
特権ユーザーのフィッシング耐性MFAは停止されず、本番で予定どおり2026年7月1日に適用されました。
なお本番の段階適用は環境ごとに順次進み、リリースグループによっては9月初旬まで続きます。ログインできているからといって、自分の環境がまだ適用前という可能性がある点に注意してください。日程は今後も動く可能性があるため、運用前にはSalesforce公式のヘルプ記事で最新を確認してください（巻末の参考（出典）参照）。
この記事のテーマは特権ユーザーのほうです。要点は次のとおりです。
対象は、「システム管理者」プロファイル、または「すべてのデータの編集」「すべてのデータの参照」「アプリケーションのカスタマイズ」「Apex 作成者」のいずれかの権限を持つユーザーです。
登録できる方式は、組み込み Authenticator（Windows Hello、Touch ID、Face ID）か物理セキュリティキー（YubiKey など）で、強制後は設定がロックされ、未登録の特権ユーザーはログイン画面でブロックされます。フィッシングでログインやセッションを奪う攻撃が実際に観測されていることが背景です。
SalesforceとNISTを重ねてみる
「Salesforceが求めているのはAAL3なのか」を整理します。答えはNoです。Salesforceが求めているのは「フィッシング耐性」という性質であって、それはAAL2（同期パスキー）でも満たせます。
Salesforceが許可する2つの方式をAALに当てはめると、以下のようになります。
実務上は、Salesforce対応だけが目的なら同期パスキー（AAL2）で十分です。全員に物理キーを配る必要はありません。
ただし、AAL2とAAL3には「鍵を持ち出せるか」という本質的な差があります。もっと厳しい基準を別途課されている組織なら、特権アカウントには物理キー（AAL3）を選ぶ判断になります。現実的には、通常は同期パスキー（AAL2）、特権用や緊急用に物理キー（AAL3）を併用する構成が、バランスが良いと思います。
「フィッシング耐性MFAを要求された」と聞くと、つい物理キー一択かと身構えてしまいます。けれど、求められている性質（フィッシング耐性）と、保証レベル（AAL）は分けて考える。これが今回の一番の学びでした。
🧩 まず、自分のPCが対応しているか確認する
ここまでで、Windows Hello（組み込み Authenticator）がフィッシング耐性MFAの条件を満たすことが分かりました。ただし使うには、PCがWindows Helloに対応し、TPMという部品が載っている必要があります。登録の前に、自分のPCで使えるかを2ステップで確認しておきましょう。Windowsユーザーなら数分で済みます。
① Windows Hello が使えるか
「設定 > アカウント > サインイン オプション」を開き、「顔認識」「指紋認識」「PIN」の表示を確認します。
私のPCでは、顔認識・指紋認識・PIN、さらにセキュリティキーまで、いずれも利用可能でした（図1）。
図1：設定 > アカウント > サインイン オプション。顔認識・指紋認識・PIN（いずれも Windows Hello）が利用可能。
生体認証の項目に「このデバイスにはWindows Hello対応のカメラ／指紋センサーがありません」と出る場合は、顔や指紋は使えません。その場合もPINで対応できます。PINもWindows Helloの一種で、次のTPMと結びついて鍵を守る仕組みです。
② TPM 2.0 を確認する（最重要）
TPMは、PCの中で鍵を安全に保管する、小さな金庫のような部品です。Windows HelloやパスキーはこのTPMに鍵を預けるので、ここが対応していないと使えません。
「Win + R」を押し、「tpm.msc」と入力して Enter を押します。
私のPCでは「TPMは使用する準備ができています」と表示され、仕様バージョンは2.0でした（図2）。この仕様バージョンが2.0であればOKです。
図2：tpm.msc の画面。状態が「使用する準備ができています」、仕様バージョンが 2.0。
「互換性のあるTPMが見つかりません」と出る場合は、要件を満たしていません。BIOS/UEFIでTPMが無効になっているだけのこともあるので、設定を確認するか、情シスや管理者に相談しましょう。
⚠️注意：①でPINだけが表示されて生体が出ない場合でも、②のTPMが2.0なら、PIN（Windows Hello）はフィッシング耐性MFAとして使えます。顔や指紋のセンサーがないPCでも諦める必要はありません。
🧪 実際にやってみた：結局、Google パスワードマネージャーで済んだ
ここからは実体験です。2026年7月14日、久しぶりにSalesforceのSandboxにログインしたところ、いつものホーム画面ではなく「Create a Passkey」という見慣れない画面が出てきました。特権ユーザーのフィッシング耐性MFAが、この環境ではすでに強制に切り替わっていたのです。前節でWindows HelloとTPMを確認していたので、てっきりWindows Helloの指紋認証で登録するものと思っていました。ところが実際の流れは、拍子抜けするくらい簡単でした。翌7月15日に登録を済ませたので、そのときの手順を残しておきます。
まず、パスキー作成画面です。「Your account requires a passkey for enhanced security.（セキュリティ強化のため、アカウントにはパスキーが必要です）」と表示されていました。下部の「Create Passkey」ボタンを押します。別の方式を選び直したいときは「やり直し」から戻れます。
ボタンを押すと、予想していたWindows Helloのダイアログではなく、ブラウザ（Chrome）が出す Google パスワードマネージャーの保存ダイアログが開きました。「このパスキーを使用してどのデバイスでもすばやくログインできます。パスキーは（対象ドメイン）の Google パスワードマネージャーに保存されます」とあります。保存先のGoogleアカウントを確認して「作成」を押します。Windows Hello などの組み込み Authenticator や物理キーを使いたい場合は、ここで「別の方法で保存」を選びます。
続いて「リカバリ PIN の作成」画面が出ます。このPINを設定しておくと、別のデバイスからでも保存済みのパスキーにアクセスできます。6桁のPINを入力して「確認」を押します。桁数は「PIN のオプション」から変更できます。このPINは再ログインや別端末からのアクセスで必要になるので、忘れないよう控えておきます。
これでホーム画面に戻り、右上に「パスキーを保存し、PIN を作成しました」と表示されれば登録完了です。保存したパスキーは Google パスワードマネージャーからいつでも確認や管理ができます。
動作確認として、一度ログアウトしてから入り直しました。パスキーでのログインがそのまま通り、問題ありませんでした。
結局、前節で念入りに確認したWindows HelloもTPMも、この登録では出番がありませんでした。ブラウザがGoogleパスワードマネージャーでの作成を提案し、それで完了したからです。ここで作られたのは複数の端末に同期されるパスキー、つまり本記事でいうAAL2にあたります。物理キー（AAL3）ではありませんが、フィッシング耐性は満たしているので、Salesforceの要件はこれでクリアできます。フィッシング耐性MFAと身構えたわりに、実態はブラウザの案内に沿ってボタンを何回か押すだけでした。
ただし、保存先には一つ注意があります。今回のパスキーはGoogleアカウントに紐づいて同期されます。会社の端末やアカウントの運用方針によっては、個人のGoogleアカウントに業務システムのパスキーを保存してよいか、事前に確認しておいたほうが安全です。組織の方針しだいでは、Windows Hello（端末内のTPMに鍵を持つ方式）や、指定したパスワードマネージャーを選ぶことになります。その意味でも、前節のTPM確認は無駄にはなりません。
✅ まとめ
- Salesforceは2026年6〜7月から、特権ユーザーにフィッシング耐性MFAを順次強制します（本番の段階適用は9月初旬まで）。未登録だとログインできなくなります。
- フィッシング耐性は方式の性質です。確認コードやプッシュは不可で、パスキーや物理キーが該当します。
- NIST SP 800-63-4では、同期パスキーがAAL2、物理キーがAAL3です。フィッシング耐性はどちらも満たします。
- だから、Salesforce対応だけならAAL2（同期パスキー）で足ります。AAL3が要るかどうかは、別の基準で判断しましょう。
- 設計のコツは、求められている性質（フィッシング耐性）と、保証レベル（AAL）を分けて考えることです。
👋 おわりに
フィッシング耐性とAALを分けて捉えると、ずいぶん整理しやすくなります。
本番の適用は9月初旬にかけて順次進むので、すでに済んだ環境もあれば、これからという環境もあるかと思います。
普段あまりログインしないシステム管理者が久しぶりに入って、突然パスキーの登録画面に出くわす、という私のようなケースはしばらく続くかもしれません。同じように面食らった方が本記事にたどり着いて、参考になってくれれば幸いです。
🔗 参考（出典）
- Salesforce: MFA for Salesforce（日本語）— https://security.salesforce.com/ja/mfa/
- Salesforce Admins Blog: Prepare Your Org for Salesforce MFA Enforcement（2026/7/6更新。適用日程の最新情報）— https://admin.salesforce.com/blog/2026/prepare-your-org-for-salesforce-mfa-enforcement
- Salesforce Help: Prepare for Phishing-Resistant MFA Enforcement for Privileged Users including Admins（記事ID 005321563）— https://help.salesforce.com/s/articleView?id=005321563&language=ja&type=1
- Salesforce Help: Prepare for MFA Enforcement for All Employee Users（記事ID 005321561）— https://help.salesforce.com/s/articleView?id=005321561&language=ja&type=1
- NIST SP 800-63B-4（デジタルアイデンティティガイドライン：認証）— https://pages.nist.gov/800-63-4/sp800-63b.html
- softwareinsights「Salesforce MFA Enforcement Update: Revised 2026 Dates」（適用日の改定・一時停止の解説）— https://www.softwareinsights.dev/posts/salesforce-mfa-enforcement-paused-revised-dates-2026
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。