Configurar Memory Integrity en Windows: guía técnica completa

Si has llegado hasta aquí porque no consigues llevarte bien con la integridad de memoria de Windows, quédate, porque vamos a destripar la función a fondo. Verás qué es exactamente, cómo se relaciona con el aislamiento del núcleo y VBS, cómo activarla en un equipo doméstico, en entornos empresariales (Intune, directivas, Registro, PowerShell…), qué requisitos exige el hardware y qué hacer cuando Windows se niega rotundamente a activarla.

El objetivo es que termines esta guía sabiendo cómo configurar Memory Integrity en Windows con soltura, qué mensajes y parámetros tienes que revisar para confirmar que todo está bien y cómo diagnosticar los errores típicos que se dan tanto en equipos físicos como en máquinas virtuales Hyper‑V. Vamos paso a paso, pero con detalle técnico suficiente como para que le saque partido tanto un usuario avanzado como un administrador de sistemas.

¿Qué es la integridad de memoria y cómo encaja en VBS?

La llamada integridad de memoria (Memory Integrity o HVCI, Hypervisor‑Enforced Code Integrity) es una pieza clave de la seguridad basada en virtualización de Windows, conocida como VBS (Virtualization‑Based Security). La idea es sencilla pero muy potente: Windows levanta un entorno virtual aislado usando el hipervisor, asumiendo que el kernel normal podría llegar a verse comprometido, y ejecuta en ese entorno protegido las comprobaciones críticas de integridad de código.

Gracias a esto, el sistema puede validar el código que se ejecuta en modo kernel desde un contexto más seguro, separar secretos y operaciones sensibles del resto del sistema operativo y endurecer el modelo de amenazas frente a malware avanzado, como rootkits o exploits que atacan directamente al núcleo de Windows.

Cuando la integridad de memoria está operativa, el sistema restringe de forma agresiva las asignaciones de memoria del kernel: las páginas de código solo se marcan como ejecutables después de superar controles de integridad en ese entorno seguro y, además, las páginas ejecutables no pueden volver a escribirse. Es decir, se dificulta enormemente la inyección de código o la modificación de estructuras críticas del kernel.

Checklist esencial de hardware antes de actualizar a Windows 11

Funciones específicas de la integridad de memoria

Aunque desde la interfaz gráfica se ve como un simple interruptor, por debajo la integridad de memoria implementa varias protecciones muy concretas sobre el kernel. Entre las más importantes están dos:

Protección del mapa de bits de Control Flow Guard (CFG) en modo kernel: se evita que código malicioso manipule las estructuras que usa CFG para validar el flujo de ejecución de los controladores, cerrando muchas puertas a exploits que redirigen llamadas a funciones no deseadas.
Blindaje del proceso de integridad de código en modo kernel: las comprobaciones que certifican que un controlador de kernel es de confianza y está firmado correctamente se ejecutan dentro del entorno VBS, de forma que no puedan ser manipuladas desde el propio kernel convencional.

En resumen, esta característica convierte la clásica integridad de código del kernel en algo mucho más robusto, porque la reubica en un contexto aislado por el hipervisor que el malware tiene muchísimo más difícil de atacar.

Dónde se configura Memory Integrity en la interfaz de Windows

En equipos de usuario, el acceso más directo a la integridad de memoria es a través de la aplicación Seguridad de Windows. Ahí se engloba dentro del apartado de aislamiento del núcleo o core isolation, que agrupa todo lo relacionado con protecciones del kernel respaldadas por VBS.

Para activarla desde la propia interfaz, el flujo habitual es el siguiente, que conviene conocer aunque luego prefieras aplicar la configuración por políticas o por Registro:

Abre Seguridad de Windows (icono de escudo en la bandeja o buscándola desde Inicio).
Entra en Seguridad del dispositivo, donde verás el bloque Aislamiento del núcleo.
Haz clic en Detalles de aislamiento del núcleo, donde aparece la opción Integridad de memoria junto a un conmutador.
Activa el interruptor. Es posible que veas mensajes como “La integridad de memoria está desactivada. Es posible que el dispositivo sea vulnerable” antes de activar la opción.
Reinicia el equipo cuando Windows lo pida para aplicar los cambios.

En esta misma pantalla es frecuente encontrar activada por defecto la lista de bloqueados de controladores vulnerables de Microsoft, que impide la carga de determinados controladores con fallos conocidos cuando está funcionando la integridad de memoria. Es un complemento importante porque refuerza la cadena de confianza de los drivers.

Relación entre aislamiento del núcleo (core isolation) e integridad de memoria

Dentro de la aplicación de seguridad, el aislamiento del núcleo engloba varias funciones. La más visible y crítica para la mayoría de usuarios es precisamente la integridad de memoria. Cuando activas esta opción, lo que estás haciendo en la práctica es habilitar HVCI sobre el entorno VBS de tu dispositivo.

El aislamiento del núcleo crea un entorno virtualizado para determinadas partes sensibles del sistema, y la integridad de memoria se apoya en ese aislamiento para inspeccionar y controlar el código de kernel. De ese modo, incluso si una aplicación con privilegios elevados sufre un exploit, el atacante lo tiene mucho más complicado para modificar el núcleo o sus estructuras internas.

Ahora bien, no todo son ventajas: este aislamiento y las comprobaciones adicionales pueden implicar cierto impacto en rendimiento, especialmente en juegos o en aplicaciones muy sensibles a la latencia. Hay usuarios que reportan caída de FPS o incluso pantallazos azules tras activar la función. En esos casos, si se confirma que el origen del problema es HVCI, se puede desactivar temporalmente el aislamiento del núcleo mientras se actualizan controladores, firmware o se corrigen incompatibilidades.

¿Cuándo se activa por defecto Memory Integrity en Windows?

En versiones modernas de Windows, Microsoft tiende a activar la integridad de memoria de serie para muchos equipos nuevos. Concretamente, Windows 11 habilita Memory Integrity por defecto en instalaciones limpias sobre hardware compatible, sin que el usuario tenga que tocar nada. Lo mismo se aplica a equipos considerados núcleo protegido y a antiguas instalaciones limpias de Windows 10 en modo S.

Si el dispositivo no cumple las condiciones mínimas, la función no se activa sola, pero el usuario o el administrador pueden encenderla manualmente desde la interfaz de Seguridad de Windows, desde una directiva o modificando el Registro. En cualquier caso, Microsoft insiste en que los profesionales de TI y los usuarios finales mantienen el control último sobre si esta protección está activa o no.

Requisitos de hardware para habilitar automáticamente la integridad de memoria

Para que el propio sistema active la integridad de memoria sin intervención del usuario, debe cumplirse un conjunto de requisitos de hardware y firmware bastante concretos. Esto es importante porque explica por qué algunos equipos no reciben la activación automática aunque sí sean capaces de usar la función de manera opcional.

A nivel de procesador, las líneas generales son:

Intel de 8ª generación o posteriores para Windows 11 versión 22H2 (y procesadores Core de 11ª generación en Windows 11 21H2).
AMD con arquitectura Zen 2 o superior, es decir, generaciones relativamente recientes.
Qualcomm Snapdragon 8180 o posteriores en dispositivos ARM.

Además, se exige que el equipo cuente con al menos 8 GB de RAM en plataformas x64, una unidad de sistema de tipo SSD de 64 GB o más y que en la BIOS/UEFI estén habilitadas las opciones de virtualización de hardware.

Otro requisito crítico es el de los controladores compatibles con integridad de memoria. Si algún driver esencial no soporta HVCI o se sabe que entra en conflicto, el sistema puede decidir no activar automáticamente VBS y Memory Integrity para evitar problemas graves de arranque. Por eso es tan importante comprobar siempre la compatibilidad de drivers en hardware más antiguo.

