Änderungen an der Geräteaktivierung für Single Sign-On (SSO)-Anmeldungen

Ursprüngliches Veröffentlichungsdatum – 16. Dezember 2025

Aktualisierungsdatum – 24. Februar 2026

Im Rahmen unserer fortlaufenden Bemühungen, strengere Sicherheitsmaßnahmen zum Schutz unserer Kunden zu implementieren, erfordert Salesforce nun die Geräteaktivierung für bestimmte Single Sign-On (SSO)-Benutzeranmeldungen. Diese Verbesserung schränkt den nicht autorisierten Accountzugriff weiter ein und baut auf früheren Sicherheitsaktualisierungen auf, die für die Geräteaktivierung für Anmeldungen ohne SSO galten (weitere Details finden Sie in diesem Artikel).

Zusammenfassung der veröffentlichten Änderungen zur Geräteaktivierung für SSO-Anmeldungen

Am 26. Januar 2026 (verschoben vom 20. Januar 2026) begann Salesforce mit der schrittweisen Einführung von Änderungen für SSO-Identitätsanbieter (IdP), um die Geräteaktivierung zu erfordern, beginnend mit OpenID Connect (OIDC). Am 9. Februar 2026 (verschoben vom 3. Februar 2026) begann Salesforce mit der Einführung von Änderungen, die die Geräteaktivierung für SAML-Identitätsanbieter erfordern.

Änderungen für OIDC- und SAML-SSO-Identitätsanbieter sind jetzt in Kraft.

Einzelheiten finden Sie im folgenden Abschnitt unter "Veröffentlichungsplan für Änderungen an der Geräteaktivierung für SSO-Anmeldungen".

Für SSO-Anmeldungen ist eine Geräteaktivierung erforderlich, es sei denn, eine der folgenden Sicherheitsmaßnahmen, die als sichere Authentifizierung gelten, ist vorhanden:

Warum werden diese Änderungen für Single Sign-On (SSO)-Anmeldungen vorgenommen?

Diese zusätzlichen Änderungen wurden als proaktive Sicherheitsmaßnahme implementiert, um den Schutz vor einer Accountübernahme (Account Takeover, ATO) und unbefugtem Zugriff zu verbessern. Diese Aktualisierungen bieten eine sicherere Anmeldeerfahrung, indem eine zusätzliche Ebene der Identitätsüberprüfung vorgeschrieben wird. Dieser zusätzliche Sicherheitsmaßnahme wird angewendet, wenn Single Sign-On (SSO)-Identitätsanbieter (IdP) keine sichere Authentifizierung bieten oder wenn bestehende Sicherheitskontrollen möglicherweise nicht robust genug sind, um aktuelle Bedrohungen abzuwehren.

Welche Änderungen wurden in der Version Summer '25 implementiert?

In der Version Summer '25 wurde der Schritt "Geräteaktivierung" implementiert, um Benutzer aufzufordern, ihre Identität unter bestimmten Umständen zu bestätigen. Bei diesen früheren Änderungen waren Single Sign-On (SSO)-Anmeldungen ausdrücklich ausgeschlossen.

• Anfang September 2025: Für nicht gewinnorientierte Organisationen ist eine Geräteaktivierung erforderlich, auch wenn ein Benutzer über einen vertrauenswürdigen IP-Bereich auf Salesforce zugreift. 

• Ende Oktober 2025: Für einige Produktions- und Sandbox-Organisationsbenutzer ist eine Geräteaktivierung erforderlich. Wenn sich Benutzer mit Benutzername und Kennwort mit einem übermäßig breiten Satz von IP-Adressen in den Netzwerkzugriffseinstellungen auf Organisationsebene oder in den IP-Bereichen für die Anmeldung auf Profilebene anmelden, wird die Geräteaktivierung erzwungen.

Veröffentlichungsplan für Änderungen bei der Geräteaktivierung für SSO-Anmeldungen

Die geplanten Änderungen an der Geräteaktivierung für Single Sign-On (SSO)-Anmeldungen sind nun in Kraft. Der nachstehende Zeitplan dient als Referenz, um detailliert darzustellen, wann die Veröffentlichung für jede geplante Änderung begonnen hat. 

