---
url: 'https://www.corbado.com/es/blog/passkeys-brave-browser'
title: 'Claves de acceso en el navegador Brave (2026): Qué funciona y qué falla'
description: 'Brave sigue a Chromium en claves de acceso, pero los conflictos en Android, Windows Hello y los administradores de contraseñas aún crean una fricción real.'
lang: 'es'
author: 'Vincent Delitz'
date: '2026-07-03T07:07:33.177Z'
lastModified: '2026-07-03T07:08:26.646Z'
keywords: 'claves de acceso en brave, webauthn, windows hello, icloud keychain, administrador de contraseñas, google play services, fido2'
category: 'WebAuthn Know-How'
---

# Claves de acceso en el navegador Brave (2026): Qué funciona y qué falla

## Key Facts

- **La ruta de código de WebAuthn es la de Chromium, casi intacta.** El repositorio
  `brave/brave-core` contiene exactamente **una** personalización visible relacionada
  con WebAuthn: una anulación de cadena que cambia el nombre de la etiqueta "Incógnito"
  de Chrome a "Privado" en el cuadro de diálogo para guardar claves de acceso. Ningún
  parche de C++ toca la ruta del código de WebAuthn.
- **24 problemas abiertos sobre claves de acceso/WebAuthn** se encontraban en
  `brave/brave-browser` hasta abril de 2026, según las búsquedas de problemas de GitHub
  para `passkey` y `WebAuthn`. Los problemas abiertos etiquetados con claves de acceso
  crecieron de \~2 por año en 2022-2023 a 6 abiertos en 2025.
- **El uso entre navegadores en macOS funciona.** Una clave de acceso creada en macOS
  puede almacenarse en iCloud Keychain y se puede usar en Safari, Chrome y otros
  navegadores de la plataforma Apple en dispositivos que compartan el mismo Apple ID.
- **Las compilaciones de Android sin Google (de-Googled) fallan.** Sin Google Play Services, el registro
  y la autenticación de claves de acceso suelen fallar en Android. Rastreado en el
  problema #45415 (abierto desde abril de 2025).
- **Windows Hello no se puede suprimir por completo.** Deshabilitar
  `brave://password-manager/settings` no impide que Windows ofrezca Hello como un
  autenticador de plataforma WebAuthn. Rastreado en el problema #51858 (abierto en enero de 2026).
- **La interceptación por parte de extensiones es la regresión más activa.** El problema
  #37762 -donde la interfaz de usuario nativa de la clave de acceso anula los avisos de
  Bitwarden y 1Password- se abrió en abril de 2024 y seguía recibiendo informes de errores
  el 25 de marzo de 2026.
- **La solución alternativa de la bandera `web-authentication-new-passkey-ui` ha desaparecido**
  en la versión 146 (Chromium 146), según el informe de un usuario en el problema #37762
  de `brave/brave-browser` con fecha del 25 de marzo de 2026.

## 1. Introducción: Soporte de claves de acceso en Brave en la actualidad

