SSOログインにおけるデバイスの有効化（Device Activation）の変更

お客様環境を保護するために、当社が実践する継続的なセキュリティ強化の取り組みの一環として、Salesforceは特定のシングルサインオン（SSO）ユーザーログインに対して、デバイスの有効化（Device Activation）を実施いたします。この強化は、不正なアカウントアクセスをさらに制限し、以前強化された非SSOログインユーザーに対しデバイスの有効化を適用したセキュリティ更新に加えて実施されるものです。（詳細については、こちらの記事をご参照ください） 

間もなく実施される変更点 

2026年1月26日（2026年1月20日から変更）より、Salesforceは、強力なセキュリティ対策を実装していない特定のシングルサインオン（SSO）ログインに対してデバイスの有効化を要求する変更をSSO IDプロバイダー（IdP）に段階的に適用し始めます。2026年2月9日（2026年2月3日から変更） より、SalesforceはSAML IdPに対して「デバイスの有効化」を必須とする変更のリリースを開始しました。OIDC および SAML SSO ID プロバイダーの両方に対する変更は、現在有効（適用済み）です。 詳細については、以下の「今後の変更予定」のセクションをご参照ください。  

以下のセキュリティ対策（セキュア認証と見なされるもの）のいずれかが実施されていない限り、SSOログインではデバイスの有効化が必要になります。

シングルサインオン（SSO）ログイン認証強化を実施する理由：

Salesforceは、アカウント乗っ取り（ATO）および不正アクセスに対する保護を強化するための先見的なセキュリティ対策として、SSO認証の検証強化（AMR値の確認等）の変更を実施しています。今回のSSO認証検証の更新は、追加の本人確認プロセスを義務付けることによって、より安全なログイン体験を提供します。この追加されたセキュリティ強化策は、シングルサインオン（SSO）ID プロバイダー（IdP）が安全な認証を欠いている場合、または既存のセキュリティ制御が現在の脅威を緩和するのに十分な堅牢さを備えていない可能性がある場合に適用されます。

Summer '25 リリースでの変更内容

今までの状況を記載すると、Summer '25 リリースでは、特定の状況下でユーザーに本人確認を促すための「デバイスの有効化」ステップが導入されました。これらの以前の変更では、シングルサインオン（SSO）ログインは明確に除外されていました。

• 2025年9月初旬：ユーザーが信頼済みIP範囲からSalesforceにアクセスする場合であっても、非収益組織に対してデバイスの有効化が要求されるようになりました。 

• 2025年10月末：一部の本番組織および Sandbox 組織のユーザーに対してデバイスの有効化が要求されるようになりました。組織レベルのネットワークアクセス設定、またはプロファイルレベルのログインIP範囲のいずれかにおいて、過度に広いIPアドレス設定でログインが行われる場合にも、デバイスの有効化が強制されます。

今後の変更予定

シングルサインオン（SSO）ログインにおけるデバイスの有効化の変更は、現在有効（適用済み）です。以下のスケジュールは、各変更のリリースがいつ開始されたかの詳細を示すための参考として記載します。

2026年2月17日のリリースで予定されている変更内容

2026年2月17日、Salesforceはプロトコル間の整合性を高め、不要なログイン時の検証を削減するため、シングルサインオン（SSO）シグナルの処理方法を更新します。

• OIDC AMRにおける「mfa」値のサポート： OIDCのAMRにて「mfa」値が渡された際、これを独立した強力なシグナルとして認識し、デバイスの有効化をスキップできるようになります。これにより、OIDCログインの挙動がSAMLと統一されます。

• OIDC認証コンテキストのサポート： 非標準またはカスタムのOIDCプロバイダーによる複雑な統合をより適切に処理するため、OIDCにおけるAuthnContext（またはACR：認証コンテキストクラス参照）シグナルの評価機能が有効化されます。

• IDPとしてのSalesforceによるAMRの発行： Salesforceが ID プロバイダー（IdP）として機能する際、安全な認証方法が使用されたかどうかを評価ロジックで判断できるよう、AMRシグナルを発行するようになります。

デバイスの有効化をスキップするために、SAML SSO ID プロバイダーとしてのSalesforceが発行する安全な認証値は以下の通りです：

• • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform

  • LightningLogin

  • Passkey

