出荷後も続くセキュリティ責任――CRAと改正PL指令に日本企業はどう備えるか

制裁金だけではない、CRAが経営にもたらすリスクとは

林：
次に、CRAと改正PL指令が企業経営に与える影響を深掘りしていきます。

CRAに対応できなければ、高額の制裁金にとどまらず、製品の販売禁止やリコールにつながる可能性があります。一方、製品の欠陥によって損害が生じれば、改正PL指令に基づく損害賠償責任も問題になります。つまり、対応の不備は単なるコンプライアンスコストではなく、企業の屋台骨を揺るがすリスクになり得ます。エレドンさんにお聞きします。日本企業の経営者はこうしたリスクをどのように捉えるべきでしょうか。財務面や事業面への影響を含め、教えてください。

エレドン：
CRAの特徴の一つは、対象範囲の広さです。インターネットに接続する製品は、自動車など一部の例外を除き、幅広く規制対象となります。

対象製品をEU市場に投入するには、サイバーセキュリティ要件への適合が必要です。適合はCEマーク^（※5）を付す前提となるため、セキュリティ要件の実装や脆弱性ハンドリングの体制が整っていなければ、EU市場で販売できません。企業にとっては、制裁金以前に、EU市場で販売できなくなるリスクがあります。

また、CRAへの対応は、市場投入時に完結するものではありません。EU市場へ上市後も継続して対象製品のリスクアセスメントやセキュリティ対策が必要です。対応を怠れば、CRA違反になりかねません。こうした出荷後の対応は見落とされがちです。

違反時の制裁も重く、制裁金は最大で1,500万ユーロまたは全世界売上高の2.5％のいずれか高いほうが科せられます。当局は是正命令に加え、対策が著しく不十分な場合には販売禁止やリコールを命じることもできます。多くの場合、製造者として責任を負うのは本社であり、影響は現地法人にとどまらず、グループ全体に及ぶ可能性があります。

さらに、セキュリティ上の不備は、改正PL指令に基づく民事責任にもつながります。例えば、深刻な脆弱性が判明したにもかかわらずアップデートの提供が遅れ、その結果、ユーザーに人身・財産の被害が生じれば、損害賠償責任を問われる可能性があります。一つのセキュリティ不備から、CRA上の行政リスクと改正PL指令上の民事リスクが連鎖することになります。

その影響は法的責任にとどまりません。損害賠償などの財務負担に加え、ブランド毀損にもつながります。製品のサイバーセキュリティが競争力を左右する中、「セキュリティに問題がある製品」と見なされれば、レピュテーションにも大きな影響を及ぼします。

図表2：制裁金だけではない、CRAが経営にもたらすリスク例

林：
ここまで見てきた経営リスクの背景には、CRAによる製品安全の考え方の変化があります。従来のCEマーキングでは、主に電気的・機械的な安全性が重視されてきましたが、CRAではそこにサイバーセキュリティという新たな観点が加わります。

石川先生、CRAは製品にどこまでサイバーセキュリティを求めるのでしょうか。法令の狙いと対象範囲、製造者に課される主な義務を整理していただけますか。

石川：
CRAには製品のサイバーセキュリティを確保するだけでなく、利用者が製品を選択・利用する際に、サイバーセキュリティを判断材料にできるようにする狙いがあります。

CRAの対象範囲は非常に広く、EU市場で提供される、ネットワークやデバイスと直接・間接に接続できるハードウェア、ソフトウェアはもちろん、製品の機能に不可欠な遠隔データ処理ソリューション^（※6）も対象となります。

製造者には、製品そのものに関するサイバーセキュリティ必須要件への適合に加え、脆弱性に対応するプロセスの整備が求められます。その基本となるのが、設計段階からセキュリティを組み込む「セキュア・バイ・デザイン」^（※7）の考え方です。

また、先述した重大インシデントなどの報告義務は、すでに販売されている製品にも及ぶと解されています。そのため、EU市場ですでにデジタル要素を含む製品を販売している日本企業は、CRAの全面適用を待たず、報告体制を整備する必要があります。これは喫緊の課題です。

林：
つまり、すでに販売済みの製品にもCRAへの対応が必要になるのでしょうか。

石川：
報告義務に限ればそのとおりです。ただし、CRAの全ての要件が既存製品にさかのぼって適用されるわけではなく、サイバーセキュリティ必須要件を後から満たす必要はありません。販売済みの製品に求められるのは、重大インシデントなどが発生した場合の報告です。

報告義務からサプライチェーン管理まで――CRA対応の実務

