Cambios en la actividad de dispositivo para los inicios de sesión único (SSO)

Fecha de publicación original: 16 de diciembre de 2025

Actualizado: 24 de febrero de 2026

Como parte de nuestros esfuerzos continuos por implementar medidas de seguridad más estrictas para proteger a nuestros clientes, Salesforce ahora hace obligatorio la activación de dispositivos para determinados inicios de sesión de usuarios con inicio de sesión único (SSO). Esta mejora limita aún más el acceso no autorizado a las cuentas y se basa en actualizaciones de seguridad anteriores que se aplicaban a la activación de dispositivos para inicios de sesión sin SSO (consulte este elemento para obtener más detalles).

Resumen de los cambios publicados para la activación de dispositivos para inicios de sesión SSO

El 26 de enero de 2026 (antes era el 20 de enero de 2026), Salesforce comenzó a publicar cambios escalonados aplicados a los proveedores de identidad (IdP) SSO para hacer la activación de dispositivos obligatoria, comenzando por OpenID Connect (OIDC). El 9 de febrero de 2026 (antes era el 3 de febrero de 2026), Salesforce comenzó a publicar cambios para hacer la activación de dispositivos obligatoria para los IdP SAML.

Los cambios para los proveedores de identidad SSO OIDC y SAML ya están en vigor.

Para obtener más información, consulte la sección siguiente titulada "Programación de lanzamiento de los cambios en la activación de dispositivos para los inicios de sesión SSO".

La activación de los inicios de sesión SSO será obligatoria si no se ha implementado una de estas medidas de seguridad, consideradas como autenticación segura:

¿Por qué estamos realizando estos cambios en los inicios de sesión de tipo SSO (Inicio de sesión único)?

Hemos implementado estos cambios adicionales como medida de seguridad proactiva para mejorar la protección contra la apropiación de cuentas (ATO) y el acceso no autorizado. Estas actualizaciones proporcionan una experiencia de inicio de sesión más segura al exigir una capa adicional de verificación de identidad. Este paso de seguridad adicional se aplica cuando los proveedores de identidad (IdP) de inicio de sesión único (SSO) carecen de autenticación segura, o cuando los controles de seguridad existentes pueden no ser lo suficientemente robustos para mitigar las amenazas actuales.

¿Qué cambios se implementaron en la versión Summer '25?

Para contextualizar, en la versión Summer '25 se implementó el paso de activación del dispositivo para realizar una solicitud a los usuarios para que verifiquen su identidad en determinadas circunstancias. Estos cambios anteriores excluían específicamente los inicios de sesión de tipo SSO (Inicio de sesión único).

• A principios de septiembre de 2025: La activación del dispositivo es obligatoria para las organizaciones sin ánimo de lucro, incluso en caso de acceso de usuario a Salesforce desde un rango de IP de confianza. 

• Finales de octubre de 2025: La activación del dispositivo es obligatoria para algunos usuarios de organizaciones de producción y sandbox. Cuando los inicios de sesión con nombre de usuario y contraseña se producen con un conjunto excesivamente amplio de direcciones IP, ya sea en la configuración de acceso a la red a nivel de la organización o en los rangos de IP de inicio de sesión a nivel de perfil, se fuerza la activación del dispositivo.

Programación de lanzamiento de los cambios en la activación de dispositivos para Inicios de sesión SSO

La programación de los cambios para la activación de dispositivos para los inicios de sesión de tipo SSO (inicio de sesión único) ya está en vigor. La siguiente programación se proporciona a modo de referencia para detallar el lanzamiento de cada cambio programado. 

Tenga en cuenta que Salesforce admite SSO a través de Security Assertion Markup Language (SAML) y OpenID Connect (OIDC), así como proveedores preconfigurados para sistemas externos como Facebook. Dado que algunos proveedores admiten tanto SAML como OIDC, confirme el protocolo exacto utilizado para su empresa y su organización de Salesforce con su IdP y el equipo responsable de configurar el IdP.

¿Qué cambios se realizaron para la versión del 17 de febrero de 2026?

