Guía completa para configurar Credential Guard y Device Guard en Windows

En entornos corporativos modernos, proteger las credenciales y controlar estrictamente qué código se ejecuta en los equipos Windows ya no es opcional. Con la llegada de Windows 10, Windows 11 y Windows Server 2016 en adelante, Microsoft ha apostado fuerte por la seguridad basada en virtualización, dando lugar a tecnologías como Credential Guard, Device Guard y Application Guard. Consulta nuestra guía completa de seguridad en Windows 11 para empresas.

Si administras una red de equipos, te interesa conocer a fondo cómo configurar Credential Guard y Device Guard de forma correcta, cómo se integran con otras medidas como BitLocker, Exploit Guard o Remote Credential Guard, y qué papel juegan las líneas base de seguridad de Microsoft Defender para punto de conexión (especialmente cuando trabajas con Intune o GPO tradicionales).

Fundamentos: VBS, VSM y el papel de Credential Guard y Device Guard

Para entender por qué Credential Guard y Device Guard son tan efectivos, primero hay que tener claro el concepto de seguridad basada en virtualización (VBS). VBS utiliza las capacidades de virtualización del procesador (Intel VT-x o AMD-V) para crear un entorno aislado dentro de la propia máquina, separado lógicamente del sistema operativo principal. Este enfoque se complementa con técnicas como el aislamiento de núcleo en Windows 11, que refuerzan la separación entre el núcleo y el resto del sistema.

Sobre ese VBS se construye el Virtual Secure Mode (VSM), un subsistema que almacena y procesa la información especialmente sensible. El sistema operativo «normal» no accede directamente a ese contenido, sino que se relaciona a través de interfaces muy limitadas y controladas, reduciendo la superficie de ataque.

Dentro de este contexto aparece Credential Guard, que utiliza el VSM para custodiar las credenciales de los usuarios y los secretos de autenticación (como los hashes de NTLM o los tickets de Kerberos). Al estar aislados del resto del sistema, incluso si un atacante consigue privilegios elevados, le resulta mucho más difícil extraer esas credenciales.

Device Guard, por su parte, se centra en el control de código. Su objetivo es que solo se ejecuten aplicaciones firmadas y confiables, bloqueando binarios desconocidos o potencialmente maliciosos. En la práctica, Device Guard se implementa con varias tecnologías, siendo la más conocida el uso de políticas de integridad de código (Code Integrity) y la configuración basada en listas blancas.

Ambas soluciones se apoyan en el mismo pilar: un entorno seguro aislado mediante VBS/VSM, con soporte reforzado mediante hardware como TPM (Trusted Platform Module), que ayuda a proteger claves criptográficas y a verificar la integridad del arranque del sistema.

Líneas base de seguridad de Microsoft Defender para punto de conexión

Si gestionas tus equipos con Microsoft Intune o con la consola de seguridad de Microsoft Defender para punto de conexión, las líneas base de seguridad son tu mejor aliada para desplegar configuraciones complejas (como Credential Guard y Device Guard) sin volverte loco con cada ajuste individual.

Una línea base de seguridad no es más que un conjunto de parámetros preconfigurados para Windows, agrupados y recomendados por los equipos de seguridad de Microsoft. Cuando creas un perfil de línea base en Intune, en realidad estás generando una plantilla con multitud de ajustes de dispositivo: políticas de credenciales, control de aplicaciones, opciones de VBS, parámetros de Defender, etc.

En la documentación de Microsoft Defender para punto de conexión se publican diferentes versiones de esta línea base, por ejemplo: 24H1, la línea base de diciembre de 2020 (versión 6), la de septiembre de 2020 (versión 5), y versiones anteriores como las de abril y marzo de 2020. Cada una de ellas incluye una lista detallada de opciones, con su estado por defecto y, cuando es posible, enlaces a los proveedores de servicios de configuración (CSP) concretos o a documentación ampliada del mismo grupo de productos.

