Salesforceには、顧客情報、商談情報、契約情報、営業活動の履歴など、企業にとって重要なデータが集約されています。
そのため、不正ログインによってアカウントが乗っ取られた場合、情報の閲覧や持ち出しだけでなく、データの変更・削除、不正な設定変更などにつながる可能性があります。
Salesforceアカウントを保護するうえで重要になるのが、多要素認証(MFA)です。
Salesforceでは、2022年2月1日から、対象製品へ画面からログインする内部ユーザーについて、MFAの利用が契約上の要件となっています。Salesforceへ直接ログインするユーザーだけでなく、外部のIDプロバイダー(IdP)を介してシングルサインオン(SSO)するユーザーも対象です。
Salesforceは、一般の従業員・内部ユーザーに対するMFAと、管理者を含む特権ユーザーに対するフィッシング耐性MFAについて、製品側で技術的に適用する更新を予定しています。
ただし、Salesforceは2026年7月1日に、これらの適用変更を一時保留すると案内しました。再開時期や今後のスケジュールは変更される可能性があるため、Salesforce公式情報で最新の状況を確認する必要があります。
また、適用再開後には、組織の移行状況に応じて延長措置が提供される場合があります。延長期間中は、特権ユーザーもSalesforce AuthenticatorやTOTP認証アプリなどの標準的なMFAを利用できることがあります。最新の適用状況や延長措置の有無は、Salesforce公式情報と自社組織の設定で確認する必要があります。
また、Salesforceで求められる認証方式は、すべてのユーザーで同じではありません。
一般ユーザーと管理者・特権ユーザーでは要件が異なるほか、Salesforceへ直接ログインする場合と、SSOを経由する場合でも確認すべきポイントが変わります。
本記事では、Salesforceの多要素認証について、必要となる理由、利用できる認証方式、パスキーやセキュリティキーの位置付け、SSO利用時の注意点、導入・運用時の確認事項を企業向けに解説します。
なお、本記事は2026年7月時点のSalesforce公式情報を基に作成しています。適用時期や対象範囲、設定項目は変更される可能性があるため、導入時にはSalesforce公式のセキュリティ関連製品更新情報もご確認ください。
MFAの基本や二要素認証、FIDO2、パスワードレス認証との違いについては、多要素認証(MFA)とは?二要素認証・パスワードレス認証・FIDO2との違いを解説でも詳しく紹介しています。