Beachten Sie, dass Salesforce SSO über die Security Assertion Markup Language (SAML) und OpenID Connect (OIDC) sowie vorkonfigurierte Anbieter für externe Systeme wie Facebook unterstützt. Da einige Anbieter sowohl SAML als auch OIDC unterstützen, überprüfen Sie bitte das genaue Protokoll, das für Ihre Enterprise- und Salesforce-Organisation verwendet wird, mit Ihrem Identitätsanbieter und dem für die Konfiguration des Identitätsanbieters verantwortlichen Team.

Welche Änderungen wurden in der Version vom 17. Februar 2026 vorgenommen?

Am 17. Februar hat Salesforce die Verarbeitung von Single Sign-On (SSO)-Signalen aktualisiert, um die Konsistenz zwischen Protokollen zu verbessern und unnötige Anmeldeprobleme zu reduzieren:

• Unterstützung des OIDC AMR-Werts "mfa": Der Wert "mfa" wird als eigenständiges starkes Signal zur Umgehung der Geräteaktivierung (FDA) erkannt, wenn es in OIDC AMR übermittelt wird. OIDC-Anmeldungen entsprechen nun dem SAML-Verhalten. 

• Unterstützung des OIDC-Authentifizierungskontexts: Salesforce bietet die Möglichkeit, Signale von AuthnContext (oder Authentication Context Class Reference (ACR)) für OIDC zu bewerten, um komplexe Integrationen für nicht standardmäßige oder benutzerdefinierte OIDC-Anbieter besser zu verarbeiten.

• Als IdP sendet Salesforce AMR-Signale: Wenn Salesforce als Identitätsanbieter fungiert, sendet es nun die AMR-Signale, damit die Auswertungslogik feststellen kann, ob eine sichere Authentifizierungsmethode verwendet wurde. 

Sichere Authentifizierungswerte, die von Salesforce als SAML-SSO-Identitätsanbieter ausgegeben werden, um die Geräteaktivierung zu überspringen:

• • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform 

  • LightningLogin 

  • Passkey

Hinweis: Der bisherige Plan, dass Salesforce als Dienstanbieter eine Anfrage für AMR von Ihrem SSO-Anbieter sendet, wurde aufgehoben. Die meisten großen Anbieter senden diese Signale standardmäßig zurück, sodass eine AuthRequest von Salesforce nicht erforderlich ist.

Wie bewertet Salesforce Single Sign-On (SSO)-Anmeldungen, um festzustellen, ob die sichere Authentifizierung verwendet wurde? 

Salesforce bewertet die Stärke einer SSO-Anmeldung, indem es die Identitätsmerkmale überprüft, die von Ihrem SSO-Identitätsanbieter (IdP) bereitgestellt werden. Salesforce verwendet eine Bewertungslogik, die starke Authentifizierungssignale sowohl über OIDC- als auch über SAML-Protokolle erkennt.

Der Bewertungsprozess: Salesforce überprüft die SSO-Antwort auf bestimmte Authentifizierungssignale. Wenn diese Signale vorhanden sind und als sicher erkannt werden, überspringt der Benutzer die Geräteaktivierung.

• Für OIDC: Salesforce liest die Referenz für Authentifizierungsmethoden (AMR) aus dem Identitätstoken. Ab dem 17. Februar 2026 bewertet Salesforce auch Signale des OIDC-Authentifizierungskontexts oder der Authentifizierungskontext-Klassenreferenz (ACR).

• Für SAML: Salesforce liest den standardmäßigen Authentifizierungskontext (AuthnContext) oder sucht nach einem Attribut mit dem Namen "AMR" oder "authnmethodsreferences".

Austauschbarkeit: Die Bewertungslogik ist funktionsübergreifend. Jeder Wert, der in OIDC als "stark" erkannt wird (z. B. face, pop, hwk), wird auch akzeptiert, wenn er innerhalb eines SAML AMR-Attributs übermittelt wird. Ebenso werden starke SAML-Standardwerte (z. B. Smartcard, TimeSyncToken) von beiden Protokollen erkannt.

