Credential Guard: impacto real en el rendimiento y cómo gestionarlo

Cuando se activa Credential Guard en equipos Windows, especialmente en hardware no muy reciente, muchos administradores se llevan una sorpresa: el sistema se vuelve más seguro, sí, pero también puede notarse un bajón de rendimiento bastante serio. En algunos portátiles y sobremesas antiguos, el equipo pasa de ir fluido a sentirse torpe solo por habilitar esta capa adicional de protección basada en virtualización.

Este comportamiento no es un fallo puntual ni algo aislado de una marca concreta de equipos; está directamente relacionado con cómo funciona la Seguridad Basada en Virtualización (VBS), cómo se apoya en Hyper-V, en extensiones de CPU como Intel VT-x/VT-d y en tecnologías como MBEC, y con el hecho de que ciertas aplicaciones (sobre todo legadas, heredadas de épocas Windows XP o similares) no estaban pensadas para convivir con este modelo de seguridad endurecida.

Qué es Credential Guard y por qué puede ralentizar el equipo

Credential Guard es una característica de seguridad de Windows que aísla y protege las credenciales de inicio de sesión (hashes NTLM, tickets de concesión de Kerberos, credenciales almacenadas en el Administrador de credenciales, etc.) dentro de un entorno protegido por el hipervisor. En vez de dejar estos secretos en el espacio de memoria normal del sistema operativo, se alojan en un subsistema aislado, al que solo el software de sistema con los privilegios adecuados puede acceder.

El objetivo principal es mitigar ataques de robo de credenciales como “pass-the-hash” y “pass-the-ticket”, muy habituales en ataques dirigidos y amenazas persistentes avanzadas (APT). Aunque el atacante consiga privilegios de administrador en el sistema operativo, el acceso a los secretos protegidos por VBS se bloquea, complicando mucho la escalada lateral por la red.

Para ofrecer este aislamiento, Credential Guard se apoya en la Seguridad Basada en Virtualización (VBS), que usa el hipervisor de Windows (Hyper-V) para crear un entorno de memoria separado del resto del sistema. Procesos clave, como la Autoridad de Seguridad Local (LSA), se ejecutan en una variante protegida (LSA aislado, LSAIso.exe) que ya no comparte el mismo espacio de memoria accesible por cualquier proceso con privilegios elevados.

¿Dónde entra en juego el impacto en rendimiento? En equipos con procesadores modernos (sobre todo a partir de Intel 7ª generación con MBEC/GMET o equivalentes de AMD) el coste suele ser moderado. Sin embargo, en CPUs anteriores que no disponen de estas instrucciones, Windows tiene que recurrir a emulación por software de ciertos mecanismos de control de ejecución, y ahí es donde se han observado caídas de rendimiento del 30-40% en algunos casos reales, especialmente en portátiles profesionales de generaciones antiguas.

En máquinas como los Dell Latitude 7280 y otros modelos corporativos con CPUs previas a la 7ª generación de Intel, varios administradores han reportado que, con una instalación de Windows 10 “limpia” el equipo funciona con soltura, pero al desplegar una imagen corporativa con VBS, Credential Guard y, en muchos casos, integridad de código protegida por hipervisor (HVCI / Memory Integrity), todo se vuelve más lento: arranque, apertura de aplicaciones, tiempos de respuesta generales, etc.

Relación entre Credential Guard, VBS, HVCI y otros componentes

Credential Guard no funciona en el vacío; forma parte de un ecosistema de características de seguridad basadas en Hyper-V. En este mismo grupo encontramos Device Guard (o App Control para empresas en su evolución), la integridad de memoria (HVCI) y otras funcionalidades como Windows Sandbox, WSL2 o incluso la propia Plataforma de máquina virtual.

VBS actúa como la base común que permite crear un entorno aislado, en el que se ejecutan componentes críticos como la integridad de código en modo kernel, el LSA aislado y otros servicios que se benefician de esta separación. Primero arranca el hipervisor de Windows, luego el sistema operativo se ejecuta “encima”, y determinadas áreas de memoria quedan reservadas para este entorno protegido.

HVCI (Hypervisor-Enforced Code Integrity), también conocida como integridad de memoria, es otra pieza clave del puzzle. Se encarga de verificar que el código que se ejecuta en modo kernel cumple unos requisitos estrictos: solo se cargan controladores firmados de forma adecuada, se dificultan técnicas de explotación de memoria y se bloquean comportamientos típicos de malware y ataques de día cero dirigidos al kernel.