El 17 de febrero, Salesforce actualizó la forma en que procesa las señales de inicio de sesión único (SSO) para mejorar la coherencia entre los protocolos y reducir los desafíos de inicio de sesión innecesarios:

• Compatibilidad con el valor 'mfa' de OIDC AMR: El valor "mfa" se reconoce como una señal de fiabilidad independiente para omitir la activación del dispositivo (FDA) cuando se pasa en OIDC AMR. Los inicios de sesión OIDC ahora reflejan el comportamiento SAML. 

• Compatibilidad con el contexto de autenticación OIDC: Salesforce activó la capacidad de evaluar las señales AuthnContext (o Authentication Context Class Reference, ACR) para OIDC con el fin de gestionar mejor la integración compleja para proveedores OIDC no estándar o personalizados.

• Salesforce, como IDP que es, emite AMR: Cuando Salesforce actúa como proveedor de identidad, ahora emite las señales AMR para que la lógica de evaluación pueda determinar si se ha utilizado un método de autenticación seguro. 

Valores de autenticación segura emitidos por Salesforce como proveedor de identidad SAML SSO para omitir la activación del dispositivo:

• • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform 

  • LightningLogin 

  • Passkey

Nota: El plan anterior para que Salesforce, como proveedor de servicios, emitiera una solicitud de AMR desde su proveedor de SSO ha sido cancelado. La mayoría de los principales proveedores devuelven estas señales de forma predeterminada, lo que hace innecesaria una AuthRequest de Salesforce.

¿Cómo evalúa Salesforce los inicios de sesión de tipo SSO (inicio de sesión único) para determinar si utilizaron una autenticación segura? 

Salesforce evalúa la solidez de un inicio de sesión SSO inspeccionando las señales de identidad proporcionadas por su proveedor de identidad SSO (IdP). Salesforce utiliza una lógica de evaluación que reconoce señales de autenticación sólidas en los protocolos OIDC y SAML.

El proceso de evaluación: Salesforce comprueba la respuesta SSO en busca de señales de autenticación específicas. Si estas señales están presentes y se reconocen como seguras, el usuario omitirá la activación del dispositivo.

• Para OIDC: Salesforce lee la referencia del método de autenticación (AMR) del token de identidad. A partir del 17 de febrero de 2026, Salesforce también evaluará las señales del contexto de autenticación OIDC o de la referencia de clase de contexto de autenticación (ACR).

• Para SAML: Salesforce lee el contexto de autenticación estándar (AuthnContext) o busca un atributo denominado específicamente "AMR" o "authnmethodsreferences".

Intercambiabilidad: La lógica de evaluación es multifuncional. Cualquier valor reconocido como "sólido, fiable" en OIDC (por ejemplo, face, pop, hwk) también se acepta si se pasa dentro de un atributo SAML AMR. Del mismo modo, los valores sólidos SAML estándar (por ejemplo, Smartcard, TimeSyncToken) se reconocen en ambos protocolos.

Coincidencia de subcadenas: La evaluación consiste en comprobar si el valor proporcionado contiene una subcadena que coincida con la lista de métodos seguros de Salesforce. Este proceso no distingue entre mayúsculas y minúsculas para SAML. Para las reclamaciones OIDC, los valores distinguen entre mayúsculas y minúsculas.

No se ha podido verificar: Si se omiten estos valores o si el IdP envía un valor como "Sin especificar", Salesforce no puede verificar la solidez del inicio de sesión y se le realizará una solicitud al usuario para que complete la activación del dispositivo.

¿Qué considera Salesforce una autenticación segura desde el proveedor de identidad (IdP) de inicio de sesión único (SSO)?

Salesforce define los siguientes métodos como métodos de autenticación seguros, según se indica en la Referencia de métodos de autenticación (AMR) para IdP OIDC o SAML, y en el Contexto de autenticación o AuthnContext para IdP SAML. La activación del dispositivo se omitirá en Salesforce si se utilizan estos métodos y el IdP de SSO devuelve los valores: 