Abgleich von Teilzeichenfolgen: Bei der Bewertung wird überprüft, ob der angegebene Wert eine Teilzeichenfolge enthält, die mit der Liste der sicheren Methoden von Salesforce übereinstimmt. Bei diesem Verfahren wird bei SAML nicht zwischen Groß- und Kleinschreibung unterschieden. Bei OIDC-Ansprüchen wird die Groß-/Kleinschreibung beachtet.

Nichtverifizierung: Wenn diese Werte nicht angegeben werden oder wenn der Identitätsanbieter einen Wert wie "Nicht angegeben" sendet, kann Salesforce die Stärke der Anmeldung nicht überprüfen, und der Benutzer wird aufgefordert, die Geräteaktivierung abzuschließen.

Was versteht Salesforce unter einer sicheren Authentifizierung durch den Single Sign-On (SSO)-Identitätsanbieter (IdP)?

Salesforce definiert die folgenden Methoden als sichere Authentifizierungsmethoden, wie sie in der Referenz für Authentifizierungsmethoden (AMR) für OIDC- oder SAML-IdPs und im Authentifizierungskontext oder AuthnContext für SAML-IdPs beschrieben sind. Die Geräteaktivierung wird in Salesforce übersprungen, wenn diese Methoden verwendet werden und Werte vom SSO-IdP zurückgegeben werden: 

1. Referenz für Authentifizierungsmethoden (AMR) (für OIDC- oder SAML-IdPs): AMR-Werte (referenziert in RFC 8176) gelten als sichere Authentifizierung:

• face (Gesichtserkennung)

• fpt (Fingerabdruck)

• hwk (Hardware-gestützter Sicherheitsschlüssel)

• iris (Iris-Scan)

• mfa (Multi-Faktor-Authentifizierung)  [Siehe *Update unten]

• retina (Retina-Scan)

• sc (Smartcard)

• pop (Besitznachweis eines Schlüssels)

• swk (Software-gestützter Sicherheitsschlüssel)
  
  Benutzerdefinierte Ansprüche von anderen Identitätsanbietern:    

• multipleauthn
• Okta_verify

*Update: Ab dem 17. Februar 2026 wird "mfa" als eigenständiges AMR-Signal akzeptiert, um die Geräteaktivierung für OIDC-Anmeldungen zu umgehen. Bei SAML AMR überspringt "mfa" weiterhin die Geräteaktivierung ab dem 9. Februar 2026.

2. Authentifizierungskontext oder AuthnContext (für SAML-IdPs): AuthnContext-Werte, die als sichere Authentifizierung gelten:

       SAML-Standardwerte:

• MobileTwoFactorContract

• PublicKey

• PGP

• Smartcard

• TimeSyncToken 

• PKI

Benutzerdefinierte Ansprüche von anderen Identitätsanbietern:

• Mfa

• Fido

• multipleauthn

Hinweis: Die Werte "x.509", "Zertifikatbasiert" und "otp" sind nicht zum Überspringen der Geräteaktivierung geeignet. Diese Methoden wurden zuvor fälschlicherweise in diesem Knowledge-Artikel aufgeführt und entfernt, um sie an die Branchenstandards für eine sichere Authentifizierung anzupassen. Wenn Ihre SSO die Werte "x.509", "Zertifikatbasiert" oder "otp" in AMR oder AuthnContext zurückgibt, fordert Salesforce zur Geräteaktivierung auf, es sei denn, es werden andere sichere AMR-/AuthnContext-Werte übergeben oder es sind andere Sicherheitsmaßnahmen vorhanden (z. B. "Eingeschränkte vertrauenswürdige IP-Adressen" oder ein zuvor aktiviertes Gerät).

Die folgende Tabelle zeigt, wann bei Single Sign-On (SSO)-Anmeldungen und Nicht-SSO-Anmeldungen in Produktions- und Sandbox-Organisationen Bestätigungscodes für die Geräteaktivierung eingeben werden müssen.

Bei jeder anderen Kombination fordert die Geräteaktivierung den Benutzer nicht zur Eingabe eines Bestätigungscodes auf.