林：
CRAが求める義務が明確になった今、次に問われるのは、企業がそれを実務でどう実行するかです。

日本のメーカーは従来、製品の出荷をもって品質責任の区切りとしてきた傾向があり、出荷後の脆弱性対応まで含めた体制を十分に整備できているとは限りません。一方、CRAへの対応では、脆弱性・インシデントの報告体制、SBOM^（※8）を活用したサプライチェーン管理、サポート期間の設計や無償更新の体制など、幅広い実務の再構築が必要になります。

エレドンさんにお聞きします。企業は何から着手し、どのような順序で対応を進めるべきでしょうか。実務上の主なハードルも含めて教えてください。

エレドン：
最優先に実施すべきは、すでに適用が始まっている報告義務への対応です。石川先生が指摘されたとおり、重大インシデントや積極的に悪用されている脆弱性は、販売済みの製品も報告対象となります。CRAに基づく報告プラットフォームの整備も進んでおり、必要な情報を収集し、迅速に報告できる体制を整えることが急務です。

次に必要なのが、製品のライフサイクル全体を見据えた対応体制です。CRAでは、設計・製造から販売後のアップデートまで継続的な対応が求められるため、単一部門では対応できません。製品設計を見直すとともに、PSIRT^（※9）など、脆弱性対応を担う専門組織を整備する必要があります。

さらに自社製品だけでなく、サプライチェーンの管理も欠かせません。脆弱性のある部品を調達すれば、製品全体のCRA適合にも影響します。設計・開発部門に加え、調達や法務も含めた横断的な対応が必要です。

実務上、特に難しいのが対象範囲の判定です。例えば、OEM先に製造を委託した自社ブランド製品でも、自社の名称や商標で市場投入すれば、CRA上の「製造者」に該当します。OEM先が製造していることを理由に、自社を対象外と判断することはできません。

クラウドサービスについても、CRAの対象となるかどうかの判定には注意が必要です。ポイントは、SaaS（Software as a Service）という提供形態そのものではなく、そのサービスによる遠隔処理が製品の機能に不可欠かどうかです。SaaSだけでサービスが完結する場合と、製品と一体となって機能する場合とでは、CRA上の扱いが異なります。提供形態だけで対象外と判断すると、適用範囲を見誤る可能性があります。

図表3：報告義務からサプライチェーン管理まで――CRA対応の実務

林：
ではSaaSとして提供されているサービスは、どのような場合にCRAの対象になるのでしょうか。

エレドン：
判断基準は、そのサービスによる遠隔処理が製品の機能に不可欠かどうかです。切り離すと製品が本来の機能を果たせない場合は、「遠隔データ処理ソリューション」としてCRAの対象になります。一方、SaaS単体で完結するサービスはCRAの対象外ですが、NIS2指令など別の法令の規制を受ける場合があります。

石川：
例えば、クラウド経由でなければ施錠・解錠できないスマートロックは、製品とクラウド処理が一体なのでCRAの対象になります。これに対し、製品を伴わずSaaSだけで完結する業務ソフトのようなサービスは対象外です。

報告の遅れから株価下落まで――連鎖する損失の仮想シナリオ

林：
CRAへの対応を考えるうえでは、改正PL指令との関係も見逃せません。CRAは、市場投入前から販売後まで、製品のセキュリティ確保や脆弱性対応を製造者に求めます。一方、改正PL指令は、製品の欠陥によって損害が生じた場合の賠償責任を定めています。つまり、製品ライフサイクルの上流から下流までCRAによるセキュリティ対応が求められ、その先で損害が生じれば改正PL指令による賠償責任が問われます。いわば、製造者を二つの法令が挟み込む構造です。

そのため、一つの脆弱性を起点に、CRA上の制裁とPL訴訟が重なり、損失が膨らむ可能性もあります。こうした連鎖は企業経営にどこまで影響し得るのでしょうか。具体的なケースで教えてください。

エレドン：
では、CRAと改正PL指令が連鎖するシナリオを想定してみましょう。

起点は、既存製品に悪用が確認されている脆弱性が見つかることです。こうした脆弱性は報告義務の対象となるため、社内での認識や報告が遅れれば、CRA違反と判断され、制裁金や、場合によっては販売停止などの措置につながる可能性があります。

さらに、その脆弱性によって製品に不具合が生じ、ユーザーに損害が発生すれば、改正PL指令に基づく訴訟に発展する可能性があります。その際、脆弱性ハンドリングの体制が十分でなく、SBOMをはじめ、セキュアな開発や継続的な脆弱性対応を行ってきたことを示す記録も整備されていなければ、訴訟上も不利になり得ます。