Cuando se habilita Credential Guard en muchos escenarios corporativos, suele activarse también HVCI, ya sea explícitamente o como parte de una política de seguridad que habilita VBS con integridad de código reforzada. Esta combinación maximiza la seguridad, pero también suma sobrecarga: comprobaciones adicionales, restricciones de entrada/salida, más uso del hipervisor y más presión sobre la CPU y la memoria.

Microsoft ha ido endureciendo la postura de seguridad con las versiones recientes de Windows 11: a partir de Windows 11 22H2 y Windows Server 2025, VBS y Credential Guard se habilitan de forma predeterminada en dispositivos que cumplen los requisitos. Esta activación suele hacerse “sin bloqueo UEFI” para permitir que los administradores puedan desactivar Credential Guard de forma remota si es necesario, pero la realidad es que muchos equipos nuevos salen ya con estas defensas activadas desde el día uno.

Requisitos de hardware, firmware y licencias para Credential Guard

Para que Credential Guard y el resto de características VBS funcionen correctamente y con el menor impacto posible, el hardware y el firmware tienen que cumplir ciertos requisitos mínimos. Cuanto más moderno y alineado con estas exigencias sea el equipo, mejor será el equilibrio seguridad-rendimiento.

Entre los requisitos de hardware básicos para Credential Guard se incluyen:

• CPU de 64 bits, con extensiones de virtualización de hardware (Intel VT-x o AMD-V) y soporte de tablas de páginas extendidas.
• IOMMU (Intel VT-d o AMD-Vi) para mejorar el aislamiento de dispositivos y mitigar ataques basados en DMA.
• TPM 1.2 o, preferiblemente, TPM 2.0 para proporcionar anclaje en hardware de las credenciales y de la cadena de arranque.

En el plano del firmware, es imprescindible disponer de UEFI 2.3.1 o superior con Arranque Seguro habilitado, además de mecanismos de actualización segura de firmware, protección de configuración de arranque y una implementación segura de Memory Overwrite Request (MOR) para asegurar que no se pueden manipular fácilmente los parámetros que afectan a VBS.

En cuanto a licenciamiento, Credential Guard no está disponible en cualquier edición de Windows. Está soportado en:

• Windows Enterprise.
• Windows Education.

Las licencias que dan derecho a usar Credential Guard incluyen Windows Enterprise E3 y E5, así como las variantes educativas A3 y A5. No está disponible en Windows Pro, Pro Education/SE ni Home, salvo que se actualice a Enterprise mediante contrato de licencias por volumen.

Fabricantes como Dell han publicado matrices muy detalladas de compatibilidad para modelos Latitude, OptiPlex, Precision, XPS y equipos Rugged, indicando versiones mínimas de BIOS, drivers y chipsets que garantizan que el sistema está “preparado” para Device Guard y Credential Guard. Estos listados aclaran qué versiones de audio, gráficos, Wi-Fi, Bluetooth, almacenamiento y otros controladores han sido validadas para funcionar con HVCI sin provocar bloqueos o caídas de rendimiento inesperadas.

Impacto práctico en rendimiento: casos reales y escenarios típicos

Más allá de la teoría, lo que preocupa a muchas organizaciones es lo que pasa en la práctica cuando se activa Credential Guard: equipos que tardan más en arrancar, aplicaciones corporativas que se abren con retraso, herramientas antiguas que parecen “arrastrarse” y usuarios llamando al soporte porque “el ordenador nuevo va peor que el viejo”.

En estaciones de trabajo con Windows 10 Enterprise (por ejemplo, la versión 1607 LTSC o 1803) se han documentado escenarios donde, tras desplegar imágenes con Credential Guard y HVCI activos, el rendimiento general cae de forma notable. Al deshabilitar estas funciones, el sistema vuelve a comportarse con normalidad. Este efecto aparece con mayor intensidad en equipos con CPUs antiguas, sin MBEC, y en entornos donde se ejecutan aplicaciones heredadas muy intensivas en llamadas al sistema o con drivers poco optimizados. Para cuantificar estos impactos a nivel de memoria se puede recurrir a herramientas como medición de rendimiento de la RAM.

Otro síntoma habitual es el aumento de consumo de CPU y latencias en procesos relacionados con LSAIso.exe, o con aplicaciones que intentan interactuar con el subsistema de credenciales aislado. Algunas herramientas que intentan leer TGT de Kerberos, manipular hashes NTLM o realizar delegación de credenciales de forma implícita pueden encontrar más resistencia, sufrir bloqueos o provocar demoras por reintentos.

