Zarządzanie cyklem życia certyfikatu ISO 15118 w 2026 r.: od pilności TLS do zgodności z CRA

TL;DR (Podsumowanie działań wykonawczych)

• Przełączenie na TLS stanowi twardą granicę (nie jest to sugestia): Z 24 lutego 2026 r., DigiCert będzie przestań akceptować publiczne żądania certyfikatu TLS z ważnością ponad 199 dni, a certyfikaty wydane od tej daty mają Maksymalna ważność 199 dni. Dla wielu operatorów jest to praktyczne rozwiązanie — prędkość odnawiania wzrasta natychmiast.
• Plan działania na okres 200→100→47 dni jest już określony: Podstawowe wymagania CA/Browser Forum określają stopniową redukcję: 200 dni od 15 marca 2026 r., 100 dni od 15 marca 2027 r., I 47 dni od 15 marca 2029 r..
• CRA dodaje zegar zgodności: Zasady raportowania CRA wymagają wczesne ostrzeżenie w ciągu 24 godzin, pełne powiadomienie w ciągu 72 godzini zdefiniowano ostateczne okna raportowania dla aktywnie wykorzystywanych luk i poważnych incydentów.
• Największym ukrytym ryzykiem nie jest wygaśnięcie: Tryb awarii systemowej to dryf kotwicy zaufania—zmiany korzeni/pośrednich/podpisywania krzyżowego nie są zsynchronizowane w EVSE, kontrolerach lokalnych i ścieżkach walidacji zaplecza.
• Pierwsza inwestycja w celu ochrony czasu sprawności: Automatyzacja oparta na systemie (ACME + inwentaryzacja + etapowe wdrażanie) plus ciągłość krawędzi (lokalna walidacja/buforowanie, rejestry dowodów i zarządzanie synchronizacją czasu).

Wprowadzenie: Rok 2026 przekształca Plug & Charge w system operacyjny

W roku 2026 funkcja Plug & Charge (P&C) przestaje być funkcją „ustaw i zapomnij”, a staje się ciągły system operacyjny.
Płaszczyzna zaufania ISO 15118 (PKI + TLS + unieważnienie + aktualizacje) jest obecnie regulowana harmonogramami, które nie tolerują ręcznych przepływów pracy.

Aby zrozumieć granicę systemu, czyli za co odpowiada norma ISO 15118, a za co OCPP, zacznij od lektury towarzyszącego artykułu:
ISO 15118 a rzeczywistość wdrożenia OCPP w 2026 r..

Natychmiastowa presja jest Kompresja cyklu życia TLSZ operacyjnego punktu widzenia nie można „czekać do marca”.
DigiCert będzie przestań akceptować publiczne żądania TLS przekraczające 199 dni startowy 24 lutego 2026 r.,
a certyfikaty wydawane od tego dnia będą miały Maksymalna ważność 199 dni.
DigiCert podkreśla również istotny szczegół operacyjny: maksymalna dopuszczalna ważność jest regulowana przez data emisji, a nie w momencie złożenia zamówienia.

Jednocześnie ustawa UE o odporności cybernetycznej (CRA) wprowadza drugi zegar: zasady sprawozdawczości wymagają
24-godzinne wczesne ostrzeganie I Powiadomienie 72-godzinne w celu ochrony przed aktywnie wykorzystywanymi lukami i poważnymi incydentami mającymi wpływ na produkty zawierające elementy cyfrowe.

W niniejszym przewodniku skupiono się na architekturze i kontroli ryzyka w kontekście obsługi certyfikatów ISO 15118 przy tych ograniczeniach.

Kamienie milowe i wymagane działania na lata 2024–2026 (tekstowy wykres Gantta)

Uwaga operacyjna: 24 lutego 2026 r. jest często faktyczną datą przejścia na nową walutę, ponieważ wtedy zmienia się sposób emisyjny głównych instytucji certyfikujących.

Uwaga dotycząca polityki: Stopniowe redukcje w całym okresie użytkowania są określone w Wymaganiach bazowych (200/100/47 dni).

Krajobraz cyklu życia: Zaopatrzenie → Eksploatacja → Odnowienie → Cofnięcie

Mapa cyklu życia (co musisz umieć obsługiwać)

1. Dostarczanie OEM: Klucze wygenerowane/wstrzyknięte; ustalono źródło zaufania (HSM/element bezpieczny).
2. Zapisy na umowę: Certyfikaty kontraktów powiązane z kontraktami użytkowników (zależne od ekosystemu).
3. Uruchomienie EVSE: Ustalono linie bazowe magazynu zaufania, zasady i linie bazowe synchronizacji czasu.
4. Walidacja operacyjna: Uzgadnianie protokołu TLS, budowanie łańcucha, sprawdzanie odwołań, egzekwowanie zasad.
5. Odnowienie / ponowne wydanie: Automatyzacja + etapowe wdrażanie + wycofywanie.
6. Odwołanie / reakcja na incydent: Naruszenie/błędne wydanie/wykorzystanie → odwołanie/obrót/odzyskanie.
7. Odzyskiwanie i pojednanie: Przywróć usługę, zachowując jednocześnie możliwość audytu i integralność rozliczeń.

Niedoceniany punkt awarii: dryf kotwicy zaufania

Większość „tajemniczych awarii P&C” w środowiskach z wieloma producentami OEM nie jest spowodowana pojedynczym wygasłym certyfikatem, lecz
błędy walidacji ścieżki spowodowane dryfem zaufania:

• Pojawiają się nowe korzenie/pośrednie (rzeczywistość wielokorzeniowa).
• Podpisywanie krzyżowe zmiany modyfikują wykonalne łańcuchy.
• Magazyny zaufania zaplecza aktualizują się szybciej niż kontrolery EVSE/lokalne.
• Artefakty odwołania stają się nieaktualne na krawędzi.

Traktuj aktualizacje kotwic zaufania jako proces zmian o znaczeniu krytycznym dla bezpieczeństwa:

• Wersjonowane magazyny zaufania
• Wdrożenia Canary
• Plany wycofania
• Dane telemetryczne dotyczące błędów walidacji według wystawcy/numeru seryjnego/ścieżki
• Jawny właściciel określający „kto, co i kiedy aktualizuje”

Niepowodzenia w podpisywaniu krzyżowym i budowaniu ścieżek (rzeczywistość 2026 r.): W ekosystemach wielokorzeniowych ISO 15118
Podłączenie i ładowanie często kończy się niepowodzeniem nie z powodu nieważności certyfikatu, ale dlatego, że urządzenie EVSE nie może utworzyć ważnego
ścieżka certyfikatu po zmianach w podpisywaniu krzyżowym (nowe pośredniki, urzędy certyfikacji mostkowe, ponownie wydane łańcuchy).
Wraz ze wzrostem liczby producentów OEM i domen PKI rośnie złożoność ścieżek. Jeśli chodzi o zaufane magazyny brzegowe (kontrolery EVSE/lokalne)
opóźnienia w aktualizacjach zaplecza, uzgadnianie TLS może się nie powieść nawet wtedy, gdy certyfikaty zaplecza wydają się „prawidłowe” w izolacji.

Rysunek 1 (Zalecany materiał wizualny): Walidacja ścieżki w systemie wielorootowym ISO 15118

(Pokaż katalog główny V2G / katalog główny OEM / katalog główny kontraktu, elementy pośrednie i mosty krzyżowe.
Zaznacz miejsce, w którym nowo podpisany pośrednik przerywa budowanie ścieżki w EVSE, jeśli magazyny zaufanych danych nie są aktualizowane w synchronizacji.)

Główne przesłanie: Większość awarii P&C, które są przypisywane „PKI”, jest w rzeczywistości błędy walidacji ścieżki spowodowane dryfem podpisywania krzyżowego i niezsynchronizowanymi magazynami zaufania.

ACME i automatyzacja: kierowane przez człowieka a kierowane przez system w cyklu życia 199/200 dni

Dlaczego ręczne odnawianie staje się deterministycznym generatorem przerw

Krótkie okresy obowiązywania sprawiają, że odnawianie jest ciągłe. Przejście DigiCert na 199 dni od 24 lutego 2026 r.
Dzięki temu rozwiązanie to staje się natychmiast dostępne dla wielu flot. A szerszy harmonogram branżowy jest już określony:
200 dni (od 15 marca 2026 r.), następnie 100 dni, Następnie 47 dni.

W przypadku każdej floty wydarzenia związane z odnawianiem przebiegają następująco:

Liczba odnowień w ciągu roku ≈ N × (365 / L)

Gdzie N jest liczbą punktów końcowych TLS i L to okres ważności certyfikatu (dni).
Jak L zmniejsza się, odnowa prowadzona przez człowieka staje się matematycznie niekompatybilna z celami dotyczącymi czasu sprawności.

Scenariusz (określanie wielkości na poziomie zarządu)

Dla operatora CPO 5000 punktów końcowych, 199-dniowy okres życia oznacza:

Wydarzenia odnowieniowe/rok ≈ 5000 × (365 / 199) ≈ 9171

W tej skali nawet 1% wskaźnik błędów ludzkich tłumaczy się mniej więcej
92 przerwy w działaniu certyfikatów rocznie—przed uwzględnieniem wpływu na godziny szczytu,
Kary SLA lub kaskadowe awarie w obrębie huba.

ACME w sieciach ładowania: co powinno zautomatyzować

Rozwiązanie ACME (Automated Certificate Management Environment) przekształca odnawianie certyfikatów w operacje zgodne z polityką w zakresie:

• EVSE ↔ zaplecze TLS
• Kontroler lokalny / serwer proxy brzegowy TLS
• Bramy witryn i kontrolery koncentratorów

Przepływ pracy sterowany przez system (wzorzec architektoniczny)

1. Spis każdy punkt końcowy (wydawca, numer seryjny, łańcuch, wygaśnięcie, ostatnia rotacja).
2. Polityka odnowienia przed (odnawiać po osiągnięciu ustalonego progu, a nie „blisko wygaśnięcia”).
3. Klucze sprzętowe jeśli to możliwe, unikaj eksportowania kluczy prywatnych.
4. Wdrażanie etapowe ze sprawdzeniem stanu zdrowia (uściśnięcie dłoni + autoryzacja + rozpoczęcie sesji).
5. Automatyczne cofanie o podwyższonych wskaźnikach awaryjności.
6. Rejestry dowodów dla każdego wydania/wdrożenia (śledzenie na poziomie zgodności).

Kierowane przez człowieka kontra kierowane przez system

• Przyczyny ludzkie: zgłoszenia, arkusze kalkulacyjne, późne odnowienia, niejasna własność, ryzykowne zmiany awaryjne.
• Kierowane przez system: deterministyczne zasady, automatyczne wydawanie, kontrolowane wdrażanie, ciągła telemetria, dowody podlegające audytowi.

Sprawdzanie odwołań: „zabójca P&C” (CRL kontra OCSP, słabe sieci i obronne zasady)

Dlaczego OCSP/CRL zawodzą w garażach i magazynach

• Słabe/przerywane LTE/5G
• Ograniczone wyjście (zapory sieciowe/portale uwierzytelniające)
• Kroki walidacji wrażliwe na opóźnienie
• Zależności zewnętrzne (odpowiedzi OCSP, punkty dystrybucji CRL)

Wynik: EVSE może zainicjować sesję, ale nie może jej ukończyć walidacja odwołania niezawodnie.

CRL kontra OCSP: praktyczne kompromisy

• Lista CRL: większe pobieranie, ale możliwe do buforowania i odświeżania zgodnie z harmonogramem (co jest korzystne dla ciągłości działania na brzegu sieci).
• OCSP: lekki na żądanie, ale często wymaga bieżącej dostępności na najsłabszym brzegu.

W roku 2026 prawidłowa postawa ciała będzie warstwowa:

• Zaplanowane buforowanie listy CRL w celu zapewnienia odporności
• OCSP, gdzie łączność jest niezawodna
• Jasna polityka dotycząca pogorszonych warunków

Dlaczego obrona przed „miękkim niepowodzeniem” staje się coraz trudniejsza

Historycznie rzecz biorąc, „miękkie błędy” (zezwolenie na sesję, jeśli upłynął limit czasu sprawdzeń odwołania) zachowywały dostępność.
W roku 2026 uzasadnienie „soft-fail” stanie się trudniejsze, ponieważ:

• Czas życia jest krótszy (mniejsza tolerancja dla nieaktualnych założeń)
• Zegar raportowania CRA wymusza większą dyscyplinę w zakresie incydentów i śledzenie dowodów

Obronny projekt wymaga wyraźnej, udokumentowanej polityki:

• Twarda awaria dla środowisk publicznych/wysokiego ryzyka
• Łaska z dowodami dla flot zamkniętych (ograniczone okno + sterowanie kompensacyjne)
• Rejestrowanie dowodów za każdą poniżoną decyzję

Ograniczenia architektoniczne (wzorce, a nie obietnice dotyczące produktu)

Wzorzec 1: Wstępna walidacja krawędzi + buforowanie

• Buforuj listy CRL z zdefiniowanymi oknami świeżości
• Pośrednie elementy pamięci podręcznej i sprawdzone łańcuchy
• Wstępne pobieranie w okresach „dobrego połączenia”

Wzorzec 2: zszywanie OCSP (jeśli to możliwe)

Zszywanie protokołu OCSP powoduje, że dostarczanie dowodów odwołania zostaje przesunięte z najsłabszego punktu, co zmniejsza zależność od infrastruktury urzędu certyfikacji podczas nawiązywania sesji.

Notatka dotycząca implementacji (rzeczywistość osadzona): W środowiskach EVSE należy potwierdzić obsługę rozszerzeń związanych ze zszywaniem
w Twoim osadzonym stosie TLS i konfiguracji kompilacji (np. mbedTLS, wolfSSL) i sprawdź poprawność działania na starszym sprzęcie,
ponieważ kompletność funkcji i ograniczenia pamięci/RTOS są różne.

Wzorzec 3: Zarządzanie zaufaniem wielordzeniowym

• Zunifikowany kanał aktualizacji magazynu zaufanych informacji dla wielu kotwic OEM
• Aktualizacje i wycofanie Canary w przypadku wzrostu liczby błędów podczas budowania ścieżek

Wzorzec 4: Zarządzanie synchronizacją czasu (nie podlegające negocjacjom)

• Polityka NTP (lub PTP, jeśli to właściwe)
• Monitorowanie dryfu i progi alarmowe
• Zdefiniowane zachowanie w przypadku braku zaufania do zegarów

Ciągłość działania w trybie offline: utrzymanie funkcjonalności funkcji Plug & Charge podczas przerw w transmisji danych między brzegiem a chmurą

Czym jest (a czym nie jest) ciągłość offline

Ciągłość offline nie polega na „omijaniu PKI”. Chodzi o kontrolowaną degradację, która zachowuje:

• Integralność kluczy i magazynów zaufania
• Audytowalność w zakresie rozliczeń i reagowania na incydenty
• Jawne ograniczenia dotyczące tego, co można lokalnie zweryfikować (i jak długo)

Kontrolery lokalne/serwery proxy brzegowe jako prymitywy dostępności

• Utrzymuj lokalne pamięci podręczne zaufania (kotwice/elementy pośrednie/listy CRL)
• Wyegzekwuj ograniczone zasady autoryzacji lokalnej
• Buforuj pomiary/logi do późniejszego uzgodnienia
• Zmniejsz promień rażenia sieci WAN, działając jako lokalny punkt końcowy dla EVSE