Cuando sale una versión nueva de la línea base, desplaza automáticamente a la versión previa. Los perfiles que creaste con una versión antigua pasan a estar en modo solo lectura: puedes seguir asignándolos, cambiar su nombre, su descripción o sus grupos de destino, pero no puedes modificar sus parámetros internos.

Para adaptar la configuración a los nuevos estándares, Intune permite actualizar esos perfiles a la versión de línea base actual. Una vez actualizado el perfil, sí podrás editar la configuración y ajustar, por ejemplo, el estado de Credential Guard, Device Guard, BitLocker o cualquier otra opción incluida.

Microsoft insiste en que esta línea base de Defender para punto de conexión está optimizada para dispositivos físicos. No se recomienda usarla tal cual en máquinas virtuales o en entornos VDI, ya que ciertas opciones pueden interferir con sesiones remotas interactivas o con determinadas arquitecturas de virtualización. Para entornos VDI es importante revisar la documentación específica sobre cómo incrementar el cumplimiento de la línea base sin romper la experiencia de usuario.

Requisitos previos y compatibilidad de sistemas

Para poner en marcha Credential Guard y Device Guard, y más aún si los quieres integrar con otras tecnologías (Remote Credential Guard, Application Guard, soluciones Citrix, etc.), es clave verificar requisitos de hardware, sistema operativo y versiones de software.

En términos generales, necesitarás:

• CPU con soporte de virtualización (Intel VT-x o AMD-V) y la virtualización habilitada en BIOS/UEFI.
• Soporte para Virtualization-based Security (VBS) activado desde la configuración de seguridad del sistema.
• TPM (de preferencia TPM 2.0) para reforzar el almacenamiento de claves y la integridad del arranque del sistema.
• Versiones compatibles de Windows 10/11 Enterprise o Windows Server a partir de 2016 para aprovechar VSM.

En el ámbito de escritorios virtuales y aplicaciones remotas, Citrix documenta requisitos específicos para su función de transferencia de dominio mejorada para SSO (inicio de sesión único), que se apoya justamente en Remote Credential Guard:

• Virtual Delivery Agent (VDA) en versión 2308 o superior; si usas Windows 11 en host de sesión o en cliente, se exige VDA 2407 o 2402 LTSR CU2 o posterior.
• Aplicación Citrix Workspace versión 2309 o superior y, en entornos con Windows 11, al menos la 2405.10 o 2402 LTSR CU2.
• Clientes Windows 10/11 de 64 bits, unidos a dominio de Active Directory y con conectividad directa con los controladores de dominio (sin conexión no hay SSO).
• Hosts de sesión de una sola sesión con Windows 10 22H2 o Windows 11 22H2 o posterior.

Esta función de Citrix sustituye a la autenticación de transferencia heredada basada en el antiguo servicio de SSO (ssonsvr.exe) y no es compatible con sistemas de 32 bits. Además, no puedes usar simultáneamente en el mismo host la transferencia de dominio heredada y la nueva transferencia de dominio mejorada.

Configuración y despliegue de Credential Guard

Credential Guard es una de las piezas centrales del ecosistema VBS. Su misión es clara: impedir que las credenciales almacenadas en el sistema (como los hashes en memoria del proceso LSASS) se roben mediante herramientas de volcado o ataques de movimiento lateral.

Para habilitar Credential Guard de forma clásica mediante directivas de grupo, el ajuste clave se encuentra dentro de las opciones de seguridad basadas en virtualización de Windows. En versiones más recientes, estas políticas suelen agruparse dentro de Device Guard en la plantilla de GPO, concretamente en “Activar la seguridad basada en virtualización”.