No solo se ve afectado el rendimiento del sistema operativo, también pueden degradarse otras cargas de trabajo que dependen de virtualización. Cuando VBS y Credential Guard están activos, Hyper-V toma control exclusivo de las extensiones de virtualización de la CPU. Esto provoca que hipervisores de tipo 2 como VMware Workstation, VMware Player u Oracle VirtualBox no puedan acceder directamente a Intel VT-x/AMD-V, con errores típicos como “VT-x no está disponible” o mensajes explícitos de incompatibilidad con Device/Credential Guard.

En versiones antiguas de VMware Workstation y VirtualBox la única salida era desactivar Hyper-V y, por extensión, deshabilitar VBS y Credential Guard, perdiendo así las ventajas de seguridad a cambio de poder ejecutar máquinas virtuales de terceros con buen rendimiento. Más recientemente, tanto VMware como Oracle han incorporado soporte para la Windows Hypervisor Platform (WHP), permitiendo ejecutar sus VMs apoyándose en las APIs de Hyper-V, aunque con ciertas limitaciones (sin virtualización anidada, sin algunos contadores de rendimiento, con algo de pérdida de rendimiento, etc.).

En muchos casos, los usuarios ni siquiera habían instalado explícitamente Hyper-V, pero al activar VBS, Device Guard o Credential Guard mediante actualizaciones de Windows 10 (por ejemplo, a partir de la versión 1607), el hipervisor se habilitaba en segundo plano, generando incompatibilidades con VMware Workstation o VirtualBox.

Las soluciones clásicas para estos conflictos eran varias:

• Desinstalar el rol Hyper-V y características relacionadas desde la GUI (Panel de control > Activar o desactivar las características de Windows) o desde PowerShell/ DISM.
• Desactivar el arranque del hipervisor mediante bcdedit /set hypervisorlaunchtype off, sin desinstalar Hyper-V del todo.
• Crear entradas de arranque duales (con y sin Hyper-V) para elegir en cada reinicio si el sistema arrancará con VBS/Hyper-V activos o en modo “nativo” para trabajar con otros hipervisores.

Con el tiempo, Microsoft publicó la Windows Hypervisor Platform (WHP), que permite a VMware Workstation (desde la versión 15.5.6) y a VirtualBox (desde la serie 6.x) ejecutarse apoyándose en las APIs de Hyper-V. En este “modo host VBS” el monitor de máquina virtual deja de tener acceso directo a VT-x/AMD-V y se ejecuta a nivel de usuario, delegando en Hyper-V las operaciones de virtualización de CPU. Es una solución de compromiso: se mantiene VBS/Device Guard/Credential Guard activos, pero se acepta una ligera pérdida de rendimiento en las VMs de terceros y algunas limitaciones (sin nested virtualization dentro de las VMs de VMware, sin ciertos contadores de rendimiento, etc.).

No obstante, en escenarios donde el rendimiento máximo de las VMs de VMware o VirtualBox es prioritario, muchos administradores siguen optando por desactivar Hyper-V, VBS y Credential Guard temporalmente en equipos de desarrollo, laboratorios o estaciones de trabajo de administración avanzada.

Compatibilidad de aplicaciones y servicios al habilitar Credential Guard

Cuando se activa Credential Guard, no solo cambia el rendimiento, también se altera el modelo de autenticación del sistema. Algunas características y protocolos quedan totalmente bloqueados, otras se consideran poco recomendables y otras siguen funcionando con normalidad, pero pasando por el filtro del entorno aislado.

Entre las funcionalidades que dejan de estar disponibles al habilitar Credential Guard encontramos:

• Uso de cifrado DES para Kerberos.
• Delegación de Kerberos sin restricciones.
• Extracción directa de TGT de Kerberos.
• Autenticación NTLMv1.

Las aplicaciones que dependen de estos mecanismos pueden romperse directamente: fallos al autenticarse contra servicios, errores en delegaciones antiguas de Kerberos, sistemas Wi-Fi empresariales que usan métodos de autenticación obsoletos, etc. Es vital probar previamente todas las aplicaciones críticas antes de desplegar Credential Guard a gran escala en una organización.

Otras funciones que siguen siendo posibles pero aumentan la superficie de ataque si se abusa de ellas, incluso con Credential Guard activo, son:

• Autenticación implícita.
• Delegación de credenciales.
• MS-CHAPv2.
• CredSSP.

