Passkeys y la extensión PRF de WebAuthn para el cifrado de extremo a extremo (2025)

WebAuthn y las Passkeys han revolucionado la autenticación web, ofreciendo inicios de sesión sin contraseña y resistentes al phishing mediante criptografía de clave pública. Pero sus capacidades van más allá de los inicios de sesión. Una característica interesante es la extensión de Función Pseudoaleatoria (PRF) de WebAuthn. Esta extensión permite a las aplicaciones web derivar claves secretas directamente de la passkey de un usuario o de una llave de seguridad de hardware durante la autenticación. Esto abre la puerta al cifrado de datos de extremo a extremo o al descifrado de una bóveda segura usando solo tu passkey, sin necesidad de una contraseña adicional. En este artículo, queremos responder a las siguientes preguntas:

• Casos de uso de la PRF para Passkeys: ¿Cuáles son los casos de uso interesantes para la extensión PRF de WebAuthn?
• Compatibilidad de la extensión PRF: ¿Cuál es la compatibilidad real actual de la extensión PRF de WebAuthn en los sistemas operativos y navegadores de hoy en día?

Este artículo analiza la extensión PRF de WebAuthn, explorando sus especificaciones técnicas, casos de uso, detalles de implementación, consideraciones de seguridad y el panorama actual de compatibilidad en navegadores y sistemas operativos. Nos centramos en los cambios en el ecosistema de 2025 y ampliamos el trabajo preliminar establecido por Matthew Miller y Levi Schuck en 2023, cuyos artículos anteriores ofrecen un trasfondo técnico detallado, ejemplos en vivo y pruebas en línea (incluido el cifrado).

La extensión PRF de WebAuthn (PRF) se define formalmente en la especificación de WebAuthn Nivel 3. Su propósito principal es permitir que una Relying Party (tu aplicación web) solicite la evaluación de una función pseudoaleatoria asociada con una credencial de WebAuthn específica (passkey) durante una ceremonia de autenticación (navigator.credentials.get()).

Una PRF toma una clave secreta (almacenada de forma segura dentro del autenticador y vinculada a la credencial) y uno o más valores de entrada (proporcionados por la Relying Party) para producir una salida determinista y criptográficamente pseudoaleatoria. Esta salida, típicamente una cadena de 32 bytes, puede ser utilizada por la aplicación del lado del cliente, principalmente como material para claves simétricas para el cifrado con WebAuthn o la derivación de claves.

Muchos autenticadores, en particular las llaves de seguridad FIDO2, implementan una capacidad subyacente definida en el Protocolo Cliente-a-Autenticador (CTAP2) llamada la extensión hmac-secret. Esta extensión de CTAP2 proporciona acceso a una función HMAC (Código de Autenticación de Mensajes basado en Hash) respaldada por hardware, que sirve como la función pseudoaleatoria. La extensión PRF de WebAuthn actúa como una forma estandarizada para que las aplicaciones web accedan a esta capacidad de hmac-secret a través de la API de WebAuthn del navegador.

Para evitar posibles conflictos o problemas de seguridad donde un sitio web podría engañar al autenticador para que genere HMACs destinados a fines no web (como el inicio de sesión en el sistema operativo local), la especificación de WebAuthn exige un paso importante: las entradas proporcionadas por el sitio web (primer y segundo salt) se hashean primero con una cadena de contexto específica ("WebAuthn PRF" y un byte nulo) antes de pasarlas a la función hmac-secret subyacente. Esto divide eficazmente el espacio de entrada de la PRF, asegurando que las salidas derivadas de la web sean distintas de las que podrían usarse en otros contextos.

La capacidad de derivar claves vinculadas al autenticador abre varios casos de uso atractivos para los desarrolladores:

1. Cifrado del lado del cliente / de extremo a extremo (E2EE): Este es el principal motivador de la extensión PRF de WebAuthn. Las aplicaciones basadas en navegador pueden derivar una clave de cifrado única por credencial durante el inicio de sesión. Esta clave puede luego usarse con la API WebCrypto para cifrar datos del usuario almacenados localmente o en el servidor. Los datos permanecen cifrados en reposo y solo pueden ser descifrados por el usuario después de autenticarse con éxito con la passkey específica, mejorando la privacidad y la seguridad de los datos. Los proveedores de servicios pueden almacenar datos de usuario sin tener acceso al texto plano. Esto es especialmente útil para aplicaciones en el mundo sin contraseñas, porque sin la extensión PRF, necesitarían solicitar adicionalmente un secreto en forma de contraseña, lo que contradice la arquitectura sin contraseñas.