注：Salesforceが サービスプロバイダー（SP）としてSSOプロバイダーにAMRを「要求」するという以前の計画は中止されました。主要なプロバイダーの多くはデフォルトでこれらのシグナルを返すため、SalesforceからのAuthRequest（認証リクエスト）は不要であると判断されました。

ご利用のSingle-Sign-On (SSO)が安全な認証方式であるかの判定方法

Salesforceは、SSO の ID プロバイダー（IdP）から提供されるアイデンティティシグナルを検査することで、SSOログインの強度を評価します。Salesforceでは、OIDCおよびSAMLの両プロトコルにおいて、強固な認証シグナルを認識する評価ロジックを使用しています。

評価プロセス： Salesforceは、SSOレスポンス内に特定の認証シグナルが含まれているかを確認します。これらのシグナルが存在し、かつ安全であると認識された場合、ユーザーは「デバイスの有効化」の手順をスキップできます。

• OIDCの場合： Salesforceは、IDトークンから Authentication Method Reference (AMR)を読み取ります。2026年2月17日から、SalesforceはOIDCの認証コンテキスト、または認証コンテキストクラス参照（ACR）シグナルの評価も行うようになります。 

• SAMLの場合： Salesforceは、標準的な認証コンテキスト（AuthnContext）を読み取るか、あるいは具体的に「AMR」または「authnmethodsreferences」という名前の属性を探します。

相互運用性： 評価ロジックはプロトコルをまたいで機能します。OIDCにおいて「強固」と認識される値（例：face, pop, hwk）は、SAMLのAMR属性内で渡された場合でも受け入れられます。同様に、SAMLの標準的な強固な値（例：Smartcard, TimeSyncToken）も、両方のプロトコルで認識されます。

部分一致判定： 評価においては、提供された値の中に、Salesforceが定義する安全な認証方式のリストと一致する文字列が含まれているかを確認します。この処理では SAML は大文字と小文字を区別しません。OIDC クレームの場合は、値の大文字と小文字を区別します。 

検証不能な場合： これらの値が省略されている場合、またはIdPが「Unspecified（未指定）」のような値を送信した場合、Salesforceはログインの強度を検証できません。その結果、ユーザーには「デバイスの有効化」を完了するよう求めるプロンプトが表示されます。

Salesforceが安全な認証であると見なすシングルサインオン（SSO）ID プロバイダー（IdP）からの情報

Salesforceは、OIDCまたは SAML IdPについては AMR（Authentication Method Reference）から、SAML IdP については 認証コンテキスト または AuthnContext から読み取られる以下のものを、安全な認証方法であると定義しています。これらの方法が使用され、SSO IdP から値が返された場合、Salesforce でのデバイスの有効化はスキップされます。

1. Authentication Method Reference (AMR) (OIDC  または SAML IdPの場合): 安全な認証とみなされるAMR 値 ( RFC 8176 で規定):

   • face (顔認証)

   • fpt (指紋認証)

   • hwk (ハードウェアベースのセキュリティキー)

   • iris (虹彩認証)

   • mfa (多要素認証) [以下の※更新情報を参照ください] 

   • retina (網膜認証)

   • sc (スマートカード)

   • pop (鍵の所有証明：Proof-of-possession of a key)

   • swk (ソフトウェアベースのセキュリティキー)

他の IdP からのカスタムクレーム:

• • multipleauthn

• • Okta_verify

※更新情報：2026年2月17日付で、OIDCログインにおいて「mfa」が独立したAMRシグナルとして承認され、デバイスの有効化のスキップが可能になります。なお、SAML AMRにおける「mfa」によるデバイスの有効化のスキップについては、2026年2月9日より引き続き適用されます。 

2. Authentication Context（認証コンテキスト） または AuthnContext（SAML IdPの場合）：
   

   • 安全な認証とみなされる AuthnContext 値:

     SAML 標準値:

     • MobileTwoFactorContract

     • PublicKey

     • PGP

     • Smartcard

     • TimeSyncToken 

     • PKI

     他の IdP からのカスタムクレーム:

     • Mfa

     • Fido

     • multipleauthn

     注記： 「x.509」、「Certificate-based」、および「otp」という値は、デバイスの有効化をスキップする条件としては認められません。これらの方式は以前、誤って本ナレッジ記事に記載されていましたが、強固な認証に関する業界標準に準拠するため削除されました。

     SSOが AMR または AuthnContext において「x.509」、「Certificate-based」、あるいは「otp」の値を返した場合、Salesforceはデバイスの有効化を要求します。ただし、他に安全な AMR / AuthnContext 値が渡されている場合、またはその他のセキュリティ対策（信頼済みIPアドレスの範囲指定や、以前に有効化済みのデバイスであることなど）が存在する場合はその限りではありません。 

