Durante años, el acceso a una cuenta se resolvió con una pantalla conocida: correo electrónico, contraseña y, si el riesgo lo justificaba, un segundo código. Las passkeys cambian esa lógica. En lugar de pedir a la persona que recuerde un secreto compartido con el sitio, usan credenciales criptográficas administradas mediante el dispositivo, el navegador y un autenticador compatible.
La publicación de Web Authentication Level 3 como Candidate Recommendation Snapshot el 26 de mayo de 2026 es una señal relevante para equipos web: la conversación ya no es si la autenticación sin contraseña existe, sino cómo incorporarla sin crear nuevos puntos de bloqueo para usuarios y para la operación.
Una autenticación más sólida solo es una mejora completa cuando la persona puede entrar, recuperar su acceso y entender qué está ocurriendo sin depender de improvisaciones.
Qué cambia realmente con una passkey
En la web, las passkeys se apoyan en WebAuthn. El sitio no recibe ni guarda una contraseña equivalente: durante el registro se crea una credencial de clave pública asociada a la relying party, normalmente el dominio del servicio. Al iniciar sesión, el servidor plantea un desafío y el autenticador produce una respuesta firmada que el servidor puede verificar.
Esto aporta una propiedad importante: la credencial está delimitada por el sitio para el que se creó. La especificación de W3C explica que el navegador media ese acceso y que las credenciales no se exponen directamente a los scripts de la página. No significa que desaparezcan todos los riesgos, pero sí que se reemplaza el patrón de contraseña reutilizable por otro modelo.
Además, WebAuthn está disponible de forma amplia en navegadores modernos y requiere HTTPS, según la documentación de MDN Web Docs. Esa disponibilidad reduce una barrera técnica, pero no resuelve por sí sola la experiencia completa.
La novedad no es solo el estándar: es el momento de revisar el acceso
Para un sitio institucional sin cuentas, las passkeys probablemente no son una prioridad. Para una plataforma de clientes, un portal de proveedores, una membresía, una intranet o una aplicación con datos sensibles, sí pueden justificar una revisión seria.
El motivo no es perseguir una tecnología de moda. Es que el inicio de sesión concentra problemas que afectan conversión, soporte y seguridad: contraseñas olvidadas, intentos de phishing, códigos que no llegan, dispositivos nuevos y cuentas compartidas sin reglas claras.
Los navegadores y gestores de credenciales también están reduciendo la fricción de adopción. Por ejemplo, Chrome documentó en mayo de 2025 una opción para solicitar la creación automática de una passkey cuando existe una contraseña guardada y usada recientemente, sin obligar a reemplazar de inmediato los métodos anteriores. La documentación de Chrome ilustra una idea práctica: la migración puede ser gradual.
Cuándo conviene evaluar passkeys
La decisión tiene más sentido cuando el acceso es una parte importante de la experiencia o del riesgo operativo. Estas son señales útiles:
- El equipo recibe muchas consultas por recuperación de contraseña o bloqueo de cuentas.
- Los usuarios vuelven con frecuencia desde celular y computadora.
- Hay información personal, documentación privada, operaciones o aprobaciones dentro del área autenticada.
- Una cuenta comprometida puede generar costos, fraude o exposición de datos.
- El registro y el acceso son pasos relevantes para una venta, reserva, trámite o uso recurrente.
- La organización puede mantener métodos de recuperación y atención documentados.
En cambio, conviene postergar la iniciativa si todavía no están claros los roles de usuario, si el sistema no tiene HTTPS correctamente implementado, si el dominio principal cambia sin planificación o si nadie podrá atender los casos excepcionales. Una passkey no compensa una arquitectura de cuentas desordenada.
Cuatro decisiones que deben tomarse antes de programar
1. Definir si será alternativa o requisito
El camino prudente suele ser ofrecer passkeys como alternativa después de un acceso exitoso con el método existente. Eso permite observar adopción y fallos sin dejar afuera a quienes todavía necesitan contraseña, enlace de un solo uso o un proveedor de identidad.
Exigir passkeys desde el primer día puede ser adecuado en entornos controlados, pero requiere una estrategia de alta, dispositivos permitidos y contingencias mucho más estricta.
2. Diseñar recuperación sin debilitar el sistema
Perder un dispositivo, cambiar de teléfono o usar un equipo compartido no debería terminar en una cuenta irrecuperable. Pero un canal de recuperación demasiado débil puede transformarse en el nuevo punto de ataque.
Definí qué evidencia se pide, quién puede aprobar excepciones, cuánto demora la recuperación, qué notificaciones se envían y cómo se registra cada cambio. El objetivo no es sumar pasos por precaución: es evitar que un soporte improvisado invalide la mejora de seguridad.
3. Revisar dominios y recorridos reales
WebAuthn vincula credenciales a una relying party identificada por dominio. Por eso, una experiencia dividida entre dominios, subdominios o marcas debe analizarse antes de lanzar. También hay que probar el flujo en el navegador y los dispositivos que realmente utiliza la audiencia, no solo en el equipo de desarrollo.
4. Medir sin convertir el acceso en una caja negra
No alcanza con contar cuántas passkeys se crean. Conviene medir, de forma respetuosa con la privacidad, el inicio de registro, la finalización, los accesos exitosos, los abandonos, los usos de recuperación y los contactos a soporte. Estas señales permiten descubrir si el problema está en la interfaz, en un dispositivo concreto o en una regla operativa.
Un plan de adopción razonable
- Mapeá el acceso actual. Identificá métodos de inicio, recuperación, dominios, proveedores externos, roles y usuarios críticos.
- Elegí un caso acotado. Empezá por empleados, clientes recurrentes o una sección privada con una población conocida.
- Conservá una alternativa controlada. La transición no tiene por qué ser todo o nada; definí cuál será el respaldo y bajo qué condiciones se usará.
- Escribí los mensajes para personas reales. Explicá qué es la passkey, cuándo se crea, en qué dispositivo puede estar disponible y qué hacer si cambia de equipo.
- Probá excepciones. Validá equipos nuevos, passkeys no disponibles, cuentas con varios dispositivos, recuperación y desactivación de una credencial.
- Revisá resultados y soporte. Ajustá el flujo con evidencia antes de ampliar el alcance.
Conclusión: no se trata de quitar un campo de contraseña
WebAuthn Level 3 muestra la madurez de una base técnica para autenticación fuerte en la web. La oportunidad para un proyecto no está en anunciar que usa passkeys, sino en reducir fricción y exposición sin dejar a las personas sin salida cuando algo cambia.
La próxima acción útil es simple: reuní a producto, desarrollo y soporte, dibujá el recorrido actual de acceso y recuperación, y señalá dónde se pierden usuarios o se generan incidentes. Si la passkey resuelve una parte concreta de ese recorrido, vale la pena planificar un piloto.
¿Tu sitio necesita un área privada, registro o acceso más seguro? En Ideasweb desarrollamos sitios web con funcionalidades alineadas al recorrido de usuarios, la operación y los objetivos del proyecto.
