‘Secure Boot Violation’: causas, soluciones y guía UEFI paso a paso

Última actualización: 25/09/2025
Autor: Isaac
  • Secure Boot bloquea cargadores sin firma válida o no reconocida por la UEFI.
  • Windows 7 no es compatible; reinstalaciones y dual boot pueden causar desajustes.
  • Desactivar es un alivio temporal; la solución real pasa por firmar o usar claves correctas.
  • Si falla la verificación tras todo, restaura claves de fábrica y contacta al fabricante.

error Secure Boot Violation

Si te has topado con el aviso de arranque ‘Secure Boot Violation’ y el equipo no pasa de esa pantalla, tranquilo: no estás solo. Este mensaje aparece antes de que cargue el sistema operativo y suele estar relacionado con cómo la BIOS/UEFI verifica las firmas digitales de los cargadores de arranque.

En muchos ordenadores, especialmente en marcas como ASUS, la verificación de arranque seguro de Microsoft viene activa por defecto para protegerte frente a malware y bootkits. El problema surge cuando las ‘claves’ o firmas que la UEFI espera no coinciden con las del cargador que intenta iniciar tu Windows o tu Linux, lo que dispara el bloqueo de seguridad.

Qué es Secure Boot y por qué aparece este mensaje

Secure Boot es una función de UEFI diseñada para permitir únicamente el arranque de software que esté firmado por entidades de confianza (Microsoft, fabricantes o el propio usuario, según el caso). Durante el encendido, la UEFI compara la firma del cargador con una base de datos de claves autorizadas; si detecta algo fuera de lo esperado, se interrumpe el proceso y aparece la violación de arranque seguro.

Hay escenarios típicos que lo provocan. Por ejemplo, en equipos con Windows 8.1, 10 u 11, si reinstalas el sistema, cambias de edición o instalas un SO diferente al preinstalado, pueden quedar desalineadas las claves del cargador (bootloader) respecto a las que la UEFI tiene registradas. Eso basta para que la verificación falle y no te deje continuar.

Otro caso clásico afecta a Windows 7: este sistema no es compatible con Secure Boot. Tras determinadas actualizaciones como la KB3133977, se han dado fallos de arranque porque la UEFI espera una firma que Windows 7 no puede proporcionar, de modo que la comprobación se invalida.

Si vienes de un entorno Linux o dual boot, el choque es incluso más probable. Instalaciones con GRUB, kernels personalizados o cargadores sin firmar pueden disparar el bloqueo, especialmente al reactivar el arranque seguro tras haberlo desactivado para instalar.

Síntomas y mensajes habituales

El aviso más común es ‘Secure Boot Violation’. En muchos equipos verás un subtítulo del estilo: ‘Invalid signature detected. Check Secure Boot Policy in Setup’. En resumen, la UEFI te está diciendo que la firma del cargador que intenta ejecutar no cuadra con su política de arranque seguro y que debes revisar la configuración en el firmware.

En ocasiones aparece sin más datos; en otras, se acompaña de instrucciones genéricas para entrar en la BIOS/UEFI o te obliga a reiniciar. Si al desactivar Secure Boot el equipo arranca con normalidad tanto en Windows como en Linux, la causa se confirma: es un problema de firmas o de políticas de verificación, no de hardware.

Cómo acceder a la BIOS/UEFI para cambiar la configuración

En ordenadores ASUS (y muchos otros), puedes entrar a la configuración del firmware con una combinación muy concreta. Con el equipo apagado, mantén pulsada la tecla F2 (o Supr) y, sin soltarla, pulsa el botón de encendido. No sueltes la tecla hasta ver la pantalla de la BIOS/UEFI.

Una vez dentro, puedes moverte por los menús con las flechas y la tecla Intro, o bien usando el panel táctil o el ratón si tu UEFI lo permite. Localiza los apartados relacionados con Boot (Arranque) o Security (Seguridad), que es donde suelen vivir los ajustes de Secure Boot.

Para guardar cambios, la vía rápida suele ser pulsar F10 y aceptar. Al confirmar el guardado, el equipo se reiniciará y aplicará los cambios. Si pruebas un ajuste y no te convence, siempre podrás volver y deshacerlo del mismo modo.