2. Descifrado de bóvedas sin contraseña: Servicios como los gestores de contraseñas (p. ej., Bitwarden, 1Password) o aplicaciones de notas seguras (p. ej., Notesnook, Reflect) pueden usar PRF para reemplazar la tradicional contraseña maestra. El usuario se autentica con su passkey, la extensión PRF deriva la clave de descifrado de la bóveda y esta se desbloquea, sin necesidad de contraseña maestra. Bitwarden ha anunciado compatibilidad para esto. Además, Dashlane adoptó recientemente la extensión PRF de WebAuthn para fortalecer la resistencia al phishing y mejorar la seguridad para acceder a bóvedas cifradas. Los usuarios se autentican usando sus passkeys, permitiendo que la PRF derive las claves de descifrado de la bóveda de forma segura, eliminando por completo la necesidad de una contraseña maestra.

3. Rotación segura de claves: La extensión PRF de WebAuthn permite proporcionar dos "salts" de entrada (primero y segundo) durante la autenticación. Esto facilita los esquemas de rotación de claves criptográficas. Un servidor podría solicitar la clave "actual" usando el primer salt y la clave "siguiente" usando el segundo. Con el tiempo, el servidor puede actualizar qué salt corresponde a la clave actual, permitiendo una rotación fluida sin interrumpir la experiencia del usuario. Esto es especialmente importante en caso de que los requisitos regulatorios o las políticas internas exijan que todas las claves se roten dentro de un cronograma específico y aumenta la seguridad.

4. Billeteras de identidad y sistemas sin custodia: La PRF puede derivar claves para proteger datos de identidad dentro de billeteras digitales o habilitar sistemas sin custodia donde las claves privadas nunca se exponen del lado del servidor.

Aunque la especificación está definida, la compatibilidad real en navegadores y plataformas es el factor crítico para los desarrolladores. La compatibilidad ha estado evolucionando y, hasta hace poco, se limitaba principalmente a los navegadores basados en Chromium. Rastrear la compatibilidad puede ser un desafío, ya que no hay una entrada dedicada en CanIUse.com para la extensión PRF en sí (buscar "webauthn" muestra la compatibilidad general de la API, pero no de extensiones específicas). La información a menudo debe recopilarse de las notas de lanzamiento de los navegadores, los rastreadores de errores y las páginas de estado. Usar con éxito la extensión PRF de WebAuthn requiere un esfuerzo coordinado en tres capas distintas de la pila tecnológica. La compatibilidad con la extensión PRF debe estar presente en cada nivel para que la función opere:

1. El autenticador: Este es el hardware (como una llave de seguridad) o el componente de la plataforma (como Windows Hello, el Llavero de iCloud y el módulo de hardware correspondiente, p. ej., TPM o Secure Enclave) que almacena de forma segura la clave secreta de la credencial y realiza el cálculo real de la función pseudoaleatoria (generalmente usando la capacidad hmac-secret de CTAP2). Si el autenticador carece de esta capacidad criptográfica fundamental, la PRF no puede funcionar.

2. El sistema operativo (SO): El SO actúa como puente entre el navegador y el autenticador. Proporciona los controladores y las API a nivel de sistema necesarios para que el navegador descubra, se comunique y solicite operaciones a los autenticadores (especialmente los autenticadores de plataforma y los conectados a través de USB/NFC/Bluetooth). El SO debe ser capaz de reconocer y exponer la capacidad PRF (hmac-secret) del autenticador al navegador. Si el SO no proporciona esta vía, el navegador no puede acceder a la función.

3. El navegador: Como interfaz para la aplicación web, el navegador debe implementar la API de JavaScript de WebAuthn, reconocer específicamente la extensión prf, traducir la solicitud web a los comandos apropiados para el SO/autenticador, manejar el paso crucial de seguridad de hashear las entradas con la cadena de contexto, y analizar y devolver correctamente los resultados a la aplicación.

Un fallo o falta de compatibilidad en cualquiera de estos tres niveles —capacidad del autenticador, exposición del SO o implementación del navegador— impedirá que la extensión PRF funcione.

Este diagrama de secuencia muestra una versión simplificada de cómo estos actores trabajan juntos para facilitar la compatibilidad con PRF.

