ISO 15118 Sertifika Yaşam Döngüsü Yönetimi 2026'da: TLS Aciliyetinden CRA Uyumluluğuna

TL;DR (Yürütme Eylemi Özeti)

• TLS geçişi kesin bir sınırdır (öneri değil): İtibaren 24 Şubat 2026DigiCert, kabul etmeyi bırak Geçerliliği olan herkese açık TLS sertifikası istekleri 199 günden fazlave o tarihten itibaren verilen sertifikalar şu özelliğe sahiptir: En fazla 199 gün geçerlilik süresiBu, birçok operatör için pratik geçiş noktasıdır; yenileme hızı anında artar.
• 200→100→47 günlük yol haritası zaten belirlendi: CA/Browser Forum Temel Gereksinimleri, aşamalı bir azaltma öngörüyor: 15 Mart 2026'dan itibaren 200 gün, 15 Mart 2027'den itibaren 100 gün, Ve 15 Mart 2029'dan itibaren 47 gün.
• CRA, uyumluluk süresi sayacını ekledi: CRA raporlama kuralları gerektirir 24 saat içinde erken uyarı, 72 saat içinde tam bildirimAyrıca, aktif olarak istismar edilen güvenlik açıkları ve ciddi olaylar için nihai raporlama sürelerini tanımladı.
• En büyük gizli risk vade sonu değil: Sistemik arıza modu şudur: güven çapası sürüklenmesi—EVSE, yerel kontrolcüler ve arka uç doğrulama yolları genelinde kök/ara/çapraz imzalama değişiklikleri senkronize değil.
• Çalışma sürekliliğini korumaya yönelik ilk yatırım: Sistem odaklı otomasyon (ACME + envanter + aşamalı devreye alma) artı kenar sürekliliği (Yerel doğrulama/önbellekleme, kanıt kayıtları ve zaman senkronizasyonu yönetimi).

Giriş: 2026, Tak ve Şarj Et sistemini işler hale getiriyor

2026'da Tak ve Şarj Et (P&C) özelliği "ayarla ve unut" özelliği olmaktan çıkıp bir sisteme dönüşüyor. sürekli işletim sistemi.
ISO 15118 güven düzlemi (PKI + TLS + iptal + güncellemeler), artık manuel iş akışlarına izin vermeyen zaman çizelgeleriyle yönetiliyor.

Sistem sınırlarını anlamak için—ISO 15118'in sorumlulukları ile OCPP'nin sorumlulukları arasındaki farkı kavramak için—ilk olarak hazırladığımız ek makaleye göz atın:
ISO 15118 ve OCPP'nin 2026'daki uygulama gerçekliği.

Acil baskı şudur: TLS yaşam döngüsü sıkıştırmasıOperasyonel olarak, "Mart ayına kadar bekleyemezsiniz."
DigiCert kabul etmeyi bırak herkese açık TLS isteklerinin aşılması 199 gün başlangıç 24 Şubat 2026,
ve o günden itibaren verilen sertifikalar şu özelliğe sahip olacaktır: En fazla 199 gün geçerlilik süresi.
DigiCert ayrıca kritik bir operasyonel detayı da vurguluyor: izin verilen maksimum geçerlilik süresi şunlar tarafından belirleniyor: yayın tarihiSipariş verildiği zaman değil.

Aynı zamanda, AB Siber Direnç Yasası (CRA) ikinci bir zamanlayıcı getiriyor: raporlama kuralları gerektiriyor.
24 saatlik erken uyarı Ve 72 saatlik bildirim Aktif olarak istismar edilen güvenlik açıkları ve dijital unsurlar içeren ürünleri etkileyen ciddi olaylar için.

Bu kılavuz, bu kısıtlamalar altında ISO 15118 sertifikalarının işletilmesi için mimari ve risk kontrollerine odaklanmaktadır.

2024–2026 Dönüm Noktaları ve Gerekli Eylemler (Metin Gantt Şeması)

Operasyonel not: 24 Şubat 2026 genellikle gerçek geçiş noktasıdır çünkü o tarihte büyük sertifika yetkililerinin ihraç davranışları değişir.