下記の表は、本番組織および Sandbox 組織におけるシングルサインオン（SSO）ログインおよび非SSOログインにおいて、いつデバイスの有効化のための検証コードを入力しなければならないかの概要を示しています。

その他の組み合わせの場合では、デバイスの有効化はユーザーに確認コードの入力を求めません。

*1 強力な認証などの他の条件が満たされない限り、ログイン IP アドレスが許可されている場合でも、プロファイルのログイン IP 範囲またはネットワーク設定の信頼済み IP 範囲が制限を超えているときは、デバイスの有効化が要求されます。ユーザーのプロファイルレベルで設定された信頼済み範囲外の IP アドレスからのログインは、引き続きブロックされます。

*2 Salesforce MFAを利用する場合、SSOログイン時のデバイスの有効化は不要となります。参考：SSO (Salesforce 組織) での Salesforce MFA の使用 

デバイスの有効化（Device Activation）とは 

デバイスの有効化（Device Activation）は、信頼されたIP範囲外、または認識されていないブラウザ、デバイスからログインする際、ユーザーに本人確認を求めるセキュリティ機能です。

メール認証は、ほとんどのユーザーにとって主要な認証方法となります。ログイン時には、ユーザーのメールアドレス宛に送信される認証コードによる確認が必要となります。ユーザーがより強力な認証方法（Salesforce Authenticator、サードパーティ製認証アプリ、セキュリティキー、組み込み認証アプリ、SMS認証）を登録されている場合、メールへのコード送信に代わり、そのより強力な認証方法が使用されます。

デバイスの有効化のプロセスにおいて、「次回からは確認しない」および「ログイン情報を保存する」チェックボックスはどのように機能しますか？

検証コードを求めるデバイスの有効化の要求を実行する際、「次回からは確認しない」チェックボックスをクリックすると、デバイスの有効化 Cookie である sfdc_lv2 プラットフォーム Cookie が設定されます。

sfdc_lv2 プラットフォーム Cookie は、ユーザーのデバイスの有効化の内容を保存します。この Cookie が有効である限り、ユーザーはログインのたびにデバイスの有効化を実施するように求められることはありません。Cookie が設定されていない、または有効期限切れの場合、ユーザーは次回のログイン時に本人確認を行う必要があります。Cookie の有効期間は1年間です。 

注意：シークレットモードやプライベートブラウジングモード、あるいはブラウザを閉じた際にCookieを自動的に削除する設定を使用している場合、「次回からは確認しない」機能は効果がありません。これらのモードではCookieが保持されないため、新しいセッションを開始するたびにデバイスの有効化が求められます。

「ログイン情報を保存する」チェックボックスはログインページにあり、ログインのたびにユーザー名を入力しなくて済むよう、ブラウザにユーザー名を保存します。この内容は、デバイスの有効化のクッキーである、sfdc_lv2 プラットフォーム Cookie には影響しません。

今回のセキュリティ施策の一環として定義した、IPアドレス制限の最大値について

お客様は、組織レベルのネットワークアクセス設定（組織の信頼済みIP範囲の設定）およびプロファイルレベルのログインIP範囲（プロファイルでのログインIPアドレスの制限）を、Salesforceによって定義された以下の制限内に構成する必要があります:

• IPv4: 2^24 IPレンジ もしくは 16,777,216 個のアドレス

この動作変更におけるIPアドレスの範囲の算出方法

この動作変更の対象となるIPアドレスの範囲は、定義されたアドレスの各行の範囲を合計することで算出されます。以下の例では、最初の行に255個のIPアドレス、2番目の行に254個のIPアドレスが含まれており、合計で509個のIPアドレスが対象範囲となります。

Sandbox へのログイン時に検証コードのメールが届かない場合

本問題が発生するユーザーは、以下のステップを使用してトラブルシューティングを行えるよう、組織のシステム管理者に連絡してください。 

ユーザーが Sandbox 組織でメールによる検証コードを受信していない場合、システム管理者は以下を確認する必要があります:

1. ユーザーのメールアドレスが正確であり、末尾に「.invalid」が付加されていないこと。詳細は 更新後に「.invalid」が追加された Sandbox のメールアドレス を参照ください。

