2026年のISO 15118証明書ライフサイクル管理：TLSの緊急性からCRAコンプライアンスまで

TL;DR（エグゼクティブアクションサマリー）

• TLS カットオーバーは厳格な境界です (提案ではありません)。 から 2026年2月24日、DigiCertは 受け入れを停止する 有効なパブリックTLS証明書リクエスト 199日以上、その日から発行された証明書には 最大199日間の有効期間これは多くの事業者にとって実用的な切り替えであり、更新速度が即座に向上します。
• 200→100→47日のロードマップはすでに定義されています。 CA/ブラウザ フォーラムのベースライン要件では、段階的な削減が設定されています。 2026年3月15日から200日, 2027年3月15日から100日間、 そして 2029年3月15日から47日間.
• CRA がコンプライアンス クロックを追加: CRAの報告規則では、 24時間以内の早期警告, 72時間以内に完全な通知、積極的に悪用されている脆弱性と重大なインシデントに関する最終報告期間を定義しました。
• 最大の隠れたリスクは有効期限ではない: システム的な故障モードは 信頼アンカードリフト—ルート/中間証明書/クロス署名の変更が、EVSE、ローカル コントローラー、およびバックエンド検証パス間で同期されていません。
• 稼働時間を保護するための最初の投資: システム主導の自動化（ACME + 在庫 + 段階的な展開）プラス エッジの連続性 (ローカル検証/キャッシュ、証拠ログ、および時間同期ガバナンス)。

はじめに: 2026年にプラグ＆チャージが運用システムになる

2026年には、プラグ＆チャージ（P&C）は「設定して忘れる」機能ではなくなり、 継続的な運用システム.
ISO 15118 信頼プレーン (PKI + TLS + 失効 + 更新) は現在、手動のワークフローを許容しないタイムラインによって管理されています。

システム境界（ISO 15118 の責任範囲と OCPP の責任範囲）を理解するには、まず次の関連資料をご覧ください。
ISO 15118と2026年のOCPP導入の現実.

当面のプレッシャーは TLSライフサイクル圧縮運用上、「3月まで待つ」ことはできません。
DigiCertは 受け入れを停止する パブリックTLSリクエストが超過 199日 起動 2026年2月24日,
そして、その日以降に発行される証明書には 最大199日間の有効期間.
DigiCertはまた、運用上の重要な詳細を強調しています。最大許容有効期間は、 発行日注文時ではなく、注文が行われた時点です。

同時に、EUサイバーレジリエンス法（CRA）は2つ目の基準を導入し、報告規則では
24時間早期警告 そして 72時間前通知 デジタル要素を備えた製品に影響を及ぼす、積極的に悪用される脆弱性や重大なインシデントに対応します。

このガイドでは、これらの制約の下で ISO 15118 証明書を運用するためのアーキテクチャとリスク管理に焦点を当てています。

2024～2026年のマイルストーンと必要なアクション（テキストガントチャート）

運用上の注意: 多くの場合、2026 年 2 月 24 日は主要な CA の発行動作が変更されるため、実際の切り替えポイントとなります。

ポリシーに関する注意事項: 段階的な寿命の短縮は、ベースライン要件 (200/100/47 日) で定義されています。

ライフサイクルの概要: プロビジョニング → 運用 → 更新 → 失効

ライフサイクルマップ（何を操作できなければならないか）

1. OEM プロビジョニング: キーが生成/挿入され、信頼のルートが確立されます (HSM/セキュア エレメント)。
2. 契約登録: ユーザー契約にバインドされた契約証明書 (エコシステムによって異なります)。
3. EVSEの試運転： 信頼ストアのベースライン、ポリシー、および時間同期のベースラインが確立されました。
4. 運用検証: TLS ハンドシェイク、チェーンの構築、失効チェック、ポリシーの適用。
5. 更新/再発行: 自動化 + 段階的なロールアウト + ロールバック。
6. 失効/インシデント対応: 侵害/誤発行/悪用 → 取り消し/ローテーション/回復。
7. 回復と和解： 監査可能性と課金の整合性を維持しながらサービスを復元します。

過小評価されている失敗ポイント：トラスト・アンカー・ドリフト

マルチOEM環境における「不可解なP&C障害」のほとんどは、期限切れの証明書1つではなく、
パス検証の失敗 トラストアンカードリフトによるもの:

• 新しいルート/中間語が出現します (多ルートの現実)。
• クロスサイン 変更により実行可能なチェーンが変更されます。
• バックエンドの信頼ストアは、EVSE/ローカル コントローラーよりも高速に更新されます。
• 失効アーティファクトはエッジで古くなります。

トラスト アンカーの更新を安全性が重要な変更プロセスとして扱います。

• バージョン管理された信頼ストア
• カナリアロールアウト
• ロールバック計画
• 発行者/シリアル/パスによる検証失敗のテレメトリ
• 「誰が何をいつ更新したか」の明確な所有者

クロスサインとパス構築の失敗（2026年の現実）: マルチルートISO 15118エコシステムでは、
プラグ＆チャージが失敗する原因は、証明書が無効であるからではなく、EVSEが有効な証明書を構築できないからであることが多い。
証明書パス クロス署名の変更後（新しい中間証明書、ブリッジ CA、再発行されたチェーン）。
OEMやPKIドメインが増加すると、パスの複雑さが増します。エッジトラストストア（EVSE/ローカルコントローラ）が
バックエンドの更新に遅れが生じると、バックエンドの証明書が単独では「有効」に見えても TLS ハンドシェイクが失敗する可能性があります。

図1（推奨ビジュアル）：マルチルートISO 15118におけるパス検証