Cuando esta política está configurada adecuadamente, el sistema arranca con VBS y activa Credential Guard. Internamente, esto se traduce en cambios en el registro, especialmente en la clave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Ahí reside el valor LsaCfgFlags, que controla el comportamiento de Credential Guard. Un valor 0 deshabilita la funcionalidad, mientras que otros valores (dependiendo de la versión de Windows) la activan en distintos modos. Si vas a tocar estas claves, conviene seguir buenas prácticas para trabajar con el registro de Windows de forma segura y, cuando proceda, realizar copias de seguridad previas.

En algunos escenarios, especialmente cuando surgen incompatibilidades, puede ser necesario desactivar temporalmente Windows Defender Credential Guard. Por ejemplo, Citrix documenta un problema conocido en el que, si Credential Guard está activo en el cliente, el SSO hacia sesiones virtuales puede fallar mostrando el mensaje de seguridad de Windows: «Tus credenciales no funcionaron. Windows Defender Credential Guard no permite usar las credenciales de inicio de sesión de Windows.»

En estos casos, hay dos vías principales para deshabilitarlo:

• Mediante Directiva de grupo, modificando la opción “Activar la seguridad basada en virtualización” dentro de Configuración del equipo > Plantillas administrativas > Sistema > Device Guard.
• Mediante el registro, estableciendo LsaCfgFlags = 0 en la ruta indicada anteriormente.

Conviene tener claro que esta limitación afecta también al uso de Remote Credential Guard a través de RDP. Si necesitas usar la transferencia de dominio mejorada con SSO junto a Credential Guard, la recomendación oficial es elevar una solicitud a Microsoft para que dicho escenario sea soportado.

Device Guard y control de código: listas blancas y modos de funcionamiento

Mientras Credential Guard se centra en las credenciales, Device Guard se enfoca en el control de qué software se puede ejecutar en el equipo. La idea es pasar de un modelo clásico basado en firmas de malware a un modelo preventivo que solo permite aquello que el administrador ha definido como confiable.

En la práctica, Device Guard se materializa principalmente a través de:

• Políticas de integridad de código (Code Integrity Policies), que especifican qué binarios, certificados y editores se consideran de confianza.
• Configuración de arranque seguro y VBS para impedir que código malicioso cargue en fases tempranas del sistema.
• Integración con herramientas de despliegue y gestión (como Intune, GPO, SCCM) para distribuir políticas firmadas.

El comportamiento de Device Guard puede ser más o menos estricto dependiendo del modo elegido:

• Modo usuario autónomo (similar a un modo de pruebas o particular), donde el propio usuario mantiene un cierto grado de control y las restricciones son menos rígidas. En entornos empresariales no es lo ideal porque deja margen de error humano.
• Modo gestionado por la organización (Enterprise-managed o Enterprise-enabled), donde el administrador define listas blancas, grises y negras para controlar con precisión qué se permite.

En este enfoque empresarial, las políticas suelen manejar tres tipos de dominios o sitios:

• Trusted sites (sitios de confianza): equivalentes a las listas blancas. Son dominios conocidos donde se considera que el riesgo es bajo, de modo que el navegador o la aplicación carga el contenido directamente en el equipo con menos restricciones adicionales.
• Neutral sites (sitios neutros): dominios que pueden incluir información sensible (corporativa o personal) y cuyo tratamiento depende del contexto. Si se accede desde un entorno protegido, se mantendrá esa protección; si se accede desde un sitio totalmente confiable, el comportamiento puede ser más permisivo.
• Untrusted sites (sitios no confiables): equivalentes a listas negras. Cualquier contenido procedente de estos dominios se abre dentro de un entorno aislado, aprovechando tecnología de virtualización para minimizar riesgos.

Paralelamente, Device Guard suele ir de la mano de otras capas como Application Guard y Exploit Guard, que supervisan la descarga y ejecución de archivos potencialmente peligrosos, así como la explotación de vulnerabilidades conocidas, generando alertas y bloqueos cuando sea necesario.

Application Guard y Exploit Guard: refuerzo adicional