Politika notu: Aşamalı ömür süresi azaltımları Temel Gereksinimlerde (200/100/47 gün) tanımlanmıştır.

Yaşam Döngüsü Genel Görünümü: Tedarik → İşletme → Yenileme → İptal

Yaşam döngüsü haritası (işletebilmeniz gerekenler)

1. OEM tedariği: Anahtarlar oluşturuldu/eklendi; güven kökü oluşturuldu (HSM/güvenli unsur).
2. Sözleşme kaydı: Kullanıcı sözleşmelerine bağlı sözleşme sertifikaları (ekosisteme bağımlı).
3. EVSE devreye alma: Güven deposu temel değerleri, politikalar ve zaman senkronizasyonu temel değerleri oluşturuldu.
4. Operasyonel doğrulama: TLS bağlantı kurma, zincir oluşturma, iptal kontrolü, politika uygulama.
5. Yenileme / yeniden düzenleme: Otomasyon + aşamalı devreye alma + geri alma.
6. İptal / olay müdahalesi: Güvenlik ihlali/yanlış düzenleme/istismar → iptal et/değiştir/geri al.
7. İyileşme ve uzlaşma: Denetlenebilirliği ve faturalama bütünlüğünü koruyarak hizmeti yeniden sağlayın.

Hafife alınan başarısızlık noktası: Güven Çapa Kayması

Çoklu OEM ortamlarında görülen "gizemli P&C arızalarının" çoğu, tek bir süresi dolmuş sertifikadan kaynaklanmaz; daha fazlasıdır.
yol doğrulama hataları Güven çapası kaymasından kaynaklanır:

• Yeni kökler/ara kökler ortaya çıkıyor (çok köklü gerçeklik).
• Çapraz imzalama Değişiklikler, olası zincirleri değiştirir.
• Arka uçtaki güven depoları, EVSE/yerel kontrol ünitelerinden daha hızlı güncellenir.
• İptal edilen eserler, sınırda bayatlıyor.

Güven çapası güncellemelerini güvenlik açısından kritik bir değişiklik süreci olarak ele alın:

• Sürümlü güven depoları
• Kanarya sürümleri
• Geri alma planları
• Yayıncı/seri numarası/yol bazında doğrulama hatalarına ilişkin telemetri verileri.
• "Kim neyi ne zaman günceller" sorusunun açık bir şekilde yanıtlanması.