Cambiar ajustes de Secure Boot: método 1 (pestaña Boot)

En muchos equipos ASUS, una forma directa de desactivar la verificación consiste en cambiar el tipo de sistema operativo. Entra en la pestaña Boot (Arranque) y busca la opción Secure Boot. Dentro de esa sección debería aparecer un parámetro similar a ‘Tipo de sistema operativo’.

  Cómo crear una jaula chroot en WSL2 paso a paso

Selecciona dicho parámetro y, en lugar de la opción que alude a Windows en modo UEFI, elige ‘Otro sistema operativo’. Ese cambio desactiva efectivamente el arranque seguro y permite que el equipo continúe con cargadores no firmados o con firmas no reconocidas por la base de datos de la UEFI.

Conviene que tengas presente una nota importante: si estableces el modo Windows UEFI, estarás activando de nuevo Secure Boot. Ese modo exige que el cargador esté firmado por una autoridad reconocida por la UEFI (típicamente Microsoft y las claves del fabricante), así que si tu sistema no encaja, la violación reaparecerá.

Cuando termines el cambio, guarda con F10, confirma y deja que el equipo reinicie. Si el sistema vuelve a arrancar con normalidad, has aislado el problema en la capa de verificación. Podrás operar con el arranque seguro desactivado o planificar su reactivación adecuada más adelante.

Cambiar ajustes de Secure Boot: método 2 (pestaña Seguridad)

Otro camino frecuente está en la pestaña Seguridad. Navega hasta Security y localiza ‘Secure Boot’. Dentro de ese menú busca ‘Secure Boot Control’ (o ‘Security Boot Menu’, según la traducción) y cámbialo a Deshabilitado.

La nomenclatura puede variar según modelo y versión de firmware, pero la idea es la misma: conmutar el control de arranque seguro a ‘Disabled’ para que la UEFI no bloquee el cargador. Una vez aplicado, usa F10 para guardar y aceptar; el equipo se reiniciará para aplicar la nueva política.

Si estás en un equipo que no es ASUS, la ruta puede cambiar ligeramente. En placas base de distintos fabricantes, ‘Secure Boot’ puede estar en Settings, Boot, Security o Authentication. Lo importante es localizar el conmutador de control y la base de claves del arranque seguro.

Recuerda que siempre puedes revertir el ajuste y reactivar Secure Boot cuando tengas listos cargadores firmados o una configuración compatible. Desactivar temporalmente ayuda a recuperar el acceso, pero la protección extra de Secure Boot es recomendable una vez todo está en orden.

El caso típico de dual boot con Windows y Arch Linux

Un ejemplo real: tras seguir un tutorial para instalar Arch Linux junto a Windows y haber desactivado el arranque seguro durante la instalación, al volver a activarlo apareció un aviso del tipo ‘Secure Boot Violation: firma no válida; revisa la política en la configuración’. En este escenario, ambos sistemas arrancan bien si Secure Boot está apagado, pero con él encendido se bloquea el proceso.

Esto ocurre porque, salvo que se configure lo contrario, GRUB, el kernel de Linux o la cadena de arranque no llevan firma aceptada por la UEFI. En placas como una Gigabyte B650M, al reactivar Secure Boot la firma del cargador de Linux no verifica con las claves de la base de datos y salta la violación.

¿Qué puedes hacer si quieres mantener Secure Boot activo en un dual boot? En el mundo Linux tienes dos vías principales: usar la cadena ‘shim’ firmada por la CA de terceros de Microsoft (cuando tu distro la ofrece), o firmar tú mismo el cargador y el kernel e inscribir tu clave (MOK/KEK) en la UEFI.

En distribuciones que soportan ‘shim’ (por ejemplo, muchas basadas en Debian/Ubuntu y Fedora), basta con instalar los paquetes shim y grub firmados, y asegurarte de que tu UEFI tiene habilitada la ‘Microsoft 3rd Party UEFI CA’. La primera vez, el sistema te pedirá enrolar la clave de propietario (MOK) al arrancar; aceptas, reinicia, y a partir de ahí la verificación debería pasar.

