Certificados Secure Boot en Windows 11: qué ha caducado en 2026 y cómo comprobar la actualización

Estado actual de los certificados Secure Boot en septiembre de 2026

A fecha de 24 de septiembre de 2026, la renovación de los certificados Secure Boot de Microsoft ya no es un acontecimiento futuro. Dos de los certificados emitidos en 2011 han caducado y el certificado utilizado para firmar el cargador de Windows alcanzará su fecha de vencimiento el 19 de octubre de 2026.

Esto no significa que todos los ordenadores afectados hayan dejado de arrancar. Microsoft explica que un dispositivo que conserve los certificados antiguos puede continuar iniciándose y recibiendo actualizaciones normales de Windows. El problema es más concreto: podría no aceptar nuevas protecciones para el entorno de arranque, como futuras versiones de Windows Boot Manager, cambios en las bases de datos de Secure Boot o revocaciones destinadas a bloquear componentes vulnerables. Puedes consultar la explicación y las fechas exactas en la tabla oficial de certificados Secure Boot de Microsoft.

Microsoft continúa distribuyendo los certificados 2023 mediante Windows Update con un despliegue gradual. Por eso, no basta con saber que Secure Boot está activado: también conviene comprobar si se han instalado los certificados requeridos y el nuevo Boot Manager firmado por Windows UEFI CA 2023.

Certificado de 2011	Fecha	Sustituto	Ubicación y función
Microsoft Corporation KEK CA 2011	Caducó el 24 de junio de 2026	Microsoft Corporation KEK 2K CA 2023	Se almacena en KEK y permite firmar cambios en DB y DBX.
Microsoft UEFI CA 2011	Caducó el 27 de junio de 2026	Microsoft UEFI CA 2023	Se almacena en DB y se utiliza para cargadores y aplicaciones EFI de terceros.
Microsoft UEFI CA 2011	Caducó el 27 de junio de 2026	Microsoft Option ROM UEFI CA 2023	Se almacena en DB y separa la confianza destinada a Option ROMs.
Microsoft Windows Production PCA 2011	Caduca el 19 de octubre de 2026	Windows UEFI CA 2023	Se almacena en DB y firma el cargador de Windows.

Es importante utilizar el nombre corregido Microsoft Corporation KEK 2K CA 2023. La denominación anterior, sin “2K”, apareció en documentación temprana y en algunos scripts, pero Microsoft la corrigió oficialmente. Buscar únicamente “Microsoft Corporation KEK CA 2023” puede producir un falso aviso de certificado ausente.

Qué es Secure Boot y para qué sirven sus certificados

Secure Boot o Arranque seguro es una función del firmware UEFI. Antes de entregar el control a Windows, el firmware comprueba las firmas digitales de los componentes que participan en el inicio. Si un componente no está firmado por una entidad de confianza o aparece en una lista de revocación, el firmware puede impedir su ejecución.

Esta protección intenta evitar que se cargue código no autorizado antes que el sistema operativo. Ese momento es especialmente delicado porque un componente malicioso ejecutado antes de Windows puede intentar ocultarse, alterar el cargador o interferir con las medidas de seguridad que se activan más tarde.

Secure Boot no sustituye al antivirus, a Microsoft Defender, al EDR ni a una configuración segura del sistema. Es una capa adicional dentro de un modelo de defensa en profundidad. Esta misma idea se desarrolla en la guía sobre seguridad activa informática: actualizar, comprobar y reducir la superficie de ataque resulta más eficaz que esperar a que ocurra un incidente.

PK, KEK, DB y DBX sin complicarlo demasiado

La cadena de confianza de Secure Boot utiliza varias variables almacenadas en el firmware:

• Platform Key o PK: representa la autoridad principal de la plataforma. Habitualmente está controlada por el fabricante del dispositivo.
• Key Enrollment Key o KEK: permite autorizar cambios en las bases de datos de firmas. Puede contener claves del fabricante y de Microsoft.
• Allowed Signature Database o DB: contiene certificados y firmas que el firmware puede considerar de confianza.
• Disallowed Signature Database o DBX: contiene firmas, certificados o identificadores revocados que ya no deben ejecutarse.

La renovación no consiste, por tanto, en reemplazar un único archivo dentro de Windows. El sistema operativo, el firmware UEFI y las claves autorizadas por el fabricante deben colaborar para actualizar las variables correspondientes sin romper la cadena de arranque.

