Guia pràctica per casos (PCs, servidors i màquines virtuals)
El juny de 2026 caduquen certificats “històrics” de Secure Boot. En entorns empresarials, normalment no es tradueix en un tall immediat, però sí que pot deixar equips en un estat de seguretat degradat i complicar la compatibilitat amb futurs components signats si no s’actualitza la cadena de confiança.
En aquesta guia tens un enfocament divulgatiu i accionable, separat per casos (PCs, servidors físics i VMs), amb un pla d’inventari, pilot, desplegament i verificació. També inclou un workaround operatiu per a laboratori/pilot i una secció de preguntes freqüents al final.
Si vols ajuda per executar un pla controlat i sense ensurts, pots recolzar-te en el nostre servei de manteniment informàtic per a empreses i en la ciberseguretat per a PIMES com a base per governar canvis de firmware, hardening i continuïtat operativa.
Resum en 5 passos
Si necessites una lectura ràpida per convertir això en un pla intern, aquí tens el flux recomanat. Està pensat per minimitzar el risc operatiu i evitar actuar “a cegues” en producció.
- Inventari: classifica per PC / servidor / VM i per BIOS/Legacy vs UEFI + Secure Boot.
- Pilot: prova en un grup representatiu (PCs, 1 servidor per família i 1–2 VMs per tipologia).
- Correccions prèvies: firmware/BIOS/UEFI al dia, gestió de BitLocker, compatibilitat de l’hipervisor en VMs.
- Desplegament per onades: de menor a major criticitat, amb finestres si aplica.
- Validació: esdeveniments, reinici correcte i verificació de serveis (especialment en servidors i VMs crítiques).
Què canvia el 2026 i per què és rellevant a l’empresa
Secure Boot forma part de l’arrencada UEFI i valida que el que s’executa a l’inici (bootloader i components relacionats) està signat per entitats de confiança. La caducitat de certificats el 2026 obliga a alinear dispositius i plataformes amb els certificats més recents per mantenir la integritat de l’arrencada a futur.
A les empreses, el risc típic no és “ha deixat d’arrencar”, sinó un estat de seguretat degradat i una major probabilitat d’incidències quan s’apliquen actualitzacions futures, hardening, canvis de plataforma o desplegaments massius.
Font recomanada (oficial): Windows Secure Boot certificate expiration and CA updates (Microsoft)
Cas 0: No aplica (BIOS/Legacy)
Aquest cas serveix per descartar ràpid i no invertir temps on no toca. Si un equip no fa servir UEFI, Secure Boot no està actiu i aquest canvi no aplica directament.
Aplica a
- PCs, servidors o VMs que arrenquen en mode BIOS/Legacy (no UEFI).
- Entorns on Secure Boot no existeix o no es pot habilitar per plataforma.
Acció recomanada
- Inventariar com a “BIOS/Legacy”.
- Valorar la migració a UEFI quan toqui (per estandardització i hardening), amb proves.
Cas 1: PCs
Als llocs de treball, el més eficient és tractar-ho com un projecte d’actualització controlada: pilot, validació i desplegament per onades. Normalment el parc s’estabilitza amb Windows Update i el firmware al dia, però convé anticipar BitLocker i firmware antics.
Riscos típics en PCs
- BIOS/UEFI desactualitzada o amb NVRAM limitada/plena.
- BitLocker i polítiques de seguretat que interfereixen amb canvis de l’arrencada.
- Equips antics sense manteniment de firmware per part del fabricant.
Workaround per a pilot (PC)
Aquest workaround està pensat per a laboratori o pilot. L’objectiu és forçar el flux i validar si l’equip pot aplicar l’actualització sense errors abans d’escalar a onades.
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /fStart-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"Després, reinicia i valida. En alguns entorns poden ser necessaris més d’un reinici per completar els canvis.
Verificació (PC)
La validació més ràpida és revisar esdeveniments. Si tens errors persistents d’escriptura a la NVRAM, acostuma a apuntar a firmware o a limitacions de l’equip.
- Ruta: Visor d’esdeveniments > Registres d’aplicacions i serveis > Microsoft > Windows > Hardware-Events > Admin
- Event ID 1: intent d’actualitzar una variable de Secure Boot
- Event ID 2: error en escriure una nova clau a la NVRAM (firmware/NVRAM/compatibilitat)
Cas 2: Servidors físics (on-prem)
Als servidors, el procediment s’assembla al dels PCs, però l’execució ha de ser més disciplinada: finestres de manteniment, rollback, validació de rols i, sobretot, dependència del firmware del fabricant.
Què canvia respecte als PCs
- Reinicios planificats i coordinació amb el negoci.
- Dependència alta de BIOS/UEFI i del firmware de plataforma.
- Validació post-reinici: rols (AD/SQL/RDS), emmagatzematge, xarxa i clúster si existeix.
Pla recomanat per a servidors
- Inventari per model i versió de BIOS/UEFI.
- Actualitzar el firmware del fabricant quan sigui necessari (abans del canvi).
- Pilot: 1 servidor per família de maquinari.
- Desplegament per onades: secundaris > crítics.
- Validació: arrencada neta + serveis/rols/clúster OK.
Si necessites alinear aquest tipus de canvis amb continuïtat operativa, acostuma a encaixar amb un servei de gestió de sistemes IT per mantenir controlats firmware, reinicis, evidències i finestra de manteniment.
Cas 3: Màquines virtuals (VMs)
Les VMs són el cas més “traïdor”. Tot i que el sistema operatiu sigui Windows i sembli un PC, el firmware és virtual i la NVRAM també. Si la plataforma no permet escriure variables de Secure Boot, el guest pot fallar encara que estigui totalment actualitzat.
Per què pot fallar en VMs
- NVRAM virtual restringida o amb limitacions d’escriptura.
- Compatibilitat de maquinari virtual / UEFI / Secure Boot no alineada.
- Hipervisor sense pegats o sense guidance aplicat.
Ordre correcte d’actuació en VMs
- Revisar l’hipervisor (pegats i recomanacions del fabricant).
- Revisar la compatibilitat de la VM: maquinari virtual, UEFI i Secure Boot.
- Pilot amb 1–2 VMs representatives per tipologia.
- Aplicar-ho al guest (updates i, si escau, workaround).
- Validar esdeveniments. Si hi ha Event ID 2 persistent, prioritzar la revisió de l’hipervisor/firmware virtual.
Inventari mínim recomanat
Amb aquest inventari pots segmentar ràpid, planificar onades i documentar evidències. És el mínim per no improvisar en producció i per poder auditar què s’ha tocat, quan i amb quin resultat.
| Camp | Exemple / valors | Per què importa |
|---|---|---|
| Tipus d’actiu | PC / Servidor físic / VM | Defineix el pla i el risc operatiu |
| Mode d’arrencada | BIOS/Legacy o UEFI | Determina si Secure Boot aplica |
| Secure Boot | Habilitat / Deshabilitat | Impacte directe del canvi |
| Fabricant/model | Dell/HP/Lenovo… | Dependència de firmware |
| Versió BIOS/UEFI | Versió exacta | Compatibilitat i escriptura a la NVRAM |
| Sistema operatiu | Windows 10/11, Server 2019/2022… | Flux d’updates i suport |
| BitLocker / xifrat | Sí/No + política | Pot afectar l’arrencada |
| Hipervisor (només VMs) | ESXi/Proxmox/Hyper-V + versió | Firmware i NVRAM virtual |
| Criticitat | Alta/mitjana/baixa | Ordre d’onades |
| Resultat del pilot | OK / Warning / Error | Decisió d’escalat |
| Evidències | Event ID 1/2 + notes | Traçabilitat i auditoria |
Checklist per tipus d’actiu
Aquest bloc està pensat perquè suport o sistemes el faci servir com a guia d’execució. Si el segueixes, redueixes la probabilitat d’incidències i evites aplicar canvis sense evidències.
Checklist PCs
- Confirmar UEFI + Secure Boot.
- Windows Update al dia.
- BIOS/UEFI en la versió recomanada pel fabricant.
- Si hi ha BitLocker: pla de suspensió/control abans del canvi.
- Pilot amb workaround si escau.
- Validació d’esdeveniments i reinici.
Checklist servidors físics
- Firmware de plataforma actualitzat (BIOS/UEFI + controladora si aplica).
- Finestra de manteniment aprovada.
- Rollback definit (backup, pla de reversió).
- Pilot per model/família.
- Validació de rols/serveis/clúster després del reinici.
Checklist VMs
- Hipervisor amb pegats i alineat amb les recomanacions del fabricant.
- Compatibilitat de la VM revisada (maquinari virtual, UEFI i Secure Boot).
- Pilot per tipologia de VM.
- Si hi ha Event ID 2 persistent, revisar hipervisor/firmware virtual abans d’insistir al guest.
Preguntes freqüents (FAQ)
Aquestes preguntes estan redactades perquè l’usuari empresarial entengui impacte, prioritats i com abordar-ho sense tecnicismes innecessaris. També es presten a marcatge de FAQ schema.
L’1 de juny de 2026 deixaran d’arrencar els meus equips?
No sol ser un “apagada” immediata. El risc típic és quedar en un estat de seguretat degradat o trobar problemes de compatibilitat futura si no s’actualitza la cadena de confiança de Secure Boot. Per això es recomana anticipar-se amb inventari, pilot i desplegament controlat.
Quins equips estan més exposats a incidències?
Els que combinen firmware antic, NVRAM limitada, configuracions de xifrat sensibles (com BitLocker) o entorns virtualitzats on el firmware/NVRAM depenen de l’hipervisor.
Si un equip està en BIOS/Legacy, he de fer alguna cosa?
Per a aquest tema concret, no aplica Secure Boot. Tot i això, BIOS/Legacy acostuma a ser deute tècnic per estandardització i hardening, i convé planificar la migració a UEFI quan sigui viable.
Per què en servidors és més delicat que en PCs?
Perquè el reinici i la validació impacten directament en la continuïtat de serveis. A més, en servidors el firmware del fabricant sol ser determinant i cal validar rols, emmagatzematge, xarxa i clúster després d’aplicar canvis.
Per què les VMs poden fallar encara que el sistema operatiu estigui actualitzat?
Perquè el firmware i la NVRAM poden estar limitats o controlats per l’hipervisor. Si el guest no pot escriure variables de Secure Boot, veuràs errors (per exemple, Event ID 2). En aquest cas, la correcció sol estar “a sota”: pegats de l’hipervisor, compatibilitat i firmware virtual.
He d’aplicar el workaround a tots els equips?
No com a primera opció. El raonable és fer-lo servir en pilot per validar el comportament i aplicar-lo només on sigui necessari. En la majoria d’entorns, el prioritari és mantenir el sistema operatiu i el firmware al dia i desplegar per onades.
Quines evidències convé guardar per a control intern?
Estat UEFI/Secure Boot per equip, data d’aplicació (pilot/onada), versió de BIOS/UEFI o hipervisor, i export/captura d’esdeveniments rellevants (especialment si hi va haver errors i remediació).
Passos següents
Si vols abordar aquest canvi sense improvisar, l’ideal és executar inventari, pilot i desplegament per onades amb evidències. Així redueixes el risc operatiu i evites incidències per firmware, xifrat o compatibilitat de virtualització.
Podem ajudar-te a definir el pla i executar-lo en PCs, servidors i VMs amb finestres de manteniment i control de canvis des del nostre servei de gestió de sistemes IT.