¹ Die Geräteaktivierung ist erforderlich, wenn die IP-Bereiche des Profils oder die Netzwerkkonfigurationsbereiche die Grenze überschreiten, selbst wenn die Anmelde-IP-Adresse zulässig ist, es sei denn, es liegen andere Bedingungen wie eine starke Authentifizierung vor. Jede Anmeldung, die von einer IP-Adresse stammt, die außerhalb des auf Profilebene des Benutzers konfigurierten vertrauenswürdigen Bereichs liegt, wird weiterhin blockiert.

² Die Geräteaktivierung ist für SSO-Anmeldungen nicht erforderlich, wenn die MFA von Salesforce verwendet wird. Weitere Informationen finden Sie unter Verwenden von Salesforce MFA für SSO.

Was ist die Geräteaktivierung?

Die Geräteaktivierung von Salesforce ist eine Sicherheitsfunktion, die von Benutzern verlangt, ihre Identität zu bestätigen, wenn sie sich von einem nicht erkannten Browser, Gerät oder Standort außerhalb eines vertrauenswürdigen IP-Bereichs anmelden.

Die E-Mail-Verifizierung ist für die meisten Benutzer die primäre Methode zur Identitätsprüfung, bei der während der Anmeldung ein Bestätigungscode an die E-Mail-Adresse des Benutzers gesendet wird. Wenn der Benutzer eine strengere Verifizierungsmethode (Salesforce Authenticator, eine Authenticator-App eines Drittanbieters, Sicherheitsschlüssel, integrierter Authenticator oder SMS) registriert hat, wird diese strengere Verifizierungsmethode anstelle eines per E-Mail generierten Codes verwendet.

Wie funktionieren die Kontrollkästchen "Nicht erneut fragen" und "Merken" im Zusammenhang mit der Geräteaktivierung?

Wenn bei der Geräteaktivierung nach einem Bestätigungscode gefragt wird, wird durch Aktivieren des Kontrollkästchens "Nicht erneut fragen" das Plattform-Cookie "sfdc_lv2" für die Geräteaktivierung gesetzt.

Das Plattform-Cookie "sfdc_lv2" speichert Informationen zur Geräteaktivierung für Benutzer.  Solange dieses Cookie aktiv bleibt, müssen Benutzer die Geräteaktivierung nicht bei jeder Anmeldung erneut durchführen.  Wenn das Cookie nicht gesetzt ist oder abläuft, müssen sich die Benutzer bei ihrer nächsten Anmeldung erneut identifizieren.  Die Gültigkeitsdauer des Cookies beträgt ein Jahr. 

Hinweis: Die Verwendung des Inkognito-/Privatmodus oder von Browsereinstellungen, die Cookies beim Schließen automatisch löschen, macht die Funktion "Nicht erneut fragen" unwirksam. Da in diesen Modi keine Cookies gespeichert werden, wird der Benutzer bei jedem Start einer neuen Sitzung zur Geräteaktivierung aufgefordert.

Das Kontrollkästchen "Merken" befindet sich auf der Anmeldeseite und speichert den Benutzernamen im Browser, sodass Sie den Benutzernamen nicht bei jeder Anmeldung eingeben müssen. Dies hat KEINE Auswirkungen auf das Plattform-Cookie "sfdc_lv2" für die Geräteaktivierung.

Was ist die maximale Anzahl von IP-Adressen, die Salesforce im Rahmen dieser Änderungen festgelegt hat?

Kunden sollten ihre Netzwerkzugriffseinstellungen auf Organisationsebene (Vertrauenswürdige IP-Bereiche für Ihre Organisation festlegen) und die IP-Bereiche für die Anmeldung auf Profilebene (IP-Adressen für die Anmeldung in Profilen einschränken) so konfigurieren, dass sie innerhalb der folgenden von Salesforce definierten Grenzen liegen:

• IPv4: 2^24 IP-Adressen oder 16.777.216 Adressen

Wie wird der Bereich der IP-Adressen für diese Verhaltensänderung berechnet?

Der Bereich der IP-Adressen für diese Verhaltensänderung wird berechnet, indem der Bereich in jeder Zeile der definierten Adressen hinzugefügt wird.  Im folgenden Beispiel enthält die erste Zeile 255 IP-Adressen und die zweite Zeile 254 IP-Adressen, also insgesamt 509 IP-Adressen im Bereich.

