Funciones de seguridad de gestores de contraseñas: cómo evaluarlas

Todos los proveedores de gestores de contraseñas afirman tener una seguridad sólida. Pocos muestran la documentación de arquitectura o el resumen de pruebas de penetración que permitiría confirmarlo. La brecha entre una página de seguridad y una afirmación verificada es donde debe comenzar la debida diligencia.

Evaluar las funciones de seguridad de un gestor de contraseñas significa verificar la arquitectura de cifrado, la fortaleza de la autenticación, la gobernanza de acceso, la verificación independiente, la alineación con normativas y la resiliencia operativa contra evidencia, no contra textos de marketing.

Esta es una guía de verificación de seguridad, no una guía de compra, y forma parte de nuestra guía completa de gestión de contraseñas empresariales. Si todavía está comparando proveedores por costo, despliegue y compatibilidad con DevOps, comience con el marco completo de 10 criterios de compra; vuelva aquí una vez que tenga una lista corta y necesite confirmar que las afirmaciones de seguridad se sostienen.

Conclusiones clave

  • Verifique, no acepte la afirmación tal cual: contraste cada página de seguridad del proveedor con evidencia antes de firmar.
  • Conocimiento cero y cifrado en reposo no son lo mismo. Pregunte dónde se generan y almacenan las claves.
  • La fortaleza del MFA y el comportamiento del tiempo de espera de sesión importan más que una lista de características — pruébelos usted mismo.
  • La granularidad del RBAC y la revocación real en la baja del empleado, más allá de desactivar el SSO, definen el privilegio mínimo en la práctica.
  • Un certificado ISO/IEC 27001 vigente y un resumen de pruebas de penetración son la prueba básica, no extras.
  • Asocie las afirmaciones del proveedor con cláusulas específicas del GDPR, NIS2 y NIST, no con lenguaje vago de «cumplimiento».

Por qué «tiene cifrado» no es una respuesta de seguridad

«Usamos cifrado de nivel militar» no dice nada sobre quién puede descifrar su bóveda, cómo se desarrollaría una brecha o si algún auditor externo ha probado alguna vez esa afirmación. El cifrado es lo mínimo esperado, no un diferenciador. Lo que realmente determina su riesgo está una capa por debajo de la línea de marketing.

Las consecuencias de equivocarse siguen aumentando. El costo promedio global de una brecha de datos alcanzó los 4,99 millones de dólares en 2026, un aumento del 12% y un máximo histórico, según el informe Cost of a Data Breach Report 2026 de IBM. El riesgo relacionado con credenciales tampoco ha desaparecido: el informe Data Breach Investigations Report 2026 de Verizon encontró que la explotación de vulnerabilidades ascendió al 31% de las brechas como primer punto de entrada registrado en 2026, superando al abuso de credenciales, que cayó al 13% en ese mismo conteo del primer paso. Rastreado en cualquier punto a lo largo de un ataque en lugar de solo el movimiento inicial, el abuso de credenciales todavía aparece en el 39% de las brechas, el punto de estrangulamiento más común en el informe.

Una afirmación verificada y una no verificada pueden leerse de forma idéntica en un sitio web. «Sus datos están cifrados con AES-256» es cierto tanto para un gestor de contraseñas con arquitectura genuina de conocimiento cero como para uno donde el proveedor tiene todas las claves y puede descifrar registros bajo solicitud. La redacción por sí sola no indica cuál está comprando. Esa es la brecha que este marco cierra, un pilar a la vez.

Cada afirmación en la página de seguridad de un proveedor es verificable. Los seis pilares a continuación le dan una lista fija de qué verificar y cómo verificarlo.

El marco de verificación de seguridad de gestores de contraseñas

El marco de verificación de seguridad de gestores de contraseñas divide la debida diligencia del proveedor en seis pilares: arquitectura de cifrado, autenticación y seguridad de sesión, gobernanza de acceso, verificación independiente, alineación con normativas y resiliencia operativa. Ejecute la tarjeta de puntuación a continuación contra cualquier proveedor, actual o potencial, antes de confiar en una afirmación que no haya verificado usted mismo.

