Las passkeys son credenciales que permiten iniciar sesión mediante criptografía de clave pública y desbloqueo local del dispositivo, sin contraseña. Si tu empresa utiliza Microsoft Entra ID, revisa ahora quién sigue autenticándose por SMS o llamada: Microsoft ha iniciado una transición con plazos. No afecta de la misma forma a todas las cuentas ni a todos los servicios.
¿Qué es una passkey y por qué interesa a una pyme?
Como ejemplo hipotético, piensa en una asesoría con varios empleados que entran a aplicaciones de facturación, correo y documentos compartidos. Cada cambio de teléfono provoca una llamada para recuperar el acceso. A veces el código llega tarde; otras, alguien confunde un mensaje legítimo con un intento de suplantación. El problema no es recordar contraseñas: es depender de un acceso frágil para trabajar cada mañana.
Una passkey utiliza un par de claves criptográficas. El servicio conserva una clave pública; la clave privada permanece protegida en el dispositivo o gestor compatible. Para usarla, la persona desbloquea el dispositivo con su método local, como PIN o biometría. Según la documentación de Google sobre passkeys, la biometría no se envía al sitio web como parte de ese proceso.
La ventaja de seguridad más importante es la resistencia al phishing: la credencial está vinculada al dominio o aplicación para la que se creó. Una página falsa no debería poder obtener una autenticación válida para el sitio auténtico. Esto no significa que una cuenta sea invulnerable: siguen existiendo riesgos de dispositivos comprometidos, errores de configuración, sesiones abiertas o recuperación de cuentas mal diseñada.
Conviene distinguir tres términos que suelen mezclarse. Contraseña es un secreto que el usuario conoce; código SMS es un método de verificación enviado por un canal de telecomunicaciones; passkey es una credencial criptográfica. Algunas passkeys se sincronizan mediante un gestor; otras están vinculadas a un dispositivo o llave física FIDO2. La elección depende de la sensibilidad de la cuenta y de las políticas de la organización.
¿Qué cambia en Microsoft Entra entre 2026 y 2027?
El motivo de actualidad es concreto. En sus preguntas frecuentes oficiales, actualizadas el 23 de septiembre de 2026, Microsoft explica que desde el 1 de septiembre de 2026 habilita passkeys para determinados usuarios que tenían SMS o voz configurados. La transición se realiza por etapas y requiere revisar la política de autenticación de cada entorno.
La misma documentación sitúa el 1 de febrero de 2027 como fecha de retirada de los métodos SMS y voz proporcionados por Microsoft para gran parte de los usuarios afectados. Para administradores globales y determinados usuarios externos, señala el 1 de julio de 2027. Existen matices para invitados internos, entornos de nube distintos y opciones de proveedores de telefonía. No conviertas esas fechas en una norma universal para cualquier cuenta Microsoft.
Además, Microsoft aclara que no todos los usuarios quedarán sin acceso de forma automática. En determinados casos, quien solo tenga SMS o voz deberá registrar una passkey antes de continuar. Eso puede traducirse en una interrupción operativa si la empresa no ha preparado dispositivos, soporte y recuperación. La propia documentación contempla escenarios y alternativas específicas; hay que revisar la versión vigente antes de ejecutar cambios.
Una integración también puede depender de quién concedió una autorización y cómo se renueva. Revisa esos vínculos con el responsable técnico antes de cambiar métodos de acceso: una cuenta de usuario y una identidad de aplicación no son intercambiables.
Para una pyme, la pregunta útil es qué accesos dependen de una persona concreta y qué pasaría si mañana no pudiera autenticarse. El impacto suele descubrirse cuando falla una conexión que nadie había documentado.
¿Cómo saber qué accesos de la empresa requieren atención?
No empieces comprando llaves físicas para todo el mundo. Empieza con un inventario. Incluye correo, administración del dominio, publicidad, tienda online, CRM, gestor documental, facturación, herramientas no-code y cuentas técnicas utilizadas por integraciones. Identifica propietario, método de acceso y procedimiento de recuperación.
| Acceso | Qué revisar | Señal de riesgo |
|---|---|---|
| Administración | Quién tiene privilegios elevados | Una sola persona puede recuperar la cuenta |
| Correo y documentos | Método MFA y dispositivos registrados | Depende de un SMS a un móvil antiguo |
| Publicidad e integraciones | Autorizaciones y tokens OAuth | Nadie sabe quién concedió el permiso |
| Software de negocio | Compatibilidad con passkeys | La aplicación solo admite contraseña |
| Cuentas compartidas | Titularidad y auditoría | Varias personas usan el mismo usuario |
Revisa también la diferencia entre autenticación de usuarios y autenticación de aplicaciones. Un proceso automatizado que accede mediante OAuth o una identidad de servicio no se gestiona igual que un empleado. No sustituyas sin análisis un token por una contraseña guardada en un flujo: podrías reducir la seguridad y hacer más difícil la renovación.
Microsoft publica una guía específica para habilitar y gestionar passkeys en Entra. Úsala para confirmar requisitos de dispositivos, políticas y restricciones de tu entorno. No todas las funciones están disponibles para todos los perfiles y versiones.
¿Qué ocurre si se pierde el móvil o la llave de seguridad?
La pregunta aparece en cuanto alguien entiende que la clave privada no está en la web. Si pierde el teléfono, ¿pierde también su trabajo? La respuesta depende de si la passkey está sincronizada en un gestor compatible, vinculada a un dispositivo concreto o almacenada en una llave física. La recuperación no puede improvisarse durante una incidencia.
Define al menos dos caminos autorizados para recuperar una cuenta crítica, sujetos a las políticas del proveedor. Puede intervenir otro autenticador previamente registrado, un proceso de soporte con verificación de identidad o una recuperación administrada. No todos esos métodos están disponibles en cualquier servicio, y habilitar una alternativa débil puede neutralizar parte de la mejora de seguridad.
Imagina que la responsable de una tienda pierde el móvil mientras viaja. Si su acceso a los anuncios depende de ese único dispositivo, la campaña puede seguir funcionando pero el equipo no podrá gestionar una incidencia. El objetivo de la transición no es que todo dependa de un aparato más moderno, sino que la empresa conserve continuidad y control.
Documenta también el procedimiento de baja. Cuando una persona sale del equipo, hay que revocar sesiones, credenciales y permisos conforme al sistema correspondiente. El cambio a passkeys no sustituye una política de altas y bajas. La autenticación protege la entrada; la autorización determina lo que alguien puede hacer una vez dentro.
¿Cómo implantar passkeys sin bloquear el trabajo?
Propón un piloto pequeño y representativo: una persona de administración, otra que trabaja fuera de la oficina y alguien con acceso a herramientas críticas. Comprueba el registro, el acceso habitual, el cambio de dispositivo y la recuperación. No basta con que el primer inicio de sesión funcione. El caso difícil es el día en que algo falla.
Antes del despliegue, comunica qué cambiará y qué no. Una passkey puede desbloquearse con huella, reconocimiento facial o PIN local; no implica que la empresa reciba una copia de la huella. Explica quién puede solicitar ayuda y qué datos no debe compartir nunca, especialmente ante mensajes inesperados que pidan códigos o aprobaciones.
Durante la migración, registra las excepciones: cuentas de proveedores, terminales antiguos, equipos compartidos, usuarios invitados y conexiones automatizadas. Cada excepción debe tener un responsable y una decisión: adaptar, sustituir, mantener temporalmente con controles o revisar con el fabricante. Una política única no resuelve entornos distintos.
Tras el cambio, revisa accesos fallidos y solicitudes de recuperación. Si se multiplican, quizá el problema no sea la tecnología sino una instrucción confusa o una incompatibilidad no detectada. Ajusta el proceso sin relajar indiscriminadamente los controles. La meta es un acceso más seguro que siga siendo usable, no una demostración técnica.
Cómo lo hemos abordado en meiika
En meiika diseñamos sistemas a medida atendiendo también a quién accede, qué permisos necesita y cómo se mantiene el servicio cuando cambia el equipo. En proyectos conectados, el acceso no es un detalle final: condiciona la continuidad de las integraciones.
También contemplamos los límites de los agentes de autogestión. Un agente no debería heredar credenciales personales sin control ni operar con permisos más amplios de los necesarios. No afirmamos que una configuración concreta sea segura sin revisar el entorno real.