Secure Boot po 24 czerwca 2026, czyli co wygasa, kto musi aktualizować firmware i dlaczego Linux też ma tu problem
Secure Boot przez lata działał w tle i mało kto zaprzątał sobie nim głowę, dopóki system startował bez komunikatów i czarnego ekranu. Teraz ten spokój się kończy. Microsoft wymienia certyfikaty UEFI używane od 2011 roku, a sprawa dotyczy nie tylko Windows 10 i 11, ale też Linuksa, firmware płyt głównych, nośników recovery i firmowych obrazów PXE. Takie historie później wracają rykoszetem do użytkownika, gdy komputer działa, lecz słabiej chroni się przed atakami.
Secure Boot nie wyłączy komputerów z dnia na dzień, ale po wygaśnięciu starych certyfikatów wiele maszyn zostanie z ochroną „zamrożoną” w czasie. W Windows oznacza to problemy z firmware i BitLockerem, a w Linuksie także z przyszłymi wersjami shimów i starszymi nośnikami instalacyjnymi.
FIFA miała lukę w systemie transmisji MŚ 2026. Wystarczył login agenta, aby dobrać się do streamów i danych meczowych
Najważniejszą rzeczą jest to, że po 24 czerwca 2026 roku pecety nie zaczną masowo odmawiać startu. Wygasa jednak Microsoft Corporation KEK CA 2011, trzy dni później Microsoft UEFI CA 2011, a 19 października Microsoft Windows Production PCA 2011. Jeśli maszyna nie dostanie odpowiedników z 2023 roku, nadal uruchomi Windows i pobierze zwykłe aktualizacje systemu, ale wypadnie z obiegu przyszłych zmian na etapie rozruchu, czyli nowego Windows Boot Managera, aktualizacji baz DB i DBX czy blokad dla kolejnych podatności klasy bootkit. System pozostanie na starym poziomie zaufania, co po LogoFail jest już istotnym ograniczeniem. Dla użytkownika Windows scenariusz jest względnie prosty, bo Microsoft wypycha aktualizacje przez Windows Update, choć starsze maszyny mogą wymagać nowego firmware od producenta. Czasem dochodzi BitLocker, który potrafi wymusić ręczną interwencję.
75 tysięcy urządzeń Fortinet na celowniku. Jeden wyciek i robi się nerwowo od korporacji po wojsko
W Linuksie sytuacja jest bardziej złożona. Dystrybucja musi dostarczyć nowy shim (niewielki program pełniący funkcję pośrednika rozruchu, tzw. bootloadera, a sprzęt nadal potrzebuje certyfikatu z 2023 roku w firmware. Red Hat udostępnił już podwójnie podpisane shim-y dla RHEL 9 i 10, RHEL 8 miał otrzymać je w czerwcu 2026, ale starsze instalacje i część sprzętu mogą utknąć w przejściu. Jeśli później pojawi się luka w shimie, system bez odświeżonej bazy DB stanie przed wyborem, czy pozostać przy podatnym loaderze, czy wyłączyć Secure Boot. Temat Secure Boot wracał już przy okazji Windows 11 i problemów z firmware u producentów płyt głównych, więc obecna zmiana nie jest zaskoczeniem. Widać tu koszt utrzymania kompatybilności całego ekosystemu PC. Windows, Linux, OEM-y i dostawcy firmware muszą zsynchronizować kilka warstw naraz. W dłuższym horyzoncie oznacza to porządkowanie łańcucha zaufania, ale krótkoterminowo najbardziej ucierpią starsze komputery, nośniki ratunkowe i firmowe procedury działające od lat na zasadzie „bo zawsze działało”.
Powiązane publikacje

Żabka zhakowana. Dane udostępnione dwa dni po ogłoszeniu sprzedaży kanadyjskiemu właścicielowi Circle K. Zbieg okoliczności?
20
100 tysięcy dolarów i kilka bezczelnych promptów - tak Anthropic zmusiło swoją AI do przełomu w kryptografii
7
Google wprowadza logowanie selfie-wideo. Żywa twarz zamiast SMS-a przy odzyskiwaniu konta Google
33
AI oszukało zabezpieczenia i włamało się do infrastruktury Hugging Face. OpenAI przyznaje się do kompromitującego incydentu
43







![Secure Boot po 24 czerwca 2026, czyli co wygasa, kto musi aktualizować firmware i dlaczego Linux też ma tu problem [1]](/image/news/2026/06/18_secure_boot_po_24_czerwca_2026_czyli_co_wygasa_kto_musi_aktualizowac_firmware_i_dlaczego_linux_tez_ma_tu_problem_1.jpg)
![Secure Boot po 24 czerwca 2026, czyli co wygasa, kto musi aktualizować firmware i dlaczego Linux też ma tu problem [2]](/image/news/2026/06/18_secure_boot_po_24_czerwca_2026_czyli_co_wygasa_kto_musi_aktualizowac_firmware_i_dlaczego_linux_tez_ma_tu_problem_0.jpg)