Por qué se separan los cargadores de terceros y las Option ROM

La antigua Microsoft UEFI CA 2011 se utilizaba en más de un escenario. La transición introduce Microsoft UEFI CA 2023 para cargadores y aplicaciones EFI de terceros y Microsoft Option ROM UEFI CA 2023 para Option ROMs. Según la documentación de Microsoft, esta separación permite controlar con más precisión qué tipos de componentes reciben confianza.

Una Option ROM es código de firmware asociado a determinado hardware, como algunos adaptadores de red, controladoras de almacenamiento o tarjetas de expansión. No todos los equipos utilizan la misma combinación de componentes, de modo que el resultado exacto depende del fabricante, del modelo y de la configuración UEFI.

Qué ocurre si el equipo conserva los certificados de 2011

El escenario normal no es un apagón inmediato del ordenador. La explicación de Microsoft sobre los certificados caducados indica que el equipo puede seguir iniciándose, utilizar sus aplicaciones y recibir actualizaciones estándar de Windows.

Lo que queda comprometido es la capacidad de recibir determinadas protecciones futuras para la fase previa al sistema operativo. Entre ellas pueden encontrarse:

• Nuevas versiones protegidas de Windows Boot Manager.
• Actualizaciones de las bases DB y DBX de Secure Boot.
• Nuevas revocaciones contra cargadores vulnerables.
• Mitigaciones para vulnerabilidades descubiertas en la cadena de arranque.
• Actualizaciones de componentes de terceros que dependan de las nuevas autoridades de certificación.

El riesgo aumenta con el tiempo. Un equipo puede funcionar aparentemente bien y, aun así, quedar fuera de una futura corrección relacionada con el arranque. Esto es distinto de amenazas que se ejecutan una vez iniciado Windows, como las descritas en la guía sobre fileless malware y abuso de herramientas del sistema. Secure Boot se concentra en una etapa anterior: verificar la confianza de los componentes que arrancan antes o junto al sistema operativo.

Secure Boot activado no equivale a certificados actualizados

Un resultado positivo en msinfo32 o en Confirm-SecureBootUEFI confirma que Arranque seguro está habilitado. No demuestra por sí solo que el dispositivo tenga todos los certificados 2023 ni que ya utilice el Boot Manager firmado con Windows UEFI CA 2023.

Del mismo modo, encontrar un certificado concreto dentro de DB tampoco acredita que haya terminado toda la secuencia. La actualización completa incluye varias autoridades, la KEK correspondiente y el Boot Manager. Por esta razón, Microsoft utiliza señales de estado adicionales y considera el evento 1808 como confirmación de que el dispositivo está completamente actualizado.

Cómo está realizando Microsoft la actualización durante 2026

Microsoft está utilizando Windows Update para desplegar los nuevos certificados de forma gradual. La compañía no aplica todos los cambios a todos los modelos al mismo tiempo: utiliza señales de compatibilidad y grupos de dispositivos para reducir el riesgo de que un firmware defectuoso no procese correctamente una variable UEFI.

Las notas de las actualizaciones de Windows publicadas durante 2026 indican que Microsoft sigue ampliando la cobertura de dispositivos considerados de alta confianza. La documentación también señala que la distribución continuará mediante actualizaciones de Windows durante los meses posteriores a los primeros vencimientos.

Orden general del proceso

La guía vigente para profesionales de TI describe este orden general:

1. Windows UEFI CA 2023 se añade a la base DB.
2. Cuando corresponde, Microsoft Option ROM UEFI CA 2023 y Microsoft UEFI CA 2023 se añaden a DB.
3. Microsoft Corporation KEK 2K CA 2023 se incorpora a KEK.
4. Windows instala el Boot Manager firmado por Windows UEFI CA 2023.
5. Uno o más reinicios permiten que los cambios pendientes se apliquen de manera segura.

Los pasos son secuenciales. Si uno falla, Windows no debería presentar el proceso como finalizado. Microsoft indica que, después de seleccionar un dispositivo para la actualización, la secuencia puede necesitar alrededor de 48 horas y uno o más reinicios. No conviene interpretar una demora breve como un fallo definitivo.

Equipos domésticos y ordenadores no gestionados

