Koniec wsparcia systemu lub urządzenia.
Co zrobić, zanim stary sprzęt stanie się problemem bezpieczeństwa?

"Jeszcze działa" to jeden z najbardziej zdradliwych argumentów w utrzymaniu infrastruktury IT.

Problem polega na tym, że sprawność techniczna i wsparcie bezpieczeństwa to dwie różne rzeczy. System może działać idealnie i jednocześnie:

Temat jest szczególnie aktualny jesienią 2026 roku

Trzy daty z cyklu życia produktów Microsoft dobrze pokazują, jak to wygląda w praktyce:

To dobry przykład, dlaczego lifecycle nie powinien być sprawdzany dopiero wtedy, gdy producent przestaje wydawać aktualizacje. Do tego momentu migracja powinna być już projektem w toku.

EOL, EOS i ESU. Nie przywiązuj się za bardzo do skrótów

Producenci używają nazw cyklu życia trochę inaczej. Można spotkać między innymi:

Dlatego zamiast tworzyć proces oparty wyłącznie na jednej kolumnie:

EOL: 2027-01-12

lepiej przechowywać konkretnie:

Wtedy wiadomo, co właściwie kończy się konkretnego dnia.

ESU kupuje czas, nie rozwiązuje problemu

Extended Security Updates mogą być bardzo sensownym rozwiązaniem. Pozwalają kupić czas potrzebny na:

Nie należy jednak mylić ich z pełnym przedłużeniem standardowego życia produktu. Microsoft wprost zaznacza, że ESU koncentruje się na określonych aktualizacjach bezpieczeństwa i nie przedłuża normalnego lifecycle produktu ani nie zapewnia wszystkich standardowych usług wsparcia.

Co właściwie może zostać bez wsparcia?

Problem nie dotyczy wyłącznie Windows.

Czasami głównym problemem nie jest nawet sam system operacyjny. Może nim być aplikacja albo urządzenie:

To właśnie takie zależności trzeba znaleźć odpowiednio wcześnie.

Koniec wsparcia jednego elementu może dotyczyć całej usługi

Dlatego nie wystarczy lista komputerów. Potrzebna jest przynajmniej podstawowa mapa zależności. Jak ją zbudować od podstaw, opisujemy w artykule dokumentacja IT od zera.

Pierwszy krok: inwentaryzacja

Nie potrzebujesz od razu rozbudowanego CMDB. Dla każdego ważnego zasobu powinieneś znać przynajmniej:

Jeśli przejmujesz środowisko po poprzednim administratorze, ta lista jest jednym z pierwszych kroków, o których piszemy w artykule audyt IT przed przejęciem obsługi.

Bardzo ważny jest owner

IT może utrzymywać system. Ale ktoś musi również zdecydować, czy aplikację można wymienić, kiedy wolno zatrzymać produkcję i jaki budżet jest dostępny.

Nieznana data wsparcia też jest problemem

Jeżeli nie wiemy, czy urządzenie nadal jest wspierane, nie wpisywałbym od razu "EOL". Lepiej:

Lifecycle: UNKNOWN
Priorytet: weryfikacja

Drugi krok: oceń ryzyko

Nie każdy stary system przedstawia takie samo ryzyko. Windows 7 z dostępem RDP z Internetu to zupełnie inna sytuacja niż komputer sterujący urządzeniem pomiarowym bez routingu do sieci firmowej. Najważniejsze czynniki można zebrać w prostą listę pytań:

Nie potrzebujesz skomplikowanego wzoru matematycznego. Potrzebujesz świadomej odpowiedzi na pytanie:

Trzy możliwe drogi

Po ocenie ryzyka każdy niewspierany albo kończący wsparcie zasób powinien dostać decyzję.

Droga A: wymiana albo upgrade

To domyślny kierunek dla systemów, których ryzyko jest istotne. Szczególnie gdy dotyczą:

Nie zawsze można wymienić system następnego dnia. Ale powinien istnieć projekt:

Droga B: czasowa izolacja i kontrole kompensacyjne

Czasem wymiana jest chwilowo niemożliwa. Klasyczny przykład:

Wtedy izolacja ma sens. Ale musi być prawdziwa.

Sam VLAN nie wystarczy

VLAN rozdziela domeny L2. Nie oznacza automatycznie, że host w jednym VLAN-ie nie może komunikować się z drugim. Jeżeli router albo firewall pozwala na EOL VLAN -> ANY, mamy osobny broadcast domain. Nie mamy skutecznej izolacji bezpieczeństwa. Potrzebujemy kontroli ruchu:

Zakres oczywiście zależy od potrzeb aplikacji. Zasada jest prosta:

Żeby wiedzieć, jaki ruch faktycznie generuje stary system, trzeba go widzieć. Więcej o tym w artykule monitoring sieci w firmie.

Jump host zamiast szerokiego dostępu

