Microsoft Secure Boot 2026: undgå svag boot-sikkerhed

Hvis jeres pc’er og servere ikke får de nye Secure Boot-certifikater før 26. juni 2026, stopper de ikke med at boote. Til gengæld risikerer I at ende i en “degraded security state”, hvor maskinerne ikke kan modtage fremtidige beskyttelser mod bootkits. Det er typisk usynligt for brugerne – lige indtil den dag, I skal forklare en revision, hvorfor jeres “root of trust” ikke kan håndhæves.

• Undgå “degraded state”: Kortlæg hvilke enheder der stadig står på Microsoft UEFI CA 2011, og planlæg udrulning af UEFI CA 2023 via Windows Update/Intune.
• Knyt det til Windows 10 EOL: Enheder på Windows 10 uden ESU efter okt. 2025 får typisk ikke opdateringen – prioriter Win11/hardware-livscyklus nu.
• Del ansvaret rigtigt: Microsoft leverer OS/boot-opdateringer; OEM leverer BIOS/UEFI-opdateringer. I skal styre begge spor og dokumentere resultatet.
• Planlæg serverrummet: Fysiske Windows Servere er også ramt; lav change-vinduer og test på ikke-kritiske værter først.
• Ryd op i boot-medier: Gamle USB-recovery/ISO’er kan fejle på opdaterede maskiner – standardisér nye medier og test dem.

Hvad sker der 26. juni 2026, hvis I ikke opdaterer?

Microsofts udmelding er klar: Secure Boot-certifikater fra 2011 udløber 26. juni 2026. Enhederne “bricker” ikke, men kan havne i en tilstand med svækket boot-beskyttelse, fordi de ikke kan tage imod fremtidige Secure Boot-opdateringer, der skal blokere nye bootkits.

Det praktiske problem for en virksomhed er ikke, at medarbejdernes pc’er pludselig dør. Det er at I mister et centralt lag i “root of trust”, som Secure Boot er en del af, og dermed bliver det sværere at håndhæve og dokumentere boot-integritet (relevant for fx compliance og NIS2-krav om sårbarhedshåndtering).

Kilder: Microsofts Windows IT Pro Blog og playbook for certifikatudløb i 2026: Tech Community (2025/2026) og Secure Boot playbook.

Hvorfor Windows 10 EOL gør Microsoft Secure Boot 2026 til en budget-sag

Windows 10 går EOL i oktober 2025. Det betyder, at en del maskiner enten skal på ESU, opgraderes til Windows 11 eller udskiftes. SecurityWeek fremhæver, at Windows 10-enheder uden ESU efter EOL typisk ikke får Secure Boot-opdateringen. I praksis skaber det en dobbelt prioritering:

1. OS-sporet: Hvem kan komme på Windows 11 (krav til hardware/TPM), og hvem kan ikke?
2. Firmware-sporet: Hvilke OEM BIOS/UEFI-opdateringer mangler I, for at UEFI CA 2023 kan fungere korrekt?

Før → Efter (1):
Før: I holder liv i Windows 10-maskiner efter EOL og håber, at “det går nok”.
Efter: I segmenterer flåden i “Win11-klar”, “kræver BIOS/firmware” og “skal udfases” og får en plan, der kan godkendes af både IT og økonomi.

Sådan fordeler ansvaret sig: OEM BIOS vs. Microsoft-opdateringer

Secure Boot ligger i skæringspunktet mellem firmware og OS. Hvis I kun kører Windows Updates, men overser BIOS/UEFI, kan I ende med delvist opdaterede enheder.

• Microsoft: Leverer opdateringer i Windows, der udruller/aktiverer de nye certifikater og fremtidige revocations til beskyttelse mod bootkits.
• OEM (HP/Dell/Lenovo m.fl.): Leverer BIOS/UEFI-opdateringer, der kan indeholde nødvendige certifikater/firmware-ændringer. Flere OEM’er har pushet UEFI CA 2023 via BIOS-opdateringer siden 2024 (jf. community-observationer hos Framework).
• Jer (drift): Skal sikre governance: hvem er opdateret, hvem er undtaget, og hvad er risikobeslutningen – dokumenteret.