Pilar Qué verificar Cómo verificar Notas de aprobado/suspenso
1. Arquitectura de cifrado Conocimiento cero vs. cifrado en reposo, ubicación de claves Solicite la documentación de arquitectura; pregunte dónde se generan las claves Suspenso: el proveedor puede descifrar sus datos bajo demanda
2. Autenticación y seguridad de sesión Fortaleza del método MFA, soporte de passkeys, tiempo de espera de sesión Pruebe el bloqueo automático y la reautenticación usted mismo Suspenso: MFA solo por SMS, sin tiempo de espera configurable
3. Gobernanza de acceso Granularidad de RBAC, revocación en bajas Simule una baja de empleado; verifique qué sobrevive a la desactivación de SSO Suspenso: contraseñas compartidas que nadie puede rotar centralmente
4. Verificación independiente ISO/IEC 27001, cadencia de pruebas de penetración Solicite el informe actual y las fechas del certificado Suspenso: sin informe o certificado caducado
5. Alineación con normativas Mapeo a cláusulas de GDPR, NIS2, NIST Pregunte a qué artículo o sección corresponde una afirmación Suspenso: solo «cumplimos», sin nombrar ninguna cláusula
6. Resiliencia operativa Acceso sin conexión, copias de seguridad, modelo de despliegue Pregunte qué sucede durante una interrupción o pérdida de dispositivo Suspenso: sin proceso de recuperación documentado

Trate la cuarta columna como una hoja de trabajo activa, no como una descripción. Complete un aprobado o suspenso real para cada pilar a medida que recopile evidencia, y califique como suspenso por defecto cualquier cosa que no pueda verificar en un plazo razonable. Un proveedor que necesita tres correos electrónicos de seguimiento para responder una solicitud de documentación le está diciendo algo sobre cómo manejará un incidente también.

Cada pilar tiene su propia sección a continuación, con las preguntas específicas a formular y cómo se ve un aprobado o suspenso en la práctica.

Pilar 1: Arquitectura de cifrado y diseño de conocimiento cero

La arquitectura de conocimiento cero significa que el proveedor no puede leer sus datos ni siquiera bajo coacción legal, no que simplemente elija no mirar. El cifrado en reposo es una afirmación mucho más débil: el proveedor tiene las claves y puede, en principio, descifrar su bóveda. Confundir los dos es la brecha más común en la página de seguridad de un proveedor.

Cifrado en reposo vs. conocimiento cero

El cifrado en reposo protege los datos de un intruso que roba la base de datos. No protege los datos del propio proveedor, de una citación judicial o de un empleado interno con acceso a la base de datos. El conocimiento cero, también descrito como cifrado de extremo a extremo cuando se aplica a dispositivos sincronizados, cierra esa brecha: el cifrado y descifrado ocurren exclusivamente en el cliente, y el servidor almacena solo texto cifrado y material de claves cifrado que no puede descifrar por sí solo. Arquitectura de conocimiento cero es el término que debe buscar por nombre, no «cifrado fuerte».

Cómo probar la afirmación

Los mecanismos importan más que la etiqueta. Las claves deben generarse del lado del cliente con un generador de números aleatorios criptográficamente seguro, derivarse a través de una función de derivación de claves (KDF) como PBKDF2 o Argon2 con un alto número de iteraciones, y usarse para cifrar los datos de bóveda y registro con AES-256. Las claves por bóveda o por registro, en lugar de una clave maestra que cubra toda la organización, limitan el radio de explosión si una sola clave se ve comprometida.

Una forma útil de probar si la explicación de un proveedor es real: pídale que recorra la cadena desde la contraseña maestra hasta el registro en texto plano. En un diseño genuino de conocimiento cero, esa cadena se ejecuta del lado del cliente en todo momento. La contraseña maestra deriva una clave maestra, la clave maestra descifra una clave privada almacenada, cifrada, en el servidor, la clave privada desbloquea las claves por bóveda, y las claves de bóveda desbloquean las claves de registro individuales que descifran cada contraseña o secreto. Si la explicación omite un paso, o el servidor necesita participar para completar el descifrado, la arquitectura no es de conocimiento cero, independientemente de lo que diga el folleto.

Lista de verificación

  • Solicite la documentación de arquitectura o criptografía.
  • Confirme dónde se generan las claves de cifrado: dispositivo del cliente o servidor.
  • Pregunte si las claves son únicas por bóveda o compartidas en toda la organización.
  • Confirme qué KDF se utiliza y su número de iteraciones o costo de memoria.

Lectura relacionada