Un flujo de trabajo PRF funcional requiere que cada capa en la cadena WebAuthn ↔ CTAP coopere.
Para mayor claridad, separamos la discusión en (1) el comportamiento del navegador + sistema operativo y (2) el comportamiento del autenticador.

El camino hacia una amplia compatibilidad con PRF resalta un desafío común con las extensiones de los estándares web: la implementación suele ser escalonada, y los problemas específicos de cada plataforma necesitan resolverse. Nuestro objetivo es mantener esta tabla actualizada, pero ten en cuenta que, dado que la extensión PRF es una de las adiciones más recientes que requiere que toda la cadena de compatibilidad se adapte, se esperan ajustes continuos.

A continuación, desglosamos la compatibilidad por sistema operativo.

La compatibilidad con la extensión PRF de WebAuthn en Windows es limitada, ya que el autenticador de plataforma nativo (Windows Hello) actualmente carece de la capacidad hmac-secret necesaria. Por lo tanto, la funcionalidad PRF depende de llaves de seguridad externas.

Con macOS 15, ha llegado la compatibilidad con PRF para los autenticadores de plataforma. Tanto Safari como Chrome admiten PRF a través del Llavero de iCloud. La compatibilidad de Firefox con el autenticador de plataforma aún está pendiente. Las llaves de seguridad solo funcionan con Chrome.

El estado en iOS y iPadOS es similar al de macOS, con PRF funcionando a través del Llavero de iCloud. Sin embargo, hay advertencias importantes: un error en las primeras versiones de iOS 18 puede provocar la pérdida de datos, y la compatibilidad con llaves de seguridad externas aún no está implementada.

Android ofrece actualmente la compatibilidad más robusta y extendida para la extensión PRF de WebAuthn. Las passkeys almacenadas en el Administrador de contraseñas de Google incluyen compatibilidad con PRF por defecto, y funciona en la mayoría de los principales navegadores, con la excepción de Firefox.

En la tabla anterior, hemos incluido las combinaciones más importantes para la compatibilidad con proveedores de passkeys de origen. Sin embargo, al usar gestores de contraseñas como proveedores de passkeys de terceros, sus capacidades específicas deben considerarse por separado. Por ejemplo, 1Password admite PRF en su versión de Android pero no en su versión de iOS. Además, el perfil de Chrome como autenticador no es compatible con PRF. Para más detalles sobre los autenticadores, ver a continuación.

Mientras que WebAuthn especifica qué puede solicitar una Relying Party, el Protocolo Cliente-a-Autenticador (CTAP) define cómo debe comportarse el autenticador. En la práctica, los autenticadores se dividen en cuatro categorías:

1. Sin compatibilidad con PRF: Autenticadores de plataforma más antiguos (p. ej., Windows Hello), llaves de seguridad heredadas sin la extensión hmac‑secret y proveedores de terceros que aún no han adoptado la extensión PRF.

2. PRF solo si se estableció el indicador PRF en la creación de la credencial: Algunas llaves de seguridad CTAP 2.0/2.1 exponen hmac‑secret, pero rechazarán las evaluaciones de PRF a menos que la Relying Party lo haya solicitado cuando se creó la credencial por primera vez para inicializar los secretos.

3. PRF disponible en la autenticación incluso si no se solicitó en la creación: Los tokens de hardware de nueva generación y el Llavero de iCloud y el Administrador de contraseñas de Google exponen la funcionalidad hmac‑secret incondicionalmente; las credenciales creadas sin el indicador siguen funcionando con PRF durante navigator.credentials.get().

4. Compatibilidad total con CTAP 2.2 (PRF + primer valor PRF en la creación): Los autenticadores de plataforma que sincronizan passkeys, como el Llavero de iCloud y el Administrador de contraseñas de Google, pueden, bajo petición, devolver la primera salida de PRF ya durante navigator.credentials.create(), agilizando los flujos de establecimiento de claves.

Saber a qué categoría pertenece un autenticador es esencial al diseñar la lógica de respaldo, migración o establecimiento de claves. También hemos incluido pruebas para estos escenarios en nuestra demo.

Puedes experimentar la extensión PRF de WebAuthn directamente usando nuestra aplicación de demostración interactiva de PRF de WebAuthn. En esta demo, podrás:

• Registrar una passkey con PRF y confirmar si tu autenticador es compatible con esta potente extensión.
• Autenticarte usando tu passkey y ver el valor criptográfico generado por PRF en acción.