Rysunek 2 (zalecana wizualizacja): Serwer proxy brzegowy jako pamięć podręczna zaufania w witrynach o słabej sieci

(Pokaż urządzenia EVSE łączące się z lokalnym serwerem proxy Edge/kontrolerem lokalnym. Serwer proxy przechowuje w pamięci podręcznej zaufane kotwice/pośredniki,
zaplanowane odświeżanie list CRL, monitorowanie synchronizacji czasu i rejestrowanie dowodów; buforuje zdarzenia przesyłane do chmury CSMS/PKI, gdy łącze uplink jest niestabilne.)

Główne przesłanie: Serwery proxy brzegowe zmniejszają zależność od zewnętrznych punktów końcowych OCSP/CRL i umożliwiają kontrolowaną ciągłość działania w trybie offline bez pomijania infrastruktury klucza publicznego (PKI).

CRA i VMP: terminy raportowania od września 2026 r. do audytowalnego modelu operacyjnego

Zasady raportowania CRA: projektowanie w trybie 24/72h

Zasady raportowania CRA wymagają od producentów zgłaszania aktywnie wykorzystywanych luk w zabezpieczeniach i poważnych incydentów mających wpływ
w sprawie bezpieczeństwa produktów z elementami cyfrowymi:

• Wczesne ostrzeżenie w ciągu 24 godzin uświadomienia sobie
• Pełne powiadomienie w ciągu 72 godzin
• Raport końcowy w zdefiniowanych oknach (w zależności od klasy incydentu)

Zakłócenie na szeroką skalę w systemie Plug & Charge spowodowane masowym wycofaniem zamówienia lub naruszeniem zaufania do kotwicy może się kwalifikować
jako poważny incydent, w zależności od dowodów dotyczących wpływu i eksploatacji.

Proces zarządzania lukami w zabezpieczeniach (VMP): minimalne możliwe możliwości

1. Prawda o flocie: zasoby + inwentarz wersji (oprogramowanie sprzętowe EVSE, obrazy kontrolerów, wersje zaufanego magazynu).
2. Integracja SBOM (dynamiczna): SBOM mapowany na wdrażalne artefakty; ciągła korelacja z informacjami o podatnościach.
3. Zarządzanie narażeniem na działanie VEX: Utrzymuj instrukcje VEX, aby odróżnić „obecne, ale nienadające się do wykorzystania” od „nadających się do wykorzystania w naszym wdrożeniu”, umożliwiając wiarygodne określanie zakresu w oknie T+24h.
4. Dlaczego VEX ma znaczenie w systemie 24-godzinnym: SBOM informuje Cię, co jest obecne; VEX pomaga Ci określić, co jest nadający się do wykorzystania, redukując liczbę fałszywych alarmów i uniemożliwiając zespołom operacyjnym śledzenie nieeksploatowalnego hałasu.
5. Przyjęcie i triaż: ostrzeżenia dostawców, CVE, ustalenia wewnętrzne; priorytetyzowanie podatności na wykorzystanie i narażenia na niebezpieczeństwo.
6. Przebieg prac nad zakresem T+24h: SBOM + VEX + korelacja inwentaryzacji w celu identyfikacji dotkniętych populacji; wstępne decyzje o powstrzymaniu; gromadzenie dowodów.
7. Przebieg pracy powiadomień T+72h: potwierdzony zakres, środki zaradcze, plan wdrożenia/wycofania, zapis komunikacji.
8. Obieg pracy nad raportem końcowym: dowody walidacyjne + przyczyna źródłowa + ulepszenia w zakresie zapobiegania po udostępnieniu środków korygujących.
9. Inżynieria rytmu poprawek: wdrażanie etapowe, plany wycofywania, podpisane artefakty, bramki weryfikacyjne.
10. Egzekwowanie łańcucha zaufania: Bezpieczny rozruch + bezpieczne aktualizacje oprogramowania sprzętowego; klucze podpisu chronione w elementach HSM/secure.
11. Rejestrowanie danych w pierwszej kolejności: zdarzenia certyfikatów, zmiany w magazynie zaufanych certyfikatów, błędy unieważnień, stan synchronizacji czasu.