Passwork vs. Bitwarden: cómo difiere la arquitectura de cifrado de bóvedas. Los dos productos ilustran este pilar desde extremos opuestos. Passwork genera una clave AES-256 independiente para cada bóveda, por lo que una clave filtrada expone solo esa bóveda, no el resto de la organización. Bitwarden deriva una única Organization Symmetric Key que envuelve la clave de cifrado de cada elemento corporativo, por lo que una clave de organización comprometida expone todo lo que posee la organización. Ambos son diseños legítimos de conocimiento cero — la diferencia es el radio de explosión después de que una sola clave se ve comprometida.

Pilar 2: Autenticación y seguridad de sesión

NIST SP 800-63B-4 indica a los verificadores que DEBERÁN permitir el uso de gestores de contraseñas y la funcionalidad de autocompletado (Sec. 3.1.1.2). Un proveedor cuyo producto obstaculiza el autocompletado del navegador, o cuya política predeterminada todavía fuerza la rotación de contraseñas cada 90 días, está trabajando contra el estándar actual, no protegiéndole.

Fortaleza del MFA y passkeys

La autenticación multifactor (MFA) es innegociable, pero no todos los MFA son iguales. Los códigos SMS son la opción más débil y vulnerables a ataques de intercambio de SIM. Las contraseñas de un solo uso basadas en tiempo (TOTP) son más fuertes y funcionan sin conexión. Las notificaciones push añaden comodidad pero son vulnerables a bombardeos de solicitudes a menos que se combinen con coincidencia de números. Las llaves de seguridad de hardware y las passkeys, basadas en el estándar FIDO2, resisten el phishing por diseño porque la credencial está vinculada al origen donde fue creada. El soporte de passkeys indica que un proveedor está al día con los estándares actuales.

El desbloqueo biométrico también merece una mirada más cercana. Face ID o un lector de huellas dactilares suele ser una capa de comodidad sobre la credencial real, desbloqueando una clave almacenada en el dispositivo en lugar de reemplazar completamente el MFA. Ese es un compromiso razonable en un dispositivo personal, pero confirme qué sucede en uno compartido o no gestionado: ¿el desbloqueo biométrico solo otorga acceso a la bóveda, o todavía requiere el paso de autenticación subyacente?

Contraseña maestra y reglas de sesión

Los requisitos de la contraseña maestra merecen el mismo escrutinio. NIST SP 800-63B-4 establece un umbral concreto: un mínimo de 15 caracteres para contraseñas de un solo factor, y ningún requisito de rotación periódica en ausencia de evidencia de compromiso. Si la política predeterminada de un proveedor todavía fuerza un cambio de contraseña maestra cada 90 días, esa política es anterior al estándar actual.

El tiempo de espera de sesión y el comportamiento de bloqueo automático determinan cuánto tiempo permanece explotable un dispositivo robado o desatendido. No confíe en la palabra de la hoja de especificaciones. Abra la aplicación, déjela inactiva durante el período de tiempo de espera indicado y confirme que realmente se bloquea. Pruebe también qué sucede después de un restablecimiento de contraseña: ¿se revoca inmediatamente cada otra sesión activa, o una sesión obsoleta en un segundo dispositivo sigue funcionando?

Lista de verificación

  • Opciones de MFA ofrecidas: TOTP, push con coincidencia de números, llave de hardware, passkey/FIDO2.
  • Política de contraseña maestra: basada en longitud, no en rotación de intervalo fijo.
  • Tiempo de espera de sesión y bloqueo automático: pruébelo usted mismo, no solo lea las especificaciones.
  • Manejo de sesiones concurrentes después de un restablecimiento de contraseña forzado o cierre de sesión.

Pilar 3: Gobernanza de acceso y privilegio mínimo

El control de acceso basado en roles (RBAC) suena como una casilla de verificación hasta que prueba qué sucede cuando alguien se va. Desactivar una cuenta de inicio de sesión único (SSO) revoca el acceso basado en directorio. No hace nada con una contraseña compartida que cuatro personas ya conocen, una clave API almacenada en caché en un pipeline de CI o un token almacenado localmente.

Qué tan granular es realmente el RBAC