Jeżeli stary system wymaga administracji, porównaj dwa modele:

Dodatkowo dostęp przez jump host można logować, ograniczyć do konkretnych administratorów i zamykać poza oknem serwisowym.

Izolacja musi mieć datę końcową

Największa pułapka wygląda tak:

Dlatego wyjątek powinien mieć:

Droga C: świadoma akceptacja ryzyka

Czasami wymiana nie ma ekonomicznego sensu. Przykład:

Organizacja może zdecydować: "Akceptujemy ryzyko do następnego przeglądu." To jest prawidłowa decyzja. Pod warunkiem, że jest:

Najgorsza forma akceptacji ryzyka wygląda tak: nikt niczego nie zdecydował.

Kontrole kompensacyjne nie przywracają wsparcia

To bardzo ważne. Jeżeli system nie dostaje aktualizacji, to:

nie sprawiają magicznie, że znów stał się wspierany. One tylko zmniejszają określone ryzyka. Dlatego w dokumentacji warto używać określenia "kontrole kompensacyjne", a nie "problem rozwiązany". Dlaczego sam EDR czy antywirus nie zastępuje innych warstw, piszemy w artykule antywirus nie wystarczy.

Backup starego systemu

Legacy często ma jeszcze jeden problem: nikt nie pamięta, jak go odtworzyć. Przykład:

Backup VM może być poprawny. Ale po restore okazuje się, że:

Dlatego przed migracją warto sprawdzić nie tylko:

Jak to sprawdzić w praktyce, opisujemy w artykule test odtwarzania backupu.

Backup konfiguracji urządzeń

Przed wymianą firewalla, switcha, routera, kontrolera WiFi czy appliance warto zachować konfigurację. Nie po to, żeby koniecznie przywrócić ją 1:1. Po to, żeby wiedzieć:

Zepsuty firewall można wymienić. Odtwarzanie jego konfiguracji z pamięci administratora jest znacznie mniej przyjemne.

Lifecycle powinien być monitorowany przed EOS

Nie warto czekać do ostatniego miesiąca. Dobry orientacyjny kalendarz może wyglądać tak:

To nie musi być dokładnie 18/12/6/3 dla każdego urządzenia. Firewall można wymienić w kilka tygodni. Migracja starego ERP może zająć rok. Najważniejsze, żeby organizacja zaczęła odpowiednio wcześnie.

Windows 10 i ESU pokazują, dlaczego potrzebujemy dwóch dat

Windows 10 22H2 osiągnął standardowy koniec wsparcia 14 października 2025. Organizacje korzystające z kwalifikujących się edycji mogą jednak wykupić ESU maksymalnie na trzy lata, do 2028 roku. Dlatego w CMDB nie wystarczy:

Windows 10
EOS: 2025-10-14

Standard support: ended
ESU: enabled
Current ESU coverage: valid
Final migration deadline: 2028-10-10
Migration ticket: IT-2026

Oczywiście faktyczny status zależy od posiadanej edycji i licencji.

Windows Server 2012/R2: bardzo aktualny przykład

Na początku października 2026 administrator posiadający Windows Server 2012 lub 2012 R2 objęty ESU powinien już mieć końcowy plan migracji. Trzeci rok ESU kończy się 13 października 2026. To już nie jest "kiedyś trzeba będzie zmigrować". To jest:

Każdy z nich powinien trafić na jedną z trzech dróg opisanych wyżej, zanim ESU wygaśnie.

Windows Server 2016: następna data jest blisko

Windows Server 2016 nadal znajduje się w rozszerzonym okresie wsparcia, ale Microsoft wskazuje jego zakończenie na 12 stycznia 2027. Jeżeli w firmie działa kilkanaście takich maszyn, październik 2026 nie jest zbyt wczesnym momentem na ich inwentaryzację. Jest raczej ostatnim wygodnym momentem na spokojny plan.

Prosty rejestr wyjątków

Nie potrzeba specjalnego systemu. Na początek wystarczy tabela:

Automatyczne wykrywanie systemów zbliżających się do EOS

Dla Linuxa można przygotować prostą kontrolę bazującą na własnej, zweryfikowanej tabeli lifecycle. Przykładowy plik eos.tsv:

debian-12	2028-06-10
ubuntu-22.04	2027-04-01

Przykładowy skrypt:

#!/usr/bin/env bash
set -euo pipefail

MAP="${1:-./eos.tsv}"
WARN_DAYS="${WARN_DAYS:-180}"

. /etc/os-release

HOST="${HOSTNAME:-$(hostname -s)}"
KEY="${ID}-${VERSION_ID}"

if [[ ! -f "$MAP" ]]; then
    echo "UNKNOWN host=$HOST system=$KEY reason=missing_map"
    exit 3
fi

EOS="$(awk -F '\t' -v key="$KEY" '$1 == key { print $2; exit }' "$MAP")"