Salesforceの多要素認証(MFA)とは
多要素認証とは、異なる種類の認証情報を組み合わせて本人確認を行う認証方式です。
一般的な認証情報は、次の3種類に分類されます。
- パスワードやPINなど、本人だけが知っている「知識情報」
- スマートフォンやセキュリティキーなど、本人が持っている「所持情報」
- 指紋や顔など、本人の身体的な特徴を利用する「生体情報」
IDとパスワードだけでログインする場合、パスワードがフィッシングや使い回しなどによって漏えいすると、第三者が本人になりすましてログインする可能性があります。
Salesforceへ直接ログインする一般的なMFAでは、ユーザー名とパスワードに加えて、Salesforce Authenticator、TOTP認証アプリ、組み込みAuthenticator(パスキー)、物理セキュリティキーなどの本人確認方法を利用します。
これにより、パスワードだけに依存する認証よりも、不正ログインのリスクを下げやすくなります。
ただし、Salesforceで利用可能な方式であれば、すべてのユーザーに同じように適しているわけではありません。ユーザーが持つ権限やログイン経路を確認し、必要なセキュリティ水準を満たす認証方式を選定することが重要です。
SalesforceでMFAが必要な理由
Salesforceでは、営業、マーケティング、カスタマーサポート、システム管理など、複数の部門が同じプラットフォームを利用することがあります。
ユーザーの権限によっては、多数の顧客情報や商談情報を閲覧できるほか、組織全体の設定やアプリケーション、プログラムを変更できる場合もあります。
そのため、1つのアカウントが不正利用されるだけでも、影響が広範囲に及ぶ可能性があります。
特に注意したいのは、次のようなリスクです。
- フィッシングによるID・パスワードの窃取
- 複数サービスで使い回されたパスワードの悪用
- 退職者や異動者のアカウント、権限の残存
- 管理者アカウントの乗っ取り
- 私物端末や管理されていない端末からのアクセス
- 認証アプリを登録したスマートフォンの紛失
- SSOやIdPの設定不備による認証の弱体化
MFAを導入すると、パスワードが漏えいした場合でも、追加の本人確認を通過しなければログインできない構成にできます。
ただし、MFAを有効にするだけですべての攻撃を防げるわけではありません。
認証方式によってフィッシングへの強さが異なるため、特に重要な権限を持つユーザーには、フィッシング耐性のある認証方式を適用することが重要です。
SalesforceのMFA要件
Salesforceでは、2022年2月1日から、対象となるSalesforce製品へ画面からログインする内部ユーザーについて、MFAの利用が契約上の要件となっています。
この要件は、SalesforceへIDとパスワードを使って直接ログインする場合だけでなく、外部のIdPを利用してSSOでログインする場合にも関係します。
SSOを利用している場合は、IdP側でMFAを実施し、その認証結果をSalesforceが認識できる形で送信することで、Salesforceの要件へ対応できます。
IdP側から適切な認証情報を送信できない場合は、Salesforce側のMFAを利用する方法もあります。
Salesforceは、一般ユーザーへのMFAと、特権ユーザーへのフィッシング耐性MFAを製品側で技術的に適用する更新を予定しています。
ただし、2026年7月1日にこれらの適用変更が一時保留されました。再開時期や対象範囲は今後変更される可能性があるため、次のSalesforce公式情報で最新の状況を確認する必要があります。
ここで注意したいのが、一般ユーザーと管理者・特権ユーザーでは、求められる認証方式が異なる点です。
一般ユーザーに必要なMFA
特権権限を持たない一般の内部ユーザーには、標準的なMFAが求められます。
利用できる主な方式には、次のものがあります。
- Salesforce Authenticator
- 第三者のTOTP認証アプリ
- 組み込みAuthenticator(パスキー)
- WebAuthnに対応した物理セキュリティキー
一般ユーザーも、パスキーや物理セキュリティキーを利用できます。
Salesforceは、一般ユーザーについても、可能な場合は組み込みAuthenticator(パスキー)や物理セキュリティキーなど、フィッシング耐性のある認証方式を利用することを推奨しています。
管理者・特権ユーザーに必要なMFA
システム管理者など、重要な権限を持つユーザーには、原則としてフィッシング耐性のあるMFAが求められます。
Salesforceが特権ユーザーとして扱う主な対象は、次のいずれかに該当するユーザーです。
- システム管理者プロファイルを持つユーザー
- 「すべてのデータの編集」権限を持つユーザー
- 「すべてのデータの参照」権限を持つユーザー
- 「アプリケーションのカスタマイズ」権限を持つユーザー
- 「Apex開発」権限を持つユーザー
プロファイルだけでなく、権限セットなどを通じてこれらの権限を付与されているユーザーも確認対象になります。
Salesforceへ直接ログインする特権ユーザーには、組み込みAuthenticator(パスキー)またはWebAuthnに対応した物理セキュリティキーなど、フィッシング耐性のある認証方式が求められます。
Salesforce AuthenticatorやTOTP認証アプリは、一般ユーザー向けの標準的なMFAとして利用できますが、フィッシング耐性MFAの要件そのものは満たしません。
SSOを利用している場合は、IdP側でフィッシング耐性のあるMFAを実施し、その認証結果をSalesforceが認識できる形で送信する構成によって要件へ対応できます。
なお、Salesforceでは組織の移行状況に応じて、フィッシング耐性MFAの延長措置が付与される場合があります。
延長期間中は、特権ユーザーもSalesforce AuthenticatorやTOTP認証アプリなどの標準的なMFAを利用できることがあります。ただし、延長期間中もMFA自体は必要です。
延長措置の有無や期限は組織によって異なるため、Salesforceの設定画面と適用後のMFAに関する公式情報を確認する必要があります。
そのため、MFA導入時にはユーザー数だけでなく、各ユーザーが持つプロファイルや権限セット、Salesforceへのログイン経路、延長措置の有無まで確認することが重要です。