Pregunte qué tan granular es realmente el RBAC. El acceso a nivel de rol («Administrador» versus «Miembro») es la opción más gruesa. El acceso basado en grupos, donde los permisos se adjuntan a un equipo o departamento y las personas los heredan por membresía, escala mejor y coincide con cómo está diseñado el control de acceso basado en roles: otorgue acceso al grupo una vez, luego añada o elimine personas de él. El acceso por carpeta o por elemento, superpuesto sobre los grupos, es lo que permite a un administrador entregar las credenciales de un proveedor a un contratista sin abrir toda la bóveda.

Desactivar SSO no es revocación

Desactivar SSO o AD no es revocación de acceso. Es desactivación de directorio. Un empleado que se va y que compartió un inicio de sesión para un portal de proveedores, un dispositivo de red o una aplicación heredada todavía conoce esa contraseña hasta que alguien la cambie. Verificar la gobernanza de acceso significa preguntar cómo el proveedor maneja esa brecha: ¿se marca una credencial compartida para rotación al dar de baja al empleado, o simplemente permanece ahí, sin revocar, indefinidamente?

La urgencia aquí no es teórica. El tiempo promedio de propagación de eCrime, el tiempo desde el acceso inicial hasta el movimiento lateral, cayó a 29 minutos en 2025, un 65% más rápido que en 2024, según el Global Threat Report 2026 de CrowdStrike. Una revisión de acceso anual no detecta una credencial que debería haberse revocado en abril. La revocación en tiempo real, impulsada por eventos, sí lo hace.

Las identidades de máquinas necesitan la misma disciplina

El privilegio mínimo debe extenderse a las identidades de máquinas, no solo a las personas. Las claves API, las cuentas de servicio y las credenciales de CI/CD a menudo quedan completamente fuera del modelo RBAC, aprovisionadas una vez y nunca revisadas de nuevo. Pregunte si las cuentas de servicio obtienen sus propios roles con alcance definido y política de rotación, separados de las cuentas de usuario interactivas, o si son una ocurrencia tardía añadida al mismo sistema de permisos construido para humanos.

Haga una pregunta más mientras está en ello: ¿puede el proveedor responder «quién tuvo acceso a esta credencial el mes pasado», después del hecho, desde un registro de auditoría, sin un ticket de soporte? Si no, el privilegio mínimo es una declaración de política, no un control aplicado.

Pilar 4: Verificación independiente: auditorías, certificaciones e historial de brechas

Cualquiera puede escribir «seguridad de nivel empresarial» en una página de destino. Una certificación de seguridad actual y nombrada con un rango de fechas válido, un resumen reciente de pruebas de penetración y un historial de incidentes documentado son la diferencia entre una afirmación y una afirmación que puede verificar. Si un proveedor no puede presentar ninguno de los tres, trate eso como una respuesta.

Qué demuestra realmente una certificación

La certificación ISO/IEC 27001 confirma que un proveedor opera un sistema de gestión de seguridad de la información certificado, evaluado por un auditor externo acreditado según un estándar internacional reconocido, no una lista de verificación autoevaluada. Verifique las fechas de emisión y vencimiento del certificado directamente en lugar de confiar en una insignia en un sitio web: las certificaciones generalmente se renuevan anualmente, y una insignia sin fecha visible podría tener años de antigüedad.

Un resumen de pruebas de penetración, idealmente de un tercero independiente o coordinado a través de un programa como HackerOne, muestra si alguien fuera del propio equipo del proveedor ha intentado irrumpir recientemente, y qué encontró.

Pregunte también qué cubre realmente la certificación. Una declaración de alcance limitada a «TI corporativo» o una sola línea de productos es evidencia más débil que una que cubra todo el entorno de producción que almacena sus credenciales. Algunos proveedores también abren su código fuente a la auditoría por parte de clientes o investigadores independientes. Esa es una señal más fuerte que un certificado solo, aunque es lo suficientemente poco común como para que su ausencia no sea automáticamente descalificadora.

El historial de brechas es en sí mismo una característica de seguridad

Cómo un proveedor manejó su último incidente de seguridad, si ha tenido uno, es en sí mismo una característica de seguridad. Ningún historial de incidentes documentado es inverosímil para cualquier proveedor que opere a escala. La pregunta más útil es si el proveedor ejecuta un proceso de monitoreo y divulgación, o si «nunca hemos tenido un incidente» es toda la respuesta.

Qué solicitar al proveedor

  • Certificación de seguridad actual (como ISO/IEC 27001), con fechas de emisión y vencimiento.
  • Resumen de la prueba de penetración más reciente y cadencia de pruebas (anual, como mínimo).