Servicios habituales como recursos compartidos de archivos SMB, Escritorio remoto o aplicaciones que usan Kerberos “moderno” continúan operando con normalidad, siempre que no intenten extraer o manipular directamente secretos protegidos por el entorno VBS. Sin embargo, si ciertas aplicaciones intentan enlazarse de forma agresiva con el proceso LSAIso.exe o utilizan técnicas no soportadas, pueden generarse problemas de rendimiento adicionales o incluso bloqueos.

En entornos con IIS, autenticación Wi-Fi avanzada o soluciones heredadas de autenticación web, se han observado problemas cuando las configuraciones apoyan esquemas viejos (como NTLMv1, DES en Kerberos o delegaciones “abiertas”), obligando a rediseñar parte de la infraestructura o a crear excepciones si no es viable actualizar todos los componentes de inmediato.

Interacción con otros hipervisores: Hyper-V, VMware, VirtualBox y VBS

Para que Credential Guard funcione, el hipervisor de Windows (Hyper-V) tiene que cargarse en el arranque y tomar control de las extensiones de virtualización de la CPU. Esto tiene una consecuencia directa: ningún otro hipervisor de tipo 2 puede usar directamente Intel VT-x o AMD-V mientras Hyper-V esté activo.

Históricamente, esto se traducía en errores como:

• “VMware Workstation e Hyper-V no son compatibles. Elimine el rol Hyper-V…”
• “VMware Workstation y Device/Credential Guard no son compatibles. VMware Workstation se puede ejecutar después de desactivar Device/Credential Guard.”
• BSOD en VirtualBox (SYSTEM_SERVICE_EXCEPTION), mensajes de “VT-x no está disponible (VER_VMX_NO_VMX)” o VMs extremadamente lentas usando modo de paravirtualización/emulación.

En muchos casos, los usuarios ni siquiera habían instalado explícitamente Hyper-V, pero al activar VBS, Device Guard o Credential Guard mediante actualizaciones de Windows 10 (por ejemplo, a partir de la versión 1607), el hipervisor se habilitaba en segundo plano, generando incompatibilidades con VMware Workstation o VirtualBox.

Las soluciones clásicas para estos conflictos eran varias:

• Desinstalar el rol Hyper-V y características relacionadas desde la GUI (Panel de control > Activar o desactivar las características de Windows) o desde PowerShell/ DISM.
• Desactivar el arranque del hipervisor mediante bcdedit /set hypervisorlaunchtype off, sin desinstalar Hyper-V del todo.
• Crear entradas de arranque duales (con y sin Hyper-V) para elegir en cada reinicio si el sistema arrancará con VBS/Hyper-V activos o en modo “nativo” para trabajar con otros hipervisores.

Con el tiempo, Microsoft publicó la Windows Hypervisor Platform (WHP), que permite a VMware Workstation (desde la versión 15.5.6) y a VirtualBox (desde la serie 6.x) ejecutarse apoyándose en las APIs de Hyper-V. En este “modo host VBS” el monitor de máquina virtual deja de tener acceso directo a VT-x/AMD-V y se ejecuta a nivel de usuario, delegando en Hyper-V las operaciones de virtualización de CPU. Es una solución de compromiso: se mantiene VBS/Device Guard/Credential Guard activos, pero se acepta una ligera pérdida de rendimiento en las VMs de terceros y algunas limitaciones (sin nested virtualization dentro de las VMs de VMware, sin ciertos contadores de rendimiento, etc.).

No obstante, en escenarios donde el rendimiento máximo de las VMs de VMware o VirtualBox es prioritario, muchos administradores siguen optando por desactivar Hyper-V, VBS y Credential Guard temporalmente en equipos de desarrollo, laboratorios o estaciones de trabajo de administración avanzada.

Cómo habilitar y deshabilitar VBS, HVCI y Credential Guard con control granular

La gestión de Credential Guard y del resto de componentes VBS se puede hacer de varias formas: directivas de grupo, modificaciones en el Registro, scripts de PowerShell, herramientas de validación oficiales (como el script DG_Readiness.ps1 de Microsoft) e incluso configuraciones mediante App Control para empresas.

Para habilitar Seguridad Basada en Virtualización e integridad de memoria sin bloqueo UEFI por Registro, se pueden usar comandos del estilo (ejecutados con privilegios de administrador):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Locked" /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 0 /f

