Categoría: Técnico
Subcategoría: Seguridad
Nivel: Intermedio
Tiempo de lectura: 15 minutos
En el artículo anterior, la puerta de entrada quedó con nombre propio. También quedó abierta una pregunta: cómo demostrás que sos quien decís ser cuando llegás a ella.
La respuesta corta es «autenticándote». La larga empieza con una escena.
Una escena para empezar
Un admin entra por la URL de su My Domain. Salesforce lo manda al proveedor de identidad de la empresa. Ahí escribe su contraseña, aprueba la notificación en el celular y vuelve.
Y Salesforce no lo deja pasar. Le pide que cree una passkey.
No es una falla. Salesforce clasifica cada login según su fuerza, y para los usuarios con más privilegios exige el nivel más alto.
El detalle está en cómo se entera. En un login por SSO, Salesforce no ve lo que pasó en el proveedor de identidad. Ve lo que el proveedor le informa. Si no le informa nada, el login se trata como si no hubiera tenido MFA.
El admin se autenticó bien. Lo que faltó fue la prueba.
Esa distancia entre autenticarse y poder demostrarlo recorre todo este artículo.
Autenticarse no es una sola cosa
Autenticarse es presentar pruebas de identidad. Una es algo que sabés, como tu contraseña. Otra es algo que tenés, como una llave de seguridad o una app en el celular.
La idea de combinarlas es simple. Una contraseña puede filtrarse. Que alguien consiga también tu segundo factor es mucho menos probable.
Salesforce llama «verificación de identidad» al momento en que pide una prueba adicional. Según cuándo la pide, le da uno de tres nombres:
- MFA: en cada login.
- Device activation: cuando el login llega desde un contexto que Salesforce no reconoce.
- Step-up authentication: cuando intentás algo que exige más seguridad.
Usan métodos parecidos, pero responden preguntas distintas.
El primer factor: la contraseña
Las políticas de contraseña definen qué tan compleja tiene que ser, qué largo mínimo tiene, cada cuánto vence, cuántas anteriores no se pueden repetir y cuántos intentos fallidos se toleran antes de bloquear al usuario.
Dos detalles cambian cómo se leen.
Endurecer la política no endurece las contraseñas actuales. Si subís la longitud mínima, los usuarios existentes no se ven afectados hasta que cambien su contraseña.
El bloqueo tampoco cuenta sólo contraseñas incorrectas. Los intentos fallidos de verificación de identidad también suman. Un usuario puede quedar bloqueado sin haberse equivocado nunca en la contraseña.
Cuando la contraseña deja de ser de Salesforce
Si un usuario se autentica contra un sistema externo, estas políticas dejan de aplicarle. Con Delegated Authentication, el vencimiento y la longitud mínima pasan a depender de ese sistema. Con SSO, el bloqueo por intentos fallidos suele manejarlo el proveedor de identidad.
La página de políticas de contraseña describe sólo las contraseñas que Salesforce todavía gestiona. En una organización con SSO, pueden ser muy pocas.
El segundo factor: MFA
Recuadro — MFA «requerido» no es MFA «aplicado»
El requisito es contractual y rige desde febrero de 2022. La aplicación técnica, es decir, Salesforce bloqueando el login de quien no cumple, llegó en 2026.
Durante años, una organización pudo incumplir el contrato y seguir entrando. Eso se terminó.
No todo MFA vale lo mismo
Salesforce ordena los métodos en tres niveles:
Sobre esos niveles hay dos exigencias.
Los usuarios privilegiados necesitan MFA resistente a phishing. Son los que tienen el perfil System Administrator o alguno de estos permisos: Modify All Data, View All Data, Customize Application o Author Apex. Si no cumplen, al entrar tienen que crear una passkey, sin opción de elegir otro método.
El resto de los usuarios internos cumple con MFA estándar.
La diferencia tiene lógica. Quien puede cambiar la configuración de la organización, o ver y modificar todos sus datos, es el objetivo más valioso para un atacante. Para esos usuarios, el segundo factor tiene que resistir un engaño.
Por qué una passkey resiste phishing
Cuando registrás una passkey, se crea una clave privada que queda en tu dispositivo. Nunca sale de ahí y nunca se comparte con Salesforce.
Esa clave está atada a un dominio. Si alguien te lleva a un sitio falso que imita a Salesforce, el autenticador detecta que el dominio no coincide y no permite el login. Un código de seis dígitos, en cambio, se puede escribir en cualquier sitio.
Acá vuelve el artículo anterior. Cambiar el My Domain invalida las passkeys registradas. Es la misma propiedad vista desde el otro lado: la credencial sabe contra qué dominio fue creada, y eso es lo que la protege.
Por la misma razón, el nivel más alto no depende de una contraseña. El login sin contraseña con passkeys cuenta como MFA resistente a phishing. También Certificate-Based Authentication, que usa un certificado digital instalado en el dispositivo del usuario.
Qué cambió con la aplicación técnica
Los dos programas se aplicaron entre julio y septiembre de 2026, con calendarios propios para cada Release Group. En una organización paga ya deberían estar vigentes, salvo que tenga una extensión.
El permiso Waive Multi-Factor Authentication for Exempt Users dejó de eximir de forma automática. Restituir una exención requiere la aprobación de Salesforce Support.
Algunos usuarios quedan afuera de estas exigencias: los externos con licencias de Experience Cloud, los usuarios Chatter External y Chatter Free, y los de organizaciones no pagas, como Developer Edition o trials. Y la exigencia apunta a los logins por interfaz. Una integración que no pasa por la interfaz no queda alcanzada.
SSO: autenticarse en otro lado
Single sign-on (SSO) permite entrar una vez y moverse entre aplicaciones sin volver a loguearse.
Siempre hay dos roles. El proveedor de identidad autentica al usuario. El proveedor de servicio es la aplicación a la que el usuario quiere entrar. Salesforce puede ocupar cualquiera de los dos.
Los protocolos más comunes son SAML y OpenID Connect (OIDC). En los dos, el proveedor de identidad le entrega a Salesforce una respuesta firmada que dice quién es el usuario. OIDC está construido sobre OAuth 2.0. Por sí solo, OAuth autoriza el acceso a datos, pero no autentica personas.
Entrar con una cuenta de Google, Apple o Facebook es una variante de lo mismo.
Forzar SSO sin quedarte afuera
Configurar SSO no obliga a usarlo. Por defecto, los usuarios pueden seguir entrando directamente a Salesforce. Para impedirlo se combina la política de login de My Domain, la del artículo anterior, con un control que desactiva las credenciales de Salesforce para los usuarios elegidos.
La documentación recomienda no forzar SSO para los admins, así pueden entrar si el proveedor de identidad falla. Esa cuenta de emergencia entra de forma directa, así que también necesita su passkey.
La prueba viaja en la respuesta
Volvamos a la escena del principio.
En un login por SSO, Salesforce depende de que el proveedor de identidad incluya dos señales estándar en su respuesta: AMR, que indica qué métodos usó el usuario, y ACR, que indica qué tan fuerte fue la autenticación. Con esas señales, Salesforce ubica el login en uno de los tres niveles.
Si las señales no llegan, o llegan en un formato que Salesforce no reconoce, el login cuenta como sin MFA. Para ver qué está enviando tu proveedor, Login History muestra ambos valores.
Recuadro — Tener SSO no es cumplir MFA
SSO resuelve dónde se autentica el usuario. MFA exige demostrar cómo lo hizo.
Un proveedor puede exigir MFA y no dejar constancia en la respuesta. Para Salesforce, ese login no tuvo MFA. Otro puede informar MFA estándar: para un empleado común alcanza, para un admin no.
Lo que tenés que revisar no está sólo en Salesforce. Está en lo que tu proveedor escribe en cada respuesta.
Delegated Authentication
Delegated Authentication se parece a SSO, pero funciona distinto.
El usuario escribe su contraseña en Salesforce. Salesforce se la pasa a un servicio externo, por ejemplo un directorio corporativo, y el servicio responde sí o no.
Resuelve un problema concreto: usar las mismas credenciales en varias aplicaciones, administradas en un solo lugar. Se asigna por usuario, así que puede convivir con usuarios que usan contraseña de Salesforce.
¿Cuenta como MFA? El servicio sólo responde si la contraseña es válida, no cómo se autenticó el usuario, y Salesforce registra estos logins como logins de usuario y contraseña. Si satisface el requisito de MFA [VERIFICAR: no está en las fuentes].
Recuadro — Delegated Authentication no es SAML
Con SAML, el usuario se autentica en el proveedor de identidad y Salesforce nunca ve la contraseña. Entra una vez y accede a varias aplicaciones.
Con Delegated Authentication, el usuario escribe su contraseña en Salesforce, que la valida contra otro sistema. Las credenciales son las mismas, pero se loguea en cada aplicación por separado.
Uno delega la autenticación completa. El otro, sólo la validación de la contraseña.
Device Activation: la verificación que mira el contexto
MFA pide una prueba en cada login. Device Activation la pide cuando el login no le resulta familiar a Salesforce.
Para los empleados se habilita sola y no se puede desactivar. Para los usuarios externos no es obligatoria por defecto.
Es un control determinístico. No calcula un nivel de riesgo: se dispara cuando falta alguna condición de confianza.
Qué la evita
En una organización paga, un login evita Device Activation si se cumple alguna de estas condiciones:
- El dispositivo ya está reconocido, porque el usuario lo activó antes.
- El login viene de una IP confiable, configurada en la organización o en el perfil.
- El usuario usó MFA de Salesforce.
Los rangos de IP confiables tienen un límite: poco más de 16 millones de direcciones. Si lo superan, Device Activation se pide igual. Un rango tan amplio no expresa confianza en ninguna red concreta.
En las organizaciones no pagas la regla es más estricta. Si el dispositivo no está reconocido, se pide verificación, sin importar la IP
Cuando el login es por SSO
Desde principios de 2026, Device Activation también aplica a los logins por SSO. En ese caso hay una condición más que la evita: que el proveedor de identidad informe una autenticación segura en sus señales.
Esa evaluación no usa la misma lista que el enforcement de MFA. Por ejemplo, la señal mfa alcanza para evitar Device Activation, pero para MFA cuenta sólo como estándar. La señal x509 cuenta como resistente a phishing para MFA, pero no evita Device Activation.
La misma respuesta del proveedor se evalúa dos veces, con criterios distintos.
Recuadro — MFA no es Device Activation
MFA pregunta, en cada login, si podés probar quién sos. Device Activation pregunta si este contexto ya es conocido.
Cuando MFA está activo, Device Activation deja de aplicar, porque el usuario ya se verifica en cada login. Y no aceptan las mismas pruebas: un código temporal generado por un admin sirve para MFA, pero no para Device Activation.
Quién sos, y desde dónde
Autenticarse en Salesforce ya no es escribir una contraseña correcta. Es demostrar quién sos con una prueba que Salesforce pueda leer, y con la fuerza que corresponde a tu nivel de acceso.
La contraseña sigue siendo el primer factor, mientras Salesforce la gestione. MFA agrega el segundo, con más exigencia para quien más puede hacer. SSO y Delegated Authentication trasladan parte del trabajo a otro sistema, pero no la obligación de demostrar lo que pasó. Y Device Activation mira algo que los demás no miran: el contexto.
En ese último punto apareció una pieza que todavía no explicamos. Los rangos de IP a veces piden verificación y a veces bloquean.
Esa es la pregunta del próximo artículo. Ya sabemos quién sos.
¿Desde dónde estás entrando?
Para seguir profundizando
Si querés profundizar en este tema, podés consultar la documentación oficial de Salesforce:
