Configurar Credential Guard en Windows paso a paso

Credential Guard se ha convertido en una pieza clave para reforzar la seguridad de credenciales en entornos Windows modernos, especialmente en organizaciones donde un ataque de robo de credenciales puede suponer un problema serio. En lugar de dejar los secretos de autenticación expuestos en la memoria del sistema, esta característica los aísla mediante seguridad basada en virtualización, reduciendo muchísimo la superficie de ataque.

En las siguientes líneas vas a ver cómo configurar Credential Guard con distintos métodos (Intune/MDM, Directiva de grupo y Registro), qué requisitos debe cumplir el equipo, qué limitaciones introduce, cómo validar que realmente está activo y también cómo deshabilitarlo en escenarios donde sea necesario, incluyendo máquinas virtuales y equipos con bloqueo UEFI. Todo explicado con detalle, pero con un lenguaje cercano para que puedas aplicarlo sin complicarte la vida.

Qué es Credential Guard y cómo protege las credenciales

Credential Guard es una característica de seguridad de Windows que usa la seguridad basada en virtualización (VBS) para aislar credenciales y otros secretos relacionados con la autenticación. En lugar de que todo se almacene directamente en el proceso de la autoridad de seguridad local (lsass.exe), los datos sensibles se guardan en un componente aislado llamado LSA aislado o isolated LSA.

Este LSA aislado se ejecuta en un entorno protegido, separado del sistema operativo principal mediante el hipervisor (modo seguro virtual o VSM). Solo un conjunto muy reducido de binarios, firmados con certificados de confianza, pueden cargarse en ese entorno. La comunicación con el resto del sistema se hace mediante RPC, lo que impide que el malware que corre en el sistema, por muy privilegiado que sea, pueda leer directamente los secretos protegidos.

Credential Guard protege específicamente tres tipos de credenciales: los hashes de contraseñas NTLM, los tickets de concesión de tickets de Kerberos (TGT) y las credenciales almacenadas por las aplicaciones como credenciales de dominio. De esta forma se mitigan ataques clásicos como pass-the-hash o pass-the-ticket, muy habituales en movimientos laterales dentro de redes corporativas.

Es importante tener claro que Credential Guard no lo protege todo: no cubre, por ejemplo, credenciales manejadas por software de terceros fuera de los mecanismos estándar de Windows, cuentas locales y de Microsoft, ni protege frente a ataques físicos o registradores de pulsaciones de teclas. Aun así, reduce enormemente el riesgo relacionado con credenciales de dominio.

Habilitación predeterminada de Credential Guard

Desde Windows 11 22H2 y Windows Server 2025, la seguridad basada en virtualización (VBS) y Credential Guard se activan por defecto en dispositivos que cumplen los requisitos de hardware, firmware y software definidos por Microsoft. Esto significa que, en muchos equipos modernos, ya viene preparado y activo sin que el administrador tenga que hacer nada.

La habilitación predeterminada se realiza en modo “sin bloqueo UEFI”, es decir, sin el candado que impide desactivarlo remotamente. Este enfoque facilita que los administradores puedan deshabilitar Credential Guard mediante políticas o configuración remota si alguna aplicación crítica no es compatible o se detectan problemas de rendimiento.

Cuando Credential Guard se activa de forma predeterminada, la propia VBS también se habilita automáticamente. No es necesario configurar VBS aparte para que Credential Guard funcione, aunque sí hay parámetros adicionales para reforzar el nivel de protección de la plataforma (por ejemplo, exigir protección DMA además del arranque seguro).

Hay un matiz importante en equipos actualizados: si un dispositivo tenía Credential Guard deshabilitado explícitamente antes de actualizar a una versión de Windows donde se active por defecto, seguirá deshabilitado tras la actualización. En otras palabras, la configuración explícita del administrador tiene prioridad sobre el comportamiento por defecto.

Requisitos de sistema, hardware, firmware y licenciamiento

Para que Credential Guard aporte protección real, el dispositivo debe cumplir una serie de requisitos mínimos de hardware, firmware y software. Aquellos equipos que superan estos mínimos y disponen de funcionalidades adicionales, como IOMMU o TPM 2.0, pueden aprovechar niveles de seguridad superiores frente a ataques DMA y amenazas avanzadas.

Requisitos de hardware y firmware

Los principales requisitos de hardware para Credential Guard incluyen una CPU de 64 bits con extensiones de virtualización (Intel VT-x o AMD-V) y soporte de traducción de direcciones de segundo nivel (SLAT, también conocidas como Extended Page Tables). Sin estas capacidades de virtualización, VBS y el modo seguro virtual no podrán aislar la memoria de forma adecuada.

A nivel de firmware es obligatorio disponer de UEFI en versión 2.3.1 o superior con soporte de arranque seguro (Secure Boot) y un proceso de actualización de firmware seguro. Además, se recomiendan características como MOR (Memory Overwrite Request) implementado de forma segura, protección de la configuración de arranque y capacidad de actualización de firmware a través de Windows Update.

El uso de una unidad de gestión de memoria de entrada/salida (IOMMU), como Intel VT-d o AMD-Vi, es muy recomendable, ya que permite habilitar protección DMA en conjunción con VBS. Esta protección evita que dispositivos maliciosos conectados al bus puedan acceder directamente a la memoria y extraer secretos.

El módulo de plataforma segura (TPM) es otro componente clave, preferentemente en versión TPM 2.0, aunque también se admite TPM 1.2. El TPM proporciona un anclaje de seguridad en hardware para proteger la clave maestra de VSM y asegurar que solo se pueda acceder a los datos protegidos por Credential Guard en un entorno de confianza.

Protecciones de VSM y papel del TPM

Los secretos protegidos por Credential Guard se aíslan en memoria mediante el modo seguro virtual (VSM). En hardware reciente con TPM 2.0, los datos persistentes del entorno VSM se cifran con una clave maestra de VSM protegida por el propio TPM y por los mecanismos de arranque seguro del dispositivo.

Aunque NTLM y los TGT de Kerberos se regeneran en cada inicio de sesión y no se suelen conservar entre reinicios, la existencia de la clave maestra VSM permite proteger aquellos datos que sí puedan mantenerse en el tiempo. El TPM garantiza que no se pueda extraer esa clave fuera del dispositivo ni acceder a los secretos protegidos fuera de un entorno validado.

Requisitos de edición de Windows y licencias

Credential Guard no está disponible en todas las ediciones de Windows. En sistemas cliente, se admite en Windows Enterprise y en Windows Education, pero no en Windows Pro ni en Windows Pro Education/SE. Es decir, un equipo con Windows Pro necesitaría una actualización a Enterprise para poder usar esta funcionalidad.

Los derechos de uso de Credential Guard se conceden mediante licencias como Windows Enterprise E3 y E5 o bien las licencias educativas A3 y A5. En entornos empresariales, esto suele obtenerse a través de acuerdos de licencia por volumen, mientras que los OEM normalmente entregan Windows Pro y el cliente realiza luego la actualización a Enterprise.

Credential Guard en máquinas virtuales Hyper-V

Credential Guard también puede proteger secretos dentro de máquinas virtuales ejecutadas en Hyper-V, de forma similar a lo que hace en equipos físicos. Los requisitos principales son que el host de Hyper-V disponga de IOMMU y que las máquinas virtuales sean de generación 2.

Es importante entender la frontera de protección en estos escenarios: Credential Guard protege frente a ataques que se originan dentro de la propia máquina virtual, pero no frente a amenazas que proceden del host con privilegios elevados. Si el host está comprometido, puede seguir teniendo acceso a las máquinas invitadas.

Requisitos de aplicaciones y compatibilidad

Al activar Credential Guard se bloquean ciertas funcionalidades de autenticación, por lo que algunas aplicaciones pueden dejar de funcionar si dependen de métodos antiguos o inseguros. Antes de desplegarlo masivamente, conviene probar las aplicaciones críticas para comprobar que siguen operativas.

Las aplicaciones que requieren cifrado DES para Kerberos, delegación de Kerberos sin restricciones, extracción de TGT o uso de NTLMv1 se verán interrumpidas porque estas opciones quedan directamente deshabilitadas cuando Credential Guard está activo. Es una medida de seguridad estricta, pero necesaria para evitar vulnerabilidades graves.

Otras funcionalidades, como la autenticación implícita, la delegación de credenciales, MS-CHAPv2 o CredSSP, exponen las credenciales a riesgos adicionales incluso cuando Credential Guard está activo. Las aplicaciones que insisten en usarlas pueden seguir funcionando, pero dejan las credenciales más expuestas, por lo que también se recomienda revisarlas.

Puede haber también impactos de rendimiento si ciertas aplicaciones intentan interactuar directamente con el proceso aislado LsaIso.exe. En general, los servicios que usan Kerberos de forma estándar (por ejemplo, recursos compartidos de archivos o Escritorio remoto) continúan funcionando normalmente sin notar cambios.

Cómo habilitar Credential Guard correctamente

La recomendación general de Microsoft es habilitar Credential Guard antes de que el dispositivo se una a un dominio o antes de que un usuario de dominio inicie sesión por primera vez. Si se activa más tarde, es posible que los secretos de usuario o del equipo ya hayan sido expuestos en la memoria sin protección.

Hay tres métodos principales para configurar esta característica: mediante Microsoft Intune/MDM, usando Directiva de grupo y a través del Registro de Windows. La elección depende del tipo de entorno, herramientas de gestión disponibles y grado de automatización deseado.

Habilitar Credential Guard mediante Microsoft Intune / MDM

En entornos gestionados con Intune u otras soluciones MDM, se puede habilitar Credential Guard creando una directiva de configuración de dispositivo que active primero la seguridad basada en virtualización y, después, defina el comportamiento específico de Credential Guard.

Usando el CSP de DeviceGuard se pueden crear directivas personalizadas con los siguientes parámetros OMA-URI clave:

• Activar VBS: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity, tipo de datos int, valor 1 para habilitar la seguridad basada en virtualización.
• Configurar Credential Guard: OMA-URI ./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags, tipo int, valor 1 para habilitar con bloqueo UEFI o 2 para habilitar sin bloqueo.

Una vez creada la directiva, se asigna al grupo de dispositivos o usuarios que se desea proteger. Tras la aplicación de la política, es necesario reiniciar el dispositivo para que Credential Guard entre en funcionamiento.

Configurar Credential Guard con Directiva de grupo (GPO)

En dominios Active Directory, el método más cómodo suele ser la GPO. Se puede usar el Editor de directiva de grupo local para un solo equipo o crear un objeto de directiva de grupo vinculado a dominios o unidades organizativas para abarcar muchos dispositivos.

La ruta concreta de la política de grupo es: Configuración del equipo → Plantillas administrativas → Sistema → Device Guard. Dentro de esa sección hay una configuración llamada «Activar la seguridad basada en virtualización».

Al habilitar esta directiva, se debe elegir la opción de Credential Guard en la lista desplegable de «Configuración de Credential Guard»:

• Habilitado con bloqueo UEFI: impide deshabilitar remotamente Credential Guard; solo puede cambiarse mediante acceso físico al firmware/BIOS.
• Habilitado sin bloqueo: permite desactivar Credential Guard posteriormente mediante GPO o configuración remota.

Las GPO se pueden filtrar mediante grupos de seguridad o filtros WMI, permitiendo aplicar esta protección solo a ciertos tipos de equipos o perfiles. Tras la aplicación de la política, también es necesario reiniciar para que los cambios tengan efecto.

Configurar Credential Guard mediante el Registro de Windows

Cuando se necesita un control más granular o un script personalizado, se puede habilitar Credential Guard directamente a través del Registro. Este método suele usarse en escenarios avanzados o automatizaciones donde no se dispone de GPO o MDM.

Para activar la seguridad basada en virtualización (VBS), hay que configurar las siguientes claves:

• Ruta de clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Nombre: EnableVirtualizationBasedSecurity, tipo REG_DWORD, valor 1.
• Ruta de clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
  Nombre: RequirePlatformSecurityFeatures, tipo REG_DWORD, valor 1 para arranque seguro o 3 para arranque seguro con protección DMA.

Para la configuración específica de Credential Guard se usa la clave:

• Ruta de clave: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
  Nombre: LsaCfgFlags, tipo REG_DWORD, valores posibles:
  0 para deshabilitar Credential Guard,
  1 para habilitarlo con bloqueo UEFI,
  2 para habilitarlo sin bloqueo.

Tras ajustar estas claves en el Registro, hay que reiniciar el equipo para que VBS y Credential Guard se inicialicen correctamente y empiecen a proteger credenciales.

Comprobar si Credential Guard está habilitado

Aunque pueda parecer tentador mirar si el proceso LsaIso.exe está en ejecución desde el Administrador de tareas, Microsoft no recomienda este método como comprobación fiable. En su lugar, se proponen tres mecanismos principales: Información del sistema, PowerShell y Visor de eventos.

Verificación con Información del sistema (msinfo32)

