Blog:
EU CRA：施行直前！2026年9月開始の脆弱性報告の対策

「サイバーレジリエンス法」が話題になってからすでにかなりの時間が経過しており、多くのデバイスメーカーは、これを「期限」としてではなく、「背景の雑音」として捉えるようになっていた。しかし、以下を期して状況は一変する。 2026年9月11日、CRAの最初の法的義務が発効する日です。この日から、デジタル要素を含む製品をEU市場に投入する事業者は、自社製品に影響を及ぼす悪用された脆弱性やセキュリティインシデントについて、中央報告プラットフォームへの報告を開始しなければなりません。

朗報なのは、この第1段階において、具体的な義務や「報告対象となる事案」とみなされる基準が、当初想像していたよりも狭く設定されているという点です。

報告義務が発生するのは、脆弱性が単に存在しているという事実ではなく、実際のエンド製品において実際に悪用された場合に限られます。しかし、残念なことに、報告義務が生じた場合、その期限は非常に短いものとなります。

では、要件がどのようなものか、準備のために何をする必要があるか、そして今後どうなるのかについて、詳しく見ていきましょう。

報告義務のみ

CRAの第14条では、製造業者が通知しなければならない事項として、正確に2つが挙げられています：

1. 積極的に悪用されている脆弱性 製品内。

2. 重大な事件 製品の安全性に影響を及ぼす。

これが、9月の義務の全容です。

それ以外のすべて（設計段階からのセキュリティ確保に関する要件、セキュリティ更新プログラムの実際の出荷義務、適合性評価、CRAの基本要件に基づくCEマーキング）は、2027年12月に規制の残りの部分とともに施行される。

「積極的に搾取されている」とは、現場で実際に搾取されていることを意味する

これは、ここ数年間CRA業務に携わる中でメーカー各社と話し合う中で最も頻繁に見られる誤解であるため、最もしっかりと理解しておくべき点です。 報告が必要なのは、「実際に悪用されている脆弱性」と「製品のセキュリティに影響を与える重大なインシデント」です。「実際に悪用されている脆弱性」については、CRAの条文自体に明確に定義されています：
「積極的に悪用された脆弱性」とは、悪意のある攻撃者が、システム所有者の許可なく、そのシステムにおいて当該脆弱性を悪用したという信頼できる証拠が存在する脆弱性を指す。

そうね ではない ENISAに対し、自社製品に公開済みのCVEを持つコンポーネントが含まれていることを報告する必要があります。ただし、自社のセキュリティチームが発見した脆弱性については報告する必要はありません。また、実験室での概念実証、理論上の攻撃経路、あるいはスキャナーによる検出結果についても報告する必要はありません。これらはいずれも、第14条に基づく報告対象事象には該当しません。

報告の対象となるのは、悪意のある攻撃者がコードを実行したり、デバイスを乗っ取ったり、あるいはその他の方法でその脆弱性を悪用したという信頼できる証拠がある脆弱性です。 現場にある製品に対して、ユーザーや製造元の知らないうちに.

重大なインシデントについても同様の論理が当てはまります。つまり、重大なインシデントとは、製品のセキュリティを実際に侵害した、あるいは現実的に侵害する可能性があった生産環境における事象を指します。CRAが対象とするインシデントの例としては、デバイスがテレメトリデータを送信するクラウドバックエンドが侵害され、ユーザーアカウント情報が漏洩したようなケースが挙げられます。

社内の方針や手順を策定する際には、欧州委員会のCRAガイダンスに記載されている以下の2つの留意点について知っておく価値があります：

• あなたには調査する義務があります。 搾取の疑いがある事案を検知した場合、またはその報告を受けた場合は、それが事実であるかどうかを判断できるよう、十分に調査を行わなければなりません。調査を拒否したからといって、報告期限を回避することはできません。報告期限は、その事実を認識した時点で開始されます。また、インシデント対応プロセスは、その調査を妨げるのではなく、支援するものでなければなりません。
• サードパーティ製コンポーネントは、一度悪用されてしまえば、あなたの責任となります。 自社製品に含まれるアップストリームライブラリの脆弱性が実際に悪用されている場合は、その脆弱性を報告する必要があります。そのコードを自社で記述していないという事実は、報告の可否とは無関係です。一方、自社製品で出荷しているコンポーネントに脆弱性があることを知っただけで、自社製品内でその脆弱性が悪用されていない場合は、報告する必要はありません。

もうひとつ安心できる点があります。それは、あなたが把握したインシデントや、実際に悪用されている脆弱性についてです。 以前 2026年9月11日については、報告する必要はありません。未処理案件を引き継ぐことはありません。

締切日

それでは、報告要件の中で最も具体的な部分、つまり期限について見ていきましょう。

これらはENISAへの報告期限であり、報告内容は機密扱いとなる点にご留意ください。この期限までに、一般向けに公開できるような完成度の高い回答を作成する必要はありません。

24時間は、運が良ければ1営業日ですが、運が悪ければ週末になってしまいます。9月までに方針、手順、担当者を整えておかないと、その期限に間に合わせることは非常に困難になるでしょう。

単一報告プラットフォーム

第16条は、 単一報告プラットフォーム（SRP）、ENISAが運営するこのシステムを、これらの通知の受付窓口としています。報告はその後、関連する各国のCSIRT（コンピュータ・セキュリティ・インシデント対応チーム）に転送されます。これは意図的な設計です。もしそうでなければ、各メーカーが30以上の各国のCSIRTに個別に報告を行うことになり、それは誰も望んでいなかったからです。

具体的には、9月までに：

