Memory integrity se activa sola en octubre, y solo donde nadie decidió nada

El 1 de septiembre Microsoft publicó dos frases seguidas: «las decisiones y políticas existentes de administrador y usuario seguirán vigentes» y «los dispositivos en los que memory integrity estaba previamente desactivada no serán cambiados automáticamente por este despliegue» (traducción nuestra; el original está en inglés). Las dos describen un censo, y Microsoft no lo esconde. La consecuencia es la que conviene leer dos veces: el cambio cae sobre los equipos donde no hay ninguna decisión, ni a favor ni en contra. En octubre, en ese conjunto, el administrador es Windows Update.

Qué se enciende, con las palabras de Microsoft

La entrada está en el centro de mensajes de Windows, fechada el 1 de septiembre de 2026, y remite al blog de Windows IT Pro. Dice así (traducción nuestra; el original está en inglés): «A partir de octubre de 2026, las actualizaciones de calidad de Windows empezarán a activar memory integrity en más dispositivos Windows elegibles. En algunos dispositivos, este cambio también activará la seguridad basada en virtualización (VBS). El despliegue será gradual, de modo que el cambio podría no llegar a todos los dispositivos elegibles al mismo tiempo». Y cierra fijando el alcance: «Las decisiones y políticas existentes de administrador y usuario seguirán vigentes. Los dispositivos en los que memory integrity estaba previamente desactivada no serán cambiados automáticamente por este despliegue».

Memory integrity es el nombre comercial de lo que la documentación técnica llama HVCI, integridad de código forzada por el hipervisor. Monta un entorno aislado con el hipervisor de Windows y mete ahí dentro la comprobación de firma del código que corre en modo núcleo. El efecto práctico: solo se carga código de núcleo y controladores en los que el sistema confía, y un atacante que ya ha conseguido ejecutar en el núcleo se encuentra con que no puede cargar su propio controlador. Es una de las pocas mitigaciones que de verdad encarece un ataque de núcleo, y conviene decirlo pronto para que no haya malentendidos: el cambio nos parece bien y el estado final correcto de casi cualquier parque es «encendida». Lo que discutimos aquí es quién decide, y con qué información.

Un apunte de calendario, porque va a circular mal: Microsoft dice «las actualizaciones de calidad de octubre de 2026», no un día concreto. El martes de parches de ese mes es el 13 de octubre, y de ahí sale la fecha que verás repetida en las noticias. Para esta activación, planifica contra el mes; para las otras dos cosas que caen ese mismo día —y que vienen más abajo— el 13 sí está confirmado por escrito.

«Elegible»: cinco factores y ninguno consultable

La misma entrada enumera los factores con los que Windows evalúa si un equipo está listo: «capacidades de hardware, compatibilidad, consideraciones de rendimiento, requisitos de sistema de Windows 11 y protecciones integradas recomendadas». La fórmula exacta es «factores como», así que la lista ni siquiera está cerrada, y ninguno de los cinco que nombra es consultable. No hay un comando que te diga «este equipo está en el conjunto», ni una lista publicada de modelos, ni un informe en Intune que lo anticipe. Puedes suponer —y es una suposición nuestra, no un criterio publicado— que un equipo reciente con Secure Boot activo es candidato. Hasta ahí.

Eso deja la planificación con una sola pregunta útil, porque «¿me va a tocar?» no la puedes contestar: ¿en qué estado está hoy cada equipo, y qué le pasa si le toca? Esa sí tiene respuesta, y se saca en una tarde.

Hay un matiz del propio manual que apunta a qué parte del parque lo va a notar. Memory integrity «funciona mejor» con procesadores Intel Kaby Lake o superiores, que traen Mode-Based Execution Control, y con AMD Zen 2 o superiores, que traen Guest Mode Execute Trap. Los procesadores más antiguos tiran de una emulación llamada Restricted User Mode y, cita literal, «tendrán un impacto mayor en el rendimiento». Dicho de otro modo: los equipos que peor lo van a llevar son los viejos, que es exactamente donde nadie ha tocado nunca esta configuración.