Salesforceで利用できる主なMFA方式
Salesforceでは、複数の本人確認方法を利用できます。
それぞれの特徴と適した利用場面を理解したうえで、自社の端末環境やユーザー権限に合った方式を選定することが重要です。
Salesforce Authenticator
Salesforce Authenticatorは、Salesforceが提供するモバイル向けの認証アプリです。
ログイン時にスマートフォンへ通知が届き、利用者が内容を確認して承認します。
画面に表示されたコードを毎回入力する必要がないため、一般ユーザーにとって比較的利用しやすい方式です。
一方で、端末の紛失や交換時には、再登録や復旧対応が必要になります。
また、特権ユーザーに求められるフィッシング耐性MFAの要件を満たす方式ではないため、対象ユーザーの権限と延長措置の有無を確認して利用する必要があります。
TOTP認証アプリ
TOTPは、一定時間ごとに変わるワンタイムコードを認証アプリで生成し、パスワードとあわせて入力する方式です。
Google AuthenticatorやMicrosoft Authenticatorなど、TOTPに対応した第三者の認証アプリを利用できます。
標準的なMFA要件への対応手段として利用できますが、フィッシング耐性のあるMFAには該当しません。
ユーザーがフィッシングサイトへワンタイムコードを入力した場合、そのコードを攻撃者に悪用される可能性があります。
そのため、TOTPはパスワードだけの認証より安全性を高められる一方、フィッシング耐性のある認証方式とは区別して考える必要があります。
組み込みAuthenticator(パスキー)
組み込みAuthenticatorとは、PCやスマートフォン、対応するパスワードマネージャーなどに搭載されたパスキーを利用する認証方式です。
Salesforceでは、Windows Hello、Touch ID、Face IDなどを利用してパスキーを登録できます。FIDO2・WebAuthnに対応したパスワードマネージャーやクラウドキーチェーンで管理されるパスキーを利用できる場合もあります。
パスキーでは、サービス側に登録された公開鍵と、端末や認証器側に保持された秘密鍵を使って認証します。
秘密鍵や生体情報そのものをSalesforceへ送信する仕組みではありません。
また、パスキーはログイン先の正規ドメインと結び付いて利用されるため、偽のログイン画面へ認証情報を入力させるフィッシング攻撃に強いという特徴があります。
Salesforceでは、パスキーは特権ユーザー向けのフィッシング耐性MFA要件を満たす認証方式として扱われています。
パスキーの仕組みについては、「パスキーとは?仕組みを分かりやすく解説|パスワードレス認証との違いも紹介」もあわせてご覧ください。
物理セキュリティキーとソフトウェアセキュリティキー
物理セキュリティキーは、USBやNFCなどを使ってPCやスマートフォンで利用する認証器です。
Salesforceでは、WebAuthn(FIDO2)に対応した物理セキュリティキーを、本人確認方法として登録できます。
セキュリティキーは、サービス側に登録された公開鍵と、認証器側に保持された秘密鍵を使って認証します。
認証情報が正規のログイン先と結び付いているため、フィッシング耐性のある認証を実現できます。
端末に組み込みAuthenticatorが搭載されていない場合や、管理者用の認証器を業務端末とは別に管理したい場合などに利用できます。
一方で、紛失、故障、持参忘れなどによってログインできなくなる可能性があるため、予備の認証手段や本人確認後の復旧方法もあわせて設計することが重要です。
また、USBなど追加の物理的なセキュリティキーを必要としないソフトウェアセキュリティキーがあります。WinMagicのMagicEndpoint FIDO Eazyは追加のハードウェアを必要とせず、既にPCにセキュリティチップとして組み込まれているTPMに秘密鍵を保持します。MagicEndpoint FIDO Eazy認証ソフトウェアはサービス側に登録された公開鍵とPCのTPMに保持された秘密鍵を使って認証します。ソフトウェアセキュリティキーでは物理セキュリティキーを必要としませんのでセキュリティキー紛失の心配がなくなります。