Verwenden Sie die Google-Suche oder andere Tools zum schnellen Bestimmen der Anzahl der IP-Adressen in Ihren vertrauenswürdigen Salesforce-IP-Bereichen.

Warum erhalte ich keine E-Mails mit Bestätigungscodes für Sandbox-Anmeldungen?

Benutzer, die von diesem Problem betroffen sind, sollten sich an den Systemadministrator ihrer Organisation wenden, damit sie die Fehler mithilfe der folgenden Schritte beheben können. 

Wenn Benutzer in Sandbox-Organisationen keine Bestätigungscodes per E-Mail erhalten, sollten Systemadministratoren Folgendes überprüfen:

1. Die E-Mail-Adressen der Benutzer sind korrekt und an sie wurde nicht ".invalid" angehängt. Weitere Details finden Sie unter E-Mail-Adressen in der Sandbox mit Anhang ".invalid" nach der Salesforce-Aktualisierung.

2. Überprüfen und aktualisieren Sie Ihre Einstellungen für die E-Mail-Zustellbarkeit zu Nur System-E-Mail oder Alle E-Mails. Wenn Sie diese Einstellung nicht aktualisieren können, wenden Sie sich an den Salesforce-Support.

Wenn Systemadministratoren keine E-Mails mit Bestätigungscode erhalten, können sie sich an den Salesforce-Support wenden.

Wie können die von dieser Änderung betroffenen Probleme bei der Bereitstellung von Metadaten behoben werden?

Bereitstellungen von Metadaten schlagen fehl, wenn in den Metadaten für den Netzwerkzugriff auf Profil-/Organisationsebene auf IP-Bereiche verwiesen wird, die in allen Bereichen mehr als 16.777.216 IP-Adressen umfassen. Die folgende Fehlermeldung wird angezeigt: "Sie haben die Obergrenze von 16.777.216 IP-Adressen in allen Ihren IP-Bereichen erreicht. Reduzieren Sie die Größe des eingegebenen IP-Bereichs und versuchen Sie es erneut."

Überprüfen Sie die vertrauenswürdige IP-Adresse in Ihren Netzwerkeinstellungen auf Organisationsebene und in den IP-Bereichen für die Anmeldung auf Profilebene. Beschränken Sie die IP-Adressbereiche auf bestimmte Adressen, die Ihrem Unternehmen oder VPN entsprechen. Dadurch wird sichergestellt, dass nicht identifizierte oder nicht vertrauenswürdige IP-Adressen innerhalb der festgelegten Grenzen abgelehnt oder angefochten werden.

Warum sind meine Integrations- oder API-Benutzer nach dieser Änderung gesperrt?

Alle Benutzer, einschließlich Integrationsbenutzer, unterliegen den Standard-Anmeldeanforderungen, einschließlich der Geräteaktivierung, wenn sie sich über die Benutzeroberfläche anmelden. Es wird empfohlen, API-Integrationsbenutzern die Berechtigung "Nur API" zuzuweisen, da sie nicht für die Anmeldung über die Benutzeroberfläche verwendet werden sollten. 

Weitere Informationen finden Sie unter Integrationsbenutzern "Nur API"-Zugriff gewähren und Bewährte Vorgehensweisen zum Konfigurieren Ihres Integrationsbenutzers.

Müssen externe Benutzer die Geräteaktivierung abschließen?

Externe Benutzer sind standardmäßig nicht gezwungen, die Geräteaktivierung zu verwenden. Dies war bereits zuvor der Fall und wird auch nach den beschriebenen Änderungen so bleiben, wie in diesem Hilfeartikel beschrieben.

Für welche Clouds oder Produkte gelten diese Änderungen an der Geräteaktivierung für SSO-Anmeldungen?

Diese Änderung gilt für auf der Salesforce Platform basierende Produkte, die MFA unterstützen.

Wie kann ich überprüfen, ob die Änderungen an der Geräteaktivierung für Single Sign-On (SSO)-Anmeldungen für meine Organisation wirksam sind?