En un PC personal compatible, la recomendación principal es mantener Windows Update activo, instalar las actualizaciones mensuales y reiniciar cuando se solicite. Microsoft intenta completar el proceso automáticamente en la mayoría de los dispositivos compatibles, aunque algunos modelos pueden requerir una actualización de firmware proporcionada por su fabricante.

Desde abril de 2026, la aplicación Seguridad de Windows puede mostrar el estado específico de los certificados en Seguridad del dispositivo > Secure Boot. Esta indicación es más útil para un usuario doméstico que intentar extraer y analizar manualmente certificados binarios del firmware.

Equipos gestionados y el matiz de los datos de diagnóstico

No es correcto resumir el proceso empresarial diciendo que toda ayuda automática de Microsoft exige enviar datos de diagnóstico. Microsoft distingue varias vías. La asistencia mediante Controlled Feature Rollout sí requiere los datos necesarios, pero la clasificación y asistencia para grupos de alta confianza es un mecanismo diferente. La propia guía fue corregida en enero de 2026 para aclarar que solo la asistencia CFR exige datos de diagnóstico.

Las organizaciones también pueden desplegar y supervisar los cambios mediante directivas de grupo, Microsoft Intune, Configuration Manager, scripts de PowerShell, claves documentadas y Windows Configuration System. El método debe elegirse según el tamaño de la flota, el nivel de control requerido y la diversidad del hardware.

Cómo comprobar los certificados Secure Boot en Windows 11

La comprobación debe realizarse por capas. Empieza por la interfaz de Seguridad de Windows y utiliza el registro o el Visor de eventos cuando necesites una validación técnica más detallada.

1. Consultar Seguridad de Windows

1. Abre el menú Inicio.
2. Busca Seguridad de Windows.
3. Entra en Seguridad del dispositivo.
4. Abre o revisa el apartado Secure Boot o Arranque seguro.

La documentación de la aplicación Seguridad de Windows describe varios estados:

• Completamente actualizado: se han aplicado los certificados requeridos y está instalado el Boot Manager actualizado. No hace falta realizar más cambios.
• Todavía no actualizado: el equipo utiliza una configuración de confianza antigua y se espera que Windows Update continúe el proceso.
• Actualización pausada: Microsoft ha detectado una condición de firmware o hardware y ha detenido temporalmente la instalación para ese grupo.
• Limitación del dispositivo: la actualización automática no está admitida por el hardware o firmware actual y se debe consultar al fabricante.
• Acción necesaria: el dispositivo ya no puede recibir una protección requerida para la experiencia de arranque con su configuración actual.

Un icono verde aislado no siempre confirma que los certificados estén actualizados. Microsoft recomienda leer también el texto mostrado en la sección y comprobar que indique expresamente que se han aplicado todas las actualizaciones necesarias.

2. Confirmar que Secure Boot está activado

Pulsa Win + R, escribe msinfo32 y revisa el campo Estado de arranque seguro. También puedes abrir PowerShell como administrador y ejecutar:

Confirm-SecureBootUEFI

El resultado True indica que Secure Boot está activado. False significa que está desactivado. Un error puede indicar que el equipo no utiliza UEFI compatible, que PowerShell no se ha abierto con privilegios suficientes o que la plataforma no expone la función esperada.

Esta comprobación solo valida la activación. Para profundizar en otras tareas administrativas de Windows, el registro y PowerShell, puedes consultar la guía de administración del sistema operativo en Windows y Linux.

3. Revisar UEFICA2023Status

Microsoft utiliza el valor UEFICA2023Status dentro de la siguiente ruta:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing

En PowerShell puedes consultarlo sin modificar el registro:

Get-ItemPropertyValue `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' `
  -Name 'UEFICA2023Status' `
  -ErrorAction SilentlyContinue

El valor Updated es una señal positiva utilizada por Microsoft para inventario y seguimiento. Sin embargo, no conviene usarlo como única prueba del estado completo. La confirmación más fuerte es el evento 1808 o el mensaje equivalente de Seguridad de Windows, porque incluyen el Boot Manager actualizado.

4. Buscar el evento 1808

Microsoft define el evento 1808 como un evento informativo que confirma que se han aplicado al firmware los certificados requeridos y que el Boot Manager se ha actualizado a la versión firmada por Windows UEFI CA 2023. La documentación afirma expresamente que este evento indica que el dispositivo está completamente actualizado.

Puedes buscarlo en el Visor de eventos, dentro de Registros de Windows > Sistema, o mediante PowerShell:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1808} `
  -MaxEvents 1 -ErrorAction SilentlyContinue | `
  Select-Object TimeCreated, Id, ProviderName, Message

Los detalles y significados oficiales están disponibles en la referencia de eventos de actualización de las variables DB, DBX y KEK.

Script PowerShell revisado para consultar señales oficiales

El siguiente script no intenta extraer certificados DER ni decide que el sistema está actualizado por encontrar solamente dos nombres. Consulta las señales que Microsoft utiliza actualmente: activación de Secure Boot, UEFICA2023Status y eventos relevantes. No cambia el registro, el firmware ni las claves UEFI.

$servicingPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing'

try {
    $secureBootEnabled = Confirm-SecureBootUEFI -ErrorAction Stop
} catch {
    $secureBootEnabled = $null
}

$uefiStatus = Get-ItemPropertyValue `
    -Path $servicingPath `
    -Name 'UEFICA2023Status' `
    -ErrorAction SilentlyContinue