Si se quiere activar únicamente VBS, sin integridad de memoria, se puede configurar solo la clave EnableVirtualizationBasedSecurity, mientras que RequirePlatformSecurityFeatures controla si se exige solo Arranque Seguro (valor 1) o también protección DMA (valor 3). El parámetro Locked, tanto para VBS como para HVCI, determina si el estado se bloquea vía UEFI (lo que impide cambios sencillos posteriores) o se deja abierto para poder revertirlo por software.

La propia interfaz de Windows 10/11 ofrece una forma gráfica de habilitar la integridad de memoria (HVCI) desde Seguridad de Windows > Seguridad del dispositivo, pero en entornos corporativos grandes es más habitual recurrir a políticas de grupo, perfiles MDM o scripts de automatización.

Para comprobar el estado efectivo de VBS, Credential Guard e integridad de memoria se puede recurrir a varias herramientas:

• El comando msinfo32.exe, que en “Resumen del sistema” muestra si la virtualización basada en seguridad está activa, si Device Guard está habilitado y qué servicios se están ejecutando.
• La clase WMI Win32_DeviceGuard, consultable con PowerShell mediante:
  Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Los campos de esta clase permiten saber qué propiedades de seguridad de hardware están disponibles (AvailableSecurityProperties), qué requisitos se exigen (RequiredSecurityProperties), si VBS está habilitado y en ejecución (VirtualizationBasedSecurityStatus), si Credential Guard y/o integridad de memoria están configurados y activos (SecurityServicesConfigured, SecurityServicesRunning), y el modo de cumplimiento de las políticas de integridad de código (CodeIntegrityPolicyEnforcementStatus).

Si algo sale mal, por ejemplo, un controlador incompatible provoca pantallazos azules o el sistema se vuelve inestable tras activar integridad de memoria, se puede deshacer el cambio desde el Entorno de Recuperación de Windows (Windows RE) deshabilitando las claves de Registro correspondientes y revisando las políticas de grupo antes de volver a iniciar normalmente.

Uso de Credential Guard y HVCI en máquinas virtuales Hyper-V

Credential Guard y la integridad de memoria no se limitan a máquinas físicas; también pueden utilizarse dentro de máquinas virtuales Hyper-V de generación 2, siempre que el host cumpla los requisitos (como mínimo Windows 10/Windows Server 2016 para integridad de memoria).

En este escenario, VBS protege los secretos y el kernel dentro de la propia VM invitada, endureciendo el sistema frente a malware o ataques que se produzcan en esa máquina concreta. No obstante, el host siempre conserva privilegios suficientes para deshabilitar la protección en la VM (por ejemplo, usando Set-VMSecurity -VirtualizationBasedSecurityOptOut $true), así que no se trata de una defensa contra administradores maliciosos del host, sino contra ataques “desde dentro” de la VM.

Al usar integridad de memoria dentro de VMs, hay ciertas limitaciones a tener en cuenta:

• Los adaptadores de canal de fibra virtual con AllowFullSCSICommandSet y algunos escenarios específicos de paso a través de discos pueden requerir desactivar la seguridad basada en virtualización en esa VM.
• Es posible combinar integridad de memoria con virtualización anidada, pero la configuración debe hacerse con cuidado para evitar conflictos de recursos y caídas de rendimiento pronunciadas.

Desde un punto de vista de rendimiento, activar VBS y Credential Guard dentro de VMs añade otra capa más de virtualización, por lo que conviene asignar suficientes recursos de CPU y RAM a las máquinas invitadas y evitar habilitar estas protecciones en VMs que vayan muy justas o ejecuten software muy sensible a la latencia.

En el plano operativo, muchas organizaciones optan por habilitar Credential Guard y HVCI en máquinas virtuales que actúan como controladores de dominio, servidores de autenticación o equipos administrativos críticos, donde el valor de reforzar la protección de credenciales y del kernel compensa con creces el coste extra en recursos.

Credential Guard, VBS e integridad de memoria ofrecen una capa muy potente de defensa frente a ataques de robo de credenciales y explotación del kernel, pero exigen un hardware y un firmware a la altura, un inventario claro de aplicaciones compatibles, una gestión cuidadosa de Hyper-V y otros hipervisores, y decisiones informadas sobre dónde activar o desactivar estas funciones para no convertir equipos perfectamente válidos en máquinas desesperantemente lentas. Elegir bien en qué estaciones de trabajo, servidores y máquinas virtuales se habilitan estas tecnologías permite encontrar el equilibrio adecuado entre seguridad fuerte y rendimiento aceptable para el día a día.