Pilar 5: Alineación con normativas (NIST, GDPR, NIS2 y reglas sectoriales)

Un proveedor que afirma «cumplimiento con GDPR» o «preparado para NIS2» sin nombrar un artículo específico está haciendo una afirmación de marketing, no legal. El Artículo 32 del GDPR y el Artículo 21 de NIS2 nombran cada uno medidas técnicas concretas. Asocie las afirmaciones de un proveedor con esas cláusulas directamente, y deje que su equipo legal confirme qué significa «cumplimiento» para sus obligaciones específicas.

Artículo 32 del GDPR

El Artículo 32(1)(a)-(b) del GDPR requiere que los responsables y encargados implementen «la seudonimización y el cifrado de datos personales» y «la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia permanentes de los sistemas y servicios de tratamiento» (GDPR, Art. 32). Para un gestor de contraseñas, eso se relaciona directamente con el Pilar 1 (arquitectura de cifrado) y el Pilar 6 (resiliencia) anteriores, no con una política de privacidad genérica.

Artículo 21 de NIS2

El Artículo 21(2) de NIS2 es aún más específico. El Artículo 21(2)(h) requiere «políticas y procedimientos relativos al uso de criptografía y, en su caso, de cifrado». El Artículo 21(2)(j) requiere «el uso de autenticación multifactor o de soluciones de autenticación continua... cuando proceda» (Directiva NIS2 (UE) 2022/2555, Art. 21). Las entidades esenciales e importantes bajo NIS2 necesitan un proveedor que pueda señalar ambas cláusulas por número, no uno que diga «sí, soportamos MFA» sin decir dónde se aplica. Los requisitos de acceso y criptografía de NIS2 profundizan en lo que cuenta como cumplimiento para organizaciones europeas específicamente.

NIST y reglas específicas del sector

NIST SP 800-63B-4, cubierto en el Pilar 2, es el estándar específico de autenticación detrás del lenguaje de MFA de ambos marcos. Vale la pena confirmar que la política predeterminada de un proveedor realmente lo refleja, no una regla de rotación más estricta y antigua dejada de un estándar anterior.

Las reglas específicas del sector se superponen a estas tres. Las organizaciones de salud añaden la regla de seguridad de HIPAA, las entidades financieras en la UE añaden DORA, y los compradores del sector público a menudo tienen requisitos de residencia que ninguno de los anteriores nombra directamente. Nada de eso cambia la pregunta subyacente que debe hacer a un proveedor de gestor de contraseñas: ¿qué artículo o cláusula satisface su arquitectura, y ese mapeo está documentado o simplemente afirmado?

Pilar 6: Resiliencia operativa, acceso sin conexión, copias de seguridad y modelo de despliegue

Las garantías de seguridad no sobreviven al contacto con una interrupción de red, un dispositivo perdido o un incidente en la nube del proveedor a menos que el proveedor haya construido para ello. El acceso sin conexión, un proceso de copia de seguridad y recuperación probado, y un modelo de despliegue que no entregue todas las claves a la infraestructura de una sola empresa son lo que mantiene un gestor de contraseñas usable — y seguro — cuando algo falla.

Interrupciones de red y acceso sin conexión

Pregunte qué sucede cuando la red se cae a mitad de sesión. Algunos productos fallan de forma cerrada, bloqueando a los usuarios de todas las credenciales hasta que se restaure la conectividad. Otros ofrecen un modo sin conexión con alcance limitado y solo lectura para registros que un usuario ha marcado explícitamente para almacenamiento en caché local cifrado, sincronizando todo de vuelta en el momento en que la conexión regresa. Solo lectura es el valor predeterminado más seguro: crear, editar y eliminar deberían requerir una conexión activa y autenticada.

Copia de seguridad y recuperación

La copia de seguridad y recuperación es la segunda mitad de la resiliencia. Pregunte cómo se cifran las copias de seguridad, quién controla la infraestructura de copias de seguridad y cómo se prueba realmente una restauración completa, no solo se programa. Una copia de seguridad que nunca se ha restaurado en un simulacro es una esperanza, no un plan.

Modelo de despliegue y resiliencia de infraestructura

