Autenticación multifactor: Salesforce valida el uso de passkeys

En el dinámico panorama de la ciberseguridad empresarial, las reglas del juego han cambiado de manera drástica e irreversible. Las organizaciones ya no pueden permitirse el lujo de depender de defensas de identidad estáticas o fácilmente eludibles. Con la llegada de los plazos definitivos impuestos por Salesforce para la implementación de su mandato de seguridad más estricto hasta la fecha, la autenticación multifactor ha dejado de ser una simple casilla de verificación de cumplimiento regulatorio para convertirse en un sofisticado campo de batalla criptográfico. Con la aplicación obligatoria iniciada en entornos Sandbox el 22 de junio de 2026, y el despliegue definitivo en entornos de producción programado para el 1 de julio de 2026, todos los usuarios con privilegios elevados dentro del ecosistema de Salesforce deben verificar su identidad utilizando métodos estrictamente resistentes al phishing.

Esta medida representa una de las transiciones de seguridad más agresivas e importantes de la década. Sin embargo, también generó un clima de incertidumbre y preocupación en los departamentos de TI de todo el mundo. La documentación inicial de Salesforce sugería que solo los factores de autenticación físicos o estrictamente “ligados al dispositivo” serían aceptados para los usuarios administradores. Esto hacía temer una pesadilla logística que implicaba la compra, distribución y soporte de miles de llaves de seguridad físicas de hardware. Afortunadamente, una aclaración oficial de política emitida el 26 de junio de 2026 ha traído un enorme suspiro de alivio a la comunidad de tecnología, validando el uso de gestores de contraseñas modernos basados en estándares FIDO2.

La evolución hacia una autenticación multifactor resistente al phishing

Para comprender el alcance de esta nueva directiva, es imperativo analizar por qué los métodos tradicionales que antes considerábamos “seguros” ya no son suficientes. Durante años, la autenticación multifactor basada en códigos de un solo uso enviados por SMS, correos electrónicos o aplicaciones de autenticación tradicionales (TOTP de 6 dígitos) sirvió como una sólida segunda línea de defensa. Sin embargo, la sofisticación de las amenazas modernas, potenciadas por motores de inteligencia artificial capaces de automatizar ataques de ingeniería social a gran escala, ha vuelto obsoletos estos mecanismos tradicionales.

El principal vector de vulnerabilidad reside en los ataques de “Adversario en el Medio” (AitM, por sus siglas en inglés). En este escenario, los ciberdelincuentes no necesitan “romper” la criptografía de un sistema; simplemente engañan al usuario para que ingrese sus credenciales y su código TOTP de 6 dígitos en una página web clonada que actúa como proxy en tiempo real. El servidor del atacante intercepta estos datos, los reenvía instantáneamente al portal legítimo de Salesforce, inicia sesión y extrae las cookies de sesión activa. A partir de ese momento, el atacante tiene acceso total, saltándose por completo la MFA tradicional.

La resistencia al phishing que exige Salesforce a partir de este verano requiere un canal de autenticación criptográficamente vinculado al dominio del sitio web real. Mediante el uso del protocolo WebAuthn (FIDO2), el navegador web del usuario y el autenticador realizan un intercambio de claves públicas que solo puede tener éxito si el dominio coincide de forma exacta y matemática con el sitio web registrado. Incluso si un usuario es engañado para interactuar con un portal de phishing idéntico, el intercambio criptográfico fallará automáticamente porque el dominio no coincidirá, bloqueando el ataque de inmediato.

La aclaración de junio de 2026: Salvados por las Passkeys en la nube

Hasta hace muy poco, el ecosistema de administradores de Salesforce se encontraba en un estado de alerta. Las directivas previas apuntaban a que los métodos válidos se limitarían estrictamente a autenticadores integrados en el hardware del equipo (como Apple Touch ID o Windows Hello) o a llaves de seguridad físicas USB/NFC (como las fabricadas por Yubico o Google). Esto creaba una barrera operativa insalvable para las empresas que trabajan con consultores externos, equipos de desarrollo distribuidos globalmente o entornos de soporte compartido que requerían el acceso concurrente de varios administradores a una misma cuenta de Salesforce Partner.