Control de la integridad de memoria mediante Registro (entornos profesionales y OEM)

En entornos corporativos es muy habitual controlar la integridad de memoria mediante claves de Registro, ya sea directamente en la imagen del sistema o a través de herramientas de gestión como Intune, scripts o GPOs. La rama clave es HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard y, en particular, el subárbol Scenarios\HypervisorEnforcedCodeIntegrity.

Para habilitar seguridad basada en virtualización y la integridad de memoria con la configuración recomendada (sin bloqueo UEFI, de forma que se pueda revertir), se usan entradas como:

EnableVirtualizationBasedSecurity en DeviceGuard, con valor 1 para activar VBS.
RequirePlatformSecurityFeatures con valores como 1 (solo arranque seguro) o 3 (arranque seguro + protección DMA).
Locked en DeviceGuard y en HypervisorEnforcedCodeIntegrity para decidir si se bloquea o no la configuración vía firmware UEFI (0 sin bloqueo, 1 con bloqueo).
Enabled en Scenarios\HypervisorEnforcedCodeIntegrity para encender o apagar específicamente la integridad de memoria.
Mandatory en DeviceGuard con valor 1 si se quiere que el sistema no complete el arranque si VBS o sus componentes críticos fallan.

Para fabricantes de equipos o administradores que preparan imágenes, hay una configuración particularmente relevante: establecer en la ruta de HVCI los valores Enabled=1, WasEnabledBy=1 y EnabledBootId=<BootId actual>. Con esto se consigue que la integridad de memoria arranque activada y, a la vez, que el propio sistema pueda deshabilitarla de forma automática si detecta bloqueos de arranque en los primeros reinicios por incompatibilidades de drivers.

BootId es un contador que se incrementa en cada arranque correcto y se encuentra en la clave HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId. La lógica de auto‑desactivación de HVCI solo aplica mientras BootId sea menor que EnabledBootId + 3, lo que ofrece una especie de red de seguridad para evitar dejar el equipo inutilizable por un conflicto de controlador.

Cambiar el comportamiento de la interfaz gráfica de Memory Integrity

Otra clave interesante para administradores es WasEnabledBy dentro del subárbol de HVCI. Sirve para controlar cómo se presenta la opción en la app de Seguridad de Windows y quién “es el responsable” de haberla activado.

Si se elimina el valor WasEnabledBy, la interfaz muestra el mensaje “This setting is managed by your administrator” y deshabilita el control para el usuario final, lo que resulta útil cuando se quiere una política corporativa muy estricta y no editable. Si se establece con cierto valor (por ejemplo, 2), la interfaz vuelve a comportarse con normalidad y el usuario puede reenviar los cambios desde la aplicación.

Habilitar Memory Integrity mediante App Control para empresas

En organizaciones que ya usan Control de aplicaciones (App Control for Business), la integridad de memoria se puede activar integrándola en la propia política de control de aplicaciones. Esto se puede hacer de varias formas, todas ellas pensadas para aprovechar la gestión centralizada existente.

Entre las opciones más habituales están:

Usar el Asistente de Control de aplicaciones para crear o editar una política y marcar la casilla Integridad de código protegida por hipervisor en la sección de reglas de directiva.
Ejecutar el cmdlet de PowerShell Set-HVCIOptions, que permite ajustar las opciones de HVCI de forma más granular desde scripts o herramientas de automatización.
Modificar directamente el XML de la política de App Control ajustando el valor del elemento <HVCIOptions>, muy útil cuando se gestiona una granja de equipos con una única plantilla de directiva.

Esto permite que la decisión de activar o no la integridad de memoria viaje con la propia directiva de control de aplicaciones, manteniendo todo el modelo de seguridad de código en un solo sitio y evitando configuraciones dispersas.

Comprobar el estado de VBS e integridad de memoria