Da diese Änderung nicht gemäß dem üblichen Verfahren für Hauptversionen eingeführt wird, können Administratoren nicht anhand ihrer Version oder auf der Salesforce Trust-Website überprüfen, ob die Änderung wirksam ist.

Sie können im Allgemeinen bestätigen, dass die Änderung wirksam ist, wenn Ihre Benutzer mehr Aufforderungen zur Geräteaktivierung erhalten. Wenden Sie sich alternativ an das Salesforce-Supportteam, um zu überprüfen, ob die Änderungen wirksam sind.

Bewertet Salesforce das Attribut AuthnContext oder AMR in einer SAML-Antwort? 

Salesforce bewertet beides. Um die Kompatibilität mit verschiedenen Identitätsanbietern zu maximieren, überprüft Salesforce das standardmäßige SAML-Element AuthnContextClassRef sowie alle Attribute, die in der XML-Antwort speziell "AMR" oder "authnmethodsreferences" genannt werden.

Sind die von Salesforce als stark akzeptierten Werte (um die Geräteaktivierung zu überspringen) für OIDC und SAML austauschbar? 

Ja. Die für OIDC AMR erkannten starken Authentifizierungswerte sind auch gültig, wenn sie in einer SAML-Antwort übermittelt werden. Wenn der Wert in einem der Protokolle als "stark" erkannt wird, wird die Geräteaktivierung übersprungen.

Was passiert, wenn mein Identitätsanbieter das MFA-Signal in einem anderen Attribut sendet?

Wenn sich das Authentifizierungssignal nicht in der AuthnContext-Anweisung oder in einem erkannten AMR-Attribut (wie "AMR" oder "authnmethodsreferences") befindet, bewertet Salesforce es derzeit nicht.

Wann ist die vollständige SAML AMR-Unterstützung für Kunden verfügbar?

 Die Einführung der SAML AMR-Unterstützung erfolgt in zwei unterschiedlichen Phasen:

• Phase 1 (Eingangserkennung – 9. Februar): Salesforce (in seiner Funktion als Dienstanbieter) beginnt mit der Erkennung und Bewertung von AMR-Signalen oder Authentifizierungskontext-Zeichenfolgen, die von Fremdanbieter-SSO-Identitätsanbietern (IdPs) gesendet werden. Wenn Ihr Identitätsanbieter bereits für das Senden dieser Signale konfiguriert ist, kann Salesforce sie verwenden, um die Geräteaktivierung ab diesem Datum zu überspringen.

• [Aktualisiert] Phase 2 (Salesforce sendet AMR-Signal als Identitätsanbieter – 17. Februar): Wenn Sie Salesforce als Ihren Identitätsanbieter verwenden, sendet es nun seine eigenen AMR-Signale, damit diese Signale während des SSO-Prozesses bewertet werden können. 

  Sichere Authentifizierungswerte, die von Salesforce als SAML-SSO-Identitätsanbieter ausgegeben werden, um die Geräteaktivierung zu überspringen:

  • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform 

  • LightningLogin 

  • Passkey

  Hinweis: Der bisherige Plan, dass Salesforce als Dienstanbieter eine Anfrage für AMR von Ihrem SSO-Anbieter sendet, wurde aufgehoben. Die meisten großen Anbieter senden diese Daten standardmäßig zurück, sodass eine formale Anfrage von Salesforce nicht erforderlich ist.

  Weitere Details zu den am 17. Februar 2026 vorgenommenen Änderungen finden Sie im folgenden Abschnitt: Welche Änderungen sind für die Version vom 17. Februar 2026 geplant?

Was sollten wir tun, wenn unser SSO-Anbieter die Übermittlung von AuthnContext per SAML standardmäßig nicht unterstützt?

Wenn Ihr Identitätsanbieter (IdP) den standardmäßigen SAML-Wert "AuthnContext" nicht senden kann, haben Sie drei primäre Optionen, um sicherzustellen, dass Benutzer nicht wiederholt angefochten werden:

1.: Verwenden Sie das Attribut "AMR": Salesforce erkennt ein speziell als "AMR" oder "authnmethodsreferences" bezeichnetes Attribut innerhalb der SAML-Antwort. Salesforce priorisiert den Attributwert gegenüber der strengen XML-Formatierung. Solange der Wert vorhanden ist und als "stark" erkannt wird (z. B. mfa, hwk), wird die Geräteaktivierung übersprungen.