1. Referencia de métodos de autenticación (AMR) (para los IdP OIDC o SAML): Valores AMR (referenciados en RFC 8176) considerados como autenticación segura:

• face (reconocimiento facial)

• fpt (huella dactilar)

• hwk (clave de seguridad respaldada por hardware)

• iris (escaneo del iris)

• mfa (autenticación multifactor) [Véase la *Actualización más abajo]

• retina (escaneo de retina)

• sc (tarjeta inteligente)

• pop (Prueba de posesión de una clave)

• swk (clave de seguridad respaldada por software)
  
  Reclamaciones personalizadas de otros IdP:    

• multipleauthn
• Okta_verify

*Actualización: A partir del 17 de febrero de 2026, se aceptará 'mfa' como señal AMR independiente para omitir la activación del dispositivo para los inicios de sesión OIDC. Para SAML AMR, 'mfa' seguirá omitiendo la activación del dispositivo a partir del 9 de febrero de 2026.

2. Contexto de autenticación o AuthnContext (para IdP SAML): Valores de AuthnContext considerados como autenticación segura:

       Valores estándar de SAML:

• MobileTwoFactorContract

• Clave pública

• PGP

• Smartcard

• TimeSyncToken 

• PKI

Reclamaciones personalizadas de otros IdP:

• MFA

• Fido

• multipleauthn

Nota: Los valores "x.509", "basado en certificado" y "otp" no cumplen los requisitos para omitir la activación del dispositivo. Estos métodos se incluyeron anteriormente por error en este artículo de conocimiento y se han eliminado para ajustarse a los estándares del sector en materia de autenticación sólida, fiable. Si su SSO devuelve valores "x.509", basado en "certificado" u "otp" en AMR o AuthnContext, Salesforce realizará una solicitud de activación del dispositivo a menos que se pasen otros valores AMR/AuthnContext seguros o se apliquen otras medidas de seguridad (como direcciones IP de confianza restringidas o un dispositivo activado previamente).

La tabla siguiente resume cuándo los inicios de sesión de tipo SSO (inicio de sesión único) y los inicios de sesión que no son SSO en organizaciones de producción y sandbox deben introducir códigos de verificación para la activación del dispositivo.

Para cualquier otra combinación, la activación del dispositivo no realizará la solicitud de un código de verificación para el usuario.

¹ Es obligatorio la activación del dispositivo si los rangos de IP del perfil o los rangos de configuración de red superan el límite, incluso cuando la dirección IP de inicio de sesión sea válida, a menos que se den otras condiciones, como una autenticación sólida. Cualquier inicio de sesión que se origine desde una dirección IP que se encuentre fuera del rango de confianza configurado en el nivel de perfil del usuario seguirá bloqueándose.

² La activación del dispositivo no será obligatoria para los inicios de sesión SSO si se utiliza Salesforce MFA. Consulte Usar Salesforce MFA para SSO.

¿Qué es la activación del dispositivo?

La activación del dispositivo de Salesforce es una función de seguridad que es obligatoria para los usuarios cuando inician sesión desde un navegador, dispositivo o ubicación no reconocidos, fuera de un rango de IP de confianza.

La verificación por correo electrónico es el método principal de verificación de identidad para la mayoría de los usuarios, y consiste en realizar una solicitud para enviar un código de verificación a la dirección de correo electrónico del usuario durante el inicio de sesión. Cuando el usuario tiene registrado un método de verificación más seguro (Salesforce Authenticator, una aplicación de autenticación de terceros, clave de seguridad, autenticador integrado o SMS), se utiliza ese método de verificación más seguro en lugar de un código generado por correo electrónico

¿Cómo funcionan las casillas de verificación "No volver a preguntar" y "Recordarme" en el contexto de la activación del dispositivo?

Al completar la solicitud de activación de dispositivos que pide un código de verificación, al hacer clic en la casilla "No volver a preguntar" se establecerá la cookie de activación de dispositivos sfdc_lv2.