Scenariusz zaufania o wysokim stopniu zagrożenia: Jeżeli odwołanie zostanie wywołane przez naruszony klucz główny lub klucz wydający,
traktować to jako incydent zaufania o najwyższym stopniu zagrożenia, wymagający natychmiastowego opanowania i podjęcia działań w ramach magazynu zaufania obejmującego całą flotę,
i gotowość do sprawozdawczości dostosowanej do potrzeb CRA w zależności od wpływu i dowodów wykorzystania.

Lista kontrolna odliczania reakcji na incydenty CRA (szablon operacyjny)

T+0 (Wykrywanie / Świadomość)

• Zamroź dowody: dzienniki, zdarzenia certyfikatów, wersje magazynu zaufanych certyfikatów, status synchronizacji czasu
• Zidentyfikuj dotknięte powierzchnie: oprogramowanie układowe EVSE, kontrolery lokalne, punkty końcowe TLS zaplecza
• Skontaktuj się z dostawcą PKI/kontaktem ds. bezpieczeństwa zaplecza

T+24h (Gotowość wczesnego ostrzegania)

• Główny cel: Używać SBOM + VEX + inwentarz floty w celu określenia populacji dotkniętej chorobą i przedstawienia wczesnego ostrzeżenia popartego dowodami
• Podejmij decyzję o powstrzymywaniu: odwołaj/obróć, wycofaj zaufany magazyn, odizoluj witrynę
• Projekt pakietu wczesnego ostrzegania: zakres, trwające działania łagodzące, tymczasowe stanowisko

T+72h (Pełna gotowość do powiadomienia)

• Potwierdź dotknięte populacje według regionu/miejsca; dostarcz plan naprawczy + metodę wdrożenia
• Tworzenie komunikatów dla klientów/operatorów i rejestrów eskalacji

Okno raportu końcowego

• Złóż raport końcowy zgodny z wymogami CRA (termin zależy od klasy incydentu)
• Dowody walidacji po wprowadzeniu poprawki + wyciągnięte wnioski

Kwantyfikacja kosztów i ryzyka (szablony, które można podłączyć do floty)

Model kosztów pracy przy odnawianiu ręcznym

Pozwalać:

• N = liczba punktów końcowych TLS (EVSE + kontrolery + bramy + zarządzane węzły zaplecza)
• L = czas życia certyfikatu (dni)
• T = czas ludzki na odnowienie (godziny)
• C = koszt pracy przy pełnym obciążeniu (USD/godzina)

Koszt_pracy ≈ N × (365 / L) × t × c

Model ryzyka awarii (wygaśnięcie lub nieudane wdrożenie)

Pozwalać:

• P_miss = prawdopodobieństwo pominiętego/nieudanego odnowienia na cykl
• H_down = oczekiwana liczba godzin przestoju na incydent
• C_godzina = godzinowy wpływ na działalność (utracone przychody, kary, kredyty SLA)

Koszt_przerwy ≈ P_miss × H_down × C_hour

Przewodnik decyzyjny: Kiedy sprawdzanie odwołań online kończy się niepowodzeniem (przekroczenie limitu czasu OCSP/CRL)

1. Obiekt publiczny czy zamknięta flota/skład?
   • Publiczny → preferuj Twarda awaria (lub ściśle kontrolowana łaska tylko z dowodami + kontrolami kompensacyjnymi)
   • Flota/skład → Łaska z dowodami może być akceptowalny dla ograniczonej liczby okien
2. Czy niezawodność sieci jest przewidywalna?
   • Tak → Online OCSP/CRL + monitoring
   • Nie → Wstępna walidacja krawędzi + buforowanie (okna odświeżania CRL, łańcuchy pamięci podręcznej)
3. Czy można ograniczyć zależność od Internetu w trakcie sesji?
   • Jeśli to możliwe → przyjąć Wzór zszywania OCSP (zabezpieczenie przed wciśnięciem bliżej krawędzi)