Además de Credential Guard y Device Guard, Windows integra tecnologías como Application Guard (orientada especialmente al navegador y a aplicaciones críticas) y Exploit Guard, que extienden el concepto de aislamiento y endurecimiento.

Application Guard crea un entorno virtualizado para ejecutar sitios web o aplicaciones potencialmente peligrosos. Cuando se accede a dominios marcados como no confiables, el sistema obliga a cargarlos dentro de esta «caja aislada» basada en VBS, evitando que el contenido malicioso afecte al sistema principal o robe datos.

Esta solución funciona junto con las listas de sitios comentadas antes (confiables, neutros y no confiables) y con las políticas de Device Guard. Así, se construye un modelo en el que el navegador y ciertas aplicaciones clave trabajan encapsuladas cuando acceden a recursos de riesgo.

Exploit Guard, por otro lado, agrupa un conjunto de medidas para mitigar vulnerabilidades en el sistema y en las aplicaciones, endureciendo elementos como:

• Protección de memoria para evitar ejecuciones arbitrarias.
• Bloqueo de comportamientos sospechosos típicos de exploits.
• Control de acceso a carpetas (Controlled Folder Access) para defenderse de ransomware.

La combinación de Credential Guard, Device Guard, Application Guard y Exploit Guard proporciona un blindaje por capas que dificulta mucho los ataques modernos, especialmente aquellos que buscan moverse lateralmente por la red o secuestrar credenciales.

Uso corporativo: Windows 10/11, Windows Server 2016 y novedades asociadas

En el ámbito de servidores, Windows Server 2016 introdujo muchas de las capacidades que ya veíamos en Windows 10, pero adaptadas al entorno de centro de datos. En materia de seguridad, además de la integración de Windows Defender como antivirus por defecto, destacan precisamente Device Guard y Credential Guard como herramientas clave para endurecer el sistema operativo. Para profundizar en estas mejoras y novedades, consulta seguridad avanzada y novedades clave en Windows Server.

Gracias a estas tecnologías, es posible proteger controladores de dominio, servidores de aplicaciones y servidores de archivos frente a la extracción de credenciales y la ejecución de binarios no autorizados. Esto cobra especial relevancia cuando se combinan con otras novedades del ecosistema Windows Server 2016:

• Soporte de virtualización anidada, que permite ejecutar Hyper-V dentro de máquinas virtuales, facilitando laboratorios y entornos de pruebas complejos.
• Herramientas adicionales como analizadores de rendimiento o sistemas de despliegue para equipos que no se unirán a dominio.
• Nuevas capacidades en PowerShell 5.1, incluyendo DSC (Desired State Configuration), PackageManagement/OneGet y PowerShell Direct para administrar máquinas virtuales o contenedores sin necesidad de conectividad de red tradicional.

En el ámbito de la infraestructura, Windows Server 2016 incorpora también mejoras en roles como DNS (políticas de DNS para respuestas condicionadas), IPAM (gestión centralizada del direccionamiento IP), IIS 10 con soporte para HTTP/2, así como tecnologías de almacenamiento como ReFS, deduplicación NTFS, Storage Replica y Storage Spaces, que si bien no son parte directa de Credential Guard o Device Guard, forman parte del ecosistema de seguridad y disponibilidad.

Remote Credential Guard, Citrix y delegación de credenciales

Remote Credential Guard amplía la filosofía de Credential Guard al escenario de conexiones remotas, especialmente con RDP y soluciones de virtualización de escritorios. La idea es que las credenciales del usuario no se transmitan sin protección al host remoto, sino que se utilice Kerberos de manera segura y se apoye en el entorno aislado del cliente.

Citrix se apoya en este enfoque para su funcionalidad de transferencia de dominio mejorada para el SSO en la aplicación Citrix Workspace y en las sesiones de escritorios y aplicaciones virtuales, siempre que los dispositivos cliente estén unidos a Active Directory y se utilice Citrix StoreFront.

Algunos puntos clave de esta función son:

• No se admite en sistemas operativos de 32 bits.
• Sustituye a la autenticación de transferencia heredada basada en ssonsvr.exe.
• No puede habilitarse simultáneamente con la autenticación de transferencia heredada en el mismo host de sesión.
• Mientras que la autenticación heredada requería habilitar la directiva “Habilitar notificaciones MPR para el sistema”, la transferencia mejorada permite SSO sin esa directiva.
• Para autenticación entre dominios, se exige una confianza transitiva bidireccional para obtener tickets de servicio entre límites de dominio; de lo contrario, la delegación Kerberos no funcionará.

En cuanto a configuración, la integración con Remote Credential Guard requiere una serie de pasos tanto en StoreFront, como en directivas Citrix, hosts de sesión y equipos cliente.

StoreFront y Citrix: configuración para SSO con Remote Credential Guard

Para que la transferencia de dominio mejorada funcione correctamente, StoreFront debe estar configurado para aceptar autenticación de transferencia de dominio tanto en el almacén como en el sitio web asociado.

Los pasos generales son:

• Abrir la consola de administración de StoreFront.
• Ir al apartado Almacén > Administrar métodos de autenticación, donde se muestra la ventana correspondiente a la web.
• Marcar la casilla “Transferencia de dominio” y aceptar.

Para el sitio web:

• En la misma consola de StoreFront, acceder a la ficha Almacenes > Receiver para sitios web > Administrar sitios de Receiver para Web > Configurar > Métodos de autenticación.
• En la ventana de modificación del sitio, seleccionar la casilla “Transferencia de dominio”.
• Aplicar los cambios.

Posteriormente, hay que habilitar la directiva de Citrix para la transferencia de dominio mejorada:

• Desde Citrix Studio o la consola web, ir a Directivas y crear una nueva.
• Buscar la configuración “Transferencia de dominio mejorada para el inicio de sesión único”.
• Establecerla como “Permitido”.
• Guardar y aplicar.

En los hosts de sesión, además, es necesario configurar una política de Windows que permita la delegación de credenciales no exportables:

• Ir a Computer Configuration\Policies\Administrative Templates\System\Credentials Delegation.
• Habilitar la opción “El host remoto permite la delegación de credenciales no exportables”.
• Reiniciar el host de sesión.

En Windows Server 2016, esta configuración concreta no aparece en la directiva local, por lo que si necesitas establecerla localmente en lugar de vía GPO, tendrás que ajustarlo mediante el registro en HKLM\SYSTEM\CurrentControlSet\Control\Lsa, creando/modificando el valor DWORD DisableRestrictedAdmin con datos a 0.

Configuración del dispositivo cliente y sitios de confianza

En el lado del dispositivo cliente, también hay trabajo que hacer. Para que la experiencia de SSO mediante transferencia de dominio mejorada sea fluida, es imprescindible habilitar la función en el cliente y confiar en el sitio de StoreFront.

La función de transferencia de dominio mejorada se puede habilitar mediante directiva local o GPO:

• Navegar hasta Computer Configuration\Policies\Administrative Templates\Citrix Components\Citrix Workspace\User Authentication.
• Activar la configuración “Transferencia de dominio mejorada para el inicio de sesión único”.
• Reiniciar la aplicación Citrix Workspace para que el ajuste surta efecto.

En paralelo, hay que asegurarse de que los clientes consideran la URL de StoreFront como parte de un sitio de intranet local o sitio de confianza. Si la URL no pertenece a un dominio ya confiable, se puede añadir mediante directiva:

• Ir a Computer Configuration\Policies\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security.
• Habilitar “Lista de asignación de sitios a zonas” y añadir las URLs pertinentes con su zona (por ejemplo, intranet local o sitios de confianza).
• Habilitar la opción “Opciones de inicio de sesión” y configurarla como “Inicio de sesión automático con el nombre de usuario y la contraseña actuales”.

