{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://atlas.maintz.dev/)"},"id":"cs/secure-boot","url":{"en":"https://atlas.maintz.dev/en/terms/cs/secure-boot/","da":"https://atlas.maintz.dev/da/terms/cs/secure-boot/"},"term":{"en":"Secure boot","da":"Sikker opstart (secure boot)"},"aka":{"en":["UEFI Secure Boot"],"da":["UEFI Secure Boot"]},"domain":["cs","security"],"cluster":"os","layer":"os","status":"current","era":2012,"summary":{"en":"A start-up check that lets a computer run only boot software and a kernel carrying a trusted digital signature.","da":"Et tjek ved opstart, der kun lader en computer køre opstartssoftware og en kerne med en betroet digital signatur."},"body":{"formal":{"en":"A chain of checks at start-up. The machine's built-in start-up software checks the digital signature of each start-up program and add-on driver against keys stored in the machine, and the signed start-up program then checks the kernel; any failed check stops the start.","da":"En kæde af tjek ved opstart. Maskinens indbyggede opstartssoftware tjekker den digitale signatur på hvert opstartsprogram og hver tilføjet driver mod nøgler gemt i maskinen, og det signerede opstartsprogram tjekker derefter kernen; et fejlet tjek stopper opstarten."},"plain":{"en":"Like a guard at the factory gate who checks every driver's badge before the working day starts, so nobody can slip in while the lights are still off.","da":"Som en vagt ved fabriksporten, der tjekker hver chaufførs adgangskort, før arbejdsdagen går i gang, så ingen kan snige sig ind, mens lyset endnu er slukket."},"inPractice":{"en":"A municipality gets laptops back from an outside repair shop. One refuses to start and shows a secure boot warning because its start-up program has been swapped, so IT takes it out of use and investigates.","da":"En kommune får bærbare retur fra et eksternt reparationsværksted. Én af dem nægter at starte og viser en secure boot-advarsel, fordi opstartsprogrammet er blevet udskiftet, så IT tager den ud af drift og undersøger den."},"whyItMatters":{"en":"Malware that loads before the operating system can hide from every protection that starts later, so the only safe place to stop it is at the very first step.","da":"Malware, der indlæses før styresystemet, kan gemme sig for al beskyttelse, der starter senere, så det eneste sikre sted at stoppe den er ved allerførste trin."}},"deepDive":{"en":"UEFI Secure Boot was introduced in UEFI 2.3.1 (Errata C, 2011) and became mainstream with Windows 8 certification in 2012. Its policy lives in authenticated UEFI variables: the Platform Key (PK), normally owned by the OEM, authorises updates to the Key Exchange Key database (KEK); KEK entries authorise updates to the signature database db (allowed certificates and hashes) and the forbidden database dbx (revoked certificates and hashes). Before executing any UEFI image, including boot loaders, drivers and option ROMs on add-in cards, the firmware verifies its Authenticode signature against db and checks that neither the image hash nor the signer appears in dbx. The chain then continues in software: Windows Boot Manager verifies winload and the kernel, while Linux distributions use a small shim signed by Microsoft's third-party UEFI CA, which embeds the distribution's own key and verifies GRUB and the kernel, with MOK (Machine Owner Key) letting administrators enrol their own keys.\n\nSecure Boot only enforces \"signed by a trusted key\"; it does not record what ran. Measured boot is the complement: each stage hashes the next into TPM Platform Configuration Registers (PCRs 0-7 for firmware and boot configuration), producing a log that can be attested remotely or used to seal disk-encryption keys, as BitLocker and systemd-cryptenroll do. Neither mechanism protects against compromise of the firmware itself, which is the domain of NIST SP 800-193 platform firmware resiliency and hardware roots of trust such as Intel Boot Guard.\n\nThe weak point is revocation. A signed but vulnerable boot component can be replayed forever unless its hash or certificate is added to dbx, and dbx has limited storage. BootHole (CVE-2020-10713) in GRUB2 and the BlackLotus bootkit, which exploited CVE-2022-21894 in Windows Boot Manager and was the first publicly known malware bypassing Secure Boot on fully patched Windows 11 (2023), required mass dbx updates and, for BlackLotus, a staged Microsoft mitigation under CVE-2023-24932. PKfail (2024) showed that hundreds of device models shipped with a test Platform Key whose private key had leaked, making Secure Boot on them bypassable.\n\nKey expiry is the current operational issue. Microsoft's original 2011 certificates run out during 2026: the Microsoft Corporation KEK CA 2011 and the Microsoft UEFI CA 2011 expired in June 2026, and the Windows Production PCA 2011 that signs the Windows boot manager expires on 19 October 2026. Devices must receive the 2023 replacement certificates in KEK and db (through Windows updates or OEM firmware) to keep receiving boot-component and dbx updates. Secure Boot can also be disabled or put into setup mode in firmware settings by anyone with physical access unless a firmware password is set, and it does nothing against attacks that start after the kernel has loaded. It should not be confused with Trusted Boot or with signed kernel modules, which extend verification later into the OS.","da":"UEFI Secure Boot blev indført i UEFI 2.3.1 (Errata C, 2011) og blev udbredt med certificeringskravene til Windows 8 i 2012. Politikken ligger i autentificerede UEFI-variabler: Platform Key (PK), normalt ejet af producenten, godkender opdateringer af Key Exchange Key-databasen (KEK); KEK-poster godkender opdateringer af signaturdatabasen db (tilladte certifikater og hashes) og forbudsdatabasen dbx (tilbagekaldte certifikater og hashes). Før firmwaren udfører et UEFI-image, herunder bootloadere, drivere og option ROM'er på udvidelseskort, verificerer den Authenticode-signaturen mod db og tjekker, at hverken imagets hash eller underskriveren står i dbx. Kæden fortsætter derefter i software: Windows Boot Manager verificerer winload og kernen, mens Linux-distributioner bruger en lille shim signeret af Microsofts tredjeparts-UEFI-CA, som indeholder distributionens egen nøgle og verificerer GRUB og kernen, og MOK (Machine Owner Key) lader administratorer indrullere egne nøgler.\n\nSecure Boot håndhæver kun \"signeret med en betroet nøgle\"; den registrerer ikke, hvad der blev kørt. Measured boot er komplementet: hvert trin hasher det næste ind i TPM'ens Platform Configuration Registers (PCR 0-7 for firmware og opstartskonfiguration), så der dannes en log, der kan attesteres over netværket eller bruges til at forsegle diskkrypteringsnøgler, som BitLocker og systemd-cryptenroll gør. Ingen af mekanismerne beskytter mod kompromittering af selve firmwaren; det hører under NIST SP 800-193 om robust platformsfirmware og hardwarebaserede tillidsankre som Intel Boot Guard.\n\nDet svage punkt er tilbagekaldelse. En signeret, men sårbar opstartskomponent kan genbruges for evigt, medmindre dens hash eller certifikat lægges i dbx, og dbx har begrænset plads. BootHole (CVE-2020-10713) i GRUB2 og BlackLotus-bootkittet, der udnyttede CVE-2022-21894 i Windows Boot Manager og i 2023 var den første offentligt kendte malware, der omgik Secure Boot på fuldt opdaterede Windows 11-maskiner, krævede massive dbx-opdateringer og for BlackLotus' vedkommende en trinvis afbødning fra Microsoft under CVE-2023-24932. PKfail (2024) viste, at hundredvis af enhedsmodeller var leveret med en test-Platform Key, hvis private nøgle var lækket, så Secure Boot på dem kunne omgås.\n\nUdløb af nøgler er det aktuelle driftsproblem. Microsofts oprindelige certifikater fra 2011 løber ud i løbet af 2026: Microsoft Corporation KEK CA 2011 og Microsoft UEFI CA 2011 udløb i juni 2026, og Windows Production PCA 2011, der signerer Windows' boot manager, udløber den 19. oktober 2026. Enhederne skal have 2023-afløserne lagt i KEK og db (via Windows-opdateringer eller firmware fra producenten) for fortsat at kunne modtage opdateringer af opstartskomponenter og dbx. Secure Boot kan desuden slås fra eller sættes i setup mode i firmwareindstillingerne af enhver med fysisk adgang, medmindre der er sat en firmwareadgangskode, og den gør intet mod angreb, der begynder, efter at kernen er indlæst. Den må ikke forveksles med Trusted Boot eller signerede kernemoduler, som fører verifikationen videre ind i styresystemet."},"howTo":{"steps":{"en":["Check the Secure Boot state on every PC and server, for example with msinfo32 or Confirm-SecureBootUEFI on Windows, mokutil --sb-state on Linux, or the device health report in your device management tool.","Switch machines that still boot in legacy BIOS or CSM mode to native UEFI, converting the disk with mbr2gpt first where needed, and then turn Secure Boot on in the firmware settings.","Set a firmware administrator password so nobody with physical access can turn Secure Boot off or put the machine into setup mode.","Make Secure Boot and UEFI firmware a requirement when you buy new PCs, servers and appliances, and ask vendors how they update the boot keys and firmware.","On Linux systems with your own kernel modules or drivers, sign them with a Machine Owner Key enrolled through MOK, instead of turning Secure Boot off to make them load.","Keep the firmware, the revocation list (dbx) and the boot certificates up to date through Windows updates or vendor firmware, including the move from Microsoft's 2011 certificates to the 2023 ones, and confirm the result in your reports.","Combine Secure Boot with a TPM, measured boot and disk encryption such as BitLocker, and use device health attestation in conditional access, so a device that fails the checks loses access.","Investigate every Secure Boot violation or device that suddenly reports it as off, and treat it as a possible bootkit until you know otherwise."],"da":["Tjek Secure Boot-status på alle pc'er og servere, fx med msinfo32 eller Confirm-SecureBootUEFI på Windows, mokutil --sb-state på Linux eller enhedsrapporten i jeres værktøj til enhedsstyring.","Skift maskiner, der stadig starter i legacy BIOS- eller CSM-tilstand, til ren UEFI, konvertér først disken med mbr2gpt, hvor det er nødvendigt, og slå derefter Secure Boot til i firmwareindstillingerne.","Sæt en administratoradgangskode på firmwaren, så ingen med fysisk adgang kan slå Secure Boot fra eller sætte maskinen i setup-tilstand.","Gør Secure Boot og UEFI-firmware til et krav, når I køber nye pc'er, servere og appliances, og spørg leverandørerne, hvordan de opdaterer boot-nøgler og firmware.","På Linux-systemer med egne kernemoduler eller drivere skal de signeres med en Machine Owner Key, der er tilmeldt via MOK, i stedet for at slå Secure Boot fra for at få dem til at indlæse.","Hold firmware, spærrelisten (dbx) og boot-certifikaterne opdateret via Windows-opdateringer eller leverandørens firmware, herunder skiftet fra Microsofts 2011-certifikater til 2023-certifikaterne, og bekræft resultatet i jeres rapporter.","Kombinér Secure Boot med TPM, measured boot og diskkryptering som BitLocker, og brug attestering af enhedens tilstand i betinget adgang, så en enhed, der fejler kontrollerne, mister adgangen.","Undersøg alle Secure Boot-overtrædelser og enheder, der pludselig melder den slået fra, og behandl dem som en mulig bootkit, indtil I ved bedre."]},"pitfalls":{"en":["Turning Secure Boot off to get an unsigned driver or Linux module working and never turning it back on.","Assuming Secure Boot is fine because it is enabled, while the dbx revocation list and boot certificates have not been updated for years.","Leaving the firmware settings without a password, so anyone at the keyboard can disable Secure Boot in a minute."],"da":["At slå Secure Boot fra for at få en usigneret driver eller et Linux-modul til at virke og aldrig slå det til igen.","At gå ud fra, at Secure Boot er i orden, fordi det er slået til, mens spærrelisten dbx og boot-certifikaterne ikke er opdateret i årevis.","At lade firmwareindstillingerne være uden adgangskode, så alle ved tastaturet kan slå Secure Boot fra på et minut."]},"guides":[{"title":"Windows Secure Boot certificate expiration and CA updates","url":"https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e","publisher":"Microsoft","tier":"official-doc"},{"title":"Secure boot","url":"https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot","publisher":"Microsoft","tier":"official-doc"},{"title":"NIST SP 800-147 - BIOS Protection Guidelines","url":"https://csrc.nist.gov/pubs/sp/800/147/final","publisher":"NIST","tier":"standard"},{"title":"SecureBoot - Debian Wiki","url":"https://wiki.debian.org/SecureBoot","publisher":"Debian","tier":"official-doc"}]},"edges":[{"type":"requires","to":"cs/digital-signature","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/kernel","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/operating-system","confidence":"high","strength":"normal"},{"type":"implements","to":"security/integrity","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/malware","why":{"en":"Hidden malware that plants itself in the start-up code is refused, because its changes break the signature check.","da":"Skjult malware, der planter sig i opstartskoden, afvises, fordi dens ændringer får signaturtjekket til at fejle."},"confidence":"high","strength":"primary"}],"depth":3,"sources":[{"title":"UEFI Specification - Secure Boot and Driver Signing","url":"https://uefi.org/specifications","tier":"standard","publisher":"UEFI Forum"},{"title":"Secure boot (Windows hardware documentation)","url":"https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-secure-boot","tier":"official-doc","publisher":"Microsoft"},{"title":"NIST SP 800-193 - Platform Firmware Resiliency Guidelines","url":"https://csrc.nist.gov/pubs/sp/800/193/final","tier":"standard","publisher":"NIST"},{"title":"Windows Secure Boot certificate expiration and CA updates","url":"https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e","tier":"official-doc","publisher":"Microsoft"}],"draft":true}