2. 「メール送信」設定を確認し、「システムメールのみ」または「すべてのメール」に更新してください。この設定を更新できない場合は、Salesforce サポートにお問い合わせください。

システム管理者自身が検証コードのメールを受信できない場合には、Salesforce サポートにお問い合わせください。

今回の変更の影響によるメタデータデプロイの問題への対処方法

プロファイルまたは組織レベルのネットワークアクセスのメタデータで参照されているIP範囲の合計が、全範囲で 16,777,216 個のIPアドレスを超える場合、メタデータデプロイは失敗します。「すべてのIP範囲における 16,777,216 個のIPアドレス制限に達しました。入力したIP範囲のサイズを縮小して、もう一度やり直してください。」というエラーメッセージが表示されます。

組織レベルのネットワーク設定の信頼済みIPアドレス、およびプロファイルレベルのログインIP範囲を確認してください。IPアドレス範囲を自社またはVPNに一致する特定の範囲に縮小してください。これにより、定義された制限内で、未特定または信頼できないIPが拒否されるか、本人確認を要求されるようになります。

今回の変更後、インテグレーションユーザーまたはAPIユーザーがロックアウトされる理由

インテグレーションユーザーを含むすべてのユーザーは、ユーザーインターフェース（UI）からログインする際、デバイスの有効化を含む標準のログイン要件に従う必要があります。APIインテグレーションユーザーはユーザーインターフェースからのログインに使用すべきではないため、それらのユーザーには「API限定ユーザー」権限を割り当てることが推奨されます。

追加の情報が必要な場合は「インテグレーションユーザーへの API 限定アクセス権の付与」および「Best Practices for Configuring Your Integration User（英語）」を参照ください。

外部ユーザーへのデバイスの有効化の影響

外部ユーザーは、デフォルトではデバイスの有効化を強制されません。こちらのヘルプ記事にあるように、これは今回の変更前も同様であり、変更後も変わりません。

SSOログインのデバイス有効化に関する変更は、どのクラウドや製品に適用されますか？ 

MFAをサポートするSalesforce Platform上に構築された製品に適用されます。

SSO（シングルサインオン）ログインのデバイス有効化への変更が、自社の組織で有効になっているか確認するにはどうすればよいですか？ 

この変更の展開は通常のメジャーリリースプロセスではないため、管理者がリリースバージョンを確認したり、Salesforce Trustサイトを参照したりして、変更が有効になっているかを確認することはできません。 ユーザーに対してデバイス有効化の確認画面が表示される頻度が増え始めた場合に、変更が有効になっていると判断できます。

SalesforceはSAMLレスポンス内のAuthnContextとAMR属性のどちらを評価しますか？ 

Salesforceは両方を評価します。さまざまなIDプロバイダー（IdP）との互換性を最大限に高めるため、Salesforceは標準的なSAMLの AuthnContextClassRef 要素だけでなく、XMLレスポンス内の「AMR」または「authnmethodsreferences」という名前の属性も確認します。

OIDCとSAMLで、Salesforceが「強固（strong）」として受け入れる（デバイス有効化をスキップするための）値には互換性がありますか？ 

はい。OIDC AMRで強固な認証として認識される値は、SAMLレスポンスで渡された場合も有効です。いずれかのプロトコルでその値が「強固」であると認識されれば、デバイス有効化はスキップされます。

IdPがMFAシグナルを別の属性で送信した場合はどうなりますか？

現時点では、認証シグナルが AuthnContext ステートメント、または認識されたAMR属性（「AMR」や「authnmethodsreferences」など）に含まれていない場合、Salesforceはそれを評価しません。

完全なSAML AMRサポートはいつ顧客に提供されますか？ 

SAML AMRサポートの展開は、2つの段階に分けて行われます。

• フェーズ1（インバウンドの識別 - 2月9日）： Salesforce（サービスプロバイダーとして機能）は、サードパーティのSSO IDプロバイダー（IdP）から送信されるAMRシグナルまたはAuthentication Context文字列の認識と評価を開始します。IdPがこれらのシグナルを送信するように既に設定されている場合、Salesforceはこの日以降、それらを使用してデバイス有効化をスキップできます。