El censo: tres campos que contestan dónde estás hoy

Windows expone todo esto en una clase WMI, Win32_DeviceGuard. Desde una sesión de PowerShell con privilegios:

Get-CimInstance -ClassName Win32_DeviceGuard `
  -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus,
                SecurityServicesConfigured,
                SecurityServicesRunning

Los tres campos se leen así, según la tabla de la documentación:

La distinción entre los dos últimos importa en la práctica: «configurada» y «en marcha» pueden no coincidir, y el propio manual documenta un caso en el que no coinciden. En las máquinas virtuales de Azure, si se ha elegido Secure Boot with DMA, memory integrity no está soportada y —cita literal— «VBS aparecerá como activada pero no en marcha». Si tu inventario solo recoge el campo de «configurada», te dirá que el parque está protegido mientras una parte no lo está. Recoge los tres.

Para una comprobación suelta sobre un equipo concreto, msinfo32 saca lo mismo al final del Resumen del sistema, y el panel de usuario vive en Seguridad de Windows → Seguridad del dispositivo → Detalles de aislamiento del núcleo. Y un aviso para cuando busques la configuración: en el registro y en las directivas de grupo esto sigue colgando de Device Guard, un nombre que Microsoft retiró. Su propio manual lo dice así: «Device Guard ya no se usa salvo para localizar los ajustes de memory integrity y VBS en la directiva de grupo o el registro de Windows». Vas a buscar una función por un nombre que la empresa que la hizo ya no usa.

Cómo llega esto al buzón de incidencias

La advertencia que abre el manual de memory integrity es de las que no se suelen escribir a la ligera: «Algunas aplicaciones y controladores de dispositivo pueden ser incompatibles con memory integrity. Esta incompatibilidad puede hacer que dispositivos o software funcionen mal y, en casos raros, puede provocar un fallo de arranque (pantalla azul)». Y más abajo, en la sección del registro: «Todos los controladores del sistema deben ser compatibles con la protección de integridad de código basada en virtualización; de lo contrario, el sistema puede fallar».

Ahora traduce eso a lo que llega a tu buzón de incidencias. Nadie va a abrir un ticket que diga «memory integrity ha bloqueado un controlador». Van a decirte que la etiquetadora del almacén no imprime, que el lector de firma no lo detecta ninguna aplicación, que el escáner de documentos de contabilidad —ese que funciona perfectamente y por eso nadie ha tocado nunca su controlador— ha dejado de aparecer, o que un portátil arranca en azul. Y como el despliegue es gradual, los tickets no llegan todos el mismo día: llegan de uno en uno a lo largo de un periodo que Microsoft no concreta, que es la peor forma posible de recibir un problema común.

Por eso el inventario se hace antes. Después, la pregunta «¿qué ha cambiado en este equipo?» ya no tiene respuesta barata. Es el mismo mecanismo que contábamos con las políticas de acceso condicional que aparecen en tu tenant sin que las hayas escrito: un cambio legítimo, firmado por el fabricante, bien intencionado, que se manifiesta en un sitio completamente distinto de donde se originó.

Si decides tú: dónde se escribe, y la trampa del candado

Hay tres sitios donde Windows lee una decisión sobre esto, y una acta de reunión no es ninguno de ellos. En directiva de grupo: Configuración del equipo → Plantillas administrativas → Sistema → Device Guard → «Activar la seguridad basada en virtualización» → Habilitada, y debajo, en «Protección de integridad de código basada en virtualización», Habilitada sin bloqueo UEFI. En Intune: catálogo de configuración, Virtualization Based Technology → Hypervisor Enforced Code Integrity, o el nodo equivalente del CSP VirtualizationBasedTechnology. Y en el registro, que es lo que las dos anteriores acaban escribiendo:

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

Esos son los valores recomendados por Microsoft, y los dos Locked a cero son el motivo de este apartado. La alternativa, el bloqueo UEFI, viene con su propia advertencia en el manual: «Selecciona Habilitada con bloqueo UEFI solo si quieres impedir que memory integrity se desactive remotamente o mediante una actualización de directiva. Una vez habilitada con bloqueo UEFI, debes tener acceso al menú de la BIOS UEFI para desactivar Secure Boot si quieres desactivar memory integrity».

Léelo como una frase de operaciones y no de seguridad. Con el bloqueo puesto, deshacerlo es un viaje físico al equipo. Con un parque de un par de centenares de portátiles repartidos entre oficinas y casas, acabas de convertir un cambio de directiva en un problema de logística. Nuestra regla, por si sirve: un endurecimiento que no puedes deshacer en remoto no es un endurecimiento, es un rehén. El bloqueo UEFI tiene sentido, pero se elige a propósito y para las máquinas que lo merecen —un controlador de dominio, un puñado de portátiles de alto riesgo—, no como valor por defecto del parque entero. Y hay además, en esa misma clave del registro, un valor Mandatory, que según el manual hace que el sistema «se niegue a arrancar» si fallan los módulos de virtualización. Esa no la toques sin un motivo muy bueno y un plan de recuperación por escrito.

Dos detalles más que se escapan con facilidad. El primero es contraintuitivo: RequirePlatformSecurityFeatures con valor 3 (Secure Boot con protección DMA) suena más estricto que el 1 (Secure Boot a secas), pero el manual avisa de que con el 3 «memory integrity y el resto de funciones VBS solo se activarán en equipos que soporten DMA. Es decir, solo en equipos con IOMMU. Cualquier equipo sin IOMMU no tendrá protección VBS ni memory integrity». El valor más estricto protege a menos máquinas. Microsoft recomienda el 1 «en la mayoría de situaciones». El segundo: si estás pilotando App Control for Business, ojo, porque «si tu directiva de App Control está configurada para activar memory integrity, se activará incluso si la directiva está en modo auditoría». Para esto, el modo auditoría no audita.

El plan de siete días que haríamos nosotros

• 1. El censo, con fecha. El comando de arriba sobre todo el parque, por la herramienta de gestión que ya tengas. Columnas: equipo, procesador, los tres campos de VBS y si existe una política escrita. Guárdalo: dentro de un mes es la única forma barata de contestar «¿esto ya estaba así?».
• 2. Tres montones. Ya encendida (nada que hacer). Apagada: Microsoft dice que a estos equipos el despliegue no los toca, y no pone como condición que exista una política —basta con que esté desactivada—, aunque nosotros la escribiríamos igual, porque una decisión que solo existe en la cabeza de alguien no sobrevive a la siguiente reinstalación. Y sin tocar: aquí cae el cambio, y es el único montón que importa.
• 3. Del tercer montón, saca los raros. Equipos con periférico que no es un ratón: etiquetadoras, escáneres, lectores de firma, llaves USB de licencia, aparatos de laboratorio o de taller, controladoras de almacenamiento antiguas, software de cifrado de disco de terceros. Esa es tu lista de pruebas, y es corta.
• 4. Anillo piloto de verdad. Microsoft lo recomienda por escrito: «recomendamos activar estas funciones en un grupo de equipos de prueba antes de activarlas en los equipos de los usuarios». Un anillo de verdad son equipos que usa gente, con sus periféricos y su software raro enchufados. Tres máquinas virtuales limpias no prueban nada de lo que falla aquí.
• 5. Escribe la decisión en los tres montones, incluido el «sí, encendida». Sin bloqueo UEFI salvo excepción razonada y anotada. El objetivo es que el estado tenga dueño.
• 6. La vuelta atrás, preparada antes. El manual la documenta en cuatro pasos y el primero es el que se salta todo el mundo: desactivar antes las directivas que activan VBS y memory integrity —la GPO, el perfil de Intune—, porque si no, vuelven a aplicar el valor en el siguiente arranque y parece que el procedimiento no funciona. Después sí: arrancar en el entorno de recuperación de Windows y poner a 0 el valor Enabled de la clave de HVCI. Impreso, en manos de quien coge el teléfono, antes de que haga falta. Y si alguien puso el bloqueo UEFI, además hay que desactivar Secure Boot en la BIOS.
• 7. Alerta por cambio, no por estado. «Avísame si memory integrity está apagada» es una alerta que se silencia la primera semana. La útil es: avísame cuando un equipo cambie de estado, en cualquiera de las dos direcciones. Un cambio que no pediste es exactamente lo que quieres ver en la bandeja.

Octubre trae tres relojes, y solo dos marcan el día 13

Mientras mirabas memory integrity, en el mismo centro de mensajes hay otras dos entradas con esa fecha. El 14 de septiembre: «El 13 de octubre de 2026, Windows 11 versión 24H2 ediciones Home y Pro, y Windows 10 Enterprise LTSB 2016, alcanzarán el fin de actualizaciones». El 11 de septiembre: «El 13 de octubre de 2026, Windows Server 2022 alcanzará el fin de soporte general. La actualización de seguridad de octubre de 2026 será la última de soporte general disponible para esta versión», y a partir de ahí pasa a soporte extendido con actualizaciones de seguridad sin coste adicional hasta el 14 de octubre de 2031. Y la tercera, con tres recordatorios publicados a 90, 60 y 30 días: el endurecimiento de los permisos del contenedor DKM de AD FS entra en modo de aplicación en octubre, por la elevación de privilegios CVE-2026-56155.

Con memory integrity son cuatro cosas en el mismo mes, y conviene no amontonarlas: solo el fin de actualizaciones de 24H2 y el fin de soporte general de Server 2022 están fechados el día 13 por escrito. Memory integrity y el endurecimiento de AD FS llevan ambos la misma etiqueta, «octubre de 2026», sin día. Y las naturalezas no se parecen: una enciende algo en los puestos, otra deja de darte algo en los servidores, la tercera modifica permisos sobre un objeto de tu directorio y la cuarta solo retira una fecha del calendario. No comparten plan de vuelta atrás ni, en la mayoría de empresas, responsable. El error típico de octubre es tratarlo todo como una sola ventana de mantenimiento.

Si tienes AD FS, el del despertador es el tercero, y por una razón concreta: la vuelta atrás no es «desinstalar la actualización», son permisos sobre un contenedor de tu Active Directory. El aviso de Microsoft dice que «durante el modo de aplicación, las versiones soportadas de Windows Server ejecutarán la remediación por defecto salvo que los administradores opten explícitamente por no hacerlo», y añade que «Windows Server 2012 y Windows Server 2012 R2 siguen requiriendo remediación manual y no se remediarán automáticamente». Es decir: en las versiones modernas se hace solo, y justo en las antiguas —donde la gente nunca ha mirado los permisos de ese contenedor— no se hace nadie cargo. Y los dos primeros son la misma historia que ya contamos con Office 2021: fin de actualizaciones no significa que deje de funcionar, significa que deja de probarse.

Las máquinas virtuales también están en el censo

Memory integrity funciona dentro de una máquina virtual igual que en una física, y Microsoft documenta el caso de Hyper-V con sus requisitos: generación 2, anfitrión de Windows Server 2016 o Windows 10 1607 como mínimo, y la posibilidad de excluir una VM desde el anfitrión con Set-VMSecurity -VMName <nombre> -VirtualizationBasedSecurityOptOut $true. Lo interesante son las dos incompatibilidades que lista, porque apuntan justo al tipo de máquina que no quieres tocar a ciegas: los adaptadores de fibra virtuales no son compatibles con memory integrity, y la opción AllowFullSCSICommandSet para discos en passthrough tampoco. En los dos casos hay que excluir la VM antes. Eso no está en un portátil cualquiera: está en el servidor de copias con su librería de cintas y en la VM que ataca un disco directo.

Una honestidad sobre el alcance de ese apartado: todo eso es la tabla de Hyper-V, y no vamos a extenderla a plataformas que Microsoft no cubre. Nosotros operamos los invitados Windows sobre Proxmox, y ahí la dependencia es de la misma naturaleza —el invitado tiene que poder levantar su propio hipervisor, así que el anfitrión tiene que exponerle las extensiones de virtualización—, pero quién contesta a eso es quien opera el anfitrión, no un manual de Hyper-V. Si tus VM Windows corren en otro sitio, esa es la pregunta que hay que hacer, y conviene hacerla antes de octubre y no durante. Si además estás en medio de una migración donde el calendario lo marca el repositorio del fabricante, ya sabes cómo acaba juntar dos relojes ajenos en la misma semana.

Lo que no estamos diciendo

No te estamos diciendo que apagues memory integrity. Al revés: si tu parque la lleva encendida y nada se ha roto, enhorabuena, estás en el sitio donde hay que estar. Tampoco nos parece mal el valor por defecto; a escala de cientos de millones de equipos domésticos, encenderla es lo correcto y lo contrario sería negligente. Nuestra pega es más estrecha y es esta: en una empresa, «no hay decisión» no es lo mismo que «da igual», y lo está resolviendo alguien que no sabe qué hay enchufado a tus máquinas.

El despliegue empieza este mes, así que aquí todavía no hay un incidente que contar: lo que hay es el centro de mensajes y el manual de memory integrity leídos enteros, más el método que aplicamos a cualquier cambio que llega solo. Si dentro de seis semanas tenemos uno, lo contaremos con sus números.

El conflicto de interés, por delante: no somos revendedores de una plataforma concreta, así que lo que recomendamos aquí no nos lo paga nadie por recomendarlo. Pasar el censo, montar el anillo piloto y escribir la política sí lo facturamos.

Fuentes (verificadas el 2 de octubre de 2026): el anuncio del despliegue de memory integrity a partir de octubre de 2026, los cinco factores de evaluación de preparación y la frase sobre que las decisiones y políticas existentes seguirán vigentes (entrada del 01-09-2026), el fin de actualizaciones de Windows 11 24H2 Home y Pro y de Windows 10 Enterprise LTSB 2016 el 13-10-2026 (entrada del 14-09-2026), el fin de soporte general de Windows Server 2022 el 13-10-2026 con soporte extendido hasta el 14-10-2031 (entrada del 11-09-2026) y los tres recordatorios del paso a modo de aplicación del endurecimiento del contenedor DKM de AD FS, con la nota sobre Windows Server 2012 y 2012 R2 (entradas del 29-07, 17-08 y 14-09-2026) — centro de mensajes de Windows, que remite al artículo «Expanding memory integrity protection across Windows devices» del blog de Windows IT Pro y a la KB5121391; la advertencia sobre controladores incompatibles y pantalla azul, la equivalencia memory integrity = HVCI, la nota sobre Kaby Lake/Zen 2 y Restricted User Mode, las rutas de directiva de grupo e Intune, las claves de registro recomendadas, la advertencia del bloqueo UEFI, el comportamiento de RequirePlatformSecurityFeatures con valor 3, la opción Mandatory, la nota de App Control en modo auditoría, la tabla de valores de Win32_DeviceGuard, el caso de las VM de Azure con Secure Boot with DMA, la recomendación de probar en un grupo de equipos de prueba, el procedimiento de recuperación por Windows RE y los requisitos e incompatibilidades en máquinas virtuales de Hyper-V — «Enable memory integrity», Microsoft Learn (fecha de artículo 14-08-2026). La lectura de la frase de Microsoft como un censo, la regla sobre el bloqueo UEFI, el plan de siete días y la alerta por cambio de estado son nuestras, no de esas fuentes.