El soporte de claves de acceso de Brave es muy similar al de Chromium a nivel de código, pero
la experiencia del usuario difiere en algunos puntos importantes. Hasta abril de 2026,
el repositorio más amplio `brave/brave-browser` todavía tenía 24 problemas abiertos
que coincidían con `passkey` o `WebAuthn`, mientras que
[`brave/brave-core`](https://github.com/brave/brave-core) mostraba una sola
personalización visible específica de WebAuthn. Los principales puntos de ruptura son
la interceptación de extensiones, los avisos de Windows Hello y
los flujos de Android en dispositivos sin Google.

Brave implementa las claves de acceso a través de la misma ruta de código de WebAuthn que
la versión original de Chromium y delega el almacenamiento de credenciales al sistema operativo.
Esa arquitectura hace que Brave parezca estándar en teoría, pero el comportamiento
en el mundo real aún depende de sistemas circundantes como las extensiones de
administradores de contraseñas, Windows Hello y Google Play Services.
Las siguientes secciones mantienen separados esos modos de fallo para que cada comportamiento
específico de la plataforma se pueda entender por sí solo.

## 2. ¿En qué se diferencia la pila WebAuthn en Brave de la de Chromium?

La implementación de WebAuthn en Brave es, a todos los efectos, la implementación de Chromium
con un solo cambio visible en el texto de la interfaz de usuario. El repositorio
[`brave/brave-core`](https://github.com/brave/brave-core) contiene una sola
personalización relacionada con WebAuthn -una anulación de cadena que cambia el nombre
de "Incógnito" a "Privado" en el cuadro de diálogo de guardado- y no hay parches de C++
que toquen la lógica central de WebAuthn. Esto significa que Brave hereda la pila de
claves de acceso de Chromium que Google envió desde Chromium 115 a partir de junio de 2023.

Esto es importante por dos razones. En primer lugar, las fusiones ascendentes normales
significan que las correcciones de WebAuthn y las nuevas funciones generalmente llegan
sin que Brave tenga que mantener una implementación de claves de acceso profundamente dividida.
Puede inspeccionar la única anulación de cadena directamente en
[`brave/brave-core`](https://github.com/brave/brave-core/blob/master/components/webauthn_strings_override.grdp).
En las asignaciones de AAGUID, la ruta del autenticador del navegador Chromium
se identifica comúnmente como `b5397666-4885-aa6b-cebf-e52262a439a2`,
etiquetada como "Navegador Chromium" en nuestra lista de referencias.
En segundo lugar, la mayoría de los fallos notificados -interceptación de extensiones,
conflictos de autocompletado y la dependencia de Google Play Services en Android-
aparecen en sistemas adyacentes como el autocompletado, los permisos, Shields o
la integración de Wallet. Rodean el flujo de WebAuthn en lugar de reemplazarlo.

## 3. ¿Se puede usar una clave de acceso creada en macOS en Safari en otro dispositivo Apple?

Sí, pero solo si la clave de acceso se guarda en iCloud Keychain. En macOS, Brave
utiliza la pila WebAuthn de Chromium y puede almacenar una nueva clave de acceso
en el autenticador de plataforma de Apple o en otro destino de almacenamiento
presentado en el aviso de creación. Una clave de acceso guardada en iCloud Keychain
se sincroniza a través del Apple ID y pasa a estar disponible en Safari, Chrome
y otros navegadores compatibles con WebAuthn en dispositivos Apple que compartan ese Apple ID.

Una vez que macOS confirma que Brave tiene permiso para acceder a iCloud Keychain,
el navegador puede usar las mismas claves de acceso sincronizadas que ve Safari.
Ese aviso de permiso es el momento práctico en el que la portabilidad entre navegadores
en los dispositivos Apple se vuelve real en lugar de teórica.

![macOS pregunta si el navegador Brave puede acceder a las claves de acceso guardadas en iCloud Keychain, lo que permite que las mismas credenciales sincronizadas funcionen en Safari, Chrome y Brave en dispositivos Apple que comparten el mismo Apple ID.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/access_icloud_8252555e93.png)

Brave en macOS también puede participar en flujos de autenticación entre dispositivos (CDA).
Si el usuario permite el acceso a Bluetooth, Brave puede descubrir y comunicarse con
dispositivos cercanos durante la CDA, lo que hace que la aprobación de la clave de
acceso a través del teléfono se sienta en gran medida perfecta desde el navegador de escritorio.

![Brave en macOS solicita acceso a Bluetooth antes de la autenticación entre dispositivos, habilitando el descubrimiento de dispositivos cercanos y flujos de aprobación de claves de acceso basados en el teléfono más fluidos.](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/bluetooth_brave_macos_c51dd36600.png)

Una clave de acceso guardada en un almacén de perfiles del navegador o en un almacén local
no estará disponible automáticamente en Safari en otro dispositivo Apple. Esa diferencia
importa porque la sincronización del autenticador de plataforma a nivel de sistema operativo
y la sincronización de perfiles del navegador siguen reglas diferentes. Brave no incluye
la sincronización de claves de acceso de Google Password Manager de Chrome, por lo que
solo la ruta de iCloud Keychain proporciona una portabilidad entre navegadores al estilo de Apple
en dispositivos Apple.

## 4. ¿Por qué las claves de acceso no funcionan de manera confiable en Android sin Google Play Services?

Android Credential Manager no forma parte de Google Play Services en sí mismo. En Android 14
y versiones posteriores, Chromium puede usar la ruta del sistema Credential Manager, mientras
que las versiones anteriores de Android dependen en mayor medida de la capa FIDO2 respaldada
por Google Play Services. En la práctica, Brave sigue heredando el fallo documentado en el
problema #45415: en GrapheneOS, CalyxOS, /e/OS y otras compilaciones de Android sin Google
que no tienen la ruta necesaria de Play Services, el registro y la autenticación de claves
de acceso pueden agotar el tiempo de espera. Hasta abril de 2026, esto seguía siendo una
brecha de compatibilidad abierta para los usuarios de Android centrados en la privacidad.

Este comportamiento está documentado en
[el problema #45415 de `brave/brave-browser`](https://github.com/brave/brave-browser/issues/45415),
abierto en abril de 2025 y que sigue abierto un año después. La
[documentación de Credential Manager](https://developer.android.com/training/sign-in/passkeys)
de Google distingue la API de Credential Manager de la dependencia de autenticación opcional
de Play Services utilizada en versiones anteriores de Android, y la guía más amplia de Android
señala que Android 14+ puede funcionar con administradores de contraseñas habilitados.
El hilo también señala que el mismo modo de fallo afecta a los navegadores basados en Chromium
en general, mientras que los navegadores basados en Firefox no se ven afectados de la misma
manera. El autor del informe original señaló que GrapheneOS aplicó un parche a la dependencia
en su propia bifurcación de Chromium, [Vanadium](https://github.com/GrapheneOS/Vanadium),
por lo que una solución técnica descendente parece posible; simplemente no ha sucedido.

Varios usuarios confirmaron de forma independiente el comportamiento en ese hilo. Una prueba
especialmente limpia en diciembre de 2025 utilizó el mismo dispositivo con dos perfiles: las
claves de acceso funcionaban en Brave solo en el perfil con Play Services habilitado, mientras
que Vanadium y Cromite funcionaban en ambos. A partir de abril de 2026, ningún mantenedor de
Brave había respondido en el hilo. Para la audiencia de Android centrada en la privacidad de
Brave, que incluye un número desproporcionado de usuarios sin Google, esto deja una brecha muy
visible. Firefox en Android utiliza su propia pila WebAuthn y no depende de Play Services
de la misma manera. En la actualidad, la solución práctica es usar Firefox para los flujos
de claves de acceso en dispositivos Android sin Play Services, o recurrir a una llave de
seguridad de hardware con un cliente compatible. Para un panorama más amplio de los fallos
en Android, consulte los Errores de claves de acceso en aplicaciones nativas. Para conocer
los detalles de Google Play Services y Credential Manager, consulte los Códigos de error de
claves de acceso en Android y Google Play Services.

## 5. ¿Por qué aparecen los avisos de claves de acceso de Windows Hello incluso cuando los deshabilito?

Deshabilitar la configuración "ofrecer guardar claves de acceso" de Brave no impide
que Windows Hello aparezca durante los flujos de WebAuthn. Una vez que un sitio llama
a WebAuthn y Windows Hello está inscrito, Windows anuncia a Hello como un autenticador
de plataforma y Brave no expone un control de cara al usuario que lo bloquee.
Hasta enero de 2026, la supresión de Windows Hello seguía sin resolverse para los
usuarios que querían Hello para el desbloqueo del dispositivo pero no para las claves de acceso.

El [problema #51858](https://github.com/brave/brave-browser/issues/51858), abierto en
enero de 2026, y el
[hilo de la comunidad 646042](https://community.brave.app/t/brave-prompts-for-windows-hello-passkeys-even-when-disabled/646042)
más extenso describen lo mismo. El informante original intentó editar el registro, las
políticas de grupo, activar y desactivar banderas e instalaciones limpias; nada de eso
cambió el comportamiento.

La razón técnica descrita en el hilo 646042 es simple: la configuración del administrador
de contraseñas del navegador controla el comportamiento de autocompletado del propio
navegador, no el límite de WebAuthn entre la página y el sistema operativo. Windows
expone a Hello de forma independiente, y la discusión no identifica una configuración
documentada y compatible que preserve Windows Hello para el desbloqueo de dispositivos
mientras lo bloquea por completo como un autenticador de plataforma WebAuthn.

Hoy en día, la única forma confiable de suprimir esos avisos es deshabilitar la
inscripción en Windows Hello por completo, lo que obviamente choca con la forma en que
la mayoría de las personas quieren desbloquear su dispositivo. Edge se comporta de
manera diferente porque está más estrechamente integrado con la capa de administración
de credenciales de Windows y expone controles que las bifurcaciones de Chromium actualmente
no tienen. Para una mirada más amplia al comportamiento de las claves de acceso en Windows,
consulte Claves de acceso en Windows 11.

## 6. ¿Debería guardar las claves de acceso de forma nativa o en su administrador de contraseñas?

El almacenamiento nativo de claves de acceso es la opción más sencilla dentro de un
solo ecosistema, mientras que las extensiones de administrador de contraseñas siguen
siendo la única capa de sincronización multiplataforma ampliamente viable. iCloud
Keychain funciona bien en todos los dispositivos Apple, Windows Hello funciona en Windows
y las bóvedas basadas en extensiones como 1Password o Bitwarden siguen siendo la única
opción realista para los usuarios que desean que las claves de acceso estén disponibles de
forma nativa en Windows, macOS, Linux y Android. La autenticación entre dispositivos
(CDA, o transporte híbrido a través de código QR y Bluetooth) aún puede unir dispositivos en el
momento del inicio de sesión, pero no sincroniza la credencial en sí ni la hace
disponible localmente en todas partes de forma predeterminada. El equilibrio está en
la confiabilidad: los flujos nativos son más simples, los flujos de extensiones son
más portátiles y es mejor entender el CDA como una ruta de respaldo en lugar de una
estrategia de almacenamiento.

La decisión se reduce principalmente a tres cosas: cuántas plataformas usa, cuánto
confía en los flujos de extensiones y dónde guarda ya sus credenciales. Si permanece
principalmente dentro del ecosistema de un sistema operativo, todo Apple o todo
Windows, la ruta del autenticador de plataforma nativo es la opción más limpia. En esa
configuración, Brave se comporta de manera muy similar a Chrome o Safari. Si necesita
que las claves de acceso lo sigan a través de Windows, macOS, Linux y Android, una
extensión de administrador de contraseñas de terceros como 1Password, Bitwarden, Dashlane
o Proton Pass sigue siendo la única capa de sincronización ampliamente viable.

La complicación es que, desde abril de 2024, han seguido llegando informes de que la interfaz
de usuario nativa de la clave de acceso secuestra intermitentemente los flujos impulsados
por extensiones. Los usuarios en el
[problema #37762](https://github.com/brave/brave-browser/issues/37762) describen
que aparecen cuadros de diálogo de autenticación del sistema operativo a pesar de que
Bitwarden o 1Password deberían ser los dueños de la credencial. Para marzo de 2026, la
antigua solución alternativa, deshabilitar `brave://flags/#web-authentication-new-passkey-ui`,
ya no estaba disponible porque la bandera se había eliminado en la versión 146.

| Ubicación de almacenamiento | Sincronización entre sistemas operativos | Uso entre navegadores | Postura de recuperación | Riesgo conocido |
| ----------------------- | ---------------------- | ------------------------- | ------------------- | ---------------------------------- |
| iCloud Keychain | Solo Apple | Navegadores Apple | Apple ID | Ninguno |
| Windows Hello | No (vinculado al dispositivo) | Mismo dispositivo Windows | Desbloqueo del dispositivo / PIN | El cuadro de diálogo de Hello no se puede deshabilitar |
| Google Password Manager | Donde GPM esté disponible | Chrome + superficies Android | Cuenta de Google | No expuesto en perfiles de Brave aquí |
| 1Password / Bitwarden | Completa | Completo (extensión) | Cuenta de la bóveda | Interceptación nativa intermitente |
| Llave de seguridad de hardware | Vinculada al dispositivo | Cualquier navegador | Posesión física | Ninguno |

En la práctica, el patrón con el que terminan muchos usuarios centrados en la privacidad
en 2026 es uno híbrido: use el autenticador de plataforma del sistema operativo para los
inicios de sesión diarios dentro de un ecosistema, use una extensión de administrador
de contraseñas donde importe la portabilidad multiplataforma y tenga a mano una llave de
seguridad de hardware para las cuentas de alto valor.

## 7. ¿Qué puntos de fricción informan los usuarios sobre las claves de acceso en 2026?

Los problemas abiertos de claves de acceso de Brave en 2026 se agrupan en torno a tres
temas recurrentes: la interceptación de extensiones, fallos en Android en dispositivos
sin Google y problemas con llaves de seguridad en computadoras de escritorio.
A partir de abril de 2026, el repositorio más amplio todavía mostraba 24 problemas
abiertos que coincidían con `webauthn` o `passkey`, lo que sugiere que la fricción
está concentrada, no es aleatoria.

El grupo más concurrido es el de la interceptación de extensiones, donde la interfaz
de usuario nativa de la clave de acceso puede anular las solicitudes de 1Password, Bitwarden
o Dashlane. La compatibilidad de Android sin Google Play Services es el segundo
problema recurrente, y la detección de llaves de seguridad en el escritorio es el tercero.
Los hilos de problemas a los que se hace referencia con más frecuencia aquí son
[`#37762`](https://github.com/brave/brave-browser/issues/37762),
[`#50561`](https://github.com/brave/brave-browser/issues/50561),
[`#45415`](https://github.com/brave/brave-browser/issues/45415),
[`#15650`](https://github.com/brave/brave-browser/issues/15650),
[`#43043`](https://github.com/brave/brave-browser/issues/43043),
[`#34441`](https://github.com/brave/brave-browser/issues/34441),
[`#33237`](https://github.com/brave/brave-browser/issues/33237) y
[`#51858`](https://github.com/brave/brave-browser/issues/51858).
Los hilos activos apuntan en la misma dirección sin necesidad de muchas citas directas.

Varios de estos problemas recibieron nuevos comentarios en los últimos 90 días, lo que
los convierte en regresiones activas en lugar de curiosidades históricas. Para los
desarrolladores que construyen flujos de claves de acceso, la conclusión es clara: pruebe
explícitamente los flujos impulsados por extensiones en Brave y ofrezca alternativas sensatas
cuando fallen las llamadas de WebAuthn. Para los usuarios, la lección es igualmente práctica:
mantenga configurada una llave de seguridad de hardware u otro factor de recuperación en
sus cuentas de alto valor.

## 8. Conclusión

La historia de las claves de acceso en Brave es limpia a nivel de código y desordenada
a nivel de experiencia del usuario. La ruta de WebAuthn es efectivamente la de Chromium,
con solo una anulación de cadena que confirma qué tan cerca se mantiene la implementación
de la original. En las plataformas Apple, la portabilidad de las claves de acceso funciona
exactamente como esperan los usuarios porque iCloud Keychain es el propietario de la credencial.
La fricción real se encuentra en otras partes: interceptación de extensiones (#37762),
supresión de Windows Hello (#51858) y la dependencia de Google Play Services de Android
(#45415). Hasta que se resuelvan esos problemas, los desarrolladores deben probar Brave
por separado en lugar de asumir la paridad de Chrome y los usuarios deben mantener un
fuerte respaldo, idealmente una llave de seguridad de hardware, para las cuentas importantes.

## 9. Acerca de Corbado

Corbado construye infraestructura de claves de acceso para el inicio de sesión del consumidor
y proporciona una plataforma de inteligencia de claves de acceso para equipos que necesitan
operar claves de acceso y sistemas de autenticación a gran escala. Publicamos análisis
técnicos del comportamiento de WebAuthn y las claves de acceso en navegadores y sistemas
operativos basados en implementaciones reales, inspección directa de fuentes y lectura
detenida de las especificaciones subyacentes. Las preguntas o correcciones son siempre bienvenidas.

## 10. Preguntas frecuentes

### 10.1 ¿Se puede usar una clave de acceso creada en Brave en macOS en Safari en otro dispositivo Apple?

Sí, pero solo si Brave guarda la clave de acceso en iCloud Keychain. En macOS, Brave
usa la pila WebAuthn de Chromium y puede almacenar una nueva clave de acceso en iCloud
Keychain o en otro destino de almacenamiento que se muestra en el aviso de creación.
Una clave de acceso guardada en iCloud Keychain se sincroniza a través del Apple ID y
estará disponible en Safari, Chrome y otros navegadores en dispositivos Apple que
compartan ese Apple ID. Una clave de acceso guardada en un almacén de perfiles del
navegador o en un almacén local no estará disponible automáticamente en Safari en otro
dispositivo Apple.

### 10.2 ¿Por qué las claves de acceso fallan en Brave en Android sin Google Play Services?

Brave en Android puede fallar sin Google Play Services, pero el motivo es más específico
que "Credential Manager forma parte de Play Services". Android Credential Manager es
un sistema y una API de Jetpack, mientras que las versiones anteriores de Android
dependen más de la capa FIDO2 respaldada por Google Play Services. En la práctica,
Brave sigue heredando el fallo documentado en el problema #45415 de `brave/brave-browser`:
en GrapheneOS, CalyxOS u otras compilaciones de Android sin Google que no tengan
la ruta necesaria de Play Services, el cuadro de diálogo de la clave de acceso
nunca se abre y el registro o la autenticación se agotan.

Para un panorama más amplio de los fallos en Android, consulte Errores de claves de acceso en aplicaciones nativas.
Para conocer los detalles de Google Play Services y Credential Manager, consulte
Códigos de error de claves de acceso en Android y Google Play Services.

### 10.3 ¿Brave sincroniza las claves de acceso entre dispositivos como lo hace Chrome?

No. Brave no proporciona un equivalente a la sincronización de claves de acceso de perfil
del navegador de Chrome a través de Google Password Manager. Las claves de acceso creadas
en Brave se almacenan en el autenticador de plataforma del sistema operativo subyacente:
iCloud Keychain en Apple, Windows Hello en Windows y Android Credential Manager en Android,
y se sincronizan solo a través de esa cuenta del sistema operativo. Si desea una
sincronización consistente entre dispositivos, confíe en el proveedor del sistema operativo o
en una extensión de administrador de contraseñas de terceros.

### 10.4 ¿Por qué Brave solicita claves de acceso de Windows Hello incluso cuando deshabilito las opciones de clave de acceso en la configuración?

El interruptor de `brave://password-manager/settings` de Brave solo controla si
Brave se ofrece a guardar las claves de acceso. No impide que Windows anuncie a
Windows Hello como un autenticador de plataforma WebAuthn a la página. El sitio
invoca WebAuthn, Windows presenta Hello y Brave no tiene un interruptor en el
navegador para suprimir el cuadro de diálogo del sistema operativo. El
comportamiento se rastrea en el problema #51858 de `brave/brave-browser`.

### 10.5 ¿Debería almacenar las claves de acceso en el flujo nativo de Brave o en mi administrador de contraseñas?

Use el flujo de sistema operativo nativo de Brave (iCloud Keychain o Google Password Manager
a través de la plataforma) si se mantiene dentro de un ecosistema y desea la menor cantidad
de partes móviles. Use una extensión de administrador de contraseñas de terceros
como 1Password o Bitwarden si necesita que las claves de acceso lo sigan a través
de Windows, macOS, Linux y Android de manera consistente, o si ya guarda sus secretos allí.
Desde 2024, la interfaz de usuario nativa de Brave ha interceptado repetidamente los flujos
de claves de acceso de extensiones, por lo que vale la pena verificar que la extensión siga
siendo dueña del aviso.

### 10.6 ¿Cuántos problemas abiertos de claves de acceso y WebAuthn tiene actualmente el repositorio brave/brave-browser sobre el comportamiento de las claves de acceso en Brave?

Hasta abril de 2026, `brave/brave-browser` tenía 24 problemas abiertos que coincidían
con búsquedas de `passkey` o `WebAuthn`. Los problemas abiertos etiquetados con claves
de acceso crecieron de aproximadamente 2 por año en 2022-2023 a 6 abiertos en 2025.
Para Brave, los temas dominantes son la interceptación de extensiones en el escritorio,
la supresión de Windows Hello y la dependencia de Google Play Services en Android.