Ver el valor PRF por ti mismo resalta las implicaciones prácticas de usar passkeys para operaciones seguras basadas en claves. Te permite verificar directamente la compatibilidad del autenticador con la extensión PRF y observar cómo las claves derivadas de PRF pueden potenciar el cifrado de extremo a extremo con WebAuthn y el descifrado seguro de bóvedas sin contraseñas.

Tómate un momento para probar la demo; comprender la capacidad PRF de tu entorno específico te ayuda a planificar mejor experiencias seguras y sin contraseñas adaptadas a tus usuarios.

¿Listo para probar el poder de la PRF? Haz clic en la imagen de arriba o sigue este enlace para comenzar tu exploración práctica.

La extensión PRF de WebAuthn no es la única extensión de WebAuthn relacionada con el almacenamiento o la derivación de datos. ¿Cómo se compara la PRF para passkeys?

• PRF vs. credBlob / largeBlob:

  • credBlob: Permite almacenar un pequeño blob estático (32 bytes) con la credencial, posiblemente en el momento de la creación. No fue diseñado principalmente para secretos, y la compatibilidad es limitada, especialmente para credenciales no detectables.

  • largeBlob: Permite almacenar más datos (~1KB) con credenciales detectables, a menudo destinado a datos auxiliares como certificados. La compatibilidad también es limitada (admitido por el Llavero de iCloud desde iOS 17, pero no por GPM). Los desarrolladores de Chrome favorecieron explícitamente centrarse en PRF sobre largeBlob para la mayoría de los casos de uso, aunque el desarrollo podría ocurrir en el futuro.

  • PRF: En contraste, la PRF está diseñada específicamente para derivar claves secretas bajo demanda durante la autenticación utilizando un secreto vinculado al hardware, en lugar de almacenar un blob estático. Generalmente se considera el mecanismo estándar más apropiado y seguro para derivar claves de cifrado vinculadas a una passkey. La evolución desde la discusión de blobs para secretos hasta la estandarización y el enfoque de implementación en PRF sugiere una convergencia en PRF como la solución dedicada para este caso de uso.

• PRF vs. Claves derivadas de contraseñas (p. ej., PBKDF2): Tradicionalmente, las claves de cifrado del lado del cliente se derivaban de las contraseñas de los usuarios. La PRF ofrece ventajas significativas:

  • Fuente más robusta: Las claves se derivan de material criptográfico fuerte dentro del autenticador, no de contraseñas potencialmente débiles o reutilizadas.

  • Resistencia al phishing: La derivación está vinculada al flujo de autenticación de WebAuthn, que es resistente al phishing.

  • Sin contraseñas: Habilita casos de uso como el descifrado de bóvedas sin requerir una contraseña en absoluto.

• PRF vs. Otros datos de WebAuthn: Intentar derivar claves de otras partes de la respuesta de WebAuthn (como la firma, authenticatorData o la clave pública) es fundamentalmente inseguro e incorrecto. Estos componentes son públicos, no secretos o están diseñados para verificación, no para derivación de claves.

Para derivar de forma segura material de clave criptográfica vinculado directamente a una credencial de WebAuthn o passkey, la extensión PRF de WebAuthn es el enfoque estándar, diseñado específicamente para este propósito y recomendado.

Al integrar la extensión PRF en tu aplicación, considera estas pautas prácticas:

Las siguientes recomendaciones ayudan a los desarrolladores a navegar eficazmente el estado actual de la compatibilidad con la extensión PRF y a planificar desarrollos futuros:

• Tratar la PRF de forma oportunista: La compatibilidad con la extensión PRF de WebAuthn varía significativamente entre navegadores, sistemas operativos y autenticadores. Por lo tanto, trata la integración de PRF como una mejora en lugar de una dependencia central.

• Evitar la dependencia crítica de la PRF: Evita que la PRF sea esencial para la funcionalidad de misión crítica. La compatibilidad actual, particularmente en plataformas como Safari en macOS e iOS, sigue siendo inconsistente e incompleta.

• Prepararse para escenarios de pérdida de passkeys: Recuerda que los datos cifrados con claves derivadas de PRF están vinculados exclusivamente a la passkey específica. Perder la passkey hará que los datos cifrados sean permanentemente inaccesibles. Implementa siempre mecanismos robustos de respaldo y recuperación.