Tjekliste: sådan auditérer I Secure Boot-certifikater via Intune

Målet er at få et beslutningsklart overblik: Hvilke enheder kræver handling, og hvilken type handling? Brug Intune til at gøre det skalerbart og minimere brugerforstyrrelser (se også vores tilgang til drift og patch governance).

Trin	Hvad I gør (konkret)	Hvad I kigger efter	Beslutningsregel
1) Segmentér flåden	Udtræk enhedsliste fra Intune (OS-version, model, producent, compliance status).	Windows 10 vs. 11, alder på hardware, kritikalitet (VIP/produktion).	Hvis Windows 10 og ikke ESU-plan: sæt i “udfas/upgrade” nu.
2) Kortlæg firmware-status	Indsaml BIOS/UEFI-version pr. model (OEM-værktøjer/rapporter) og sammenhold med OEM’s anbefalede version.	Modeller med kendte BIOS-gaps.	Hvis BIOS er >12 mdr. bag OEM baseline: planlæg firmware-opdatering før cert-udrulning.
3) Sikr opdateringskanal	Verificér at Windows Update for Business/Intune policies ikke blokerer relevante sikkerhedsopdateringer.	Ringe/deferral der udskyder kritiske updates.	Hvis sikkerhedsopdateringer udsættes: reducer deferral for en pilot-gruppe.
4) Pilotér	Vælg 5–10% repræsentative enheder (forskellige modeller) + 1 ikke-kritisk server.	Genstart-adfærd, BitLocker-recovery prompts, boot-medier.	Hvis BitLocker kræver recovery: justér BIOS/TPM/BitLocker-policy før bred udrulning.
5) Udrul og mål	Rul ud i bølger via Intune. Mål fejlrate og undtagelser pr. model.	Fejl cluster pr. OEM-model.	Hvis en model har gentagne fejl: stop bølgen og eskalér til OEM firmware remediation.
6) Dokumentér	Gem rapport: segmenter, beslutninger, undtagelser, datoer, ansvarlig.	Audit-spor til NIS2/ISO-praksis.	Hvis I ikke kan dokumentere status pr. enhed: behandl som “ikke compliant”.

Før → Efter (2):
Før: Support opdaterer BIOS manuelt, når brugeren klager, og I har ingen samlet status.
Efter: I ruller firmware- og Secure Boot-relaterede ændringer ud i bølger, med måling pr. model og en tydelig undtagelsesliste til ledelsen.

Hvordan påvirker det Windows Server, Hyper-V og Azure?

Microsofts Windows Server-playbook gør det tydeligt: fysiske Windows Servere er også omfattet. Her er de praktiske tommelfingerregler:

• Fysiske servere: Planlæg change-vinduer. Test først på en ikke-kritisk host. Sørg for out-of-band adgang (iDRAC/iLO) ved firmware-ændringer.
• Virtuelle maskiner: Afhængigt af generation/opsætning kan påvirkningen være anderledes. Microsoft nævner, at Gen1 Hyper-V og Azure Local er undtaget i playbook-kontekst, men jeres sikkerhedsmodel kan stadig kræve opdatering af skabeloner og images.
• Azure: Fokusér på images og deployment pipelines: sikr at nye VM-images og recovery-processer bygger på opdaterede, understøttede versioner.

Kilde: Microsoft Windows Server Secure Boot playbook.

Fejl der koster tid: boot-medier og recovery-ISO’er, der ikke længere virker

En overset faldgrube er jeres egne værktøjer: USB-recovery-sticks, gamle WinPE-medier og ISO’er til fejlsøgning. Når Secure Boot-kæden ændres, kan ældre, signede bootloadere og custom-miljøer fejle på maskiner med de nye certifikater.

Gør det praktisk:

• Lav en “golden” recovery-USB pr. platform (Windows klient, Windows Server) og test boot på en pilot-maskine, der har fået opdateringen.
• Versionér jeres ISO’er og smid alt ud, der ikke længere er i brug.
• Hvis I har Linux i miljøet: standard-kernels booter typisk fortsat, men custom-signed kernels kan være sårbare for fejl (jf. Red Hat’s guidance).

FAQ om Microsoft Secure Boot 2026

Bricker pc’erne den 26. juni 2026?

Nej. Ifølge Microsoft booter enhederne typisk videre, men kan ende i en “degraded security state”, hvor de ikke kan få fremtidige Secure Boot-beskyttelser mod nye bootkits. Det er en sikkerheds- og compliance-risiko, ikke en øjeblikkelig driftsstop-garanti.

Hvad betyder “Secure Boot degraded state” for os i praksis?

Det betyder, at jeres boot-beskyttelse kan blive fastlåst på et niveau, der ikke kan opdateres mod nye trusler. Tommelfingerregel: hvis I ikke kan dokumentere, at jeres enheder kan modtage fremtidige Secure Boot-opdateringer, bør de behandles som “ikke compliant” i jeres risikostyring.

Hvordan hænger Windows 10 EOL og Secure Boot certifikat udløb sammen?

Windows 10 EOL (okt. 2025) afgør, om enheder fortsat får relevante sikkerhedsopdateringer. SecurityWeek peger på, at Windows 10 uden ESU efter EOL typisk ikke får Secure Boot-opdateringen. Beslutningsregel: Windows 10 uden ESU-plan = prioriter udskiftning/opgradering før I bruger tid på fine-tuning.

Kan vi auditere Secure Boot via Intune uden at forstyrre brugerne?

Ja. Start med segmentering (OS, model, kritikalitet) og kør pilot-udrulning i bølger. Forstyrrelsen kommer typisk fra genstarter og evt. BitLocker recovery-prompts. Reducér risikoen ved at pilotere på repræsentative modeller og have en klar recovery-proces.

Hvem har ansvaret: Microsoft eller OEM (HP/Dell/Lenovo)?

Begge har en del. Microsoft leverer Windows-opdateringerne, der håndterer Secure Boot-certifikat-skiftet, mens OEM leverer BIOS/UEFI-opdateringer, der kan være nødvendige på specifikke modeller. Jeres ansvar er at styre processen end-to-end og dokumentere status pr. enhed.

Gælder det også Windows Server og vores fysiske infrastruktur?

Ja, fysiske Windows Servere er omfattet. Planlæg change-vinduer, test på en ikke-kritisk server først, og sørg for out-of-band adgang ved firmware-ændringer. Brug Microsofts server-playbook som kravliste til jeres driftsplan.

Skal vi udskifte alle pc’er for at være klar?

Nej. Mange enheder produceret efter 2024 har typisk de nye certifikater pre-installeret, og andre kan opdateres via BIOS/UEFI + Windows-opdateringer. Beslutningsregel: hvis en enhed både er Windows 10 (uden ESU) og har manglende firmware-support, er udskiftning ofte den mest forudsigelige vej.

Sådan kommer I i mål de næste 30 dage

1. Lav en liste over alle Windows 10-enheder og beslut ESU vs. Windows 11 vs. udfasning.
2. Segmentér efter hardware-model (top 10 modeller dækker ofte størstedelen) og identificér BIOS/UEFI-gaps.
3. Byg en pilot-ring i Intune med repræsentative brugere og klare genstarts-vinduer.
4. Test jeres recovery-medier på en pilot-maskine efter opdatering, og standardisér én “golden” USB/ISO.
5. Planlæg server-changes (fysiske Windows Servere) med out-of-band adgang og rollback-plan.
6. Dokumentér beslutninger og undtagelser (hvad, hvem, hvornår, hvorfor) så det kan bruges i audit og ledelsesrapportering.

Hvis I vil samle Windows 10 EOL, hardware-livscyklus og Microsoft Secure Boot 2026 i én plan, kan vi hjælpe med prioritering, Intune-udrulning og driftsdokumentation på tværs af Microsoft 365, enheder og servere.