if [[ -z "$EOS" ]]; then
    echo "UNKNOWN host=$HOST system=$KEY reason=no_lifecycle_entry"
    exit 3
fi

TODAY_EPOCH="$(date -d "$(date +%F)" +%s)"
EOS_EPOCH="$(date -d "$EOS" +%s)"

DAYS_LEFT=$(( (EOS_EPOCH - TODAY_EPOCH) / 86400 ))

if (( DAYS_LEFT < 0 )); then
    echo "EOS_PAST host=$HOST system=$KEY eos=$EOS days=${DAYS_LEFT}"
    exit 2
fi

if (( DAYS_LEFT <= WARN_DAYS )); then
    echo "EOS_SOON host=$HOST system=$KEY eos=$EOS days_left=$DAYS_LEFT"
    exit 1
fi

echo "OK host=$HOST system=$KEY eos=$EOS days_left=$DAYS_LEFT"
exit 0

Dzięki temu monitoring może rozróżnić cztery stany:

UNKNOWN nie oznacza "system na pewno jest niewspierany". Oznacza, że administrator nie potrafi obecnie udowodnić, jaki jest jego status. I właśnie dlatego powinien powstać ticket.

Tabela lifecycle również wymaga ownera

Statyczny eos.tsv może sam stać się problemem, jeżeli nikt go nie aktualizuje. Dlatego warto przechowywać go w Git i dla każdej zmiany mieć źródło, datę weryfikacji i review. W większej infrastrukturze można wykorzystać API producentów, RMM albo narzędzia asset management. Ale niezależnie od technologii potrzebny jest proces aktualizacji danych.

To dobre zadanie dla automatyzacji, także z pomocą AI, pod warunkiem że model nie wymyśla dat, tylko wskazuje rozbieżności ze źródłem.

NIS2 a niewspierane systemy

NIS2 nie zawiera prostego nakazu "nie wolno używać systemów po EOS". Dyrektywa wymaga jednak od podmiotów objętych jej zakresem odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem. Artykuł 21 obejmuje między innymi analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw oraz zarządzanie podatnościami.

Jeżeli więc organizacja świadomie utrzymuje niewspierany system, powinna przynajmniej potrafić odpowiedzieć:

To znacznie lepsza pozycja niż: "Nie wiedzieliśmy, że producent zakończył wsparcie dwa lata temu."

OT i stare systemy wymagają innego podejścia

W środowiskach OT nie zawsze można powiedzieć "zaktualizuj jutro". Zmiana może wymagać:

• › certyfikacji producenta,
• › testu z maszyną,
• › postoju produkcji,
• › wymiany całego sterownika.

Czasem bezpieczeństwo operacyjne i dostępność procesu mają większe znaczenie niż natychmiastowa aktualizacja. Wtedy szczególnie ważne stają się:

Prawdziwy air-gap jest trudniejszy, niż się wydaje

Brak routingu do Internetu jest dobrym początkiem. Ale system może nadal otrzymywać dane przez:

Dlatego air-gap jest modelem kontroli przepływu danych, a nie tylko brakiem default gateway. Jeżeli system jest naprawdę krytyczny, również nośniki wymienne i sprzęt serwisowy powinny mieć określoną procedurę.

Najczęstszy błąd

Najczęściej nie widzę problemu w samym fakcie istnienia legacy. Problemem jest brak świadomości, że legacy istnieje. Typowy scenariusz wygląda tak:

Dopiero incydent uruchamia pytanie: "Co to w ogóle jest?". Dobry lifecycle management powinien odpowiedzieć na to pytanie kilka lat wcześniej.

Comiesięczna checklista i lifecycle

Cykl życia sprzętu i oprogramowania warto połączyć z normalnym miesięcznym przeglądem infrastruktury. Nie oznacza to ręcznego przeglądania stron każdego producenta co miesiąc. Raport powinien automatycznie wskazywać:

Administrator analizuje wyjątki. Nie liczy dat ręcznie.

Co zrobić ze starym sprzętem po migracji?

Wyłączenie produkcji nie kończy tematu. Przed utylizacją albo odłożeniem urządzenia warto sprawdzić:

Inaczej po dwóch latach ktoś znajdzie serwer w szafie i zapyta: "Możemy go włączyć? Chyba był ważny."

Jak podchodzimy do lifecycle w PRO-Admin?

Następnie można zdecydować:

Najgorszą opcją jest brak decyzji.

FAQ - koniec wsparcia systemów i urządzeń

Podsumowanie

Koniec wsparcia nie jest awarią. Jest terminem. I właśnie dlatego można się do niego przygotować. Dobry proces wygląda tak:

Największym problemem nie jest system, który ma 10 lat. Największym problemem jest system, o którym nikt nie wie:

Stary system może czasami pozostać w firmie jeszcze przez jakiś czas. Ale powinien pozostawać tam z decyzji. Nie przez zapomnienie.