(V2G ルート / OEM ルート / コントラクト ルート、中間、およびクロスサイン ブリッジを表示します。
信頼ストアが同期して更新されていない場合、新しくクロス署名された中間体が EVSE でのパス構築を中断する場所を強調表示します。

コアメッセージ: P&Cの障害の多くは「PKI」のせいだとされているが、実際には パス検証の失敗 クロス署名ドリフトと同期されていない信頼ストアによって引き起こされます。

ACMEと自動化：199日/200日の寿命における人間主導とシステム主導

手動更新が決定論的な停止の原因となる理由

有効期限が短いため、更新は継続的に行われます。DigiCertの 2026年2月24日から199日
これにより、多くの艦隊ですぐに運用が可能になります。そして、業界全体のタイムラインはすでに定義されています。
200日 （2026年3月15日から） 100日、 それから 47日間.

どの艦隊でも、更新イベントは次のようにスケールします。

年間更新イベント数 ≈ N × (365 / L)

どこ 北 TLSエンドポイントの数であり、 L 証明書の有効期間（日数）です。
として L が減少すると、人間主導の更新は数学的に稼働時間目標と両立しなくなります。

シナリオ（ボードレベルのサイズ設定）

CPO運営の場合 5,000エンドポイント199日間の寿命は次のことを意味します。

更新イベント数/年 ≈ 5000 × (365 / 199) ≈ 9,171

この規模では、 1%ヒューマンエラー率 大体
年間92回の証明書による停止—ピーク時の影響を考慮する前に、
SLA ペナルティ、またはハブ全体にわたる連鎖的な障害。

充電ネットワークにおけるACME：自動化すべきこと

ACME (自動証明書管理環境) は、次のような更新をポリシー主導の操作に変換します。

• EVSE ↔ バックエンド TLS
• ローカル コントローラ / エッジ プロキシ TLS
• サイトゲートウェイとハブコントローラ

システム主導のワークフロー（アーキテクチャパターン）

1. 在庫 すべてのエンドポイント (発行者、シリアル、チェーン、有効期限、最終ローテーション)。
2. 事前更新ポリシー （「有効期限が近い」ではなく、一定のしきい値で更新します）。
3. ハードウェアバックアップキー 可能な場合は、秘密鍵のエクスポートを避けてください。
4. 段階的な展開 ヘルスチェック（ハンドシェイク + 承認 + セッション開始）付き。
5. 自動ロールバック 失敗率の上昇について。
6. 証拠ログ すべての発行/展開に対して（コンプライアンス グレードのトレーサビリティ）。

人間主導 vs システム主導

• 人間主導: チケット、スプレッドシート、更新の遅れ、あいまいな所有権、リスクのある緊急の変更。
• システム主導: 決定論的なポリシー、自動発行、制御されたロールアウト、継続的なテレメトリ、監査可能な証拠。

失効チェック：「P&Cキラー」（CRL vs OCSP、脆弱なネットワーク、防御可能なポリシー）

OCSP/CRLがガレージや倉庫で失敗する理由

• LTE/5Gが弱い/断続的
• 制限された出口（ファイアウォール/キャプティブポータル）
• レイテンシに敏感な検証手順
• 外部依存関係（OCSP レスポンダ、CRL 配布ポイント）

結果: EVSEはセッションを開始できるが完了できない 失効検証 確実に。

CRL vs OCSP: 実用的なトレードオフ

• CRL: ダウンロードは重くなりますが、スケジュールに従ってキャッシュおよび更新できます (エッジの継続性に適しています)。
• OCSP: リクエストごとに軽量ですが、最も弱いエッジでのライブ到達可能性が必要になることがよくあります。

2026年には、正しい姿勢が重層化されます。

• 回復力のためのCRLキャッシュのスケジュール
• 接続性が信頼できるOCSP
• 劣化状態に対する明示的なポリシー

「ソフトフェイル」の擁護が難しくなっている理由

歴史的には、「ソフト フェイル」(失効チェックがタイムアウトした場合にセッションを許可する) によって可用性が維持されていました。
2026 年には、次の理由によりソフト フェイルを正当化することが難しくなります。

• 寿命が短くなる（古い仮定に対する許容度が低くなる）
• CRAの報告期限は、事件規律と証拠の追跡を強化する。

防御可能な設計には、明示的で文書化されたポリシーが必要です。

• ハードフェイル 公共/高リスク環境向け
• 証拠のある恵み 閉鎖型艦隊向け（制限されたウィンドウ＋補償制御）
• 証拠記録 あらゆる劣悪な決定に対して

アーキテクチャ上の緩和策（パターン、製品の約束ではない）

パターン1: エッジ事前検証 + キャッシュ

• 定義された鮮度ウィンドウを持つキャッシュCRL
• 中間体と検証済みチェーンをキャッシュする
• 「良好な接続」期間中のプリフェッチ

パターン 2: OCSP ステープリング (可能な場合)

OCSP ステープリングにより、失効証明の配信が最も弱いエッジから切り離され、セッション確立中の CA インフラストラクチャへのライブ依存が軽減されます。

実装ノート（埋め込み現実）: EVSE環境では、ステープル関連の拡張機能のサポートを確認する
組み込みTLSスタックとビルド構成（mbedTLS、wolfSSLなど）で、レガシーハードウェア全体の動作を検証します。
機能の完全性とメモリ/RTOS の制約が異なるためです。

パターン3: マルチルート信頼ガバナンス

• 複数の OEM アンカー用の統合信頼ストア更新チャネル
• パス構築エラーが急増した場合のカナリアアップデート + ロールバック

パターン4: 時間同期ガバナンス（交渉不可）

• NTPポリシー（または適切な場合はPTP）
• ドリフト監視とアラートしきい値
• クロックが信頼できない場合の定義された動作

オフライン継続性: エッジからクラウドへの接続が切断されている間もプラグ&チャージを使用可能に保つ

オフライン継続性とは何か（そしてそうでないもの）

オフライン継続性は「PKIをバイパスする」ことではありません。制御された劣化によって以下のものが維持されます。

• 鍵と信頼ストアの整合性
• 請求とインシデント対応の監査可能性
• ローカルで検証できる内容（およびその期間）に関する明示的な制限

可用性プリミティブとしてのローカル コントローラ / エッジ プロキシ

• ローカル信頼キャッシュ（アンカー/中間キャッシュ/CRL）を維持する
• 限定的なローカル認証ポリシーを適用する
• バッファ計測/ログ（後で調整するため）
• EVSEのローカルエンドポイントとして機能することでWANの爆発半径を縮小

図2（推奨ビジュアル）：脆弱なネットワークサイトにおける信頼キャッシュとしてのエッジプロキシ

（オンサイトのエッジプロキシ/ローカルコントローラに接続するEVSEを示します。プロキシはキャッシュされたトラストアンカー/中間物を維持し、
スケジュールされた CRL 更新、時間同期監視、および証拠ログ。アップリンクが不安定な場合は、イベントをクラウド CSMS/PKI にバッファリングします。

コアメッセージ: エッジ プロキシは、外部の OCSP/CRL エンドポイントへのライブ依存性を軽減し、PKI をバイパスせずに制御されたオフライン継続性を実現します。

CRAとVMP：2026年9月から監査可能な運用モデルへの報告期限

CRA報告ルール: 24時間/72時間クロックの設計

CRAの報告規則では、製造業者は積極的に悪用されている脆弱性や、影響を与える重大なインシデントを報告することが義務付けられている。
デジタル要素を含む製品のセキュリティについて:

• 24時間以内の早期警告 気づくこと
• 72時間以内に完全な通知
• 最終報告書 定義されたウィンドウ内（インシデントクラスによって異なります）

大規模な失効やトラストアンカーの侵害によって引き起こされる大規模なプラグ＆チャージの中断 資格があるかもしれない
影響と悪用の証拠に応じて重大なインシデントとして分類されます。

脆弱性管理プロセス（VMP）：最小限の実行可能な機能

1. 艦隊の真実： 資産 + バージョン インベントリ (EVSE ファームウェア、コントローラー イメージ、信頼ストアのバージョン)。
2. SBOM統合（動的）: SBOM は展開可能な成果物にマッピングされ、脆弱性インテリジェンスと継続的に相関します。
3. VEX 駆動型露出管理: VEX ステートメントを維持して、「存在するが悪用可能ではない」と「展開で悪用可能」を区別し、T+24 時間ウィンドウ内での信頼できるスコープ設定を可能にします。
4. 24時間制においてVEXが重要な理由: SBOMは何が存在するかを教えてくれます。VEXは何が存在しないかを判断するのに役立ちます。 悪用可能誤報を減らし、運用チームが悪用できないノイズを追跡することを防ぎます。
5. 受付とトリアージ: サプライヤーのアドバイス、CVE、内部調査結果。悪用可能性と露出を優先します。
6. T+24h スコープワークフロー: SBOM + VEX + 在庫相関による影響を受けた集団の特定、初期封じ込めの決定、証拠の捕捉。
7. T+72h 通知ワークフロー: 確認された範囲、緩和策、ロールアウト/ロールバック計画、通信記録。
8. 最終レポートのワークフロー: 検証証拠 + 根本原因 + 是正措置の利用可能性後の予防改善。
9. パッチケイデンスエンジニアリング: 段階的なロールアウト、ロールバック計画、署名済みアーティファクト、検証ゲート。
10. 信頼チェーンの実施: セキュア ブート + セキュア ファームウェア アップデート、HSM/セキュア エレメントで保護された署名キー。
11. 証拠優先のログ記録: 証明書イベント、信頼ストアの変更、失効の失敗、時間同期の健全性。

重大度の高い信頼シナリオ: ルートまたは発行キーの侵害によって失効が引き起こされた場合、
これを最高レベルの信頼インシデントとして扱い、即時の封じ込め、艦隊全体の信頼ストアのアクション、
影響と搾取の証拠に応じて、CRA に準拠した報告の準備を整えます。

CRA インシデント対応カウントダウンチェックリスト（運用テンプレート）

T+0（検出/認識）

• 凍結の証拠: ログ、証明書イベント、信頼ストアのバージョン、時刻同期ステータス
• 影響を受けるサーフェスを特定する: EVSE ファームウェア、ローカル コントローラ、バックエンド TLS エンドポイント
• PKIプロバイダー/バックエンドセキュリティ担当者と連携する

T+24h（早期警戒態勢）

• 主な目的: 使用 SBOM + VEX + 艦隊インベントリ 影響を受ける人口を特定し、証拠に基づいた早期警告を提出する
• 封じ込めを決定する: 取り消し/ローテーション、信頼ストアのロールバック、サイトの分離
• 早期警戒パッケージ案：範囲、進行中の緩和策、暫定的な態勢

T+72h（通知準備完了）

• 地域/サイトごとに影響を受ける人々を確認し、修復計画と展開方法を提供します。
• 顧客/オペレーターのコミュニケーションとエスカレーション記録を作成する

最終報告ウィンドウ

• CRA の要件に準拠した最終レポートを提出します (タイミングはインシデント クラスによって異なります)
• 修正後の検証証拠と学んだ教訓

コストとリスクの定量化（フリートに組み込めるテンプレート）

手動更新の労働コストモデル

させて：

• 北 = TLSエンドポイントの数（EVSE + コントローラ + ゲートウェイ + 管理対象バックエンドノード）
• L = 証明書の有効期間（日数）
• t = 更新あたりの人的時間（時間）
• c = フル装備の労働コスト（USD/時間）

労働コスト ≈ N × (365 / L) × t × c

停止リスクモデル（有効期限切れまたはデプロイ失敗）

させて：

• P_ミス = サイクルごとの更新の失敗/欠落の確率
• H_ダウン = インシデントあたりの予想ダウンタイム時間
• C_時間 = 時間単位のビジネスへの影響（収益損失、ペナルティ、SLA クレジット）

コスト_停止 ≈ P_miss × H_down × C_hour

意思決定ガイド: オンライン失効チェックが失敗した場合 (OCSP/CRL タイムアウト)

1. 公開サイトか、それとも閉鎖された艦隊/デポか?
   • 公開 → 優先 ハードフェイル （または、証拠と補償制御のみで厳密に制御された恩恵）
   • 艦隊/倉庫 → 証拠のある恵み 限られた時間内では許容できるかもしれない
2. ネットワークの信頼性は予測可能ですか?
   • はい → オンラインOCSP/CRL + 監視
   • いいえ→ エッジ事前検証 + キャッシュ （CRL更新ウィンドウ、キャッシュされたチェーン）
3. セッション時にオンライン依存を減らすことはできますか?
   • 実行可能な場合→採用する OCSP ステープルパターン （端に近づけるとプルーフが開きます）
4. 証拠ログ + 時間同期ガバナンスはありますか?
   • そうでない場合 → まずこれらを修正してください。これらがないと、デグレードモードのポリシーを守るのは困難です。

実用的な責任マトリックス（停止を防ぐ境界）

用語集

• 公開鍵暗号: 公開鍵基盤（発行、検証、信頼アンカー、失効）
• アクメ: 自動証明書管理環境（自動発行・更新）
• OCSP/CRL: オンライン証明書ステータスプロトコル / 証明書失効リスト
• OCSP ステープリング: サーバーは失効証明を提示し、ライブOCSPへの依存を減らす
• 信頼アンカー: バリデーターが信頼するルート証明書/中間証明書
• SBOM: ソフトウェア部品表（脆弱性スコープのコンポーネントインベントリ）
• ヴェックス： 脆弱性悪用可能性交換（悪用可能性ステータスステートメント）
• TLS 1.3: 最新の TLS プロファイル。ハンドシェイク + 証明書の検証は遅延の影響を受けやすいままです。
• VMP: 脆弱性管理プロセス（受付、トリアージ、パッチ適用、報告、証拠）

将来的なリスク：暗号通貨の俊敏性とPQCの準備

2026年はTLSの寿命が短くなり、CRAの報告が主流となるが、課金インフラは評価を始めるべきである。
暗号の敏捷性長期使用資産（車両と充電器）の場合、アーキテクチャはハードウェアのロックインを回避するために、
HSM/セキュア エレメントと組み込みスタックは、ハードウェアの更新を必要とせずに、将来のアルゴリズムと証明書プロファイルの更新をサポートできます。

よくある質問

プラグ＆チャージはオフラインでも使えますか？

部分的に設計上。オフラインP&Cは、ローカルトラストキャッシュ（可能な場合はアンカー/中間キャッシュ/CRL）を使用して制御された劣化です。
明示的な猶予ポリシーと、調整のためのバッファリングされた監査ログ。PKIをバイパスするのではなく、ライブクラウドへの依存を減らす必要があります。
整合性と監査可能性を維持しながら。

有効期間が 199 日または 200 日の証明書はどのくらいの頻度で更新する必要がありますか?

エンドポイントごとに年間で複数の更新サイクルを計画してください。多くの事業者にとって、運用の切り替えは
2026年2月24日 DigiCertは最大で 199日間 その日から有効となります。
より広いエコシステムレベルでは、ベースライン要件は段階的な削減を定義しています。 200/100/47日.

CRA 報告義務が発生するきっかけは何ですか?

CRAの報告規則では、 24時間早期警告 そして 72時間前通知 積極的に悪用される脆弱性や深刻なインシデントに対して
最終報告期間も延長されます。大規模なP&Cの信頼関係の破壊（悪意のある失効や認証の侵害など）は、状況に応じて対象となる場合があります。
影響と活用の証拠に基づいて、CRA対応のVMPは以下をサポートする必要があります。 SBOM + VEX + 艦隊インベントリ 最初の 24 時間以内にスコープを設定します。