En Arch Linux, donde a menudo se deja al usuario configurar este punto, puedes optar por firmar tus binarios con herramientas como sbctl o sbsigntools. El proceso consiste en generar tu par de claves, firmar el cargador (p. ej., GRUB o systemd-boot) y el kernel/EFI stub, e introducir tu clave pública en la UEFI (vía MOK Manager o directamente, según el método elegido). Tras hacerlo, Secure Boot podrá validar tu cadena de arranque.

  Tipos de Firewalls: Protege tu Red con las Mejores Soluciones de Seguridad

Si ya intentaste ‘restaurar las claves de fábrica’ en la UEFI y no funcionó, es señal de que no basta con devolver las bases PK/KEK/DB/DBX a origen; también necesitas que el cargador que pretendes usar esté firmado por alguna de esas claves de confianza, o que inscribas una nueva que legitime tu binario.

Particularidades por fabricante: ASUS y Gigabyte

En ASUS, además de las rutas comentadas, hay un matiz que conviene recordar: el ajuste ‘Windows UEFI’ equivale a tener Secure Boot activado, y ‘Otro sistema operativo’ a tenerlo desactivado. Si reinstalas Windows o cambias de edición, una discrepancia de claves puede impedir el arranque en modo seguro hasta que se alinee de nuevo.

En placas base Gigabyte (como una B650M), el menú de Secure Boot suele encontrarse en Settings o Security, con un submenú de verificación de firmas y la gestión de claves. Revisa que el modo esté en ‘Standard’ o ‘Custom’ según vayas a usar sólo las claves de fábrica o tus propias claves. Si vas a tirar de shim y firmas de terceros, habilita la ‘Microsoft 3rd Party UEFI CA’ si tu firmware lo expone.

Evita borrar la DBX (lista de binarios revocados), ya que sirve para bloquear cargadores vulnerables o comprometidos. Si necesitas limpiar, limítate a ‘Reset to factory keys’ para devolver PK/KEK/DB/DBX a su estado original, y vuelve a probar con un cargador firmado correctamente.

Gigabyte también permite desactivar el arranque seguro de forma global si sólo buscas recuperar el acceso mientras ajustas tu cadena de arranque. Desactívalo, inicia el sistema, prepara la firma del cargador y luego vuelve a activarlo para mantener la protección.

Cuándo desactivar Secure Boot, y riesgos de dejarlo apagado

Desactivar Secure Boot es una solución práctica para recuperar el arranque de inmediato o mientras configuras el dual boot. Sin embargo, perderás una capa relevante de seguridad a nivel de firmware, que mitiga ataques que se cargan antes del sistema operativo.

Si lo dejas apagado de forma permanente, considera reforzar otras capas: cifrado de disco, arranque con contraseña en la UEFI, y buenas prácticas de actualización. Cuando tengas tu cargador y kernel correctamente firmados, es recomendable volver a activarlo.

Para entornos corporativos o equipos expuestos, conviene mantener Secure Boot activo y utilizar cadenas de arranque firmadas por claves de confianza. Las distribuciones ‘enterprise’ suelen proporcionar todo lo necesario para que funcione con la CA de terceros de Microsoft.

En equipos domésticos, si sólo usas Windows y no has modificado el arranque, una reinstalación limpia de Windows en modo UEFI suele alinear las claves y resolver los errores de verificación, siempre que no haya cambios de firmware peculiares.

Si nada funciona: restaurar claves, revisar políticas y pedir ayuda

Si sigues viendo la violación con todo en orden, entra en la UEFI y busca la opción de ‘Reset to factory keys’ o similar para restablecer PK, KEK, DB y DBX. Tras la restauración, prueba con un cargador firmado y compatible; si funciona con Windows pero no con Linux, te faltará completar la cadena de firma en el lado de Linux.

Otra vía es revisar la política exacta que aplica tu firmware: algunos equipos separan el modo ‘Standard’ (sólo claves del fabricante) del ‘Custom’ (permite añadir las tuyas). Si pretendes usar tus propias firmas, activa el modo personalizado y añade tu MOK o tu certificado a la DB de firmas permitidas.

Cuando la situación apunte a un fallo del propio firmware (p. ej., bloqueos inesperados, opciones que se restablecen solas, o imposibilidad de guardar claves), contacta con el soporte del fabricante del equipo o de la placa base. En casos ASUS, su Centro de Atención al Cliente puede guiarte con pasos específicos de tu modelo.