El modelo de despliegue decide quién controla las claves. Un proveedor completamente alojado en la nube tiene la infraestructura, incluso bajo un diseño de conocimiento cero, lo que significa que el tiempo de actividad y la jurisdicción dependen de la región de nube de ese proveedor y su respuesta a incidentes. El despliegue autoalojado e híbrido pone la infraestructura, y la elección de dónde residen físicamente los datos, en manos del cliente, lo cual importa más para organizaciones con requisitos de residencia de datos, aislamiento de red o requisitos específicos del sector en salud, finanzas, gobierno o infraestructura crítica.

Pregunte también sobre los modos de fallo a nivel de infraestructura. Los servidores de aplicaciones redundantes y un clúster de base de datos correctamente configurado evitan que una sola falla de hardware deje fuera de servicio el acceso por completo. Para organizaciones que ejecutan redes completamente aisladas o sin conexión a internet, confirme que el despliegue funciona sin conexión a internet saliente de forma continua; un instalador sin conexión por sí solo no lo garantiza.

Cómo Passwork aborda estos seis pilares

Este marco se aplica a cualquier proveedor, incluido Passwork. Passwork es un gestor de contraseñas y secretos autoalojado, de conocimiento cero, construido para equipos empresariales y de DevOps. Así es como responde a cada uno de los seis pilares anteriores, con enlaces a la misma documentación que un evaluador externo solicitaría.

  • Arquitectura de cifrado: Passwork utiliza un modelo de cifrado de conocimiento cero del lado del cliente. Las claves se generan y usan en el cliente. El servidor almacena solo texto cifrado y material de claves cifrado, cifrado una segunda vez con una capa AES-256 independiente del lado del servidor encima. Las claves maestras se derivan a través de PBKDF2 con un alto número de iteraciones, y los datos de bóveda y registro usan AES-256 con claves únicas por bóveda y por registro, no una clave para toda la organización.
  • Autenticación y gobernanza de acceso: Passwork soporta TOTP, WebAuthn/passkeys, desbloqueo biométrico, SAML SSO y sincronización LDAP/AD, junto con tiempos de espera de sesión configurables y umbrales de bloqueo por intentos fallidos de inicio de sesión. El RBAC funciona a través de roles y grupos personalizados ilimitados, con mapeo de grupos de AD para que los cambios de directorio fluyan automáticamente al acceso a la bóveda en lugar de esperar un ticket. Las políticas de tipo de bóveda vinculan a los administradores corporativos a una categoría de bóveda en sí, no a quien la creó, cerrando la brecha de bóvedas personales no autorizadas que el acceso a nivel de rol solo no detecta.
  • Registro de auditoría y verificación independiente: cada bóveda, carpeta, contraseña y acción de administrador llega a un registro de actividad exportable, filtrable por usuario, fecha y tipo de acción, y puede alimentar un SIEM directamente. Passwork está certificado en ISO 27001 y se somete a pruebas de penetración externas anuales a través de HackerOne; el registro de auditoría y certificación de Passwork es el mismo tipo de documento que este marco pide a cada proveedor que presente, no una afirmación que aceptar por fe.
  • Alineación con normativas: el despliegue autoalojado de Passwork mantiene los datos en la infraestructura del cliente, lo que simplifica los requisitos de residencia de datos bajo GDPR y reglas sectoriales, y su RBAC vinculado a políticas más registros de auditoría exportables se relacionan con las medidas de gestión de riesgos del Artículo 21(2) de NIS2 y los controles del Anexo A de ISO/IEC 27001 sobre gestión de acceso y registro.
  • Resiliencia operativa: debido a que Passwork se ejecuta en la propia infraestructura del cliente, incluidas redes sin conexión a internet, el tiempo de actividad y la estrategia de copias de seguridad permanecen bajo el control del cliente en lugar del cronograma de incidentes de nube de un proveedor. El modo seguro sin conexión permite a los usuarios ver registros específicamente marcados sin una conexión activa, solo lectura, con caducidad automática de caché y sincronización completa del registro de actividad al reconectarse.

Conclusión

Ninguno de los seis pilares anteriores es exótico. Son los documentos, preguntas y pruebas específicas que convierten la página de seguridad de un proveedor de una afirmación en algo que realmente ha verificado: dónde residen las claves, cómo se comportan realmente el MFA y las sesiones, si la baja de empleados alcanza a las credenciales compartidas, y si un certificado ISO 27001 está vigente en lugar de ser aspiracional.