SalesforceのMFA方式を比較
Salesforceで利用する主な認証方式を整理すると、次のようになります。
| 認証方式 | 主な特徴 | 特権ユーザー向けのフィッシング耐性MFA要件 |
|---|---|---|
| Salesforce Authenticator | スマートフォンへの通知を確認して承認 | 満たさない |
| TOTP認証アプリ | 時間制限付きのワンタイムコードを入力 | 満たさない |
| 組み込みAuthenticator(パスキー) | Windows HelloやTouch IDなどを利用 | 満たす |
| 物理セキュリティキー ソフトウェアセキュリティキー |
WebAuthn対応のセキュリティキーを利用 | 満たす |
Salesforce Authenticatorと第三者のTOTP認証アプリは、標準的なMFAとして一般ユーザーの要件へ対応できます。
一方、Salesforceへ直接ログインする特権ユーザーには、原則として組み込みAuthenticator(パスキー)、物理セキュリティキーまたはソフトウェアセキュリティキーなど、フィッシング耐性のある認証方式が求められます。
SSOを利用している特権ユーザーについては、IdP側でフィッシング耐性のあるMFAを実施し、その認証結果をSalesforceへ適切に伝える構成も選択できます。
※フィッシング耐性MFAの延長措置が付与されている組織では、延長期間中に限り、特権ユーザーもSalesforce AuthenticatorやTOTP認証アプリなどの標準的なMFAを利用できる場合があります。
フィッシング耐性MFAとは
フィッシング耐性MFAとは、偽のログイン画面に誘導されても、認証情報を攻撃者に渡したり、別のサイトで再利用されたりしにくい認証方式です。
Salesforce AuthenticatorやTOTP認証アプリは、パスワードだけで認証する場合より安全性を高められます。
一方で、利用者が偽サイト上で承認操作を行ったり、ワンタイムコードを入力したりすると、攻撃者に悪用される可能性があります。
パスキー、物理セキュリティキー、ソフトウェアセキュリティキーは、認証情報が利用対象のサービスと結び付いているため、偽のドメインでは正規の認証が成立しにくい仕組みです。
そのため、Salesforceでは、システム管理者など影響範囲の大きい権限を持つユーザーに対して、フィッシング耐性のある方式を求めています。
ただし、フィッシング耐性MFAを導入しても、端末のマルウェア対策、権限管理、セッション管理、退職者アカウントの無効化などが不要になるわけではありません。
認証方式だけでなく、アカウントと端末を含む運用全体を整備する必要があります。
Salesforceでパスキーを利用するメリット
Salesforceでは、パスキーをMFAの本人確認方法として利用できるほか、管理者が機能を有効にすることで、パスキーを使ったパスワードレスログインも利用できます。
Salesforceのパスキーによるパスワードレスログインは、2026年4月に一般提供が開始されました。対象となる内部ユーザーは、登録済みの組み込みAuthenticatorまたはセキュリティキーを利用して、パスワードを入力せずにログインできます。
フィッシング対策を強化できる
パスキーは、登録先の正規サービスと結び付いて認証を行います。
そのため、偽のSalesforceログイン画面へ誘導された場合でも、正規の認証情報を攻撃者へ渡しにくくなります。
パスワード入力の負担を減らせる
パスワードレスログインを有効にした場合、ユーザーはWindows Hello、Touch ID、Face ID、セキュリティキーなどを使ってSalesforceへログインできます。
複雑なパスワードの記憶や入力を減らせるため、利便性の向上やパスワードリセット対応の削減も期待できます。
特権ユーザーのMFA要件に対応できる
パスキーは、Salesforceが特権ユーザーへ求めるフィッシング耐性MFAの方式として利用できます。
ただし、どの端末やパスワードマネージャーを利用可能にするか、端末交換時にどう復旧するかなど、企業としての運用ルールは別途必要です。
Salesforceでパスキーによるパスワードレスログインを利用する際は、管理者が機能を有効にし、利用者が組み込みAuthenticatorまたはセキュリティキーを登録する必要があります。
参考:Salesforce公式「パスキーを使用したパスワードレスログイン」