2.: Vertrauenswürdige IP-Bereiche: Stellen Sie sicher, dass sich Ihre Benutzer über ein Netzwerk in Ihren vertrauenswürdigen IP-Bereichen auf Organisations- und Profilebene anmelden. Wenn die Anmelde-IP-Adresse als vertrauenswürdig erkannt wird und der insgesamt definierte Bereich für jede IP-Adresse innerhalb der von Salesforce festgelegten Obergrenze liegt, wird die Geräteaktivierung übersprungen.

Wenn kein sicheres Signal übermittelt werden kann und die IP-Adresse nicht vertrauenswürdig ist und innerhalb der von Salesforce festgelegten Obergrenze liegt, werden Benutzer aufgefordert, die Geräteaktivierung abzuschließen.  Überprüfen Sie dies über den per E-Mail gesendeten Code und klicken auf "Nicht erneut fragen", um ein Plattform-Cookie zu setzen, mit dem dieses bestimmte Gerät/dieser bestimmte Browser für mindestens ein Jahr ausgenommen wird.

Wie kann ich die Signale anzeigen, die mein SSO-Identitätsanbieter zurückgibt?

• Fragen Sie für OIDC AMR das Feld "AuthMethodReference" im Anmeldeverlauf von Salesforce ab.

• Für SAML wird AuthnContext oder AMR derzeit nicht in den Salesforce-Anmeldeverlauf geschrieben.  Sie können Ihre SAML-Antwort mit externen Tools oder Browser-Erweiterungen überprüfen oder sich an das Team wenden, das Ihren SSO-IdP verwaltet.

Muss ich sowohl eine sichere Authentifizierung (SAML/OIDC-Signale) als auch vertrauenswürdige IP-Bereiche implementieren, um die Geräteaktivierung zu überspringen?

Nein, die Implementierung einer der beiden Optionen ist ausreichend, um die Aufforderung zur Geräteaktivierung zu überspringen.

• Sichere Authentifizierung: Durch die Bereitstellung eines anerkannten Signals über SAML AuthnContext, SAML AMR-Attribute oder OIDC AMR-Ansprüche wird die Aufforderung umgangen.

• Vertrauenswürdige IP-Bereiche: Die Anmeldung über eine definierte, vertrauenswürdige IP-Adresse (innerhalb der Begrenzung von 16,7 Millionen IP-Adressen) umgeht ebenfalls die Aufforderung.

Sicherheitsempfehlungen: Obwohl jede Methode für sich allein funktioniert, empfehlen wir die Implementierung beider Methoden, um ein mehrschichtiges, tiefgreifendes Sicherheitsverhalten zu gewährleisten.

"Meine Salesforce-Organisation" ist ein SSO-Serviceanbieter (SP), der die SAML-SSO mit MFA eines externen Identitätsanbieters (IdP) verwendet. "Meine Salesforce-Organisation" ist auch ein Identitätsanbieter für andere interne SP-Organisationen von Salesforce. Warum ist eine Geräteaktivierung in nachgelagerten SP-Organisationen erforderlich, wenn die MFA beim vorgelagerten IdP bereits abgeschlossen ist?

Das liegt daran, dass Salesforce derzeit keine spezifischen Authentifizierungssignale – wie SAML AMR oder ACR – über eine Identitätsanbieter-Kette weiterleitet. Da diese Signale für die Bewertungslogik der Geräteaktivierung erforderlich sind, kann die nachgelagerte Organisation die vorgelagerte MFA (oder eine andere sichere Authentifizierungsmethode) nicht überprüfen und löst die Geräteaktivierungsabfrage aus.

Salesforce arbeitet derzeit an zukünftigen Designänderungen, um die AMR- und ACR-Werte über die gesamte Identitätsanbieter-Kette hinweg zu übermitteln.  In der Zwischenzeit empfehlen wir die Verwendung von eng definierten vertrauenswürdigen IP-Bereichen, um die Geräteaktivierung zu umgehen.