• あなたの「指名代表者」となる人物の名前を記入してください。 誰があなたに代わって申請を行う権限を持つか、またその代理人は誰かを決めておきましょう。24時間体制のシステムは、セキュリティ担当責任者が休暇中であるなどという事情を一切考慮しません。
• プラットフォームへの登録の準備をしてください。 プラットフォーム自体はまだ利用できませんが、すでに ドキュメント ARとして登録するために必要なことについて。事前にできることの一つとして、ARが正常に動作していることを確認してください。 EUログイン アカウント。
• リハーサルや机上の演習を行ってください。 架空の悪用された脆弱性を、検出 → 優先順位付け → 報告対象であるとの判断 → 24時間以内の報告 → 72時間以内の評価、という一連のプロセス全体を通じて追跡してみてください。
• 今すぐ責任ある情報開示方針を作成しましょう。 CRAは、いつ情報を公開すべきかを強制するものではありませんが、顧客やCSIRT、場合によっては90日間の期限を課された研究者など、各方面から様々な意見が寄せられるでしょう。インシデント発生中に情報開示の方針を決定しようとすると、結果として不適切な対応を招くことになります。責任ある情報開示方針の策定もCRAの要件の一つであるため、今から準備を始めておくのが賢明です。

他に何かすべきことや準備すべきことはありますか？

2026年9月の義務には、報告された脆弱性に対して実際にパッチを適用する義務は含まれていません。セキュリティ更新プログラムを提供する義務は、CRAのその他の基本要件と同様に、2027年12月になって初めて課されることになります。

しかし、現実的な観点から言えば、修正パッチを適用する手段がないインシデントを報告するのは得策ではありません。例えば、最終報告書には緩和策を記載する必要があります。 14日後に「申し訳ありませんが、この問題に対するパッチはありません」と回答することになれば、顧客はその対応にあまり満足しないでしょう。さらに言えば、この報告体制全体は、多くのデバイスメーカーが現在回答できない一連の質問に対して、信頼できる回答ができることを前提としています： この脆弱性は当社の製品にも存在しますか？もしそうであれば、どのバージョンに存在しますか？また、それらのバージョンを実行しているデバイスはいくつあり、EUのどの国にある可能性がありますか？

こうした疑問点があると、十分な準備ができていない場合、24時間という期限は「厳しい」ものから「不可能な」ものへと変わってしまいます。 CSIRTや顧客、研究者から、自社のデバイスがCVEの悪用を受けていると通報された場合、彼らに対して行うべき調査は、まず自社の部品表（BOM）と、現場に展開されているデバイスの導入状況を把握することから始まります。それがなければ、3日間のプロセスの初日を、何を出荷したのかを把握することに費やすことになってしまいます。

基本的なニーズは以下の通りです：

• リリースされたイメージごとに管理されたSBOM。 これは、悪用された可能性のあるCVEを調査する際に、まず必要となるものです。正確な情報が手元にある場合は、 実行可能な リリース済みの製品に対応するSBOMがあれば、影響範囲を判断するためのより確かな基準となります。
• そのSBOMに対するCVEの継続的な追跡。 潜在的な脆弱性について初めて知るのが、実環境でエクスプロイトが発見された時点である場合、24時間以内に対応することはほぼ不可能です。CVEを継続的に監視することで、インシデント発生時に初めてパニック状態で対応するのではなく、自社のスケジュールに合わせて脆弱性の優先順位付けを行うことができます。
• 車両の可視性。 適切な端末管理と監視体制が整っていれば、どの端末がどのバージョンを実行しているか、またそれがどの国にあるかを把握することができます。これは、脆弱性が発見された場合に、24時間体制の早期警告システムが実際に求めていることなのです。
• 安全で信頼性の高い更新システム。 これが、報告対象となる事象を解決済み事象に変えるものであり、いずれにせよ2027年12月からは必須要件となります。早めに導入しておけば、2027年の製品セキュリティ対策がはるかにスムーズに進むでしょう。

これらはいずれも、特に珍しいことではありません。セキュアな製品開発のためのベストプラクティスに従い、基本的なツールやプロセスが整っているなら、おそらくそのほとんどはすでに備わっているはずです。

TorizonがCRAへの対応準備をどのように支援できるか

Torizonは、こうしたあらゆる問題に対して、信頼性が高く、安全で、使いやすいソリューションを提供します。 Torizon OS 実際にデプロイしたイメージのソフトウェア部品表（SBOM）が管理された状態で提供され、Torizon 脆弱性管理ツール 公開された脆弱性について継続的に追跡しているため、「このCVEは自社のデバイス群に影響するか？」という疑問に対して、誰かが質問する「24時間以内」という期限が切れる前に、その答えが得られます。また、お客様の実際の脅威モデルに基づき、実際に導入されているデバイスに対する脆弱性の監視および優先順位付けも提供しています。

Torizon Cloudのセキュアな 無線アップデート このシステムでは、Uptaneがバックエンドで動作し、すべてのデバイスから署名付きマニフェストを取得できるため、問題の2つの側面を1か所で解決できます。つまり、出荷した品目の正確な証拠が得られるだけでなく、現場で内容を変更することも可能です。前者の側面こそが、2026年9月の報告義務の根拠となるものです。 2つ目の要件は、2027年12月から義務化されるものです。

コンプライアンスは、この点において有用な推進力ではありますが、これを行う本当の理由ではありません。その理由は、もしコンプライアンスを遵守していなければ――つまり、自社製品が悪用されていることに気づいた時点で、その製品に何が含まれているかを突き止めなければならない状況に陥る――それは、絶対に避けたいような最悪の一日（いや、実際には最悪の一週間）になってしまうからです。