La cookie de plataforma sfdc_lv2 almacena los detalles de activación del dispositivo de los usuarios.  La activación del dispositivo no será obligatoria en cada inicio de sesión mientras esta cookie permanezca activa.  Si la cookie no está configurada o caduca, los usuarios deberán verificar su identidad la próxima vez que inicien sesión.  La duración de la cookie es de un año. 

Nota: El uso de los modos de navegación de incógnito/privada o de la configuración del navegador que borra automáticamente las cookies al cerrarlo hará que la función "No volver a preguntar" no se pueda aplicar. Dado que estos modos no conservan las cookies, se realizará una solicitud al usuario para que active el dispositivo cada vez que se inicie una nueva sesión.

La casilla "Recordarme" se encuentra en la página de inicio de sesión y guardará el nombre de usuario en el navegador para que no tenga que escribirlo cada vez que inicie sesión. Esto NO afecta a la cookie de activación del dispositivo sfdc_lv2 de la plataforma.

¿Cuál es el límite máximo de direcciones IP que Salesforce ha definido como parte de estos cambios?

Los clientes deben establecer la configuración de acceso a la red a nivel de organización (Establecer rangos de IP de confianza para su organización) y los rangos de IP de inicio de sesión a nivel de perfil (Restringir las direcciones IP de inicio de sesión en los perfiles) para que se encuentren dentro de los siguientes límites definidos por Salesforce:

• IPv4: direcciones 2^24 IP o 16 777 216

¿Cómo se calcula el rango de direcciones IP para este cambio de comportamiento?

El rango de direcciones IP para este cambio de comportamiento se calcula sumando el rango de cada fila de direcciones definidas.  En el siguiente ejemplo, la primera fila contiene 255 direcciones IP y la segunda fila contiene 254 direcciones IP, lo que da un total de 509 direcciones IP en el rango.

Utilice la búsqueda de Google u otras herramientas para determinar rápidamente el número de direcciones IP dentro de sus rangos de IP de confianza de Salesforce

¿Por qué no recibo los correos electrónicos con el código de verificación para iniciar sesión en sandbox?

Los usuarios afectados por este problema deben ponerse en contacto con el administrador del sistema de su organización para que pueda solucionar el problema siguiendo los pasos que se indican a continuación. 

Si los usuarios no reciben códigos de verificación por correo electrónico en las organizaciones sandbox, los administradores del sistema deben comprobar lo siguiente:

1. Las direcciones de correo electrónico de los usuarios son correctas y no se les añade ".invalid". Consulte más detalles aquí Direcciones de correo electrónico en sandbox añadidas con ".invalid" después de la actualización de Salesforce

2. Revise y actualice la configuración de Entrega de correo electrónico a Solo correo electrónico del sistema o Todo el correo electrónico. Si no puede actualizar esta configuración, póngase en contacto con el servicio de asistencia de Salesforce.

Si los administradores del sistema no reciben correos electrónicos con códigos de verificación, pueden ponerse en contacto con el servicio de asistencia de Salesforce.

¿Cómo solucionar los problemas de implementación de metadatos afectados por este cambio?

Las implementaciones de metadatos fallan si tienen rangos de IP referenciados en sus metadatos de acceso a la red a nivel de perfil/organización que superan las 16 777 216 direcciones IP en todos los rangos. Verá este mensaje de error: "Ha alcanzado el límite de 16 777 216 direcciones IP en todos sus rangos de IP. Reduzca el tamaño del rango de IP que ha introducido e inténtelo de nuevo."

Revise las direcciones IP de confianza en la configuración de red a nivel de organización y los rangos de IP de inicio de sesión a nivel de perfil. Reduzca los rangos de direcciones IP a direcciones específicas que coincidan con su empresa o VPN, lo que garantizará que las IP no identificadas o no confiables sean denegadas o cuestionadas dentro del límite definido.

¿Por qué se bloquea el acceso a mis usuarios de integración o API después de este cambio?

