自社のSalesforce管理者は、いまSMSや認証アプリのコードでログインしていないだろうか。それはもうすぐ通用しなくなる。 Salesforceは2026年5月、セキュリティ強化として、特権ユーザーへの「フィッシング耐性MFA」必須化と、全従業員へのMFA強制化を公式に告知した。本番環境での適用は、特権ユーザーが2026年7月1日、全従業員が7月20日だ。重要なのは、SMSや認証アプリのワンタイムコード（TOTP）は「フィッシング耐性MFA」に該当しないため、特権ユーザーはパスキーやセキュリティキー等への移行が必要になる点だ。
本記事では、Salesforceを使う企業の情シス向けに、対象者の線引きと、締切に向けた準備の進め方を整理する。
この記事の要点
-
Salesforceは2026年5月5日付の公式情報で、MFAの強制化と、特権ユーザーへの「フィッシング耐性MFA（PRMFA）」必須化を告知（任意ではなく強制）。
-
適用日：特権ユーザーのPRMFA＝Sandbox 6/22・本番 7/1／全従業員のMFA＝Sandbox 6/22・本番 7/20。全従業員は「標準MFA」、特権ユーザーのみ「フィッシング耐性MFA」が必要。
-
特権ユーザーの定義は、システム管理者プロファイル、または「すべてのデータの編集／参照」「アプリケーションのカスタマイズ」「Apexの作成」のいずれかの権限を持つユーザー。
-
フィッシング耐性MFAに該当：パスキー、セキュリティキー（WebAuthn/FIDO2・YubiKey等）、内蔵認証（Touch ID／Face ID／Windows Hello）。SMSや認証アプリのTOTPは該当しない。
-
背景には、SaaS利用者を狙うソーシャルエンジニアリング（不正なコネクテッドアプリの認可・OAuthトークンの悪用等）がある。
何が、いつから変わるのか
Salesforceの公式情報（2026年5月5日付）によれば、変更点は2つの軸に分かれる。
| 対象 | 必要なMFA | Sandbox適用 | 本番適用 |
|---|---|---|---|
| 特権ユーザー | フィッシング耐性MFA（PRMFA） | 2026年6月22日 | 2026年7月1日 |
| 全従業員ユーザー | 標準MFA | 2026年6月22日 | 2026年7月20日 |
ポイントは、全従業員には「標準MFA」、特権ユーザーには一段強い「フィッシング耐性MFA」が求められることだ。そして、これは推奨ではなく強制である。Salesforceは設定を無効化できないようロックし、要件を満たさないユーザーはログイン時にブロックされるとしている。
なお、レポート操作に対するステップアップ認証など関連する変更もあるが、本記事では上記2つのMFA軸に絞る。
SECURITY OPERATION
日常の脆弱性運用、情シス1人で回せる体制にしませんか？
月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。
「特権ユーザー」とは誰か
自社の誰が7/1の対象になるのか。Salesforceの定義では、特権ユーザーは次のいずれかに該当する。
-
システム管理者プロファイルを持つユーザー
-
**すべてのデータの編集（Modify All Data）**権限
-
**すべてのデータの参照（View All Data）**権限
-
**アプリケーションのカスタマイズ（Customize Application）**権限
-
**Apexの作成（Author Apex）**権限
つまり、肩書きの「管理者」だけでなく、強い権限を持つ実務担当者も対象になりうる。まずは自社のSalesforceで、これらの権限を持つユーザーを棚卸しすることが第一歩だ。「誰が特権ユーザーか把握できていない」状態は、それ自体が権限管理上のリスクでもある。
フィッシング耐性MFAとは：SMS・認証アプリでは不十分
「フィッシング耐性MFA（Phishing-Resistant MFA）」とは、偽サイトに認証情報を入力させる中間者（AiTM）型のフィッシングに耐性を持つ認証方式を指す。Salesforceの整理では、次が該当する。
-
パスキー
-
セキュリティキー（WebAuthn/FIDO2・YubiKey等）
-
内蔵認証（Touch ID／Face ID／Windows Hello）
一方、次は特権ユーザーのフィッシング耐性MFA要件を満たさない。
-
SMS（弱い認証に分類）
-
認証アプリのワンタイムコード（TOTP）（Salesforce Authenticatorアプリ等も含め「標準MFA」に分類）
ここが見落とされやすい。「うちはもうMFAを入れているから大丈夫」と思っていても、それがSMSや認証アプリのコードなら、特権ユーザーは7/1までにパスキー等へ移行する必要がある。パスキー・セキュリティキーの配布と運用設計（紛失時の再発行、複数デバイス対応など）には準備期間が要る。認証基盤の考え方はIAM（Okta／Entra ID／Keycloak）とゼロトラスト・ゼロトラスト・セキュリティの実装ガイド（中小企業向け）が参考になる。
なぜ今、強制化なのか
この強制化の背景には、SaaS利用者を狙うソーシャルエンジニアリングの高度化がある。近年、攻撃者はMFAそのものを突破するのではなく、利用者をだまして不正なコネクテッドアプリを認可させ、OAuthトークンを乗っ取って大量のデータを持ち出す手口に移っている。電話を使った音声フィッシング（ビッシング）による標的型の事例も、セキュリティ各社から報告されている（攻撃者の特定や手口の詳細は各社の報告に基づくもので、Salesforce公式の断定ではない）。
つまり、MFAの「強さ」と「正しい運用」が、SaaS時代の侵害対策の要になっている。これはSalesforceに限らず、自社が使う主要SaaS全般に通じる論点だ。複数SaaSの認証を束ねるSSO/IdP統合の考え方はSSO・IdP統合（中堅企業向け）で扱っている。
7/1までに、特権ユーザーのパスキー移行は間に合いますか
GXOでは、SalesforceをはじめとするSaaSの認証強化（特権ユーザーの棚卸し、パスキー・セキュリティキーの導入設計、SSO/IdP統合）を支援しています。「誰が特権ユーザーかも把握できていない」段階のご相談を歓迎します。
※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK
実務判断のポイント
この記事を読むべきなのは、経営者、営業責任者、CS責任者、マーケ責任者、情シスです。単に情報を把握するだけでなく、CRM再設計、営業AI支援、FAQ/RAG、SaaS棚卸し、KPI設計の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。Salesforce、特権ユーザーのMFA強制化が7/1本番適用｜パスキー対応の締切と準備に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
営業DXやCS改善はツール導入ではなく、商談化条件、データ定義、運用KPI、現場入力負荷を整えることが先である。
GXOは既存SaaSを活かしながら、CRM/FAQ/AI/業務フローを接続する方が投資対効果を出しやすいと見る。
GXOが提供できる価値は、CRM、SaaS連携、FAQ/RAG、営業・CS業務改善を横断して支援できる。 ことです。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、CRM改善、CS自動化、SaaS連携開発、運用改善へ接続。さらに、既存SaaSを活かす設計で開発リスクを抑え、継続改善にする。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問（FAQ）
Q1. 締切はいつですか？
本番環境では、特権ユーザーのフィッシング耐性MFAが2026年7月1日、全従業員のMFAが7月20日に適用されます（Sandboxはいずれも6月22日）。要件を満たさないユーザーはログイン時にブロックされるとされているため、それまでに準備を完了する必要があります。
Q2. 今のSMS認証や認証アプリではダメなのですか？
全従業員向けの「標準MFA」としては有効ですが、特権ユーザーに求められる「フィッシング耐性MFA」には該当しません。特権ユーザーは、パスキー、セキュリティキー（WebAuthn/FIDO2）、内蔵認証（Touch ID／Face ID／Windows Hello）のいずれかへ移行する必要があります。
Q3. 自社の特権ユーザーをどう特定すればよいですか？
システム管理者プロファイル、または「すべてのデータの編集／参照」「アプリケーションのカスタマイズ」「Apexの作成」のいずれかの権限を持つユーザーが対象です。Salesforceの権限設定から該当ユーザーを棚卸ししてください。この機会に過剰な権限付与を見直すと、セキュリティと運用の両面で効果があります。
Q4. パスキー導入で気をつけることは？
デバイス紛失時の再発行手順、複数デバイス対応、入社・退職時の運用などを設計しておく必要があります。場当たり的に配布すると、ログインできない・サポート負荷が増えるといった問題が起きます。SSO/IdPと組み合わせて、他のSaaSも含めた認証基盤として設計するのが望ましいです。
まとめ：MFAは「入れた」より「正しく運用できている」かが問われる
Salesforceの2026年のMFA強制化は、SaaS時代のセキュリティが「MFAを入れたか」から「フィッシングに耐える方式で、正しく運用できているか」へ移っていることを示している。特権ユーザーは7/1、全従業員は7/20が本番適用の締切だ。まずは自社の特権ユーザーを棚卸しし、SMS・認証アプリからパスキー・セキュリティキーへの移行を計画したい。
これはSalesforceに限らず、自社が使う主要SaaS全般に通じる課題でもある。GXOは、特権ユーザーの棚卸しから、パスキー導入設計、SSO/IdP統合まで支援している。詳細はセキュリティ運用伴走・セキュリティ事業をご覧いただきたい。
SaaS認証、締切前に「現在地」を点検しませんか
特権ユーザーの棚卸し、パスキー・セキュリティキーの導入設計、複数SaaSのSSO/IdP統合まで、貴社の運用に合わせて整理します。Salesforceの7/1締切を起点に、認証全体を見直す好機です。
参考情報
-
Salesforce公式「Phishing-Resistant MFA for Privileged Users」（2026年5月5日公開。特権ユーザーのPRMFA必須化：Sandbox 6/22・本番 7/1。特権ユーザー定義／対応する認証方式）：https://help.salesforce.com/s/articleView?id=005321563&type=1
-
Salesforce公式「MFA Enforcement for All Employee Users」（全従業員のMFA強制化：Sandbox 6/22・本番 7/20）：https://help.salesforce.com/s/articleView?id=005321561&type=1
-
※ 攻撃者の特定（UNC6040／ShinyHunters等）や音声フィッシング（ビッシング）の手口に関する記述は、セキュリティ各社の報告に基づく二次情報であり、Salesforce公式の断定ではない。最新・正確な適用条件は上記Salesforce公式ページで確認のこと。
