Análisis editorial original de OrbTrail ampliado con investigación complementaria, contexto práctico y referencias verificadas.
La ampliación del MFA en Salesforce no es otra casilla en Setup. La plataforma ahora evalúa la fortaleza de cada autenticación y espera evidencias distintas según el usuario acceda directamente o mediante SSO y tenga permisos comunes o privilegiados. El 10 de agosto de 2026, nuevos grupos de producción entraron en su ventana de aplicación. Para muchas empresas, el riesgo inmediato ya no es ignorar una recomendación, sino descubrir durante la jornada que el proveedor de identidad no envía la evidencia que Salesforce espera.
La pregunta central es operativa: ¿cómo implantar la exigencia sin bloquear administradores, personal de primera línea, integraciones o usuarios móviles? La respuesta comienza separando tres problemas que suelen tratarse como uno: cobertura de MFA para todos los usuarios internos, autenticación resistente al phishing para cuentas privilegiadas y prueba técnica de la fortaleza del acceso cuando existe federación. OrbTrail comparó el calendario y las tablas de autenticación de Salesforce con la experiencia documentada del rollout y la configuración de passkeys en Microsoft Entra ID para construir un plan verificable.
Clasificar el nivel de acceso
Determina si la cuenta es común o recibe privilegios mediante perfil, permission set o grupo de permisos.
Demostrar la fortaleza requerida
El acceso directo usa verificadores de Salesforce; SSO debe entregar señales AMR o ACR aceptadas para el nivel exigido.
Probar pérdida y recuperación
Registra un método alternativo, un responsable del desbloqueo y un procedimiento de emergencia antes de la aplicación.
El calendario ahora depende del grupo de release
Salesforce inició la aplicación en sandboxes en julio y dividió producción por grupos de instancias. La guía publicada el 14 de julio informa ventanas específicas: R2a y R2b comienzan el 10 de agosto y deben terminar el 17 y el 13 de agosto, respectivamente; Japón y Corea aparecen el 1 de septiembre y las demás instancias no listadas, el 3 de septiembre. Una fecha genérica no basta. Cada equipo debe identificar la instancia de su organización y consultar el grupo correspondiente.
Esa precisión importa porque el rollout ya se detuvo una vez. Salesforce Ben informó que la aplicación fue pausada brevemente después de que usuarios con llaves existentes recibieran solicitudes incorrectas para registrar nuevas credenciales. El proceso se reanudó con un calendario revisado. La conclusión práctica no es desconfiar del control, sino abandonar planes basados en un solo día: revisa el artículo oficial, valida primero en sandbox y prepara la comunicación para cambios de ventana.
Usuarios comunes y privilegiados no tienen la misma regla
Para usuarios internos sin privilegios elevados, Salesforce acepta MFA estándar o resistente al phishing. En el acceso directo, las opciones incluyen Salesforce Authenticator y aplicaciones TOTP, además de passkeys y llaves compatibles. Para usuarios privilegiados, el nivel sube: el perfil System Administrator o permisos como Modify All Data, View All Data, Customize Application y Author Apex colocan la cuenta en el alcance de MFA resistente al phishing. TOTP y aprobaciones push siguen siendo útiles para la población común, pero no cumplen por sí solos la exigencia privilegiada.
El inventario no puede limitarse al nombre del perfil. Permission sets y permission set groups pueden otorgar un permiso crítico a personas que nunca fueron llamadas administradoras. Una revisión segura cruza usuarios activos, perfiles y permisos efectivos, asigna un responsable a cada cuenta privilegiada y elimina accesos temporales que se volvieron permanentes. Este es el análisis de OrbTrail: reducir privilegios innecesarios disminuye al mismo tiempo la superficie de ataque y la población que necesita el método más estricto.
SSO no es una exención: Salesforce debe recibir la evidencia
En una federación, el proveedor de identidad puede mostrar que el MFA terminó y Salesforce aun así clasificar el acceso como débil. La razón está en las señales AMR y ACR de la aserción SAML o el token OIDC. La documentación de Salesforce organiza los métodos en tres niveles —resistente al phishing, MFA estándar y débil o sin MFA— y decide el resultado a partir del verificador directo o las señales del IdP. Una política correcta en Entra, Okta u otro proveedor no ayuda si Salesforce recibe una afirmación genérica, ausente o incompatible.
La prueba decisiva no es una captura de Conditional Access, sino una autenticación real por persona. Elige un usuario común y uno privilegiado, ejecuta el flujo completo en sandbox y confirma el método usado, las señales recibidas por Salesforce y si apareció una solicitud adicional de registro. En Microsoft Entra ID, las passkeys FIDO2 pueden asignarse por grupos con credenciales ligadas al dispositivo o sincronizadas, attestation y restricciones por AAGUID. La política debe reflejar el riesgo del grupo y la señal que la aplicación consumidora reconoce.
Las passkeys reducen el phishing, pero exigen decisiones de dispositivo y recuperación
Las passkeys y llaves WebAuthn eliminan el secreto reutilizable que una página falsa intentaría capturar. Aun así crean decisiones operativas. Una credencial ligada al dispositivo ofrece control fuerte, pero depende de ese hardware; una passkey sincronizada mejora la continuidad entre dispositivos, aunque incorpora al proveedor de sincronización en el modelo de confianza. Para administradores y funciones sensibles, la empresa debe decidir si exige attestation, restringe modelos de llave y entrega una segunda credencial antes de cualquier pérdida o sustitución.
La compatibilidad también forma parte del diseño. Salesforce informa que los autenticadores integrados no funcionan como verificador MFA en la aplicación móvil Salesforce, Experience Cloud, acceso por API o login OAuth de Data Loader; esos escenarios pueden necesitar un método alternativo. La recuperación no debe degradarse silenciosamente a un factor débil. Define quién puede desconectar un autenticador perdido, cómo validar la identidad, cuándo corresponde un código temporal de administrador y cómo auditar el evento.
Un plan que evita bloqueos el día de la aplicación
Primero, determina el alcance. Lista usuarios activos, ruta de acceso, dispositivo principal, uso móvil, privilegios efectivos y dependencia de cuentas compartidas o automatizaciones. Separa cuentas humanas de usuarios API-only y valida las exenciones legítimas con la documentación y, cuando corresponda, Salesforce Support; el permiso de dispensa no debe ser un atajo para usuarios internos. Después, elige el estándar por persona: MFA estándar para la población elegible, passkey o llave para privilegiados y políticas SSO capaces de emitir evidencia suficiente.
Segundo, prueba el recorrido completo. Registra al menos dos métodos para quien no puede perder acceso y prueba login directo y SSO, navegación móvil, Data Loader y recuperación de dispositivo. Mide tiempo, fallos por navegador o hardware y tickets abiertos. Tercero, publica instrucciones breves antes de la ventana de la instancia y prepara al service desk para distinguir registro de passkey, MFA estándar, activación de dispositivo y step-up authentication; mensajes similares pueden tener causas distintas.
Finalmente, trata la aplicación como un cambio controlado. Monitoriza fallos de acceso, usuarios no registrados, códigos temporales y solicitudes de recuperación durante las primeras horas. Mantén un administrador de emergencia protegido, con credenciales independientes y procedimiento probado, sin convertirlo en una cuenta cotidiana. Después de estabilizar, revisa permisos elevados y métodos obsoletos. El resultado esperado no es solo superar el enforcement, sino terminar con una arquitectura de identidad más clara y recuperable.
Conclusión: MFA ya forma parte de la arquitectura de plataforma
La exigencia de 2026 conecta configuración Salesforce, diseño de identidad, política de dispositivos y soporte. Activar MFA sigue siendo necesario, pero ya no es suficiente. La organización debe demostrar la fortaleza correcta para cada usuario, transmitir esa evidencia por SSO y recuperar acceso sin reabrir la puerta que el control intentó cerrar. Los equipos que prueban personas y fallos antes de su ventana convierten una obligación en reducción real de riesgo; quienes solo miran el toggle pueden descubrir la arquitectura en el peor momento.