Cualquier usuario, incluidos los usuarios de integración, está sujeto a los requisitos de inicio de sesión estándar, incluida la activación del dispositivo, cuando inicia sesión desde la interfaz de usuario (UI). Se recomienda que asigne el permiso Solo API a sus usuarios de integración de API, ya que no deben utilizarse para iniciar sesión desde la interfaz de usuario. 

Consulte la orientación adicional que se describe en Dar a los usuarios de integración acceso solo a la API y Prácticas recomendadas para configurar su usuario de integración.

¿La activación del dispositivo es obligatoria para los usuarios externos?

Los usuarios externos no están obligados de forma predeterminada a utilizar la activación del dispositivo. Esto era así antes y seguirá siendo así después de estos cambios, tal y como se describe en este artículo de ayuda.

¿A qué nubes o productos se aplican estos cambios en la activación de dispositivos para inicios de sesión SSO?

Este cambio se aplica a los productos creados en la plataforma Salesforce que admiten MFA.

¿Cómo puedo verificar si los cambios en la activación de dispositivos para inicios de sesión de tipo SSO (inicio de sesión único) están en vigor para mi organización?

Dado que la implementación de este cambio no sigue el proceso estándar de lanzamiento de versiones principales, los administradores no pueden verificar si el cambio está en vigor comprobando su versión de lanzamiento o consultando el sitio Salesforce Trust.

Por lo general, puede confirmar que el cambio está en vigor si sus usuarios comienzan a recibir más solicitudes de activación de dispositivos. De lo contrario, póngase en contacto con el equipo de asistencia de Salesforce para que le ayuden a confirmar si los cambios están en vigor.

¿Salesforce evalúa el atributo AuthnContext o AMR en una respuesta SAML? 

Salesforce evalúa ambos. Para maximizar la compatibilidad con diferentes proveedores de identidad (IdP), Salesforce comprueba el elemento SAML AuthnContextClassRef estándar, así como cualquier atributo denominado específicamente "AMR" o "authnmethodsreferences" dentro de la respuesta XML.

¿Son intercambiables los valores aceptados por Salesforce como sólidos (para omitir la activación del dispositivo) para OIDC y SAML? 

Sí. Los valores de autenticación fuerte (fiable) reconocidos para OIDC AMR también son válidos cuando se pasan en una respuesta SAML. Si el valor se reconoce como "sólido, fiable" en cualquiera de los dos protocolos, se omitirá la activación del dispositivo.

¿Qué ocurre si mi IdP envía la señal MFA en un atributo diferente?

Actualmente, si la señal de autenticación no se encuentra en la declaración AuthnContext o en un atributo AMR reconocido (como "AMR" o "authnmethodsreferences"), Salesforce no la evaluará.

¿Cuándo estará disponible para los clientes la compatibilidad total con SAML AMR?

 La implementación de la compatibilidad con SAML AMR se llevará a cabo en dos fases distintas:

• Fase 1 (reconocimiento de entradas: 9 de febrero): Salesforce (en calidad de proveedor de servicios) comenzará a reconocer y evaluar las señales AMR o las cadenas de contexto de autenticación enviadas por proveedores de identidad SSO (IdP) de terceros. Si su IdP ya está configurado para enviar estas señales, Salesforce puede utilizarlas para omitir la activación del dispositivo a partir de esta fecha.

• [Actualizado] Fase 2 (Salesforce emite AMR como IdP: 17 de febrero): Si utiliza Salesforce como proveedor de identidad, ahora comenzará a enviar sus propias señales AMR para que puedan evaluarse durante el proceso de SSO. 

  Los valores de autenticación segura emitidos por Salesforce como proveedor de identidad SSO SAML para omitir la activación del dispositivo:

  • SalesforceAuthenticator

  • MFATOTP

  • MFAWebAuthnRoaming

  • MFAWebAuthnPlatform 

  • LightningLogin 

  • Passkey

  Nota: El plan anterior para que Salesforce, como proveedor de servicios, emitiera una solicitud de AMR desde su proveedor de SSO ha sido cancelado. La mayoría de los principales proveedores devuelven estos datos de forma predeterminada, por lo que no es necesario realizar una solicitud formal desde Salesforce.

  Para obtener más detalles sobre los cambios que se producirán el 17 de febrero de 2026, consulte la sección: ¿Qué cambios están previstos para la versión del 17 de febrero de 2026?