La forma más sencilla para muchos administradores es utilizar la herramienta «Información del sistema» de Windows:

1. Selecciona Inicio y escribe msinfo32.exe, luego abre la aplicación «Información del sistema».
2. En el panel izquierdo, accede a Resumen del sistema.
3. En el panel derecho, busca el apartado «Servicios de seguridad basados en virtualización en ejecución» y comprueba que aparezca «Credential Guard» entre los servicios listados.

Si Credential Guard figura como servicio en ejecución en esta sección, significa que está correctamente habilitado y activo en el equipo.

Verificación mediante PowerShell

En entornos administrados resulta muy práctico usar PowerShell para comprobar de forma masiva el estado de Credential Guard. Desde una consola de PowerShell con privilegios elevados, puedes ejecutar:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Este comando devuelve un conjunto de valores numéricos que indican qué servicios de seguridad basados en virtualización están activos. En el caso concreto de Credential Guard, se interpretan así:

• 0: Credential Guard deshabilitado (no está en ejecución).
• 1: Credential Guard habilitado (en ejecución).

Además de esta consulta genérica, Microsoft ofrece el script DG_Readiness_Tool (por ejemplo, DG_Readiness_Tool_v2.0.ps1), con el que se puede comprobar si el sistema es capaz de ejecutar Credential Guard, habilitarlo, deshabilitarlo y validar su estado mediante opciones como -Capable, -Enable, -Disable y -Ready.

Uso del Visor de eventos

Otra vía de comprobación más orientada a auditoría es utilizar el Visor de eventos. Desde eventvwr.exe se puede acceder a «Registros de Windows» → «Sistema» y filtrar los eventos cuyo origen sea «WinInit».

Entre esos eventos aparecen entradas relacionadas con el arranque de los servicios de seguridad basados en virtualización, incluyendo aquellos que indican si Credential Guard se ha inicializado correctamente durante el proceso de inicio.

Deshabilitar Credential Guard y gestión del bloqueo UEFI

Aunque lo normal es querer mantener Credential Guard habilitado, hay escenarios donde puede ser necesario desactivarlo: incompatibilidades de aplicaciones, pruebas de laboratorio, cambios de arquitectura de seguridad, etc. El procedimiento para deshabilitarlo dependerá de cómo se activó y de si se utilizó el bloqueo UEFI.

En términos generales, deshabilitar Credential Guard implica revertir la configuración aplicada mediante Intune/MDM, Directiva de grupo o Registro, y posteriormente reiniciar el equipo. Sin embargo, cuando se activó con bloqueo UEFI, hay pasos adicionales porque parte de la configuración queda almacenada en variables EFI del firmware.

Deshabilitación de Credential Guard con bloqueo UEFI

Si Credential Guard se habilitó con bloqueo UEFI, no basta con cambiar la GPO o el Registro. Hay que eliminar también las variables EFI asociadas a la configuración de LSA aislado utilizando bcdedit y un pequeño proceso especial de arranque.

Desde un símbolo del sistema con privilegios elevados se ejecuta una secuencia de comandos para:

1. Montar una unidad EFI temporal con mountvol y copiar SecConfig.efi a la ruta de arranque de Microsoft.
2. Crear una entrada de cargador de sistema con bcdedit /create apuntando a ese SecConfig.efi.
3. Configurar el bootsequence del gestor de arranque para que arranque una vez con ese cargador especial.
4. Agregar la opción de carga DISABLE-LSA-ISO para deshabilitar la configuración de LSA aislado almacenada en UEFI.
5. Desmontar de nuevo la unidad EFI temporal.

Tras realizar estos pasos se reinicia el dispositivo. Antes de que arranque el sistema operativo, aparecerá un mensaje indicando que se ha modificado la configuración UEFI y se pedirá confirmación. Es imprescindible aceptar ese mensaje para que los cambios de desactivación sean persistentes.

Deshabilitar Credential Guard en máquinas virtuales

En el caso de máquinas virtuales conectadas a un host Hyper-V, se puede hacer que la VM no utilice VBS y Credential Guard incluso si el sistema operativo invitado estaría preparado para ello.

Desde el host, con PowerShell, se puede ejecutar el siguiente comando para que una máquina virtual quede excluida de la seguridad basada en virtualización:

Set-VMSecurity -VMName <VMName> -VirtualizationBasedSecurityOptOut $true