Con este conjunto de ajustes, el cliente puede aprovechar Remote Credential Guard y la transferencia de dominio mejorada para SSO, siempre que no existan limitaciones por la presencia de Windows Defender Credential Guard, tal y como se ha comentado en la parte de problemas conocidos.

Zona de sitios restringidos, ActiveX y endurecimiento del navegador

Otra pieza relevante del puzle de seguridad en Windows es la configuración de zonas de seguridad de Internet Explorer (que, aunque esté en retirada, todavía influye en muchos componentes del sistema) y, por extensión, en el modo en que se manejan controles ActiveX, scripting y descargas.

En la zona de sitios restringidos es donde más se endurecen las políticas. Entre las opciones habituales que pueden ajustarse mediante GPO están:

• Permitir o no acceso a orígenes de datos entre dominios.
• Habilitar o deshabilitar scripts activos y comportamientos binarios y de script.
• Controlar si se permite arrastrar y soltar archivos o copiar/pegar entre sitios y ventanas.
• Permitir o bloquear descargas de archivos y descargas automáticas.
• Controlar la carga de archivos XAML y el uso de META REFRESH.
• Limitar el uso de ActiveX a dominios explícitamente aprobados, tanto para el control TDC como para otros controles.
• Restringir ventanas iniciadas por script sin límites de tamaño o posición.
• Administrar el uso de VBScript, Java, applets y componentes dependientes de .NET.
• Decidir si se ejecutan antivirus contra ActiveX o se permite su uso sin antimalware.
• Activar filtros como el Cross-Site Scripting (XSS) Filter, el Modo protegido o el filtro SmartScreen.

Todo este conjunto de políticas forma parte de un enfoque de defensa en profundidad donde, además de Credential Guard y Device Guard, se busca reducir la superficie de ataque desde el navegador, que suele ser una de las puertas de entrada más habituales.

ACL, control de acceso y PAC: contexto adicional de seguridad

Más allá de VBS, VSM y los «Guards» de Windows, la seguridad del sistema descansa de forma muy importante en las Listas de Control de Acceso (ACL). En Windows, las ACL definen quién puede acceder a qué recursos y con qué permisos, tanto a nivel de sistema de archivos como en otros componentes internos.

Las ACL permiten configurar permisos muy específicos sobre objetos (Object Permissions), más allá del típico leer/escribir. Por ejemplo, se puede permitir que un usuario lea el contenido de un archivo pero no cambie sus permisos, o que un servicio modifique un registro pero no lo elimine.

La herencia de ACL juega también un papel clave, pues facilita que los permisos se propaguen a subcarpetas y archivos sin necesidad de configurarlos uno a uno. Esto hay que manejarlo con cuidado: una mala herencia de permisos puede abrir más de la cuenta, o por el contrario bloquear procesos legítimos.

En escenarios más avanzados, Windows soporta modelos de control de acceso basado en políticas (PAC) que permiten aplicar reglas más dinámicas y contextuales. Todo esto se integra con el sistema de registro, que aunque no se describe en detalle aquí, es otro componente crítico para la seguridad y la auditoría; puedes consultar nuestra entrada sobre auditoría de seguridad en Windows para ver cómo registrar y revisar eventos relevantes.

La relación con VSM es directa: el VSM se apoya en ACL y en el modelo de seguridad de Windows para aislar partes sensibles del sistema, asegurando que solo código validado y con los privilegios adecuados pueda interactuar con los componentes protegidos.

Con el despliegue correcto de Credential Guard, Device Guard, Application Guard, Exploit Guard, políticas de navegador, ACL bien diseñadas y el uso de líneas base de seguridad, es posible construir un entorno Windows donde las credenciales estén a salvo, el código malicioso tenga muy difícil ejecutarse y las vías de ataque habituales queden fuertemente blindadas, siempre manteniendo un equilibrio razonable entre seguridad y usabilidad para los usuarios finales.