Çapraz imzalama ve yol oluşturma başarısızlıkları (2026 gerçeği): Çok köklü ISO 15118 ekosistemlerinde,
Plug & Charge işlemi genellikle sertifikanın geçersiz olmasından değil, EVSE'nin geçerli bir sertifika oluşturamamasından dolayı başarısız olur.
sertifika yolu Çapraz imzalama değişikliklerinden sonra (yeni ara ürünler, köprü CA'lar, yeniden yayınlanan zincirler).
Daha fazla OEM ve PKI etki alanı katıldıkça, yol karmaşıklığı artar. Uç güven depoları (EVSE/yerel kontrolcüler)
Arka uç güncellemelerinde gecikme yaşanması durumunda, arka uç sertifikaları tek başına "geçerli" görünse bile TLS el sıkışmaları başarısız olabilir.

Şekil 1 (Önerilen Görsel): Çok Köklü ISO 15118'de Yol Doğrulama

(V2G Kökü / OEM Kökü / Sözleşme Kökü, ara bağlantılar ve çapraz imza köprülerini göster.)
(Güven depoları senkronize olarak güncellenmediği takdirde, yeni çapraz imzalanmış bir ara işlemin EVSE'de yol oluşturmayı nerede bozduğunu vurgulayın.)

Ana mesaj: “PKI”ye atfedilen P&C kesintilerinin çoğu aslında... yol doğrulama hataları Çapraz imzalama kayması ve senkronize olmayan güven depolarından kaynaklanmaktadır.

ACME ve Otomasyon: 199/200 günlük ömür süreleri altında insan odaklı mı yoksa sistem odaklı mı?

Manuel yenilemenin neden sürekli bir arıza kaynağı haline geldiği

Kısa kullanım ömrü, yenilemelerin sürekli olmasını gerektirir. DigiCert'in bu yöndeki hamlesi... 24 Şubat 2026'dan itibaren 199 gün
Bu durum, birçok filo için anında uygulanabilir hale geliyor. Ve daha geniş sektör zaman çizelgesi zaten belirlenmiş durumda:
200 gün (15 Mart 2026'dan itibaren), o zaman 100 gün, Daha sonra 47 gün.

Herhangi bir filo için yenileme etkinliklerinin ölçeği şu şekildedir:

Yılda gerçekleşen yenilenme olaylarının sayısı ≈ N × (365 / L)

Nerede N TLS uç noktalarının sayısıdır ve L Sertifikanın geçerlilik süresi (gün) nedir?
Gibi L Azaldıkça, insan kaynaklı yenileme, kesintisiz çalışma hedefleriyle matematiksel olarak bağdaşmaz hale gelir.

Senaryo (Karton seviyesinde boyutlandırma)

Bir CPO işletmesi için 5.000 uç nokta199 günlük bir ömür şu anlama gelir:

Yenilenme olayları/yıl ≈ 5000 × (365 / 199) ≈ 9.171

Bu ölçekte, hatta bir 1% insan hatası oranı kabaca şu anlama gelir
Yılda 92 sertifika kaynaklı kesinti—yoğun saatlerdeki etkiyi hesaba katmadan önce,
SLA cezaları veya bir merkez genelinde zincirleme arızalar.

ACME şarj ağlarında: neleri otomatikleştirmeli?

ACME (Otomatik Sertifika Yönetim Ortamı), yenileme işlemlerini politika odaklı operasyonlara dönüştürür:

• EVSE ↔ arka uç TLS
• Yerel Denetleyici / Uç Proxy TLS
• Site ağ geçitleri ve merkez kontrolörleri

Sistem odaklı iş akışı (mimari model)

1. Envanter her bir uç nokta (ihraççı, seri numarası, zincir, son kullanma tarihi, son rotasyon).
2. Yenileme öncesi politikası (Süre bitimine yakın değil, belirli bir eşikte yenileme).
3. Donanım destekli anahtarlar Mümkün olduğunca özel anahtarların dışa aktarılmasından kaçının.
4. Aşamalı dağıtım Sağlık kontrolleriyle birlikte (el sıkışma + yetkilendirme + oturum başlatma).
5. Otomatik geri alma Yüksek arıza oranları nedeniyle.
6. Kanıt kayıtları Her bir dağıtım/uygulama için (uyumluluk düzeyinde izlenebilirlik).

İnsan Odaklı mı, Sistem Odaklı mı?

• İnsan kaynaklı sorunlar: Destek talepleri, elektronik tablolar, geç yenilemeler, belirsiz sahiplik, riskli acil değişiklikler.
• Sistem odaklı: Belirleyici politikalar, otomatik düzenleme, kontrollü dağıtım, sürekli telemetri, denetlenebilir kanıt.

İptal Kontrolleri: "P&C Katili" (CRL ve OCSP, zayıf ağlar ve savunulabilir politikalar)

OCSP/CRL neden garajlarda ve depolarda başarısız oluyor?

• Zayıf/kesintili LTE/5G
• Kısıtlı çıkış (güvenlik duvarları/kapalı portallar)
• Gecikmeye duyarlı doğrulama adımları
• Dış bağımlılıklar (OCSP müdahale ekipleri, CRL dağıtım noktaları)

Sonuç: EVSE oturumu başlatabiliyor ancak tamamlayamıyor. iptal doğrulaması güvenilir bir şekilde.

CRL ve OCSP: Pratik Avantajlar ve Dezavantajlar

• CRL: Daha büyük boyutlu indirmeler, ancak önbelleğe alınabilir ve programlı olarak yenilenebilir (uç süreklilik için iyi).
• OCSP: İsteğe bağlı olarak hafif yapıdadır, ancak genellikle en zayıf noktada canlı erişilebilirlik gerektirir.

2026'da doğru duruş katmanlandırılmıştır:

• Veri dayanıklılığı için planlanmış CRL önbellekleme.
• Bağlantının güvenilir olduğu OCSP
• Bozulmuş koşullar için açık politika

“Yumuşak başarısızlık”ın savunulması neden giderek zorlaşıyor?

Tarihsel olarak, "yumuşak başarısızlık" (iptal kontrolleri zaman aşımına uğrarsa oturuma izin verme) kullanılabilirliği koruyordu.
2026'da, "yumuşak başarısızlık" durumunu haklı çıkarmak daha zor hale gelecek çünkü:

• Yaşam süreleri daha kısa (eskimiş varsayımlara daha az tolerans gösteriliyor)
• CRA'nın raporlama süresi, olaylara ilişkin daha sıkı disiplin ve kanıt takibi yapılmasını zorunlu kılıyor.

Savunulabilir bir tasarım, açık ve belgelenmiş bir politika gerektirir:

• Kesin başarısızlık halka açık/yüksek riskli ortamlar için
• Kanıtla birlikte lütuf Kapalı filolar için (sınırlı zaman aralığı + telafi edici kontroller)
• Kanıt kaydı her bozulmuş karar için

Mimari hafifletme önlemleri (ürün vaatleri değil, kalıplar)

Desen 1: Kenar ön doğrulama + önbellekleme

• Tanımlanmış geçerlilik süreleriyle CRL'leri önbelleğe alın.
• Önbellek ara ürünleri ve doğrulanmış zincirler
• "İyi bağlantı" dönemlerinde önceden yükleme

Desen 2: OCSP zımbalama (mümkün olduğunda)

OCSP zımbalama yöntemi, iptal kanıtı teslimatını en zayıf noktadan uzaklaştırarak oturum oluşturma sırasında CA altyapısına olan canlı bağımlılığı azaltır.

Uygulama notu (gömülü gerçeklik): EVSE ortamlarında, zımbalama ile ilgili uzantı desteğini doğrulayın.
Gömülü TLS yığınınızda ve derleme yapılandırmanızda (örneğin, mbedTLS, wolfSSL) ve eski donanımlarda davranışını doğrulayın,
Çünkü özelliklerin eksiksizliği ve bellek/gerçek zamanlı işletim sistemi kısıtlamaları değişkenlik gösterir.

Model 3: Çok köklü güven yönetimi

• Birden fazla OEM bağlantı noktası için birleşik güven deposu güncelleme kanalı.
• Yol oluşturma hatalarında ani artış olduğunda Canary güncellemeleri + geri alma işlemi

Desen 4: Zaman Senkronizasyonu Yönetimi (pazarlık konusu değil)

• NTP politikası (veya uygunsa PTP)
• Sürüklenme izleme ve uyarı eşikleri
• Saatlere güvenilmediğinde tanımlanan davranış

Çevrimdışı Süreklilik: Uçtan buluta bağlantı kesintileri sırasında Plug & Charge'ın kullanılabilirliğini koruma

Çevrimdışı sürekliliğin ne olduğu (ve ne olmadığı)

Çevrimdışı süreklilik, "PKI'yı atlamak" anlamına gelmez. Bu, aşağıdakileri koruyan kontrollü bir bozulmadır:

• Anahtarların bütünlüğü ve güven depoları
• Faturalama ve olay müdahalesi için denetlenebilirlik
• Yerel olarak nelerin doğrulanabileceğine (ve ne kadar süreyle) ilişkin açık sınırlar.

Yerel Denetleyiciler / Uç Proxy'ler kullanılabilirlik temel öğeleri olarak

• Yerel güven önbelleklerini (çapa noktaları/ara veriler/CRL'ler) koruyun.
• Sınırlı yerel yetkilendirme politikalarını uygulayın.
• Daha sonraki mutabakat için tampon ölçüm/kayıtları
• EVSE için yerel uç nokta görevi görerek WAN'ın etki alanını azaltın.

Şekil 2 (Önerilen Görsel): Zayıf Ağ Bağlantılı Sitelerde Güven Önbelleği Olarak Uç Proxy

(EVSE'lerin yerel bir Edge Proxy/Yerel Denetleyiciye bağlanmasını gösterin. Proxy, önbelleğe alınmış güven çapalarını/ara bağlantılarını korur.)
Planlanmış CRL yenilemesi, zaman senkronizasyonu izleme ve kanıt kayıtları; bağlantı kararsız olduğunda olayları bulut CSMS/PKI'ye tamponlar.

Ana mesaj: Uç proxy'ler, harici OCSP/CRL uç noktalarına olan canlı bağımlılığı azaltır ve PKI'yı atlamadan kontrollü çevrimdışı sürekliliği sağlar.

CRA ve VMP: Eylül 2026 raporlama son tarihlerinden denetlenebilir bir işletme modeline

CRA raporlama kuralları: 24/72 saatlik saat dilimine göre tasarım yapın.

CRA raporlama kuralları, üreticilerin aktif olarak istismar edilen güvenlik açıklarını ve ciddi etkiye sahip olayları bildirmelerini gerektirmektedir.
Dijital unsurlar içeren ürünlerin güvenliği konusunda:

• 24 saat içinde erken uyarı farkına varmak
• 72 saat içinde tam bildirim
• Son rapor Belirlenen zaman aralıkları içinde (olay sınıfına bağlı olarak)

Kitlesel iptal veya güven çıpasının zedelenmesi nedeniyle ortaya çıkan büyük ölçekli bir Plug & Charge aksaması. uygun olabilir
Etki ve istismar kanıtlarına bağlı olarak ciddi bir olay olarak değerlendirilebilir.

Güvenlik Açığı Yönetim Süreci (VMP): Minimum uygulanabilir yetenekler

1. Filo gerçeği: Varlık + sürüm envanteri (EVSE bellenimi, kontrol cihazı görüntüleri, güven deposu sürümleri).
2. SBOM entegrasyonu (dinamik): SBOM, konuşlandırılabilir yapılara eşlenmiştir; güvenlik açığı istihbaratıyla sürekli korelasyon sağlanmaktadır.
3. VEX tabanlı risk yönetimi: "Mevcut ancak istismar edilemez" ile "dağıtımımızda istismar edilebilir" durumları birbirinden ayırmak için VEX ifadelerini koruyun; bu, T+24h penceresi içinde güvenilir kapsam belirleme olanağı sağlar.
4. 24 saatlik zaman diliminde VEX'in önemi neden büyük: SBOM size neyin mevcut olduğunu söyler; VEX ise neyin eksik olduğunu belirlemenize yardımcı olur. sömürülebilirBu sayede yanlış alarmlar azaltılır ve operasyon ekiplerinin değerlendirilemeyecek gereksiz gürültünün peşinden koşması önlenir.
5. Giriş ve önceliklendirme: Tedarikçi uyarıları, CVE'ler, şirket içi bulgular; istismar edilebilirliğe ve görünürlüğe öncelik verin.
6. T+24h kapsam belirleme iş akışı: SBOM + VEX + envanter korelasyonu ile etkilenen popülasyonların belirlenmesi; ilk karantina kararları; kanıt toplama.
7. T+72h bildirim iş akışı: Onaylanmış kapsam, risk azaltma önlemleri, devreye alma/geri alma planı, iletişim kayıtları.
8. Nihai rapor iş akışı: Doğrulama kanıtı + temel neden + düzeltici önlemlerin uygulanmasından sonra önleme iyileştirmeleri.
9. Yama ritmi mühendisliği: Aşamalı devreye alma, geri alma planları, imzalı belgeler, doğrulama aşamaları.
10. Güven zincirinin uygulanması: Güvenli önyükleme + güvenli bellenim güncellemeleri; imzalama anahtarları HSM/güvenli öğeler içinde korunmaktadır.
11. Kanıta dayalı kayıt tutma: Sertifika olayları, güven deposu değişiklikleri, iptal hataları, zaman senkronizasyonu durumu.

Yüksek önem dereceli güven senaryosu: Eğer iptal işlemi, ele geçirilmiş bir kök veya verme anahtarı nedeniyle tetiklenirse,
Bunu, acil müdahale gerektiren, filo genelinde güven deposu işlemleri yapılmasını gerektiren, en yüksek önem derecesine sahip bir güven olayı olarak ele alın.
ve etki ve istismar kanıtlarına bağlı olarak CRA ile uyumlu raporlama hazırlığı.

CRA Olay Müdahale Geri Sayım Kontrol Listesi (Operasyonel Şablon)

T+0 (Algılama / Farkındalık)

• Dondurma kanıtları: günlükler, sertifika olayları, güven deposu sürümleri, zaman senkronizasyon durumu
• Etkilenen yüzeyleri belirleyin: EVSE bellenimi, yerel kontrolcüler, arka uç TLS uç noktaları.
• PKI sağlayıcısı/arka uç güvenlik sorumlusuyla iletişime geçin.

T+24h (Erken uyarı hazırlığı)

• Temel amaç: Kullanmak SBOM + VEX + filo envanteri Etkilenen nüfusu belirlemek ve kanıtlara dayalı erken uyarı sunmak
• Kısıtlama kararı verin: iptal etme/döndürme, güven deposu geri alma, site izolasyonu
• Erken uyarı paketi taslağı: kapsamı, devam eden önlemler, geçici durum

T+72h (Tam bildirim hazırlığı)

• Etkilenen nüfus gruplarını bölge/alan bazında doğrulayın; iyileştirme planı ve uygulama yöntemini sağlayın.
• Müşteri/operatör iletişimlerini ve sorun bildirim kayıtlarını oluşturun.

Son rapor penceresi

• CRA gerekliliklerine uygun nihai raporu gönderin (zamanlama olay sınıfına bağlıdır).
• Düzeltme sonrası doğrulama kanıtları + öğrenilen dersler

Maliyet ve Risk Nicelendirmesi (Filo sisteminize entegre edebileceğiniz şablonlar)

Manuel yenileme işçilik maliyeti modeli

İzin vermek:

• N = TLS uç noktalarının sayısı (EVSE + kontrolcüler + ağ geçitleri + yönetilen arka uç düğümleri)
• L = sertifika ömrü (gün)
• T = yenileme başına insan zamanı (saat)
• C = Tam maliyet üzerinden hesaplanan işçilik maliyeti (USD/saat)

İşgücü maliyeti ≈ N × (365 / L) × t × c

Kesinti riski modeli (süre dolma veya başarısız dağıtım)

İzin vermek:

• P_kaçırma = döngü başına yenileme işleminin kaçırılma/başarısız olma olasılığı
• H_aşağı = olay başına beklenen arıza süresi (saat cinsinden)
• C_saat = saatlik işletme etkisi (kayıp gelir, cezalar, SLA kredileri)

Maliyet kesintisi ≈ P_kaçırma × H_kesinti × C_saat

Karar Kılavuzu: Çevrimiçi İptal Kontrolleri Başarısız Olduğunda (OCSP/CRL Zaman Aşımı)

1. Halka açık alan mı yoksa kapalı filo/depo mu?
   • Kamuoyu → tercih eder Kesin başarısızlık (veya yalnızca kanıt ve telafi edici kontrollerle sıkı bir şekilde denetlenen hoşgörü)
   • Filo/depo → Kanıtla birlikte lütuf Sınırlı süreler için kabul edilebilir olabilir
2. Ağ güvenilirliği tahmin edilebilir mi?
   • Evet → Çevrimiçi OCSP/CRL + izleme
   • Hayır → Uç nokta ön doğrulama + önbellekleme (CRL yenileme pencereleri, önbelleğe alınmış zincirler)
3. Oturum sırasında çevrimiçi bağımlılığı azaltabilir misiniz?
   • Mümkün olan yerlerde → benimseyin OCSP zımbalama deseni (Kanıtı kenara daha yakın itin)
4. Kanıt kaydı ve zaman senkronizasyonu yönetimini kullanıyor musunuz?
   • Eğer durum böyle değilse → önce bunları düzeltin; bunlar olmadan düşük performanslı çalışma politikalarını savunmak zordur.

Pratik Sorumluluk Matrisi (Kesintileri önleyen sınırlar)

Sözlük

• PKI: Açık Anahtar Altyapısı (verme, doğrulama, güven çapaları, iptal)
• ACME: Otomatik Sertifika Yönetim Ortamı (otomatik düzenleme/yenileme)
• OCSP / CRL: Çevrimiçi Sertifika Durumu Protokolü / Sertifika İptal Listesi
• OCSP Zımbalama: Sunucu, canlı OCSP bağımlılığını azaltmak için iptal kanıtı sunar.
• Güven Çapaları: Doğrulayıcılarınızın güvendiği kök/ara sertifikalar
• SBOM: Yazılım Malzeme Listesi (güvenlik açığı tespiti için bileşen envanteri)
• VEX: Güvenlik Açığı İstismar Edilebilirliği Değişimi (istismar edilebilirlik durum bildirimleri)
• TLS 1.3: Modern TLS profili; el sıkışma ve sertifika doğrulama işlemleri gecikmeye duyarlıdır.
• VMP: Güvenlik Açığı Yönetimi Süreci (kabul, önceliklendirme, yama uygulama, raporlama, kanıt toplama)

Geleceğe Yönelik Risk: Kripto Para Çevikliği ve PQC Hazırlığı

2026 yılı kısa TLS ömürleri ve CRA raporlamasıyla öne çıkarken, şarj altyapıları değerlendirmeye başlamalıdır.
kripto-çeviklikUzun ömürlü varlıklar (araçlar ve şarj cihazları) söz konusu olduğunda, mimariler donanıma bağımlılığı önlemek için aşağıdaki hususları sağlamalıdır:
HSM/güvenli elemanlar ve gömülü yığınlar, donanım yenilemesi gerektirmeden gelecekteki algoritma ve sertifika profili güncellemelerini destekleyebilir.

SSS

Plug & Charge çevrimdışı çalışabilir mi?

Kısmen - tasarım gereği. Çevrimdışı P&C, yerel güven önbelleklemesi (mümkün olan yerlerde çapalar/ara öğeler/CRL'ler) kullanılarak kontrollü bir şekilde bozulur.
Açık ve net tolerans politikaları ve uzlaştırma için tamponlanmış denetim kayıtları içermelidir. PKI'yı atlamamalı; canlı bulut bağımlılığını azaltmalıdır.
Bütünlüğü ve denetlenebilirliği korurken.

199/200 günlük geçerlilik süresi olan sertifikaları ne sıklıkla yenilememiz gerekiyor?

Her bir uç nokta için yılda birden fazla yenileme döngüsü planlayın. Birçok operatör için operasyonel geçiş şu tarihte başlar:
24 Şubat 2026 Çünkü DigiCert, azami sayıda TLS sertifikası içeren halka açık TLS sertifikaları yayınlayacaktır. 199 gün Geçerlilik tarihi o tarihten itibaren başlar.
Daha geniş ekosistem düzeyinde, Temel Gereksinimler aşamalı bir azaltmayı tanımlar. 200/100/47 gün.

CRA'nın raporlama yükümlülüklerini tetikleyen faktörler nelerdir?

CRA raporlama kuralları gerektirir 24 saatlik erken uyarı Ve 72 saatlik bildirim Aktif olarak istismar edilen güvenlik açıkları ve ciddi olaylar için,
Ayrıca son raporlama süreleri de dahildir. Büyük ölçekli bir P&C güven ihlali (örneğin, kötü niyetli iptal veya doğrulama ihlali) duruma bağlı olarak nitelendirilebilir.
Etki ve istismar kanıtlarına dayanarak; CRA'ya hazır bir VMP'nin desteklemesi gerekir. SBOM + VEX + filo envanteri İlk 24 saat içinde kapsam belirleme.