¿Qué debemos hacer si nuestro proveedor de SSO no admite el paso de AuthnContext a través de SAML de forma predeterminada?

Si su proveedor de identidad (IdP) no puede enviar el AuthnContext de SAML estándar, tiene tres opciones principales para garantizar que los usuarios no se enfrenten a repetidos desafíos de identificación:

1: Utilizar el atributo "AMR": Salesforce reconocerá un atributo denominado específicamente AMR o authnmethodsreferences dentro de la respuesta SAML. Salesforce da prioridad al valor del atributo sobre el formato XML estricto; siempre que el valor esté presente y se reconozca como "fuerte, fiable" (por ejemplo, mfa, hwk), se omitirá la activación del dispositivo.

2: Rangos de IP de confianza: Asegúrese de que sus usuarios inicien sesión desde una red dentro de los rangos de IP de confianza a nivel de organización y de perfil. Si la IP de inicio de sesión se reconoce como de confianza y el rango total definido para cada una está dentro del límite establecido por Salesforce, se omite la activación del dispositivo.

Si no se puede transmitir ninguna señal segura y la IP no es de confianza y se encuentra dentro del rango establecido por Salesforce, se realizará una solicitud a los usuarios para que completen la activación del dispositivo.  Verifique mediante el código enviado por correo electrónico y recuerde hacer clic en "No volver a preguntar" para establecer una cookie de plataforma que exima a ese dispositivo/navegador específico durante al menos un año.

¿Cómo puedo ver las señales que devuelve mi proveedor de identidad SSO?

• Para OIDC AMR, consulte el campo AuthMethodReference en el historial de inicio de sesión de Salesforce.

• Para SAML, AuthnContext o AMR no se escriben actualmente en el historial de inicio de sesión de Salesforce.  Puede inspeccionar su respuesta SAML utilizando herramientas externas o extensiones del navegador, o trabajando con el equipo que gestiona su IdP de SSO.

Para omitir la activación del dispositivo, ¿necesito implementar la autenticación segura (señales SAML/OIDC) Y TAMBIÉN los rangos de IP de confianza?

No, basta con implementar cualquiera de los dos para omitir la solicitud de activación del dispositivo.

• Autenticación segura: Proporcionar una señal reconocida a través de SAML AuthnContext, atributos SAML AMR o reclamaciones OIDC AMR omitirá la solicitud.

• Rangos de IP de confianza: Iniciar sesión desde una dirección IP definida y de confianza (dentro del límite de 16,7 millones de IP) también omitirá la solicitud.

Prácticas recomendadas de seguridad: Aunque cualquiera de los dos métodos funciona de forma independiente, recomendamos implementar ambos para proporcionar una postura de seguridad de defensa en profundidad por capas.

Mi organización de Salesforce es un proveedor de servicios (SP) de SSO que utiliza un proveedor de identidad (IdP) externo SAML SSO con MFA. Mi organización de Salesforce también es un IdP para otras organizaciones SP internas de Salesforce. ¿Por qué los usuarios necesitan la activación del dispositivo en las organizaciones SP descendentes cuando la MFA se completa en el IdP ascendente?

Esto se debe a que Salesforce actualmente no propaga señales de autenticación específicas, como SAML AMR o ACR, a través de una cadena de proveedores de identidad. Dado que estas señales son obligatorias para la lógica de evaluación de la activación del dispositivo, la organización descendente no puede verificar la MFA ascendente (u otro método de autenticación segura) y desencadena el desafío de identidad para la activación del dispositivo.

Salesforce está trabajando en futuros cambios de diseño para transmitir los valores AMR y ACR a través de la cadena de proveedores de identidad.  Mientras tanto, recomendamos utilizar rangos de IP de confianza estrictamente definidos para omitir la activación del dispositivo.