En la época de Windows XP (2001), Microsoft endureció el sistema de firma digital de controladores que ya existía desde Windows 2000. La idea era garantizar que los drivers provinieran de un editor verificado, reduciendo inestabilidades causadas por código de terceros no auditado. Para que un controlador fuera aceptado sin advertencias, debía poseer un certificado digital compatible con Microsoft.
En realidad, la firma garantiza autenticidad (quién publicó el driver), no estabilidad absoluta. Un driver firmado puede tener bugs igual que uno no firmado. Lo que sí reduce es el riesgo de instalar malware disfrazado de driver.
Si intentabas instalar un driver sin firma en Windows XP, el sistema mostraba una advertencia y, en algunos casos, un indicador en el Administrador de dispositivos. Sin embargo, el artículo original confundía este comportamiento con el icono de «quitar hardware con seguridad», que aparece por dispositivos USB y extraíbles, no por drivers no firmados.
En Windows XP: deshabilitar la advertencia
Para evitar el mensaje en Windows XP, el procedimiento era:
Haz clic con el botón derecho en Mi PC y elige Propiedades.
Ve a la pestaña Hardware y haz clic en Firma de controladores.
En la pregunta ¿Qué acción desea que realice Windows?, selecciona Ninguna: instalar el software sin pedir mi aprobación.
De esta manera, Windows XP instalaba drivers no firmados sin mostrar advertencias.
En Windows 11/10: la firma es obligatoria
En Windows 10 y Windows 11, la situación cambió radicalmente. Microsoft exige certificados WHQL (Windows Hardware Quality Labs) o EV (Extended Validation) para la mayoría de drivers. Si Secure Boot está activado en la UEFI, un driver no firmado simplemente no carga; no es solo una advertencia que se puede ignorar.
Si necesitas instalar un driver no firmado para pruebas o desarrollo, tienes dos opciones principales:
Opción 1: modo de prueba de controladores
Abre Símbolo del sistema como administrador y ejecuta:
bcdedit /set testsigning onReinicia el equipo. En este modo, Windows acepta drivers no firmados, pero muestra una marca de agua en el escritorio indicando que está en modo de prueba. Para desactivarlo:
bcdedit /set testsigning offOpción 2: deshabilitar la firma en el arranque avanzado
Ve a Inicio > Configuración > Actualización y seguridad > Recuperación y, en Inicio avanzado, haz clic en Reiniciar ahora.
Elige Solucionar problemas > Opciones avanzadas > Configuración de inicio > Reiniciar.
Al reiniciar, presiona 7 o F7 para seleccionar Deshabilitar el uso obligatorio de controladores con firma.
Este método es temporal: al siguiente reinicio normal, la firma vuelve a estar activa.
En macOS: Gatekeeper y extensiones del kernel
En macOS, el equivalente a los drivers de Windows son las extensiones del kernel (KEXT, Kernel Extensions) y, desde macOS Catalina (10.15), los System Extensions y DriverKit. Apple implementó un sistema de firma mucho más restrictivo que el de Windows.
Gatekeeper bloquea por defecto la ejecución de software no firmado o no notarizado por Apple. Para los drivers, Apple exige que las KEXT estén firmadas con un certificado de desarrollador de Apple y, además, notarizadas. Desde macOS Big Sur (11.0), las KEXT tradicionales están en desuso y Apple promueve DriverKit, que funciona en espacio de usuario en lugar del kernel, mejorando la estabilidad del sistema.
Si necesitas cargar una KEXT no firmada en macOS, debes desactivar System Integrity Protection (SIP) desde el modo de recuperación:
- Reinicia en modo recuperación manteniendo pulsado Cmd + R.
- Abre Terminal desde el menú de utilidades.
- Ejecuta
csrutil disable. - Reinicia.
Además, debes permitir explícitamente la extensión en Preferencias del Sistema > Seguridad y privacidad > General tras un intento de carga bloqueado. Apple desaconseja esta práctica y la considera solo para desarrollo avanzado.
En Linux: controladores firmados y DKMS
En Linux, el kernel no exige firma digital de controladores por defecto en la mayoría de distribuciones. Sin embargo, si tienes Secure Boot activado, los módulos del kernel (equivalente a los drivers de Windows) deben estar firmados con una clave confiable o el sistema rechazará su carga.
Herramientas como DKMS (Dynamic Kernel Module Support) permiten recompilar y firmar automáticamente los módulos de terceros (como NVIDIA o VirtualBox) para que funcionen con Secure Boot. En distribuciones como Ubuntu, el proceso de firma se gestiona tras la instalación del paquete correspondiente.
Para firmar manualmente un módulo con Secure Boot activo, puedes usar MOK (Machine Owner Key):
sudo mokutil --import MOK.derEsto registra tu clave personal en la UEFI, permitiendo cargar módulos firmados por ti.
En Android: Verified Boot y drivers del kernel
En Android, los drivers no son instalables por el usuario de forma directa como en Windows o Linux. El sistema operativo está basado en el kernel de Linux, pero la arquitectura es distinta: los drivers vienen integrados en la imagen del sistema o en módulos del kernel compilados por el fabricante.
Google implementó Verified Boot (arranque verificado) desde Android 4.4, endurecido con dm-verity en versiones posteriores. Este mecanismo verifica la integridad de las particiones del sistema en cada arranque mediante firmas criptográficas. Si un driver del kernel o una partición del sistema ha sido modificada sin la firma correcta, el dispositivo entra en un estado de advertencia o no arranca.
En dispositivos con bootloader bloqueado (el estado por defecto), no es posible cargar drivers del kernel no firmados. Para instalar un kernel o drivers modificados (por ejemplo, en ROMs personalizadas como LineageOS), es necesario:
- Desbloquear el bootloader (proceso que borra los datos del dispositivo).
- Desactivar Verified Boot o firmar la imagen del sistema con tus propias claves.
- Flashear la imagen del kernel firmada o con verificación desactivada.
Algunos fabricantes como Google (Pixel) y OnePlus permiten desbloquear el bootloader oficialmente. Otros, como Samsung en modelos recientes con Knox, invalidan permanentemente la garantía del hardware al desbloquear el bootloader, marcando el contador eFuse.
Listado comparativo
Firma de controladores
- En Windows XP: advertencia configurable; se podía desactivar desde Propiedades del sistema > Hardware
- En Windows 10/11: obligatoria con Secure Boot; drivers no firmados no cargan
- En macOS: KEXT firmadas y notarizadas por Apple; DriverKit en espacio de usuario desde Big Sur
- En Linux: no obligatoria por defecto; con Secure Boot activo, requiere firma de módulos del kernel
- En Android: drivers integrados en imagen del sistema; Verified Boot rechaza modificaciones no firmadas
Deshabilitar la firma
- En Windows XP: opción permanente en panel de control
- En Windows 10/11: modo de prueba con
bcdedito arranque avanzado temporal - En macOS: desactivar SIP desde recuperación y permitir en Seguridad y privacidad
- En Linux: gestión mediante MOK o desactivar Secure Boot
- En Android: desbloquear bootloader y desactivar Verified Boot (borra datos)
Certificados requeridos
- En Windows XP: cualquier certificado digital válido
- En Windows 10/11: WHQL o EV obligatorios para distribución pública
- En macOS: certificado de desarrollador de Apple + notarización
- En Linux: firma propia o de la distribución; no hay autoridad central obligatoria
- En Android: firma del fabricante o del ROM builder; Google exige firma para Play Store
Conclusión
Aunque en Windows XP era posible (y relativamente común) instalar drivers no firmados silenciando una advertencia, en Windows 11 la firma digital de controladores es un requisito de seguridad estructural, especialmente con Secure Boot activado. macOS fue aún más allá, desplazando los drivers del kernel al espacio de usuario con DriverKit y exigiendo notarización.
Linux mantiene mayor flexibilidad, aunque Secure Boot impone las mismas restricciones si está habilitado. Android, por su arquitectura cerrada, integra los drivers en el sistema y rechaza modificaciones mediante Verified Boot. En todas las plataformas modernas, el mensaje es el mismo: los drivers no firmados son técnicamente posibles de instalar, pero requieren reducir deliberadamente las protecciones de seguridad del sistema.