$eventIds = 1795, 1800, 1801, 1802, 1803, 1808
$events = Get-WinEvent `
    -FilterHashtable @{ LogName = 'System'; Id = $eventIds } `
    -MaxEvents 30 `
    -ErrorAction SilentlyContinue

$latest1808 = $events | Where-Object Id -eq 1808 |
    Sort-Object TimeCreated -Descending | Select-Object -First 1

$latestProblem = $events | Where-Object Id -in 1795,1801,1802,1803 |
    Sort-Object TimeCreated -Descending | Select-Object -First 1

$result = [PSCustomObject]@{
    ComputerName        = $env:COMPUTERNAME
    SecureBootEnabled   = $secureBootEnabled
    UEFICA2023Status    = $uefiStatus
    FullyUpdatedEvent   = if ($latest1808) { $latest1808.TimeCreated } else { $null }
    LatestProblemEvent  = if ($latestProblem) { $latestProblem.Id } else { $null }
    ProblemEventTime    = if ($latestProblem) { $latestProblem.TimeCreated } else { $null }
}

$result | Format-List

if ($latest1808) {
    Write-Host 'CONFIRMADO: existe un evento 1808. Microsoft considera el dispositivo completamente actualizado.' -ForegroundColor Green
} elseif ($uefiStatus -eq 'Updated') {
    Write-Warning 'UEFICA2023Status figura como Updated, pero no se ha encontrado un evento 1808. Revisa Seguridad de Windows y los eventos recientes.'
} else {
    Write-Warning 'No hay confirmación completa. Instala actualizaciones, reinicia y consulta Seguridad de Windows o la guía del fabricante.'
}

La ausencia de un evento 1808 en la consulta no demuestra automáticamente que el equipo sea incompatible. El registro puede haberse limpiado, el despliegue puede estar en curso o la versión instalada puede mostrar el estado por otra vía. Contrasta siempre el resultado con Seguridad de Windows y la documentación del fabricante.

Qué significan los principales eventos

• 1795: el firmware devolvió un error al intentar actualizar DB, DBX o KEK. Microsoft recomienda consultar al fabricante por una actualización de firmware.
• 1800: hace falta reiniciar antes de instalar un cambio pendiente de Secure Boot.
• 1801: los certificados y el Boot Manager todavía no se han aplicado completamente al firmware.
• 1802: la actualización se ha bloqueado de forma intencionada por una condición conocida de hardware o firmware.
• 1803: Windows no ha encontrado para ese dispositivo una KEK firmada correctamente por la Platform Key.
• 1808: los certificados necesarios y el Boot Manager firmado con Windows UEFI CA 2023 están aplicados; el dispositivo se considera completamente actualizado.

Qué hacer si el equipo todavía no está actualizado

Instalar Windows Update y reiniciar

Empieza por Configuración, Windows Update y Buscar actualizaciones. Instala las actualizaciones acumulativas disponibles y reinicia aunque Windows no muestre un error visible. Parte del proceso se ejecuta mediante tareas programadas y puede necesitar varios ciclos de reinicio.

No descargues paquetes de certificados desde webs de terceros ni ejecutes scripts que escriban directamente en DB, DBX o KEK sin una guía específica para tu modelo. Un error en las variables de Secure Boot puede impedir el arranque o provocar solicitudes de recuperación de BitLocker.

Actualizar BIOS o UEFI desde el fabricante

Consulta la página de soporte del fabricante usando el modelo exacto, el número de producto o el identificador de servicio. Algunos dispositivos necesitan firmware actualizado para procesar correctamente las nuevas claves. Microsoft mantiene además un listado de páginas de fabricantes relacionadas con Secure Boot.

Antes de actualizar el firmware:

• Conecta el portátil a la corriente.
• Guarda el trabajo y cierra las aplicaciones.
• Comprueba que la actualización corresponde exactamente al modelo.
• Conserva accesible la clave de recuperación de BitLocker si la unidad está cifrada.
• No interrumpas el equipo durante la escritura del firmware.

No desactivar Secure Boot como solución permanente

Desactivar Secure Boot evita su función de comprobación y no renueva los certificados. Microsoft desaconseja utilizarlo como forma de eludir el vencimiento porque reduce la protección contra código malicioso ejecutado durante el arranque.

No restablezcas las claves del firmware, no borres PK, KEK, DB o DBX y no cambies entre modos Standard y Custom siguiendo un tutorial genérico. Esas operaciones dependen del fabricante y pueden eliminar claves necesarias. Si el estado indica una limitación de firmware, utiliza la documentación del OEM o abre una incidencia de soporte.

Plan recomendado para empresas y centros educativos

En una flota gestionada no es suficiente con comprobar dos portátiles y desplegar el cambio a todos los equipos. Microsoft recomienda inventariar fabricantes, modelos, versiones de BIOS, placas base, estado de BitLocker y señales de Secure Boot; después, probar grupos representativos antes de ampliar la implantación.

1. Inventario: identifica qué dispositivos tienen Secure Boot activado, su firmware y el valor UEFICA2023Status.
2. Línea base: recoge eventos 1801, 1808, 1795, 1802 y 1803 antes de intervenir.
3. Piloto: selecciona varios equipos de cada combinación representativa de fabricante, modelo y firmware.
4. Copias y recuperación: verifica que las claves de recuperación de BitLocker estén almacenadas correctamente.
5. Despliegue por anillos: amplía progresivamente solo después de comprobar reinicios, eventos y funcionamiento.
6. Remediación: separa los dispositivos bloqueados, sin KEK firmada o con firmware antiguo.
7. Confirmación: utiliza el evento 1808 y el estado de Seguridad de Windows, no solo la presencia aislada de certificados.

Para imágenes doradas, VDI, máquinas virtuales y medios personalizados hay que comprobar tanto la imagen como la plataforma virtual. El firmware virtual debe admitir la actualización de variables Secure Boot. En una infraestructura Hyper-V, Azure, VMware u otra plataforma, consulta también la guía específica del proveedor.

Si necesitas ensayar herramientas o configuraciones sin alterar directamente el sistema principal, la guía para usar Windows Sandbox de forma segura explica las posibilidades y límites de un entorno desechable. No obstante, Windows Sandbox no reproduce el firmware UEFI físico del anfitrión y no sirve para validar la actualización real de sus claves Secure Boot.

Windows 10, arranque dual y dispositivos antiguos

Windows 10 necesita una edición con mantenimiento aplicable

El soporte general de Windows 10 versión 22H2 terminó el 14 de octubre de 2025. Los equipos acogidos al programa ESU y determinadas ediciones LTSC mantienen calendarios diferentes. Por tanto, no debe afirmarse de forma genérica que cualquier instalación de Windows 10 continúa en soporte. La posibilidad de recibir estas correcciones depende de la edición, el canal y su situación de mantenimiento.

Arranque dual y cargadores de terceros

La transición también afecta a escenarios que utilizan cargadores EFI de terceros porque Microsoft UEFI CA 2023 sustituye a la autoridad de 2011 utilizada para ese tipo de confianza. Eso no significa que todo sistema con arranque dual vaya a fallar, pero sí aconseja mantener actualizado tanto Windows como la distribución, el cargador y el firmware.

No elimines certificados antiguos ni añadas revocaciones manuales solo para acelerar el proceso. Comprueba primero que todos los sistemas instalados pueden arrancar con sus componentes actuales y sigue las instrucciones de Microsoft, del fabricante y de la distribución utilizada.

Equipos sin soporte del fabricante

Un ordenador antiguo puede seguir funcionando, pero su firmware podría no admitir correctamente la actualización automática o no disponer de una KEK firmada por el fabricante. Los eventos 1802 y 1803 ayudan a distinguir estas situaciones. Si el OEM ya no mantiene el modelo, puede no existir una solución automática compatible.

En ese caso, documenta la excepción, evalúa la importancia del equipo y considera su sustitución si necesita mantener protección completa para el arranque. Instalar certificados manualmente sin soporte no es una recomendación general segura.

Checklist para un PC con Windows 11

• Instala todas las actualizaciones acumulativas disponibles.
• Reinicia el equipo y vuelve a buscar actualizaciones.
• Comprueba en Seguridad de Windows el texto específico del estado de Secure Boot.
• Confirma con msinfo32 o Confirm-SecureBootUEFI que Arranque seguro está activado.
• Consulta UEFICA2023Status como señal adicional.
• Busca el evento 1808 para confirmar certificados y Boot Manager actualizados.
• Si aparecen los eventos 1795, 1802 o 1803, revisa el soporte del fabricante.
• Mantén disponible la clave de recuperación de BitLocker antes de actualizar el firmware.
• No borres ni sustituyas manualmente las claves UEFI siguiendo instrucciones genéricas.
• No desactives Secure Boot para ocultar el aviso.

Preguntas frecuentes sobre los certificados Secure Boot de Windows 11

¿Mi ordenador deja de arrancar cuando caduca un certificado?

No de forma automática. Microsoft indica que los dispositivos que conservan los certificados antiguos pueden seguir iniciándose y recibiendo actualizaciones estándar. La limitación afecta a nuevas protecciones y actualizaciones relacionadas con el entorno de arranque.

¿Secure Boot en estado “Activado” significa que ya estoy actualizado?

No. Solo demuestra que la función está habilitada. Para confirmar la transición completa, busca el mensaje correspondiente en Seguridad de Windows o el evento 1808.

¿Qué certificado KEK debo buscar?

El nombre actualizado es Microsoft Corporation KEK 2K CA 2023. La variante sin “2K” está desactualizada.

¿UEFICA2023Status igual a Updated es suficiente?

Es una señal positiva, pero no debería utilizarse aisladamente para afirmar que todo el proceso ha terminado. El evento 1808 confirma además que el Boot Manager firmado por Windows UEFI CA 2023 está instalado.

¿Puedo forzar la actualización desde PowerShell?

Las organizaciones disponen de métodos documentados, pero un usuario doméstico no debería escribir directamente en las variables UEFI con un script encontrado en Internet. La ruta segura es Windows Update, los reinicios, el firmware oficial y la guía específica del fabricante.

¿Los Copilot+ PC están exentos?

No debe darse por hecho. El estado depende de los certificados, el firmware y el Boot Manager presentes en cada modelo. Algunos equipos recientes pueden venir preparados de fábrica, pero deben verificarse igual mediante Seguridad de Windows, los eventos y la documentación del OEM.

¿Cuándo termina todo el proceso?

No existe una única fecha de despliegue válida para todos los modelos. Dos certificados caducaron en junio de 2026 y Microsoft continúa distribuyendo los reemplazos de forma gradual. El siguiente hito es el 19 de octubre de 2026, fecha de caducidad de Microsoft Windows Production PCA 2011.

Conclusión

Los certificados Secure Boot Windows 11 ya se encuentran en una transición activa y parcialmente posterior a los primeros vencimientos. Microsoft Corporation KEK CA 2011 caducó el 24 de junio de 2026 y Microsoft UEFI CA 2011 lo hizo el 27 de junio. Microsoft Windows Production PCA 2011 caducará el 19 de octubre de 2026.

Para un usuario doméstico, el proceso razonable es mantener Windows Update al día, reiniciar, revisar Seguridad de Windows y actualizar el firmware únicamente desde el fabricante. Para confirmar técnicamente la finalización, el evento 1808 es una señal más completa que un script que se limite a buscar dos certificados.

En empresas, la prioridad debe ser inventariar, probar por modelos, desplegar en anillos y supervisar UEFICA2023Status junto con los eventos oficiales. Secure Boot activado es el punto de partida; disponer de los certificados 2023 y del Boot Manager actualizado es lo que permite mantener la cadena de arranque preparada para futuras protecciones.