El año cero de Passkey en B2B: del consumidor a la empresa
Las Passkeys que Apple, Google y Microsoft promovieron conjuntamente entre 2022 y 2024 se popularizaron inicialmente como método de autenticación para consumidores. Sin embargo, desde la segunda mitad de 2025 la adopción B2B ha avanzado rápidamente, y 2026 puede llamarse el «año cero del despliegue de Passkeys en B2B». Okta, Entra ID, Google Workspace y 1Password Business soportan tanto Cross-Device Passkey como Passkeys sincronizadas, y han madurado para operar en coexistencia con llaves de seguridad compatibles con FIDO2 (YubiKey 5C, Google Titan).
La razón principal por la que las Passkeys se adoptan con seriedad en B2B es la resistencia al phishing. Entre 2024 y 2025 proliferaron kits de phishing AiTM (Adversary-in-the-Middle) dirigidos a empresas japonesas. Los tradicionales TOTP y SMS OTP son vulnerables a ataques de proxy de intermediario que secuestran sesiones de autenticación, y ocurrieron varios incidentes en los que miles de cuentas de grandes SaaS nacionales fueron comprometidas en una sola noche. Las Passkeys (WebAuthn) son estructuralmente resistentes a AiTM porque el binding de dominio impide que la firma tenga validez en un sitio de phishing. Que la seguridad esté «garantizada por el protocolo» y no por la precaución del usuario fue el argumento decisivo para la dirección.
El debate sobre la compensación entre Passkeys sincronizadas (vía iCloud Keychain o Google Password Manager) y Passkeys vinculadas al dispositivo (restringidas al YubiKey u otro hardware) sigue abierto. Los sectores financiero y de defensa prefieren el vínculo al dispositivo; para despliegues masivos entre empleados, las Passkeys sincronizadas son más prácticas. La revisión de NIST SP 800-63B de 2025, que reconoció las Passkeys sincronizadas como AAL2, ha favorecido la definición de políticas.
Escollos en la implementación de WebAuthn y recuperación de cuentas
El primer error habitual es el diseño del RP ID (Relying Party ID). Como el RP ID es por dominio, `corp.example.jp` y `portal.example.jp` requieren registros de Passkey separados. Para unificarlos habría que usar `example.jp` como RP ID, pero si ese dominio se comparte con el sitio de marketing, el impacto debe evaluarse con cuidado.
La recuperación de cuentas es el mayor punto crítico en la operación de Passkeys. Si no se diseña bien, el mecanismo de respaldo sigue siendo una autenticación débil (OTP por email o SMS) y el nivel de seguridad queda limitado por ese respaldo. El diseño recomendado tiene tres capas. La recuperación leve (inicio de sesión desde otro dispositivo) se resuelve automáticamente con Passkeys sincronizadas; la recuperación moderada (pérdida de todos los dispositivos) requiere aprobación del administrador más verificación de identidad; la recuperación grave (sospecha de alteración de identidad) exige verificación de identidad presencial. Es importante también que la recuperación grave no pase por el canal de atención al cliente (CS), ya que en 2024 ocurrió al menos un caso real de compromiso mediante ingeniería social al CS.
SCIM y automatización del provisionamiento
El aprovisionamiento automático con SCIM 2.0 ya no es una opción, es un prerequisito. La sincronización SCIM desde el IdP a cada SaaS propaga en tiempo real las altas de usuarios, actualizaciones de atributos y bajas. Los principales SaaS (Salesforce, Slack, Notion, GitHub Enterprise, Atlassian) ofrecen SCIM 2.0 de forma estándar, y la calidad de las implementaciones del lado receptor ha mejorado notablemente respecto a 2024.
Lo que suele pasarse por alto en la operación de SCIM es el diseño del mapeo de atributos. El mapeo de departamento, cargo y tipo de contrato del IdP a los grupos y roles del SaaS debe mantenerse en una tabla que RR. HH. e informática puedan gestionar conjuntamente. Okta Workflows y Entra Lifecycle Workflows tienen una UI no-code que permite expresar las transformaciones con cadenas de condiciones if. Las transformaciones de atributos basadas en scripts suelen quedarse obsoletas ante cambios ocurridos seis meses después. En 2026 aumentan las auditorías internas que solicitan un plan para abandonar la sincronización diaria por CSV.
De SAML a OIDC: ¿por qué ahora?
SAML fue el estándar de SSO B2B durante años, pero en 2026 los nuevos proyectos adoptan OIDC como primera opción. Las razones son tres. Primera, la compatibilidad con móvil y SPA: el flujo de redirección XML de SAML es más engorroso que OIDC con PKCE en apps móviles nativas. Segunda, la complejidad de la firma y el cifrado: la especificación XML Signature de SAML es amplia y a lo largo de la historia ha generado frecuentes vulnerabilidades por diferencias de implementación (como los ataques XML Signature Wrapping). Tercera, la separación estructural entre autenticación (ID Token) y autorización de API (Access Token) simplifica el diseño de permisos en entornos de microservicios.
Sin embargo, eliminar SAML por completo no es realista. SAP SuccessFactors, Workday y algunos módulos de Oracle Cloud solo ofrecen SAML como SSO. La estrategia de migración es: «OIDC para lo nuevo, SAML existente se mantiene por ahora, se consolida el IdP en una plataforma que soporte ambos». El mayor problema en la migración es la «diferencia en el mapeo de atributos»: al trasladar la lógica de transformación de Assertions de SAML acumulada durante años al diseño de claims de OIDC, son frecuentes los conflictos de nombres de grupo y las inconsistencias en el scope de roles. Antes de migrar, es imprescindible el paso de «listar todos los atributos del SAML Assertion actual y crear la tabla de correspondencia a claims estándar y personalizados de OIDC».
MFA adaptativo y autenticación step-up
El MFA adaptativo ajusta dinámicamente la intensidad de la autenticación según el contexto de la solicitud. Habitualmente se deja pasar solo con Passkey, pero se exige autenticación adicional cuando el acceso se produce desde un dispositivo desconocido, en horario nocturno o desde un país nunca visto. La autenticación step-up es un subconjunto: antes de operaciones de alto riesgo como «consulta de datos salariales», «despliegue en producción» o «exportación masiva de datos de clientes», se reevalúa la intensidad de autenticación de la sesión actual y, si no es suficiente, se solicita autenticación adicional. El estándar es declarar mediante el claim `acr` (Authentication Context Class Reference) de OIDC que «esta operación requiere `acr=phr` (phishing-resistant)».
Lo más difícil en el diseño es «el umbral de tolerancia a los falsos positivos». Si es demasiado estricto, el trabajo se detiene; si es demasiado laxo, se pasan por alto compromisos. La regla empírica del autor es empezar con «dispositivo conocido + geografía conocida = solo Passkey» y «dispositivo desconocido = Passkey + step-up», y ajustar mensualmente la tasa de falsos positivos y el historial de incidentes.
Colisiones típicas en empresas japonesas: número personal y cuentas compartidas
Al impulsar Passkeys, SCIM y OIDC en empresas japonesas, surgen fricciones culturales que no aparecen en la documentación de proveedores extranjeros. La primera es «el manejo del número de empleado y el número personal (My Number)». El número personal está sujeto a un uso estrictamente limitado por la Ley del Número de Identificación, y no debe incluirse en el claim `sub` del IdP ni en el `externalId` de SCIM. Sin embargo, en la práctica existen sistemas core que vinculan el número de empleado con el número personal, y se producen incidentes en los que el número personal se filtra a SaaS externos durante el diseño de la sincronización SCIM. La tabla de mapeo de atributos debe incluir obligatoriamente una lista de verificación de «atributos prohibidos de exportar».
La segunda es la colisión con la «cultura de las cuentas compartidas». En empresas pequeñas y medianas japonesas subsisten cuentas compartidas por cargo como `soumu@` o `keiri@`. Como las Passkeys están vinculadas al autenticador personal de cada individuo, asignar Passkeys a cuentas compartidas hace imposible rastrear quién inició sesión. La estrategia de migración es separar las cuentas compartidas en cuentas funcionales (service accounts) para recibir correos y cuentas personales para iniciar sesión. Si se prioriza la trazabilidad del log de auditoría, la única solución es eliminar completamente el inicio de sesión compartido. La tercera colisión es «la mezcla de dispositivos corporativos y BYOD»: la solución práctica es Passkeys sincronizadas para dispositivos gestionados y llave de hardware obligatoria para BYOD.
Hoja de ruta para la migración
Hoja de ruta de 12 a 18 meses. Etapa 1 (0–3 meses): consolidar la infraestructura del IdP, habilitar soporte dual SAML/OIDC e inventariar los SaaS que admiten SCIM. Etapa 2 (3–6 meses): piloto de Passkeys, primeras políticas de MFA adaptativo y automatización SCIM en los 10 SaaS prioritarios. Etapa 3 (6–12 meses): despliegue de Passkeys en toda la organización, eliminación gradual de TOTP y SMS OTP, integración de step-up en las aplicaciones. Etapa 4 (12–18 meses): prohibición de nuevas implementaciones SAML, decisión de migrar o retirar los SAML legados a OIDC, eliminación total de cuentas compartidas. Para la presentación a la dirección, los dos ejes más efectivos son «el costo estimado de un incidente AiTM» y «la reducción de horas dedicadas a auditorías». La infraestructura de gestión de identidades que integra el IdP como eje central con RR. HH., ZTNA y el ecosistema de SaaS está dejando de ser un proyecto puntual para convertirse en una capacidad organizacional permanente.