• Anticipar una compatibilidad más amplia para 2026: La compatibilidad con la extensión PRF está madurando rápidamente. Para 2026, anticipa una disponibilidad consistente en los principales navegadores, sistemas operativos y autenticadores, particularmente con los proveedores de passkeys de origen.

• Monitorear el ecosistema de Windows: La compatibilidad con el autenticador de plataforma a través de Windows Hello está actualmente ausente. La integración completa de PRF en entornos de Windows depende en gran medida de la estrategia de adopción de Microsoft, así que mantén este ecosistema bajo estrecha observación.

Seguir estas pautas asegura que los desarrolladores puedan incorporar la PRF sin problemas mientras mantienen la compatibilidad y la seguridad durante su fase de adopción.

Entender cómo se alinea la PRF con tu estrategia general de passkeys te ayuda a maximizar sus beneficios sin complicaciones innecesarias:

• Integración flexible: No es necesario decidir si aprovechar la PRF en el momento de la creación de la passkey. Las passkeys existentes pueden integrarse sin problemas más tarde con casos de uso de PRF sin una sobrecarga adicional de gestión de credenciales.

• Adaptación retroactiva de la PRF: Dado que la PRF opera durante la fase de autenticación (navigator.credentials.get()), las passkeys creadas previamente pueden admitir flujos de trabajo basados en PRF en una etapa posterior. Esto permite que tu aplicación mejore la seguridad de forma incremental sin interrumpir los métodos de autenticación establecidos. Este enfoque funciona con el Llavero de iCloud y el Administrador de contraseñas de Google (GPM) y las llaves de seguridad más nuevas. Para las llaves de seguridad más antiguas, es posible que solo se genere un hmac-secret si se solicita en la creación de la credencial.

• Consideraciones sobre la complejidad de las passkeys: Las complejidades inherentes a la gestión de passkeys —como la sincronización de credenciales, la autenticación entre dispositivos y los procesos de recuperación— se aplican igualmente al usar PRF. Asegúrate de que tu implementación de PRF se alinee de manera cohesiva con tu estrategia general de autenticación con passkeys, manteniendo experiencias de usuario optimizadas y controles de seguridad robustos.

Considerar la PRF como parte de una estrategia de passkeys holística permite una transición más fluida hacia prácticas de autenticación más seguras y fáciles de usar.

Para los proveedores de servicios empresariales que manejan datos de usuario sensibles, la capacidad de aprovechar la PRF de WebAuthn junto con las passkeys abre posibilidades para mejorar la seguridad y la experiencia del usuario, particularmente en escenarios que requieren el cifrado del lado del cliente de Información de Identificación Personal (PII) o la protección de aplicaciones que requieren cifrado de extremo a extremo. Si bien Corbado Connect está diseñado principalmente para una integración empresarial fluida de passkeys, también puede facilitar la implementación de extensiones de passkeys como SPC o PRF.

Así es como Corbado puede ayudar a las organizaciones que buscan integrar PRF:

• Facilitando la PRF para el almacenamiento cifrado: En entornos empresariales, a veces existe el requisito de almacenar información sensible de forma segura, quizás incluso directamente del lado del cliente para minimizar la exposición de PII del lado del servidor. Corbado Connect puede configurarse para solicitar valores PRF durante el flujo de autenticación con passkey (navigator.credentials.get()), permitiendo a las aplicaciones derivar las claves criptográficas necesarias.
• Patrones de almacenamiento flexibles: Los datos cifrados con claves derivadas de PRF pueden almacenarse de varias maneras según los requisitos de seguridad y la arquitectura:
  • Lado del cliente: Almacenados directamente en el navegador usando mecanismos como localStorage o cookies seguras. Los datos en texto plano solo existen de forma transitoria en el cliente durante el descifrado.
  • Backend de Corbado (E2EE): Aunque Corbado generalmente evita almacenar PII de clientes, el mecanismo PRF técnicamente permite almacenar datos cifrados del lado del cliente en los servidores de Corbado. Corbado no poseería las claves para descifrar estos datos; el descifrado seguiría ocurriendo del lado del cliente después de una autenticación de usuario exitosa.
  • Backend del cliente: Los datos cifrados también podrían enviarse y almacenarse en los propios sistemas de backend de la empresa, beneficiándose aún del cifrado del lado del cliente.