こうなると、企業が負うコストは一気に膨らみます。CRA上の制裁金に加え、リコールとなればその費用が発生し、PL訴訟では損害賠償責任を問われる可能性があります。さらに、事案によっては第三者委員会の設置や調査対応が必要となり、上場会社であれば株価への影響も考えられます。深刻なケースでは、減俸や辞任など、経営陣の責任問題にまで波及する可能性があります。

CRAや改正PL指令への対応を現場任せにしていると、一つの脆弱性が法的リスク、財務リスク、経営リスクへと連鎖しかねません。製品セキュリティは、全社・グループ横断で取り組むべき経営課題なのです。

図表4：欧州規制対応をグローバルな経営課題へ（例）

林：
石川先生、CRA違反と改正PL指令上の「欠陥」は、法的にはどのような関係にあるのでしょうか。

石川：
CRAに違反したからといって、直ちに改正PL指令上の「欠陥」と認定されるわけではありません。ただし、CRA違反の事実が、PL訴訟で欠陥を判断する際の有力な証拠になり得ることは、欧州委員会のQ&Aでも示されています。

すなわち、改正PL指令では、欠陥を判断する際、製品を販売した時点に加え、その後のセキュリティアップデートの提供状況も考慮されます。必要なアップデートを提供しなければ、CRA上の義務違反であると同時に、改正PL指令上も欠陥と判断される可能性があります。つまり、CRAへの適切な対応は、PL訴訟のリスクを低減することにもつながるのです。

欧州規制対応をグローバルな経営課題へ

林：
最後に、欧州規制への向き合い方について伺います。

CRAや改正PL指令への対応は、企業にとって決して軽い負担ではありません。一方、EUの規制や基準は、グローバル企業の製品設計やサプライチェーンを通じて域外にも波及する可能性があります。対応を先送りすれば、将来、欧州以外の市場でも後手に回りかねません。こうした状況を踏まえ、企業はCRAや改正PL指令への対応をどのように進めるべきでしょうか。

石川：
まず重要なのは、制裁金の大きさだけで対応の要否を判断しないことです。CRAに対応できなければ、そもそもEU市場で製品を販売できなくなります。製造業にとっては、制裁金以上に市場を失うリスクのほうが深刻です。EU市場で事業を継続する以上、対応を避けて通れない法令だと考えるべきです。

もう一つは、CRAには「ブリュッセル効果」^（※10）が生じやすいことです。データ法やAI法と比較し、CRAはその影響がEU域外にも波及しやすいと考えられます。CRAに対応するには、EU向け製品に脆弱性管理や長期的なアップデートの仕組みを組み込み、サプライチェーンにも同様の対応を求める必要があります。そうなると、市場ごとに製品仕様を変えるより、CRAに対応した仕様をグローバルに展開する方が効率的です。

実際、デジタル要素を含む製品にセキュリティ要件を課す動きは英国などにも広がり、日本でも経済産業省のガイドラインなどが同様の方向性を示しています。企業に問われているのは、CRAに対応するか否かではありません。製品セキュリティの基準がグローバルに広がることを前提に、いかに対応するかです。

林：
では、こうした規制を経営課題として捉えた場合、企業は実務面でどのような体制を整える必要があるのでしょうか。

エレドン：
前提として、CRAへの対応は特定の部門だけに任せられるものではありません。求められるのは、製品の設計・開発から調達、販売後の対応までを一つの流れとして捉え、全社で管理できる体制です。

そのためには、大きく二つの観点が必要になります。一つは「組織」です。経営主導で部門横断の責任者や組織を設け、設計・開発、調達、法務、セキュリティ、アフターサービスなどが連携できる体制を整える必要があります。従来の縦割り組織のままでは、製品ライフサイクル全体を通じた対応は難しいからです。

もう一つが「バリューチェーン」です。自社内の製品開発だけを管理すればよいわけではありません。脆弱性は調達した部品やソフトウェアから入り込み、対応は販売後にも続きます。したがって、調達から販売後の脆弱性対応やアップデートまで、サプライチェーンを含む一連のプロセスを管理する必要があります。

改正PL指令への備えも、この体制の延長線上にあります。セキュリティ上の脆弱性や販売後の対応が欠陥判断の要素となり得る以上、CRA対応のために整えた組織やプロセスは、そのままPL訴訟への備えにもなります。

林：
CRAや改正PL指令への対応では、経営主導の部門横断体制と、サプライチェーンを含む製品ライフサイクル全体の管理が重要になるということですね。本日はありがとうございました。