Al activar esta opción de exclusión, la VM se ejecutará sin las protecciones de VBS y, por extensión, sin Credential Guard, lo cual puede resultar útil en entornos de test o cuando se ejecutan sistemas heredados dentro de máquinas virtuales.

Integración de Credential Guard en AWS Nitro y otros escenarios

Credential Guard también está disponible en entornos de nube como Amazon EC2, aprovechando la arquitectura segura del sistema AWS Nitro. En este contexto, VBS y Credential Guard se apoyan en Nitro para evitar que las credenciales de inicio de sesión de Windows se extraigan de la memoria del sistema operativo invitado.

Para usar Credential Guard en una instancia de Windows en EC2, hay que lanzar una instancia compatible, seleccionando un tipo de instancia admitido y una AMI de Windows preconfigurada que incluya TPM virtual y soporte de VBS. Esto se puede hacer desde la consola de Amazon EC2, desde AWS CLI usando run-instances o con PowerShell mediante New-EC2Instance, especificando, por ejemplo, una imagen del estilo TPM-Windows_Server-2022-English-Full-Base.

En algunos escenarios será necesario desactivar la integridad de memoria (HVCI) antes de activar Credential Guard, ajustando políticas de grupo relacionadas con «Protección basada en la virtualización de la integridad del código». Una vez realizados estos ajustes y reiniciada la instancia, se puede habilitar Credential Guard y validarlo, como en cualquier otro equipo Windows, con msinfo32.exe.

Límites de protección y aspectos que Credential Guard no cubre

Aunque Credential Guard da un salto enorme en protección de credenciales, no es una bala de plata que lo resuelva todo. Hay casos concretos que quedan fuera de su ámbito, y conviene tenerlos claros para no caer en una falsa sensación de seguridad.

Algunos ejemplos de lo que no protege son:

• Software de terceros que gestiona credenciales fuera de los mecanismos estándar de Windows.
• Cuentas locales y cuentas de Microsoft configuradas en el propio equipo.
• Base de datos de Active Directory en controladores de dominio Windows Server.
• Canales de entrada de credenciales como servidores de puerta de enlace de Escritorio remoto.
• Registradores de pulsaciones de teclas y ataques físicos directos al equipo.

Tampoco impide que un atacante con malware en el equipo haga uso de los privilegios ya concedidos a una credencial activa. Es decir, si un usuario con permisos elevados se conecta a un sistema comprometido, el atacante puede aprovechar esos permisos mientras dure la sesión, aunque no pueda robar el hash desde la memoria protegida.

En entornos con usuarios o cuentas de alto valor (administradores de dominio, personal de TI con acceso a recursos críticos, etc.), sigue siendo recomendable utilizar equipos dedicados y otras capas adicionales de seguridad, como autenticación multifactor, segmentación de red y medidas anti-keylogger.

Device Guard, VBS y relación con Credential Guard

Device Guard y Credential Guard suelen mencionarse juntos porque ambos aprovechan la seguridad basada en virtualización para reforzar la protección del sistema, aunque resuelven problemas distintos.

Credential Guard se centra en proteger credenciales (NTLM, Kerberos, Credential Manager) aislándolas en el LSA protegido. No depende de Device Guard, aunque ambos comparten el uso del hipervisor y de características de hardware como TPM, arranque seguro e IOMMU.

Device Guard, por su parte, es un conjunto de características de hardware y software que permiten bloquear el dispositivo para que solo pueda ejecutar aplicaciones de confianza definidas en políticas de integridad de código. Cambia el modelo tradicional (todo se ejecuta salvo que lo bloquee un antivirus) por otro en el que solo se ejecuta lo explícitamente autorizado.

Ambas funciones forman parte del arsenal de Windows Enterprise para proteger frente a amenazas avanzadas. Device Guard depende de VBS y requiere que los controladores sean compatibles con HVCI, mientras que Credential Guard se apoya en VBS para aislar los secretos de autenticación. Juntas, ofrecen una combinación potente: código más fiable y credenciales mejor protegidas.

Tener Credential Guard bien configurado supone blindar uno de los puntos más delicados de cualquier entorno Windows: las credenciales de usuarios y equipos. Entender sus requisitos, saber cómo activarlo con Intune, GPO o Registro, conocer sus límites y disponer de procedimientos claros para verificar su estado y deshabilitarlo en casos excepcionales permite aprovechar al máximo esta tecnología sin llevarse sorpresas en producción.