• Flujo seguro de derivación de claves: Los componentes de Corbado Connect gestionan la interacción con la API de WebAuthn. Cuando se solicita PRF:
  1. El autenticador genera una salida PRF específica del usuario, vinculada a la passkey individual.
  2. Esta salida se devuelve de forma segura a la aplicación del lado del cliente.
  3. La aplicación debe entonces usar una Función de Derivación de Clave (KDF) a través de la API WebCrypto (p. ej., HKDF) para derivar una clave de cifrado simétrica robusta a partir de la salida PRF.
  4. Esta clave simétrica se usa con WebCrypto (p. ej., AES-GCM) para cifrar o descifrar la información objetivo (como la PII).
• Descifrado fluido en inicios de sesión posteriores: Cuando el usuario se autentica de nuevo usando la misma passkey, Corbado Connect inicia la misma solicitud PRF. Esto produce la misma salida PRF, permitiendo a la aplicación volver a derivar la misma clave simétrica y descifrar la información previamente almacenada del lado del cliente.
• Inteligencia de adopción de PRF: Implementar PRF requiere saber si el entorno del usuario (SO, navegador, autenticador) lo admite. Corbado Connect recopila señales sobre el dispositivo y las capacidades del usuario durante la autenticación. Esta inteligencia se puede usar para:
  • Determinar la preparación para PRF en toda la base de usuarios antes de activar completamente las funciones dependientes de PRF.
  • Implementar PRF de forma oportunista, ofreciéndola como una mejora para los usuarios compatibles mientras se mantienen mecanismos de respaldo (como solicitar una nueva verificación o usar métodos alternativos) para aquellos sin soporte.
• Agilizando la disponibilidad de PII: Al usar PRF para cifrar PII verificada (p. ej., atributos de identidad obtenidos a través de un flujo de verificación) y almacenarla del lado del cliente, las aplicaciones pueden hacer que estos datos estén disponibles inmediatamente después de un inicio de sesión con passkey para interacciones o transacciones posteriores, reduciendo significativamente la fricción en comparación con la re-verificación o los flujos basados en aplicaciones.
• Habilitando sistemas E2EE personalizados: Si bien Corbado Connect ofrece componentes de UI para flujos estándar, los principios subyacentes pueden permitir a los desarrolladores integrar la funcionalidad PRF más profundamente en aplicaciones sensibles. Esto permite construir sistemas cifrados de extremo a extremo donde la aplicación frontend aprovecha directamente las claves derivadas de PRF para operaciones criptográficas complejas en datos existentes o nuevos. Por el momento, esto solo será posible de forma oportunista y los mecanismos de respaldo necesitarán implementar una forma diferente de almacenar esa información.

Corbado tiene como objetivo simplificar las complejidades de la integración de passkeys y PRF, permitiendo a las empresas aprovechar los estándares de forma segura y eficaz, adaptándose a casos de uso específicos como el cifrado de PII del lado del cliente mientras navegan por el panorama en evolución.

La extensión PRF de WebAuthn marca un paso importante para hacer que las aplicaciones verdaderamente sin contraseña y con cifrado de extremo a extremo sean una realidad práctica. Al aprovechar las passkeys para derivar claves criptográficas de forma segura, proporciona una experiencia de usuario fluida y segura sin comprometer la privacidad.

Respondiendo directamente a las preguntas planteadas al inicio de este artículo:

• Casos de uso interesantes de PRF: La PRF habilita casos de uso atractivos como el almacenamiento de datos con cifrado de extremo a extremo, el descifrado de bóvedas sin contraseña para gestores de contraseñas, esquemas seguros de rotación de claves criptográficas y billeteras de identidad seguras o sistemas sin custodia que protegen la privacidad del usuario al garantizar que las claves privadas nunca salgan de los dispositivos del cliente.

• Estado actual de la compatibilidad con PRF (junio de 2025): La compatibilidad sigue siendo fragmentada y en evolución. Mientras que Android tiene un soporte sólido en todos los navegadores y autenticadores, plataformas como macOS y especialmente iOS son inestables, particularmente como fuente de CDA con un error grave. El soporte de Windows se limita principalmente a llaves de seguridad externas, con una notable ausencia de soporte de plataforma nativo a través de Windows Hello.

Los desarrolladores que consideren la extensión PRF deben anticipar una mejora rápida, pero proceder con cautela, construyendo aplicaciones resilientes que manejen con elegancia las limitaciones actuales. A medida que surja una adopción más amplia en las principales plataformas y ecosistemas de autenticadores, el futuro del cifrado sin contraseña habilitado por PRF parece brillante, prometiendo una mayor privacidad y usabilidad en la autenticación web.