4. Czy posiadasz system rejestrowania dowodów i zarządzania synchronizacją czasu?
   • Jeśli nie → najpierw je napraw; bez nich trudno będzie obronić zasady dotyczące trybu zdegradowanego

Praktyczna macierz odpowiedzialności (granice zapobiegające awariom)

Słowniczek

• Infrastruktura klucza publicznego: Infrastruktura klucza publicznego (wydawanie, walidacja, punkty zaufania, unieważnianie)
• KULMINACJA: Zautomatyzowane środowisko zarządzania certyfikatami (automatyczne wydawanie/odnawianie)
• OCSP / CRL: Protokół statusu certyfikatu online / Lista odwołanych certyfikatów
• Zszywanie OCSP: Serwer przedstawia dowód odwołania w celu zmniejszenia zależności od protokołu OCSP na żywo
• Kotwice zaufania: Certyfikaty główne/pośrednie, którym ufają Twoi walidatorzy
• SBOM: Wykaz materiałów oprogramowania (inwentaryzacja komponentów do określania zakresu podatności)
• DRAŻNIĆ: Wymiana informacji o możliwości wykorzystania luk (oświadczenia o stanie wykorzystania)
• TLS 1.3: Nowoczesny profil TLS; uzgadnianie i walidacja certyfikatu pozostają wrażliwe na opóźnienie
• VMP: Proces zarządzania lukami w zabezpieczeniach (przyjęcie, selekcja, łatanie, raportowanie, dowody)

Ryzyko przyszłościowe: Zwinność kryptowalut i gotowość PQC

Podczas gdy rok 2026 będzie zdominowany przez krótkie okresy obowiązywania TLS i raportowanie CRA, infrastruktura ładowania powinna zacząć podlegać ocenie
krypto-zwinnośćW przypadku zasobów o długim okresie użytkowania (pojazdów i ładowarek) architektury powinny unikać uzależnienia od sprzętu, zapewniając
Elementy HSM/secure i wbudowane stosy mogą obsługiwać przyszłe aktualizacje algorytmów i profili certyfikatów bez konieczności wymiany sprzętu.

Często zadawane pytania

Czy usługa Plug & Charge działa w trybie offline?

Częściowo – zgodnie z projektem. Kontrolowana degradacja w trybie offline P&C odbywa się za pomocą lokalnego buforowania zaufania (kotwice/pośrednie/listy CRL, jeśli to możliwe).
Jawne zasady dotyczące ulgi i buforowane dzienniki audytu do uzgadniania. Nie powinno to pomijać infrastruktury klucza publicznego (PKI); powinno to zmniejszyć zależność od chmury na żywo.
zachowując jednocześnie integralność i możliwość audytu.

Jak często musimy odnawiać certyfikaty o okresie ważności 199/200 dni?

Zaplanuj wiele cykli odnawiania rocznie dla każdego punktu końcowego. Dla wielu operatorów przejście operacyjne rozpoczyna się
24 lutego 2026 r. ponieważ DigiCert będzie wydawać publiczne certyfikaty TLS o maksymalnej 199-dniowy ważności od tej daty.
Na poziomie szerszego ekosystemu Wymagania bazowe określają etapową redukcję 200/100/47 dni.

Co powoduje obowiązek sprawozdawczy CRA?

Zasady raportowania CRA wymagają 24-godzinne wczesne ostrzeganie I Powiadomienie 72-godzinne w przypadku aktywnie wykorzystywanych luk i poważnych incydentów,
plus ostateczne okna raportowania. Zakłócenie zaufania P&C na dużą skalę (np. złośliwe unieważnienie lub naruszenie walidacji) może kwalifikować się w zależności od
w oparciu o dowody dotyczące wpływu i eksploatacji; gotowy do wdrożenia przez CRA program VMP powinien wspierać SBOM + VEX + inwentarz floty zakres w ciągu pierwszych 24 godzin.