Si sólo te interesan opciones de recuperación del sistema Windows (restaurar, recuperar o reparar), explora las funciones avanzadas de recuperación que ofrece Microsoft. Estas herramientas ayudan si el problema es del sistema operativo, aunque recuerda que la ‘Secure Boot Violation’ se origina en la etapa de firmware.

  Cómo reparar la base de datos de Outlook (.pst y .ost)

Buenas prácticas para evitar futuras ‘Secure Boot Violation’

Antes de reinstalar o cambiar de edición de Windows, confirma que lo harás en modo UEFI con partición GPT, y evita mezclar modos Legacy/CSM con UEFI. Cuanta más coherencia mantengas entre firmware y sistema, menos papeletas tendrás para toparte con firmas que no cuadran.

Si usas Linux, verifica si tu distribución ofrece paquetes ‘shim’ y cargadores firmados. En caso de kernels personalizados, planifica su firma y la inscripción de claves para que la UEFI pueda validarlos sin bloquear el arranque.

Actualiza la UEFI/BIOS a la última versión estable cuando el fabricante lo recomiende, ya que mejoras y correcciones de compatibilidad con Secure Boot son habituales. Eso sí, realiza la actualización con el equipo alimentado y siguiendo las instrucciones al pie de la letra.

Evita cambios bruscos en la base de claves si no es necesario. Limitarte a ‘reset a valores de fábrica’ es más seguro que borrar DBX o modificar PK/KEK sin un plan. Un error en estas bases puede dejarte con un firmware que rechaza casi todo, complicando la recuperación.

Notas específicas sobre Windows 7, Windows 8.1/10/11 y Secure Boot

Windows 7 no soporta Secure Boot; si lo instalas en equipos con la función activa, es normal que no pase la verificación. Ciertas actualizaciones, como KB3133977, han puesto de manifiesto esta incompatibilidad, resultando en fallos de arranque cuando la UEFI exige firmas válidas.

En Windows 8.1, 10 y 11 el soporte sí existe, pero hay matices: reinstalaciones, cambios de edición, o instalaciones distintas a la versión con la que venía el equipo pueden provocar discrepancias hasta que el cargador y las claves vuelvan a entrar en sintonía.

Si necesitas reparar el cargador de Windows, puedes usar su entorno de recuperación para reconstruir BCD o reinstalar el gestor de arranque. Hazlo siempre con Secure Boot en mente: si lo mantienes activo, procura usar medios oficiales y firmados para evitar nuevos bloqueos.

Cuando todo falle, reinstalar Windows en modo UEFI y dejar que el instalador configure de nuevo el cargador firmado suele funcionar. Después podrás añadir Linux con una cadena de arranque compatible, si ese es tu objetivo.

Si necesitas desactivar: vete a Boot o Security, busca ‘Secure Boot’ o ‘Secure Boot Control’ y ponlo en Deshabilitado, o cambia el ‘Tipo de sistema operativo’ a ‘Otro sistema operativo’. Guarda con F10 y prueba a arrancar.

Si necesitas activarlo: elige ‘Windows UEFI’ o activa ‘Secure Boot Control’ en Habilitado. Asegúrate de que tu cargador está firmado y de que la base de claves (DB) reconoce esa firma (ya sea de Microsoft, del fabricante o tuya).

Si usas Linux con shim: habilita la CA de terceros de Microsoft cuando exista la opción, e inscribe el MOK cuando lo solicite al primer arranque. Si firmas tus binarios, añade tu clave pública a la DB o mediante MOK Manager.

Si algo falla tras toquetear claves: restaura a valores de fábrica las PK/KEK/DB/DBX y vuelve a intentar con un cargador firmado oficial. Si persiste, el soporte del fabricante es tu siguiente aliado.

La famosa ‘Secure Boot Violation’ no tiene por qué convertirse en un callejón sin salida: conociendo qué comprueba la UEFI y cómo encajar las firmas correctas, puedes recuperar el arranque con seguridad y sin renunciar a la protección, tanto si usas sólo Windows como si convives con Linux en dual boot.

buscar archivos windows
Artículo relacionado:
Cómo escanear y reparar archivos fuera del arranque de Windows usando SFC y DISM: guía avanzada y solución de problemas