La actualización del 26 de junio de 2026 a las directrices de Salesforce resolvió este dilema de manera elegante. La compañía confirmó de forma explícita que las llaves de acceso (passkeys) sincronizadas en la nube y almacenadas dentro de gestores de contraseñas empresariales compatibles con FIDO2/WebAuthn (tales como 1Password, Bitwarden e iCloud Keychain) son plenamente aceptadas y cumplen formalmente con los estrictos requisitos de resistencia al phishing de la nueva normativa.

Este cambio de política permite que las organizaciones aprovechen la infraestructura de software que ya tienen desplegada. En lugar de gestionar la logística de enviar y reemplazar dispositivos físicos de hardware a trabajadores remotos o terceros, los equipos de TI pueden simplemente instruir a sus administradores para que registren una passkey FIDO2 dentro de sus bóvedas corporativas de contraseñas. Al estar cifradas de extremo a extremo y sincronizadas de manera segura, estas passkeys ofrecen la inmunidad contra el phishing del protocolo FIDO2 junto con la flexibilidad operativa de los entornos de nube compartidos.

La delgada línea técnica: Rellenar credenciales tradicionales vs. Auténticas Passkeys

A pesar de las buenas noticias, los expertos en seguridad advierten que existe un malentendido crítico que los administradores de TI deben corregir de inmediato. Simplemente utilizar un gestor de contraseñas para rellenar de forma automática el usuario y la contraseña tradicional, y posteriormente copiar un código de verificación de 6 dígitos (TOTP) almacenado en el mismo gestor, no cumple con el nuevo mandato de Salesforce.

La diferencia técnica radica en el protocolo que se utiliza durante el inicio de sesión:

• El escenario no conforme: El gestor de contraseñas actúa únicamente como una base de datos de credenciales estáticas y un generador de tokens de tiempo (TOTP). Este flujo sigue siendo vulnerable a ataques de intermediario (AitM) porque el usuario final o un script malicioso todavía puede copiar y pegar esos datos en un sitio falso.
• El escenario conforme: El gestor de contraseñas actúa como un autenticador WebAuthn (FIDO2) activo. Durante el proceso de inicio de sesión, el navegador solicita un desafío criptográfico que el gestor de contraseñas firma digitalmente de manera local. No hay códigos que copiar, ni contraseñas que interceptar; todo el proceso ocurre a través de un canal seguro y encriptado que valida la autenticidad del dominio de Salesforce.

¿Quiénes están en la línea de fuego? Usuarios y permisos afectados

Es fundamental comprender que esta estricta exigencia de resistencia al phishing no se aplica de manera uniforme a todos los empleados de una organización, sino que apunta directamente a lo que Salesforce define como “los poseedores de las llaves del reino digital”. El mandato se activa de manera técnica y obligatoria para todos aquellos usuarios internos que cuenten con privilegios elevados o perfiles de administración.

Específicamente, el sistema bloqueará el acceso tradicional y requerirá la verificación phishing-resistant a cualquier usuario que posea el perfil de Administrador de Sistema (System Administrator) o que tenga asignados permisos y conjuntos de permisos que incluyan las siguientes capacidades:

• Modify All Data (Modificar todos los datos).
• View All Data (Ver todos los datos).
• Customize Application (Personalizar aplicación).
• Author Apex (Crear Apex / Desarrollar código).

Para ayudar a las empresas a planificar su transición tecnológica antes de la fecha límite del 1 de julio de 2026, a continuación se desglosa la clasificación de los factores de autenticación según la postura oficial de Salesforce:

1. Métodos phishing-resistant autorizados (Cumplen con el mandato):
   • Autenticadores integrados en el hardware del dispositivo (Apple Touch ID, Face ID, Windows Hello).
   • Llaves de acceso (passkeys) gestionadas y sincronizadas mediante gestores de contraseñas compatibles con FIDO2/WebAuthn (como 1Password, Bitwarden, iCloud Keychain).
   • Llaves físicas de seguridad de hardware (YubiKeys de Yubico o llaves Titan de Google conectadas vía USB, NFC o Bluetooth).
   • Autenticación Basada en Certificados (CBA) utilizando certificados de cliente x.509 firmados e instalados en los dispositivos corporativos.
2. Métodos estándar (Ya no son válidos para usuarios privilegiados a partir de julio de 2026):
   • Códigos de verificación enviados por Mensajes de Texto (SMS).
   • Códigos de verificación enviados por correo electrónico.
   • Notificaciones push enviadas a través de la aplicación nativa Salesforce Authenticator.
   • Códigos TOTP tradicionales generados por aplicaciones de terceros como Google Authenticator o Microsoft Authenticator.