• 【更新】フェーズ2（IdPとしてSalesforceがAMRを発行 - 2月17日）：Salesforce を ID プロバイダー（IdP）としてご利用の場合、SSOプロセスの過程で評価が可能となるよう、Salesforce自身がAMRシグナルの送信を開始いたします。

  デバイスの有効化をスキップするために、SAML SSO ID プロバイダーとしてのSalesforceが発行する安全な認証値は以下の通りです。

  • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform

  • LightningLogin

  • Passkey

  注：Salesforceがサービスプロバイダー（SP）としてお客様のSSOプロバイダーにAMRを要求するという以前の計画は中止されました。主要なプロバイダーの多くはデフォルトでこれらのデータを返すため、Salesforceから正式な要求を行う必要がないと判断されました。

  2026年2月17日のリリースで予定されている変更の詳細については、「2026年2月17日のリリースで予定されている変更内容」のセクションをご参照ください。

SSOプロバイダーがデフォルトでSAML経由でのAuthnContextの受け渡しをサポートしていない場合はどうすればよいですか？ 

IDプロバイダー（IdP）が標準のSAML AuthnContext を送信できない場合、ユーザーに繰り返し確認が求められないようにするための主なオプションが3つあります。

1. 「AMR」属性を使用する： Salesforceは、SAMLレスポンス内の「AMR」または「authnmethodsreferences」という名前の属性を認識します。Salesforceは厳密なXMLフォーマットよりも属性値を優先します。値が存在し、「強固」（例：mfa、hwk）であると認識される限り、デバイス有効化はスキップされます。

2. 信頼できるIP範囲： ユーザーが、組織レベルおよびプロファイルレベルの「信頼できるIP範囲」内のネットワークからログインしていることを確認してください。ログインIPが信頼できると認識され、定義された各範囲の合計がSalesforceの設定した制限内であれば、デバイス有効化はスキップされます。

3. 安全なシグナルを渡すことができず、IPも信頼されておらず、範囲がSalesforceの設定制限内の場合）、ユーザーはデバイス有効化を完了するよう求められます。メールで送信されたコードで確認を行い、「次回からは確認しない 」をクリックし、その特定のデバイス/ブラウザを少なくとも1年間免除するプラットフォームCookieを設定することをお勧めします。

SSO IDプロバイダーが返すシグナルを確認するにはどうすればよいですか？

• OIDC AMRの場合： Salesforceのログイン履歴にある AuthMethodReference 項目をクエリしてください。

• SAMLの場合： AuthnContext や AMR は現在Salesforceのログイン履歴に書き込まれません。外部ツールやブラウザ拡張機能を使用してSAMLレスポンスを検査するか、SSO IdPを管理するチームと協力ください。

デバイス有効化をスキップするには、安全な認証（SAML/OIDCシグナル）と信頼できるIP範囲の両方を実装する必要がありますか？ 

いいえ、どちらか一方を実装すれば、デバイス有効化のプロンプトをスキップするのに十分です。

• 安全な認証： SAML AuthnContext、SAML AMR属性、またはOIDC amrクレームを介して認識済みのシグナルを提供することで、プロンプトをバイパスできます。

• 信頼できるIP範囲： 定義された信頼できるIPアドレス（1670万IPの制限内）からログインすることでも、プロンプトをバイパスできます。

セキュリティのベストプラクティス： いずれかの方法単独でも機能しますが、多層防御（defense-in-depth）のセキュリティ体制を提供するために、両方を実装することをお勧めします。

自社の Salesforce 組織が、MFA を備えた外部 ID プロバイダー (IdP) の SAML SSO を使用している SSO サービスプロバイダー (SP) であるとします。 また、その Salesforce 組織が、他の内部 Salesforce SP 組織の IdP としても機能している場合、アップストリームの IdP で MFA が完了しているのに、なぜダウンストリームの SP 組織でユーザーにデバイスの有効化が求められるのですか？ 

これは、Salesforce が現在、SAML AMR や ACR などの特定の認証シグナルを ID プロバイダーチェーン全体に伝播させないために発生します。 これらのシグナルはデバイスの有効化の評価ロジックに必要であるため、ダウンストリーム組織はアップストリームの MFA（またはその他の安全な認証方法）を検証できず、デバイスの有効化チャレンジをトリガーします。 Salesforce は、ID プロバイダーチェーンを介して AMR および ACR 値を渡すための将来的な設計変更に取り組んでいます。 それまでの間は、デバイスの有効化をスキップするために、限定された「信頼済み IP 範囲」を使用することをお勧めします。