Salesforceへ直接ログインする場合の対応
Salesforceへユーザー名とパスワードなどを使って直接ログインする場合は、Salesforce側でMFAを設定します。
一般的な準備の流れは、次のとおりです。
- 対象ユーザーとログイン方法を確認する
- 特権ユーザーに該当するアカウントを洗い出す
- 利用可能にする本人確認方法を決める
- ユーザーへ認証器の登録方法を案内する
- 紛失・故障・端末交換時の復旧方法を整備する
- Sandboxや一部ユーザーで動作を確認する
- 適用後のログイン状況や問い合わせを確認する
特に管理者アカウントについては、Salesforce AuthenticatorやTOTP認証アプリのみでは、フィッシング耐性MFAの要件を満たしません。
延長措置が付与されている組織では一時的に標準的なMFAを利用できる場合がありますが、将来の適用に備えて、管理者や特権ユーザーがパスキー、物理セキュリティキーまたはソフトウェアセキュリティキーを登録できる環境を準備することが重要です。
また、主要な本人確認方法を利用できなくなった場合に備え、複数の認証方法や復旧手順を用意しておく必要があります。
SSOでSalesforceへログインする場合の対応
企業によっては、Salesforceへ直接ログインせず、外部のIdPを介したSSOを利用している場合があります。
SSO環境では、ユーザーがIdPへログインし、IdP側でMFAを完了した後、Salesforceへ認証結果を渡します。
SalesforceがIdP側で実施されたMFAを適切に認識できれば、Salesforce側で追加のMFAを求められない構成にできます。
そのためには、IdPからSalesforceへ、どの認証方式を使用したかを示すAMRまたはACR情報を送信する必要があります。
SAMLを利用するIdPではSAML応答に、OpenID Connectを利用するIdPではIDトークンに、AMRまたはACR情報を含めます。
特権ユーザーの場合は、IdP側でフィッシング耐性のあるMFAを実施したことを、Salesforceが認識できる構成が必要です。
認証情報が正しく渡されない場合には、次のような問題が起こる可能性があります。
- SSOでMFAを完了した後に、Salesforce側でも追加確認を求められる
- 端末の有効化を求められる
- Salesforce側のMFA検証方法の登録を求められる
- 想定した認証方式としてSalesforceに認識されない
SSOを利用している企業では、単に「IdP側でMFAを有効にした」という確認だけで終わらせず、Salesforce側で認証方式がどのように認識されているかまでテストすることが重要です。
また、SAMLやOpenID Connect、IdPの構成、Salesforce組織の設定によって必要な対応が異なるため、本番適用前に検証環境や対象ユーザーを限定して確認する必要があります。
参考:Salesforce公式「SSO IDプロバイダーのMFAサービスの使用」
SSOの基本的な仕組みについては、「シングルサインオン(SSO)とは?仕組みやメリットをご紹介」もあわせてご覧ください。
Salesforce MFA導入前に確認すべきこと
SalesforceのMFAを円滑に導入するためには、認証機能を有効にする前の準備が重要です。
対象ユーザーを確認する
Salesforceへ画面からログインする内部ユーザーを洗い出します。
利用頻度が低いアカウントや、退職者・異動者のアカウントが残っていないかも確認する必要があります。
なお、Experience Cloudサイトの外部ユーザーなど、MFA要件の適用範囲が異なるユーザーもいるため、内部ユーザーと外部ユーザーを分けて整理することが重要です。パスキーによるパスワードレスログインも、Salesforce組織の内部ユーザーを対象とする機能です。
特権ユーザーを確認する
システム管理者プロファイルだけでなく、権限セットを介して重要な権限が付与されているユーザーも確認します。
開発担当者や外部委託先が、特権ユーザーに該当する場合もあります。
ログイン経路を確認する
Salesforceへ直接ログインしているのか、SSOを経由しているのかを整理します。
複数のログイン経路が併存している場合は、それぞれでMFAが適切に機能するか確認する必要があります。
利用端末を確認する
Windows Hello、Touch ID、Face IDなどの組み込みAuthenticatorを利用できる端末があるか、物理セキュリティキーを配布するか、ソフトウェアセキュリティキーをインストールする必要があるかを確認します。
共有PC、仮想デスクトップ、スマートフォンを利用できない環境についても考慮が必要です。
複数のPCを使うユーザーについては、端末ごとの登録や、別の認証手段が必要になる場合があります。
復旧方法を決める
スマートフォンやPC、セキュリティキーの紛失・故障、端末交換が発生した場合の対応を決めます。
管理者が本人確認方法を解除・再登録する条件や手順、問い合わせ先も事前に整理しておくことが重要です。
ユーザーへ周知する
MFAの目的、登録方法、ログイン方法、端末変更時の対応をユーザーへ案内します。
十分な説明がないまま適用すると、ログインできないユーザーが増え、管理者への問い合わせが集中する可能性があります。
Salesforce MFAの運用で起こりやすい課題
MFAは有効化して終わりではありません。
導入後には、次のような運用課題が発生する可能性があります。
認証用端末を紛失した
スマートフォンやセキュリティキーを紛失すると、ユーザーがSalesforceへログインできなくなる可能性があります。
本人確認を行ったうえで、登録済みの認証手段を解除・再登録できる手順を整えておく必要があります。
PCやスマートフォンを交換した
端末交換によって、登録済みの組み込みAuthenticatorや認証アプリを利用できなくなる場合があります。
旧端末の登録解除と新端末への登録を、端末の返却・廃棄フローとあわせて管理することが重要です。
特権ユーザーが対応方式を登録していない
システム管理者がSalesforce AuthenticatorやTOTP認証アプリだけを利用している場合、フィッシング耐性MFAの要件を満たせません。
延長措置が付与されている期間は標準的なMFAを利用できる場合がありますが、延長終了後の運用に備えて、対象となる権限を事前に棚卸しし、パスキー、物理セキュリティキーまたはソフトウェアセキュリティキーを登録できる環境を整えておく必要があります。
SSOで追加の確認が発生する
IdP側でMFAを実施していても、Salesforceが認証方式を適切に認識できなければ、追加確認や端末の有効化を求められる可能性があります。
IdPから送信されるAMR・ACR情報と、Salesforce側のログイン結果を確認する必要があります。
退職者や異動者の登録情報が残る
退職や異動の際には、Salesforceのアカウントや権限だけでなく、登録されている認証器も含めて管理する必要があります。
アカウントの無効化、権限の削除、認証器の登録解除を一連の手続きとして整備することが重要です。

