Memory integrity s'activa sola a l'octubre, i només on ningú no va decidir res

L'1 de setembre Microsoft va publicar dues frases seguides: «les decisions i polítiques existents d'administrador i usuari continuaran vigents» i «els dispositius en què memory integrity estava prèviament desactivada no seran canviats automàticament per aquest desplegament» (traducció nostra; l'original és en anglès). Totes dues descriuen un cens, i Microsoft no ho amaga. La conseqüència és la que convé llegir dues vegades: el canvi cau sobre els equips on no hi ha cap decisió, ni a favor ni en contra. A l'octubre, en aquest conjunt, l'administrador és Windows Update.

Què s'encén, amb les paraules de Microsoft

L'entrada és al centre de missatges de Windows, datada l'1 de setembre del 2026, i remet al blog de Windows IT Pro. Diu això (traducció nostra; l'original és en anglès): «A partir d'octubre del 2026, les actualitzacions de qualitat de Windows començaran a activar memory integrity en més dispositius Windows elegibles. En alguns dispositius, aquest canvi també activarà la seguretat basada en virtualització (VBS). El desplegament serà gradual, de manera que el canvi podria no arribar a tots els dispositius elegibles al mateix temps». I tanca fixant l'abast: «Les decisions i polítiques existents d'administrador i usuari continuaran vigents. Els dispositius en què memory integrity estava prèviament desactivada no seran canviats automàticament per aquest desplegament».

Memory integrity és el nom comercial del que la documentació tècnica anomena HVCI, integritat de codi forçada per l'hipervisor. Munta un entorn aïllat amb l'hipervisor de Windows i hi fica a dins la comprovació de signatura del codi que corre en mode nucli. L'efecte pràctic: només es carrega codi de nucli i controladors en què el sistema confia, i un atacant que ja ha aconseguit executar al nucli es troba que no pot carregar el seu propi controlador. És una de les poques mitigacions que de debò encareix un atac de nucli, i convé dir-ho aviat perquè no hi hagi malentesos: el canvi ens sembla bé i l'estat final correcte de gairebé qualsevol parc és «encesa». El que discutim aquí és qui decideix, i amb quina informació.

Un apunt de calendari, perquè circularà malament: Microsoft diu «les actualitzacions de qualitat d'octubre del 2026», no un dia concret. El dimarts de pedaços d'aquell mes és el 13 d'octubre, i d'aquí surt la data que veuràs repetida a les notícies. Per a aquesta activació, planifica contra el mes; per a les altres dues coses que cauen aquell mateix dia —i que vénen més avall— el 13 sí que està confirmat per escrit.

«Elegible»: cinc factors i cap de consultable

La mateixa entrada enumera els factors amb què Windows avalua si un equip està a punt: «capacitats de maquinari, compatibilitat, consideracions de rendiment, requisits de sistema de Windows 11 i proteccions integrades recomanades». La fórmula exacta és «factors com ara», així que la llista ni tan sols és tancada, i cap dels cinc que anomena no és consultable. No hi ha una ordre que et digui «aquest equip és al conjunt», ni una llista publicada de models, ni un informe a l'Intune que ho anticipi. Pots suposar —i és una suposició nostra, no un criteri publicat— que un equip recent amb Secure Boot actiu és candidat. Fins aquí.

Això deixa la planificació amb una sola pregunta útil, perquè «em tocarà?» no la pots contestar: en quin estat és avui cada equip, i què li passa si li toca? Aquesta sí que té resposta, i se'n surt en una tarda.

Hi ha un matís del mateix manual que apunta a quina part del parc ho notarà. Memory integrity «funciona millor» amb processadors Intel Kaby Lake o superiors, que porten Mode-Based Execution Control, i amb AMD Zen 2 o superiors, que porten Guest Mode Execute Trap. Els processadors més antics tiren d'una emulació anomenada Restricted User Mode i, cita literal, «tindran un impacte més gran en el rendiment». Dit d'una altra manera: els equips que pitjor ho portaran són els vells, que és exactament on ningú no ha tocat mai aquesta configuració.

El cens: tres camps que contesten on ets avui

Windows exposa tot això en una classe WMI, Win32_DeviceGuard. Des d'una sessió de PowerShell amb privilegis:

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

Els tres camps es llegeixen així, segons la taula de la documentació:

La distinció entre els dos últims importa a la pràctica: «configurada» i «en marxa» poden no coincidir, i el mateix manual documenta un cas en què no coincideixen. A les màquines virtuals d'Azure, si s'ha triat Secure Boot with DMA, memory integrity no està suportada i —cita literal— «VBS apareixerà com a activada però no en marxa». Si el teu inventari només recull el camp de «configurada», et dirà que el parc està protegit mentre una part no ho està. Recull-ne els tres.

Per a una comprovació solta sobre un equip concret, msinfo32 treu el mateix al final del Resum del sistema, i el panell d'usuari viu a Seguretat de Windows → Seguretat del dispositiu → Detalls d'aïllament del nucli. I un avís per quan busquis la configuració: al registre i a les directives de grup això continua penjant de Device Guard, un nom que Microsoft va retirar. El seu propi manual ho diu així: «Device Guard ja no s'usa llevat de per localitzar els ajustos de memory integrity i VBS a la directiva de grup o al registre de Windows». Buscaràs una funció per un nom que l'empresa que la va fer ja no fa servir.

Com arriba això a la bústia d'incidències

L'advertiment que obre el manual de memory integrity és dels que no se solen escriure a la lleugera: «Algunes aplicacions i controladors de dispositiu poden ser incompatibles amb memory integrity. Aquesta incompatibilitat pot fer que dispositius o programari funcionin malament i, en casos rars, pot provocar una fallada d'arrencada (pantalla blava)». I més avall, a la secció del registre: «Tots els controladors del sistema han de ser compatibles amb la protecció d'integritat de codi basada en virtualització; si no, el sistema pot fallar».

Ara tradueix això al que arriba a la teva bústia d'incidències. Ningú no obrirà un tiquet que digui «memory integrity ha bloquejat un controlador». Et diran que l'etiquetadora del magatzem no imprimeix, que el lector de signatura no el detecta cap aplicació, que l'escàner de documents de comptabilitat —aquell que funciona perfectament i per això ningú no ha tocat mai el seu controlador— ha deixat d'aparèixer, o que un portàtil arrenca en blau. I com que el desplegament és gradual, els tiquets no arriben tots el mateix dia: arriben d'un en un al llarg d'un període que Microsoft no concreta, que és la pitjor manera possible de rebre un problema comú.

Per això l'inventari es fa abans. Després, la pregunta «què ha canviat en aquest equip?» ja no té resposta barata. És el mateix mecanisme que explicàvem amb les polítiques d'accés condicional que apareixen al teu tenant sense que les hagis escrit: un canvi legítim, signat pel fabricant, ben intencionat, que es manifesta en un lloc completament diferent d'on es va originar.

Si decideixes tu: on s'escriu, i el parany del pany

Hi ha tres llocs on Windows llegeix una decisió sobre això, i una acta de reunió no és cap d'ells. A directiva de grup: Configuració de l'equip → Plantilles administratives → Sistema → Device Guard → «Activar la seguretat basada en virtualització» → Habilitada, i a sota, a «Protecció d'integritat de codi basada en virtualització», Habilitada sense bloqueig UEFI. A Intune: catàleg de configuració, Virtualization Based Technology → Hypervisor Enforced Code Integrity, o el node equivalent del CSP VirtualizationBasedTechnology. I al registre, que és el que les dues anteriors acaben escrivint:

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

Aquests són els valors recomanats per Microsoft, i els dos Locked a zero són el motiu d'aquest apartat. L'alternativa, el bloqueig UEFI, ve amb el seu propi advertiment al manual: «Selecciona Habilitada amb bloqueig UEFI només si vols impedir que memory integrity es desactivi remotament o mitjançant una actualització de directiva. Un cop habilitada amb bloqueig UEFI, has de tenir accés al menú de la BIOS UEFI per desactivar Secure Boot si vols desactivar memory integrity».

Llegeix-ho com una frase d'operacions i no de seguretat. Amb el pany posat, desfer-ho és un viatge físic a l'equip. Amb un parc d'un parell de centenars de portàtils repartits entre oficines i cases, acabes de convertir un canvi de directiva en un problema de logística. La nostra regla, per si serveix: un enduriment que no pots desfer en remot no és un enduriment, és un ostatge. El bloqueig UEFI té sentit, però es tria a propòsit i per a les màquines que s'ho mereixen —un controlador de domini, un grapat de portàtils d'alt risc—, no com a valor per defecte del parc sencer. I hi ha a més, en aquesta mateixa clau del registre, un valor Mandatory, que segons el manual fa que el sistema «es negui a arrencar» si fallen els mòduls de virtualització. Aquesta no la toquis sense un motiu molt bo i un pla de recuperació per escrit.

Dos detalls més que s'escapen amb facilitat. El primer és contraintuïtiu: RequirePlatformSecurityFeatures amb valor 3 (Secure Boot amb protecció DMA) sona més estricte que l'1 (Secure Boot a seques), però el manual avisa que amb el 3 «memory integrity i la resta de funcions VBS només s'activaran en equips que suportin DMA. És a dir, només en equips amb IOMMU. Qualsevol equip sense IOMMU no tindrà protecció VBS ni memory integrity». El valor més estricte protegeix menys màquines. Microsoft recomana l'1 «en la majoria de situacions». El segon: si estàs pilotant App Control for Business, compte, perquè «si la teva directiva d'App Control està configurada per activar memory integrity, s'activarà fins i tot si la directiva és en mode auditoria». Per a això, el mode auditoria no audita.

El pla de set dies que faríem nosaltres

• 1. El cens, amb data. L'ordre de dalt sobre tot el parc, per l'eina de gestió que ja tinguis. Columnes: equip, processador, els tres camps de VBS i si existeix una política escrita. Guarda'l: d'aquí a un mes és l'única manera barata de contestar «això ja estava així?».
• 2. Tres munts. Ja encesa (res a fer). Apagada: Microsoft diu que aquests equips el desplegament no els toca, i no posa com a condició que existeixi una política —n'hi ha prou que estigui desactivada—, encara que nosaltres l'escriuríem igualment, perquè una decisió que només existeix al cap d'algú no sobreviu a la següent reinstal·lació. I sense tocar: aquí cau el canvi, i és l'únic munt que importa.
• 3. Del tercer munt, treu els rars. Equips amb perifèric que no és un ratolí: etiquetadores, escàners, lectors de signatura, claus USB de llicència, aparells de laboratori o de taller, controladores d'emmagatzematge antigues, programari de xifratge de disc de tercers. Aquesta és la teva llista de proves, i és curta.
• 4. Anell pilot de debò. Microsoft ho recomana per escrit: «recomanem activar aquestes funcions en un grup d'equips de prova abans d'activar-les als equips dels usuaris». Un anell de debò són equips que fa servir gent, amb els seus perifèrics i el seu programari rar endollats. Tres màquines virtuals netes no proven res del que falla aquí.
• 5. Escriu la decisió als tres munts, inclòs el «sí, encesa». Sense bloqueig UEFI llevat d'excepció raonada i anotada. L'objectiu és que l'estat tingui amo.
• 6. La marxa enrere, preparada abans. El manual la documenta en quatre passos i el primer és el que es salta tothom: desactivar abans les directives que activen VBS i memory integrity —la GPO, el perfil d'Intune—, perquè si no, tornen a aplicar el valor a l'arrencada següent i sembla que el procediment no funciona. Després sí: arrencar a l'entorn de recuperació de Windows i posar a 0 el valor Enabled de la clau d'HVCI. Imprès, a mans de qui agafa el telèfon, abans que faci falta. I si algú va posar el bloqueig UEFI, a més cal desactivar Secure Boot a la BIOS.
• 7. Alerta per canvi, no per estat. «Avisa'm si memory integrity és apagada» és una alerta que se silencia la primera setmana. La útil és: avisa'm quan un equip canviï d'estat, en qualsevol de les dues direccions. Un canvi que no vas demanar és exactament el que vols veure a la safata.

L'octubre porta tres rellotges, i només dos marquen el dia 13

Mentre miraves memory integrity, al mateix centre de missatges hi ha altres dues entrades amb aquella data. El 14 de setembre: «El 13 d'octubre del 2026, Windows 11 versió 24H2 edicions Home i Pro, i Windows 10 Enterprise LTSB 2016, assoliran el fi d'actualitzacions». L'11 de setembre: «El 13 d'octubre del 2026, Windows Server 2022 assolirà el fi de suport general. L'actualització de seguretat d'octubre del 2026 serà l'última de suport general disponible per a aquesta versió», i a partir d'aquí passa a suport estès amb actualitzacions de seguretat sense cost addicional fins al 14 d'octubre del 2031. I la tercera, amb tres recordatoris publicats a 90, 60 i 30 dies: l'enduriment dels permisos del contenidor DKM d'AD FS entra en mode d'aplicació a l'octubre, per l'elevació de privilegis CVE-2026-56155.

Amb memory integrity són quatre coses el mateix mes, i convé no amuntegar-les: només el fi d'actualitzacions de 24H2 i el fi de suport general de Server 2022 estan datats el dia 13 per escrit. Memory integrity i l'enduriment d'AD FS porten tots dos la mateixa etiqueta, «octubre del 2026», sense dia. I les naturaleses no s'assemblen: una encén alguna cosa als llocs de treball, una altra deixa de donar-te alguna cosa als servidors, la tercera modifica permisos sobre un objecte del teu directori i la quarta només retira una data del calendari. No comparteixen pla de marxa enrere ni, a la majoria d'empreses, responsable. L'error típic d'octubre és tractar-ho tot com una sola finestra de manteniment.

Si tens AD FS, el del despertador és el tercer, i per una raó concreta: la marxa enrere no és «desinstal·lar l'actualització», són permisos sobre un contenidor del teu Active Directory. L'avís de Microsoft diu que «durant el mode d'aplicació, les versions suportades de Windows Server executaran la remediació per defecte llevat que els administradors optin explícitament per no fer-ho», i afegeix que «Windows Server 2012 i Windows Server 2012 R2 continuen requerint remediació manual i no es remediaran automàticament». És a dir: a les versions modernes es fa sol, i justament a les antigues —on la gent no ha mirat mai els permisos d'aquell contenidor— no se'n fa càrrec ningú. I els dos primers són la mateixa història que ja vam explicar amb Office 2021: fi d'actualitzacions no vol dir que deixi de funcionar, vol dir que deixa de provar-se.

Les màquines virtuals també són al cens

Memory integrity funciona dins d'una màquina virtual igual que en una física, i Microsoft documenta el cas d'Hyper-V amb els seus requisits: generació 2, amfitrió de Windows Server 2016 o Windows 10 1607 com a mínim, i la possibilitat d'excloure una VM des de l'amfitrió amb Set-VMSecurity -VMName <nom> -VirtualizationBasedSecurityOptOut $true. L'interessant són les dues incompatibilitats que llista, perquè apunten just al tipus de màquina que no vols tocar a cegues: els adaptadors de fibra virtuals no són compatibles amb memory integrity, i l'opció AllowFullSCSICommandSet per a discos en passthrough tampoc. En tots dos casos cal excloure la VM abans. Això no és en un portàtil qualsevol: és al servidor de còpies amb la seva llibreria de cintes i a la VM que ataca un disc directe.

Una honestedat sobre l'abast d'aquest apartat: tot això és la taula d'Hyper-V, i no l'estendrem a plataformes que Microsoft no cobreix. Nosaltres operem els convidats Windows sobre Proxmox, i allà la dependència és de la mateixa naturalesa —el convidat ha de poder aixecar el seu propi hipervisor, així que l'amfitrió li ha d'exposar les extensions de virtualització—, però qui contesta això és qui opera l'amfitrió, no un manual d'Hyper-V. Si les teves VM Windows corren en un altre lloc, aquesta és la pregunta que cal fer, i convé fer-la abans d'octubre i no durant. Si a més ets enmig d'una migració on el calendari el marca el repositori del fabricant, ja saps com acaba ajuntar dos rellotges aliens a la mateixa setmana.

El que no estem dient

No et diem que apaguis memory integrity. Al revés: si el teu parc la porta encesa i res no s'ha trencat, enhorabona, ets al lloc on cal ser. Tampoc no ens sembla malament el valor per defecte; a escala de centenars de milions d'equips domèstics, encendre-la és el correcte i el contrari seria negligent. La nostra pega és més estreta i és aquesta: en una empresa, «no hi ha decisió» no és el mateix que «tant se val», i ho està resolent algú que no sap què hi ha endollat a les teves màquines.

El desplegament comença aquest mes, així que aquí encara no hi ha cap incident per explicar: el que hi ha és el centre de missatges i el manual de memory integrity llegits sencers, més el mètode que apliquem a qualsevol canvi que arriba sol. Si d'aquí a sis setmanes en tenim un, l'explicarem amb els seus números.

El conflicte d'interès, per davant: no som revenedors d'una plataforma concreta, així que el que recomanem aquí no ens ho paga ningú per recomanar-ho. Passar el cens, muntar l'anell pilot i escriure la política sí que ho facturem.

Fonts (verificades el 2 d'octubre del 2026): l'anunci del desplegament de memory integrity a partir d'octubre del 2026, els cinc factors d'avaluació de preparació i la frase sobre que les decisions i polítiques existents continuaran vigents (entrada de l'01-09-2026), el fi d'actualitzacions de Windows 11 24H2 Home i Pro i de Windows 10 Enterprise LTSB 2016 el 13-10-2026 (entrada del 14-09-2026), el fi de suport general de Windows Server 2022 el 13-10-2026 amb suport estès fins al 14-10-2031 (entrada de l'11-09-2026) i els tres recordatoris del pas a mode d'aplicació de l'enduriment del contenidor DKM d'AD FS, amb la nota sobre Windows Server 2012 i 2012 R2 (entrades del 29-07, 17-08 i 14-09-2026) — centre de missatges de Windows, que remet a l'article «Expanding memory integrity protection across Windows devices» del blog de Windows IT Pro i a la KB5121391; l'advertiment sobre controladors incompatibles i pantalla blava, l'equivalència memory integrity = HVCI, la nota sobre Kaby Lake/Zen 2 i Restricted User Mode, les rutes de directiva de grup i Intune, les claus de registre recomanades, l'advertiment del bloqueig UEFI, el comportament de RequirePlatformSecurityFeatures amb valor 3, l'opció Mandatory, la nota d'App Control en mode auditoria, la taula de valors de Win32_DeviceGuard, el cas de les VM d'Azure amb Secure Boot with DMA, la recomanació de provar en un grup d'equips de prova, el procediment de recuperació per Windows RE i els requisits i incompatibilitats en màquines virtuals d'Hyper-V — «Enable memory integrity», Microsoft Learn (data d'article 14-08-2026). La lectura de la frase de Microsoft com un cens, la regla sobre el bloqueig UEFI, el pla de set dies i l'alerta per canvi d'estat són nostres, no d'aquelles fonts.