El peligro invisible del SSO: El “Gotcha” que puede bloquear a tus administradores

Para las medianas y grandes empresas que utilizan proveedores de identidad centralizados (IdP) como Microsoft Entra ID (antes Azure AD), Okta o Ping Identity para gestionar el acceso mediante Single Sign-On (SSO), existe un componente técnico crítico que podría pasar desapercibido y provocar bloqueos masivos el 1 de julio de 2026.

Cuando un administrador inicia sesión en Salesforce a través de SSO, Salesforce no tiene visibilidad directa de la interacción física entre el usuario y su dispositivo. En su lugar, el sistema depende enteramente de la aserción de seguridad (el token SAML o el token OIDC) enviada por el IdP. Si las aserciones enviadas por el IdP no notifican explícitamente que el usuario se ha autenticado mediante un método resistente al phishing, Salesforce interpretará que el usuario empleó un método de MFA estándar no conforme, impidiendo su acceso inmediatamente.

Por ejemplo, si un administrador se autentica en Microsoft Entra ID con su contraseña y una notificación push convencional en su teléfono móvil, el IdP transmitirá en el token SAML el valor de referencia de contexto como multipleauthn o un equivalente estándar. Para Salesforce, este valor de aserción pertenece al nivel de MFA estándar, lo que resultará en que el usuario sea rechazado en la puerta de acceso de producción a partir de julio de 2026.

Para solucionar esto de manera preventiva, los ingenieros de sistemas deben configurar sus políticas de acceso condicional en el IdP para exigir métodos basados en FIDO2 y mapear correctamente las declaraciones en los tokens de identidad. Los IdP deben emitir aserciones específicas que Salesforce reconozca como válidas, tales como fido, fido2, hwk, swk o X509. Sin estas aserciones explícitas configuradas en la infraestructura interna de SSO, incluso los administradores que utilicen tecnologías seguras serán bloqueados por falta de una correcta comunicación entre sistemas.

Plan de acción inmediato para administradores y líderes de TI

Ante la inminencia del despliegue masivo y gradual en los entornos de producción a partir del 1 de julio de 2026, las áreas de tecnología deben ejecutar de inmediato una estrategia de transición estructurada. Ignorar este cambio normativo no solo interrumpirá las operaciones del día a día, sino que podría dejar huérfanos de soporte técnico los flujos críticos de negocio durante las ventanas de mantenimiento.

El camino más rápido y eficiente para alcanzar el cumplimiento de manera segura se compone de cuatro pasos clave:

1. Ejecutar una auditoría de roles y permisos: Se debe extraer un informe completo desde la sección de Configuración de Salesforce para identificar a cada usuario que posea el perfil de Administrador de Sistema, así como a aquellos que tengan asignados conjuntos de permisos que otorguen Modify All Data, View All Data, Customize Application o Author Apex.
2. Habilitar el soporte WebAuthn en Salesforce: Dentro del panel de Verificación de Identidad de la plataforma, es necesario activar las casillas que permiten a los usuarios registrar autenticadores integrados (passkeys) y llaves de seguridad físicas.
3. Coordinar el despliegue de Passkeys corporativas: En lugar de iniciar compras masivas de hardware costoso, se debe verificar que el gestor de contraseñas corporativo de la organización (como Bitwarden o 1Password) esté configurado para soportar el almacenamiento y la generación de passkeys FIDO2. Instruya a los administradores auditados para que generen y guarden una passkey específica de Salesforce dentro del gestor.
4. Auditar las aserciones de SSO: Si su organización utiliza Single Sign-On, se debe utilizar un analizador de trazas SAML (SAML Tracer) durante el inicio de sesión de un administrador de pruebas para certificar que el proveedor de identidad está transmitiendo la etiqueta criptográfica adecuada hacia Salesforce.

La ciberseguridad moderna requiere que abandonemos los métodos obsoletos que dependen de la infalibilidad humana y avancemos hacia defensas basadas en matemáticas y criptografía asimétrica. Al abrir la puerta de manera oficial a los gestores de contraseñas compatibles con FIDO2, Salesforce ha encontrado el equilibrio ideal entre la rigurosidad técnica necesaria para frenar las amenazas del mañana y la flexibilidad operativa imprescindible para mantener la agilidad de los negocios en el día a día