MagicEndpointによるSalesforce認証の強化
SalesforceのMFAを検討する際は、Salesforceが提供する認証方式に加えて、企業全体のパスワードレス認証やSSO環境との連携を検討する方法もあります。
WinMagicでは、企業向けのパスワードレス認証ソリューションとしてMagicEndpointを提供しています。
MagicEndpointを利用すれば、ソフトウェアセキュリティキーを使用してSalesforceのログイン画面に直接ログインすることも可能ですし、MagicEndpoint IdPを使用してSalesforceにSSOすることも可能です。
MagicEndpointは、ユーザーに代わってエンドポイントがリモートサービスの認証を行い、パスワードを使ったユーザーの認証操作を、フィッシングに強い認証へ置き換えるソリューションです。
MagicEndpointは、Windowsログオン、VPN、Microsoft 365、Salesforce、そのほかのFIDO、SAMLやOpenID Connectに対応したSaaSアプリケーションやサービスへの認証に対応しています。
Salesforceへのログインをパスワードレス化したい場合や、Windowsログオン、VPN、SaaSへの認証を一体的に強化したい場合は、MagicEndpointの活用も選択肢になります。
詳しくは、「MagicEndpoint製品ページ」をご覧ください。
リモート環境やSaaSを含む認証設計については、「リモートアクセスの認証強化とは?MFA・FIDO2・パスワードレスで安全な社外アクセスを実現する方法」でも詳しく解説しています。
Salesforceの認証強化やパスワードレス化をご検討中ですか?
Salesforceへの直接ログイン、MagicEndpoint IdPを利用したSSO、WindowsログオンやSaaSを含む認証設計についてご相談ください。
まとめ
Salesforceの多要素認証は、顧客情報や商談情報などの重要なデータを、不正ログインやアカウント乗っ取りから守るための重要な対策です。
Salesforceでは、対象製品へ画面からログインする内部ユーザーにMFAが契約上求められています。また、一般ユーザーへのMFAと特権ユーザーへのフィッシング耐性MFAを製品側で技術的に適用する更新も予定されていますが、2026年7月1日に適用変更が一時保留されました。今後の再開時期については、Salesforce公式情報を確認する必要があります。
一般ユーザーは、Salesforce Authenticator、TOTP認証アプリ、組み込みAuthenticator(パスキー)、物理セキュリティキー、ソフトウェアセキュリティキーなどを利用できます。
一方、Salesforceへ直接ログインするシステム管理者などの特権ユーザーには、原則としてパスキー、物理セキュリティキー、ソフトウェアセキュリティキーといった、フィッシング耐性のある方式が求められます。
フィッシング耐性MFAの延長措置が付与されている場合は、延長期間中に標準的なMFAを利用できることがありますが、将来の適用に備えてパスキー、物理セキュリティキー、ソフトウェアセキュリティキーを準備することが重要です。
SSOを利用している場合は、IdP側でMFAを実施するだけでなく、その認証方式をSalesforceが適切に認識できるように、必要なAMR・ACR情報を送信する必要があります。
導入時には、ユーザーと権限の棚卸し、ログイン経路の確認、認証方式の選定、端末紛失時の復旧手順、ユーザーへの周知まで含めて計画することが重要です。
Salesforceへのログイン認証をどのように強化すべきか、既存のSSO・IdP環境やWindowsログオンを含めて検討している場合は、MagicEndpointの活用も含めてご相談ください。