Una vez activada la función, es fundamental poder comprobar de forma fiable si VBS y HVCI están activos y funcionando. Windows ofrece varios mecanismos para validar esto, tanto desde la línea de comandos como con herramientas gráficas.

cómo evitar estafas al comprar discos duros baratos

Clase WMI Win32_DeviceGuard y PowerShell

En Windows 10, Windows 11 y Windows Server 2016 o superior existe la clase WMI Win32_DeviceGuard, que expone un buen número de propiedades relativas a VBS y a la integridad de memoria. Desde una consola de PowerShell con privilegios de administrador se puede consultar con:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

La salida muestra, entre otros, campos como:

InstanceIdentifier y Version, que identifican la instancia de la clase y la versión (actualmente 1.0).
AvailableSecurityProperties, un array de valores que indica qué características de seguridad soporta el dispositivo (compatibilidad con hipervisor, arranque seguro, protección DMA, sobrescritura de memoria segura, protecciones NX, mitigaciones SMM, MBEC/GMET, virtualización APIC…).
RequiredSecurityProperties, que indica qué propiedades de seguridad son imprescindibles para activar VBS (por ejemplo, necesidad de hiper‑V, arranque seguro, IOMMU, etc.).
CodeIntegrityPolicyEnforcementStatus y UsermodeCodeIntegrityPolicyEnforcementStatus, que señalan si las políticas de integridad de código están desactivadas, en modo auditoría o en modo forzado.
SecurityServicesConfigured y SecurityServicesRunning, donde se ve si Credential Guard, Memory Integrity u otros servicios VBS están configurados y si se están ejecutando realmente.
VirtualizationBasedSecurityStatus, que se usa para saber si VBS no está habilitado, está habilitado pero no arrancado, o directamente habilitado y en ejecución.
VirtualMachineIsolation y VirtualMachineIsolationProperties, que informan sobre el aislamiento de MV, con valores como AMD SEV‑SNP, Intel TDX o la propia seguridad basada en virtualización.

Interpretar estas propiedades te permite diagnosticar por qué VBS no se inicia (si falta una característica de hardware, si hay un problema de configuración, si solo está habilitado pero no en marcha, etc.) y si la integridad de memoria está en modo de auditoría o de aplicación estricta.

Uso de msinfo32.exe y otras comprobaciones

Otra forma rápida y bastante visual de comprobar el estado de VBS es ejecutar msinfo32.exe. Abriéndolo con permisos elevados, en la sección Resumen del sistema aparece, en la parte inferior, un bloque con características de seguridad basadas en virtualización y servicios que están ejecutándose.

También se puede revisar una clave de Registro volátil que refleja el estado de HVCI, concretamente HKLM\System\CurrentControlSet\Control\CI\State, donde el valor HVCIEnabled indica si la integridad de memoria está realmente activa tras el arranque.

Desde el punto de vista del usuario, la comprobación más inmediata sigue siendo abrir Seguridad de Windows > Seguridad del dispositivo y fijarse en el epígrafe Ejecución de servicios de seguridad basados en virtualización y en el interruptor de integridad de memoria dentro de los detalles de aislamiento del núcleo.

Solución de problemas comunes con Memory Integrity

No todo el mundo tiene una experiencia de “activar y listo”. Es bastante habitual que aparezca el famoso mensaje de “No se puede activar la integridad de la memoria” o que, en entornos gestionados por Intune, la configuración muestre estado de error sin más explicación. Para estos casos conviene tener un pequeño arsenal de comprobaciones y técnicas de diagnóstico.

Errores de activación manual en equipos domésticos

Cuando activas la integridad de memoria desde Seguridad de Windows y el sistema se niega, normalmente hay detrás alguno de estos factores:

Controladores obsoletos o incompatibles, en especial de dispositivos USB, tarjetas gráficas antiguas o periféricos poco habituales.
Software antivirus o de seguridad de terceros que entra en conflicto con el funcionamiento de HVCI y sus comprobaciones.
Problemas de compatibilidad de hardware (CPU sin características necesarias, BIOS sin virtualización, falta de SLAT, IOMMU o arranque seguro en determinados escenarios).
Actualizaciones de Windows pendientes, que impiden completar el despliegue de VBS y Memory Integrity hasta que no se instalan ciertos parches.

Algunas guías recomiendan como soluciones extremas cosas como reinstalar Windows desde cero o hacer un restablecimiento de fábrica, pero antes de llegar a ese punto conviene probar opciones mucho menos invasivas: eliminar controladores problemáticos, actualizar todos los drivers (especialmente USB y chipset), realizar un escaneo con el Comprobador de archivos de sistema (sfc /scannow) y un análisis completo de malware con Seguridad de Windows.

En casos en los que la función aparece bloqueada “por el administrador”, otra salida es revisar y modificar el Registro, asegurando que el valor Enabled en la ruta de HVCI se establece a 1 y que no hay políticas de grupo activas que impongan lo contrario. Eso sí, cualquier cambio en el Registro debe realizarse con permisos de administrador y copia de seguridad previa, porque un error puede dejar el sistema inestable.

Fallo de activación a través de Intune u otras herramientas de MDM

En despliegues gestionados con Intune es relativamente frecuente ver que una política de aislamiento del núcleo o integridad de memoria aparece como Error en un alto porcentaje de equipos, mientras que la activación manual desde la interfaz local sí funciona.

Cuando esto pasa y no hay entradas claras ni en IME.log ni en el Visor de eventos, conviene comprobar:

Que el dispositivo cumple de verdad los requisitos de hardware y firmware, incluyendo virtualización habilitada en BIOS, arranque seguro cuando la política lo exige y drivers actualizados.
Que no haya otra directiva o configuración anterior que entre en conflicto con la política de Intune para HVCI, especialmente si se han probado ajustes con y sin bloqueo UEFI.
Que el agente de Intune realmente esté recibiendo la directiva, revisando de nuevo IME.log en busca de menciones a DeviceGuard o HVCI aunque no aparezca un error explícito.
Si el error se produce solo en determinados modelos, comprobar con las herramientas de diagnóstico de compatibilidad de VBS (por ejemplo, SkTool o los registros de setupact.log) si se han detectado VBS_COMPAT_ISSUES concretos.

En ocasiones, la propia lógica de protección de arranque de Windows decide no activar automáticamente HVCI vía política si en arrancadas anteriores ha detectado bloqueos o reinicios forzados que apuntan a un controlador incompatible, aunque el usuario pueda activarlo manualmente sin aparente problema. Revisar las claves relacionadas con EnabledBootId y los mensajes con SYSPRP HVCI en setupact.log ayuda a ver si ha ocurrido algo así.

Uso de SkTool y logs para depurar VBS e integridad de memoria

El SDK de Windows incluye una utilidad poco conocida pero muy útil para soporte y administración avanzada, llamada SkTool. Se encuentra en la carpeta bin del SDK, en una ruta similar a C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\<arquitectura>, donde la arquitectura será x64, arm64, etc.

Ejecutando sktool.exe sin parámetros se muestra el estado actual del hipervisor y de VBS, indicando incluso la razón por la que VBS se ha iniciado o no se ha iniciado. Conmutadores como /status, /lkey o /mitigations permiten profundizar en detalles de aprovisionamiento de claves, mitigaciones del kernel seguro y otros aspectos de la seguridad basada en virtualización.

Por otro lado, para ver si la integridad de memoria está bloqueando controladores en tiempo de ejecución se puede consultar el registro de eventos en Applications and Service Logs\Microsoft\Windows\CodeIntegrity\Operational. Los eventos con EventID 3087 suelen estar relacionados con problemas de compatibilidad de HVCI con ciertos drivers, y son una pista clave para saber qué componente hay que actualizar o sustituir.