Elija el pilar donde la respuesta de su proveedor actual es más débil, y comience su próxima conversación de renovación allí.

Si está evaluando un gestor de contraseñas, o auditando el que ya tiene, pruebe Passwork gratis y aplique este marco a una bóveda autoalojada de conocimiento cero construida para responder cada una de estas preguntas con evidencia.

Preguntas frecuentes

¿Cuál es la diferencia entre «cifrado» y «conocimiento cero» en un gestor de contraseñas?

El cifrado en reposo solo significa que los datos están codificados en los servidores del proveedor; el proveedor todavía puede tener las claves. El conocimiento cero significa que el proveedor nunca tiene el texto plano ni las claves para descifrarlo. Solo la clave del lado del cliente del usuario puede desbloquear la bóveda, incluso si la infraestructura del proveedor está completamente comprometida.

¿Un gestor de contraseñas necesita soportar passkeys para considerarse seguro?

No estrictamente, pero el soporte de passkeys y FIDO2 indica que el proveedor está al día con los estándares actuales de autenticación. El MFA, idealmente no solo SMS, es la línea base innegociable. Las passkeys se esperan cada vez más además de esto, especialmente para el inicio de sesión resistente al phishing en la propia bóveda.

¿Qué sucede con la seguridad del gestor de contraseñas si el servicio en la nube del proveedor se cae?

Si el proveedor solo soporta acceso en línea, una interrupción puede bloquearle de todas las credenciales hasta que se reanude el servicio. Busque un modo sin conexión o local de solo lectura documentado, un proceso de copia de seguridad y recuperación probado, y una opción de despliegue — autoalojado o híbrido — que le mantenga en control si la infraestructura del proveedor falla.

¿Con qué frecuencia deben re-verificarse las certificaciones de seguridad de un gestor de contraseñas?

Las certificaciones como ISO/IEC 27001 generalmente se renuevan anualmente. Solicite las fechas de emisión y vencimiento del certificado actual en lugar de asumir que una insignia mencionada en el sitio web de un proveedor todavía está activa; un certificado caducado es fácil de pasar por alto sin verificar directamente.

¿Qué requiere realmente el GDPR o NIS2 de la arquitectura de un gestor de contraseñas?

El Artículo 32(1)(a)-(b) del GDPR requiere «la seudonimización y el cifrado de datos personales» y la capacidad de garantizar la confidencialidad, integridad, disponibilidad y resiliencia continuas de los sistemas de tratamiento. El Artículo 21(2)(h) y (j) de NIS2 requieren políticas de criptografía documentadas y autenticación multifactor o continua. Pida a un proveedor que asocie su arquitectura con estas cláusulas específicas, no que responda con un genérico «sí, cumplimos».

¿Es un gestor de contraseñas autoalojado más seguro que uno alojado en la nube?

No automáticamente, pero cambia quién controla el tiempo de actividad, la residencia de datos y la respuesta a incidentes. Un proveedor alojado en la nube tiene la infraestructura incluso bajo un diseño de conocimiento cero, por lo que una interrupción o brecha de su lado le afecta directamente. El despliegue autoalojado e híbrido mantiene la infraestructura, y la ubicación física de los datos, en manos del cliente, lo cual importa más para entornos regulados, sin conexión a internet o sensibles a la residencia de datos.

Gestión de contraseñas empresariales: guía completa para organizaciones B2B
Una guía completa para líderes B2B sobre gestión de contraseñas empresariales. Explore opciones de despliegue (nube, local, híbrido), arquitectura de seguridad y mejores prácticas de implementación.
PassworkAlex Muntyan
¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos
El cifrado de conocimiento cero significa que el servidor nunca tiene sus claves de descifrado, solo texto cifrado. Aprenda cómo funciona la cadena de claves, contra qué protege, contra qué no, y cómo verificar la afirmación de un proveedor.
PassworkPasswork Team
Requisitos de contraseñas de NIS2: lo que las empresas europeas deben hacer en 2026
Las brechas de credenciales son el principal punto de fallo en auditorías NIS2 en 2026. Esta guía cubre los requisitos de contraseñas del Artículo 21, la alineación con NIST SP 800-63B, los pasos de endurecimiento de AD y la evidencia de auditoría que los reguladores piden primero.
PassworkAlex Muntyan