Si se quiere revisar cómo se tomó la decisión de habilitar o no HVCI por defecto durante la preparación del sistema, en setupact.log se pueden buscar cadenas como HVCI: Enabling HVCI o OS does not meet HVCI auto-enablement requirements. Los mensajes que incluyen VBS_COMPAT_ISSUES 0xXXXXXXXX enumeran, a través de un valor hexadecimal, los distintos problemas de compatibilidad detectados (por ejemplo, arquitectura no soportada, falta de SLAT, inexistencia de tabla ACPI WSMT, SSD ausente, RAM insuficiente, etc.).

Recuperar el sistema cuando Memory Integrity provoca inestabilidad

Si tras activar la integridad de memoria el sistema no inicia correctamente, se bloquea en el arranque o se vuelve inestable, lo recomendable es usar el entorno de recuperación de Windows (Windows RE) para deshacer el cambio.

El procedimiento general consiste en:

Desactivar temporalmente cualquier directiva de grupo o política de MDM que fuerce VBS o HVCI.
Arrancar el equipo afectado en Windows RE, usando las opciones avanzadas de recuperación.
Abrir una consola con privilegios y modificar la clave Enabled de HVCI en el Registro, poniéndola a 0 en la rama de DeviceGuard para desactivar la integridad de memoria.
Reiniciar el dispositivo y comprobar si el sistema vuelve a iniciar con normalidad.

Este enfoque permite recuperar equipos que se han quedado atrapados en un bucle de errores de arranque sin necesidad de reinstalar completamente el sistema operativo ni de perder datos, y es especialmente útil en entornos de producción donde el tiempo de inactividad es crítico.

Integridad de memoria en máquinas virtuales Hyper‑V

La integridad de memoria no es exclusiva de equipos físicos: también se puede activar en máquinas virtuales Hyper‑V, protegiendo el sistema invitado igual que si se tratara de un host físico. Desde dentro de la máquina virtual los pasos de configuración son prácticamente los mismos: habilitar VBS y HVCI, ya sea por políticas, Registro o desde la interfaz de Seguridad de Windows.

Eso sí, conviene tener claro el perímetro de protección: la integridad de memoria protege frente a malware que se ejecuta dentro de la máquina virtual, pero no añade defensa adicional frente al administrador del host ni frente a ataques sobre el propio hipervisor.

Desde el host de Hyper‑V se puede desactivar la inclusión de una máquina virtual en el esquema de seguridad basada en virtualización usando el cmdlet:

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

Para que todo esto funcione correctamente, hay varios requisitos a tener en cuenta:

El host de Hyper‑V debe ejecutar Windows Server 2016 o Windows 10 1607 o superior.
La máquina virtual debe ser de generación 2 y ejecutar Windows Server 2016 o Windows 10 o posterior.
La integridad de memoria es compatible con virtualización anidada, pero es necesario instalar primero el rol de Hyper‑V dentro de la MV en un entorno preparado para virtualización anidada.
Los adaptadores de canal de fibra virtual no son compatibles con integridad de memoria; antes de conectarlos a una MV, debe excluirse esa MV de VBS con Set‑VMSecurity.
La opción AllowFullSCSICommandSet en discos de paso a través tampoco se soporta con HVCI activa; de nuevo, es necesario optar por excluir la máquina virtual de VBS antes de usar esa configuración.

Con este conjunto de condiciones bien cubiertas, es posible desplegar escenarios de laboratorio y producción con VBS y Memory Integrity dentro de máquinas virtuales, lo que facilita probar políticas y configuraciones sin arriesgar directamente el host.

La integridad de memoria de Windows se ha convertido en una pieza central del modelo de seguridad moderno del sistema operativo: aprovecha la virtualización para aislar las decisiones críticas de integridad de código, endurece el kernel frente a exploits avanzados, integra su gestión con App Control, políticas de dispositivo y herramientas como Intune, y permite diagnósticos detallados a través de WMI, msinfo32, SkTool y registros específicos.