EU CRA報告義務の実務対応｜報告対象と「24時間」の起算点をケース別に解説【第1回】

2026年9月11日、EUサイバーレジリエンス法（CRA）の報告義務が適用されました。EU市場にデジタル製品を出す製造業者は、悪用された脆弱性や重大インシデントを認知したら、24時間以内に早期警告を出さなければなりません。ENISAは同日、報告窓口となる「Single Reporting Platform（SRP）」の運用を始めました。

ところが公式資料は、法文、欧州委員会のFAQとガイダンス、ENISAのFAQ・ガイダンス・Glossary・マニュアル・動画と多岐にわたります。法文は各EU公用語で読めますが、実務資料の中心は英語で、SRP自体も現時点では英語のみです。

本稿は全2回に分けて、これらを交通整理します。第1回では、「その事象は本当に報告対象か」「24時間はいつから動き始めるか」という2つの判断を、ケース別に解説します。

はじめに

第1回の要点は次の2点です。

第一に、脆弱性が存在することと、CRA14条の義務的報告の対象になることは別であり、悪意ある悪用の信頼できる証拠があるか、その悪用が自社製品で起きているかが分かれ目になります。

第二に、24時間は第一報を受け取った瞬間ではなく、初期評価で合理的な確度に達した時点から動き始めるため、認知時刻を自社で説明できる記録が要になります。

何が開始されたのか

報告対象は2種類です。

• 悪用された脆弱性（AEV）：悪意ある者がシステム所有者の許可なく悪用したという、信頼できる証拠がある脆弱性（3条42号）
• 重大インシデント（SI）：製品が重要または機微なデータ・機能の可用性・真正性・完全性・機密性を保護する能力を損なう（または損ない得る）インシデント、あるいは製品やそのユーザーのシステムで悪性コードの導入・実行につながった（またはつながり得る）インシデント（14条5項）

期限は次の3段階です（14条2項・4項）。

AEVおよび重大インシデントの報告期限

見落とされがちな点が2つあります。

第一に、報告義務はCRA本体の全面適用（2027年12月11日）より前に上市した製品にも適用されます（69条3項）。

第二に、制裁金です。ただし、いつから適用されるかには留保があります。71条2項が2026年9月11日からの先行適用として挙げているのは14条（と第IV章）であり、64条は列挙されていないため、先行適用された14条の違反にこの制裁金規定がいつから適用されるかは、別途確認が必要です。

そのうえで水準を押さえておくと、64条2項は、14条違反について最大1,500万ユーロ、または全世界年間売上高の2.5%のいずれか高い額を行政罰金の上限として定めています。零細企業・小企業については、24時間の早期警告の期限違反に限り行政罰金を適用しないとされています（64条10項）。

各資料の位置づけ：どの資料を何のために読むべきか

ENISAの資料は主としてSRPの運用実務を扱い、解釈の問題は欧州委員会の資料を参照させています。ENISA資料だけで実務上の答えが得られる場合もありますが、報告対象かどうかの解釈根拠を確かめるには、欧州委のFAQ・ガイダンスまで遡る必要があります。

なお欧州委のガイダンスは法的拘束力を持たず、最終的な解釈権限はEU司法裁判所にあります。

本連載（第1回・第2回）で引用する資料の位置づけを下表で簡単に整理します。

資料の位置づけ

報告判断の全体像

CRAの報告対応では、最初からSRPの入力項目を追うのではなく、まず次の3つを順に整理すると全体像をつかみやすくなります。

• 何を報告するのか：その事象がAEVまたはSIとして報告対象になるか
• いつから期限が動くのか：製造業者がいつ「認知」したと扱われ、24時間・72時間の期限のカウントがいつ始まるか
• 誰が、どこへ、どうやって出すのか：報告先のCSIRT、SRPの担当者、実際の提出方法をどうするか

このうち「何を報告するのか」と「いつから期限が動くのか」を、本稿にて順に見ていきます。「誰が、どこへ、どうやって出すのか」は第2回で扱います。

あわせて第2回では、この3つが決まったあとに実際にSRPの画面へ入力する段階で、初期リリース固有の仕様や画面表示につまずかないための注意点を取り上げます。

1．それは報告対象か

脆弱性やセキュリティ上の問題が存在することと、CRA14条の義務的報告の対象になることは同じではありません。脆弱性が見つかっただけではAEVにはならず、顧客環境で被害が発生しただけでSIになるわけでもありません。

報告対象かを検討するときは、次の4つを順に切り分けると整理しやすくなります。

• 何が起きたのか：脆弱性の発見なのか、実際の悪用なのか、インシデントなのか
• 自社製品とどう関係するのか：その製品で悪用可能なのか、実際に悪用されたのか
• 14条の定義を満たすか：AEVまたはSIとして義務的報告の対象になるのか
• 適用上の境界条件はないか：旧製品、SaaS、適用開始日前後などをどう扱うか

以下では、この4つの切り分けで迷いやすい場面をケースごとに見ていきます。

ケースA1〜A7の一覧

ケースA1　バグバウンティで未公開の脆弱性が報告された

結論：悪意ある悪用の証拠がない限り、義務的報告の対象外です。

根拠：欧州委FAQ5.2は、倫理的ハッカーがバグバウンティ経由で報告したゼロデイや、委託先の評価ラボが試験で見つけた脆弱性について、悪意ある悪用の証拠がなければAEVに当たらないとしています。

実務では：「脆弱性が見つかった」ことと「CRA14条の義務的報告が必要」なことを分けて判断することが有効です。任意報告（15条）は可能ですが、SRPの任意報告機能はまだ実装されていません。

ケースA2　顧客から「未修正の脆弱性を突かれた」と証拠付きで連絡があった

結論：報告対象になり得ます。パッチの有無やCVE番号の有無は、判断を左右しません。

根拠：欧州委FAQ5.2では、悪用について信頼できる証拠があれば、ゼロデイでもAEVとなり得ます。

実務では：まず初期評価を行い、いつ「認知」に至ったかを記録しておくことが有効です。24時間の起算点の考え方は、次節3.2で扱います。

ケースA3　組み込んだOSSのCVEが、既知の悪用脆弱性リストに載った

結論：リスト掲載だけでは義務的報告の対象になりません。自社製品において、その脆弱性が実際に悪用されたかまで確認します。

根拠：欧州委FAQ5.4は、統合した部品に由来するAEVが自社製品に含まれる場合でも、自社製品の構成では悪用できない場合は対象外としています。さらに、後発の欧州委ガイダンス9.1節「Reporting obligations（報告義務）」の第三者コンポーネントに関する項目と併せて読むと、自社製品で悪用可能であっても、まだ自社製品では悪用されていない段階では義務的報告の対象外です。

認知のポイント：筆者の見解では、「自社製品で悪用された」事実を、製造業者自身が自社顧客の環境で直接観測している必要まではありません。顧客、部品の供給元、当局、セキュリティ研究者などから、自社製品での悪用を示す信頼できる情報を得た場合も「認知」に至り得ます。

一方、同じ部品の同じ脆弱性が他社製品で悪用されたという情報だけでは、自社製品での悪用を意味しません。

実務では：部品由来の脆弱性を次の4段階に分けて記録しておくことが有効です。VEXの「悪用可能／不可能」の判定だけでは、14条の判断は完結しません。

部品由来の脆弱性を切り分ける4段階

この整理では、段階3までが義務的報告の対象となるための実体的な条件です。そのうえで、製造業者が段階4の「認知」に至った時点で14条の通知義務が具体化し、24時間の期限が動き始めます。実務上は、段階2で止まっている脆弱性についても、段階3に進む兆候を監視し続けることが有効です。

補足：統合部品の脆弱性をその製造・保守元へ報告する義務は13条6項に規定されています。ただし13条の適用開始は原則として2027年12月11日であり、2026年9月11日から適用されている14条の報告義務とは区別する必要があります（71条2項）。

ケースA4　顧客環境でランサムウェア被害が出た

結論：ランサムウェア被害が発生したという事実だけでは、SIとは判断できません。

根拠：14条5項では、製品が重要または機微なデータ・機能を保護する能力を損なう（または損ない得る）か、あるいは製品やそのユーザーのシステムで悪性コードの導入・実行につながった（またはつながり得る）かが基準になります。

実務では：筆者の見解では、自社製品が侵入経路になったのか、製品の保護能力が損なわれたのかを切り分けることが判断の出発点になります。

ケースA5　開発環境も担当者も残っていない旧製品

結論：旧製品であっても報告義務はあります。サポートを終了した製品も報告対象です。

根拠：欧州委FAQ5.3は、古い製品では調査自体が難しい場合があることを認めたうえで、通知は必要だと整理しています。

また、欧州委ガイダンス9.1節「Reporting obligations（報告義務）」のサポート終了後の製品に関する項目は、脆弱性対応の義務がサポート期間中に限られるのとは異なり、14条の報告義務はサポート終了後も適用され続けるとしています。

条文上も、サポート期間は脆弱性対応を行う期間として定義され（3条20号、13条8項）、14条はこれに紐付けられていません。さらに69条3項により、2027年12月11日より前に上市された製品にも報告義務が適用されます。

注意点：影響を受けるユーザーへの周知（14条8項）は旧製品でも必要です。SRPの入力項目にも「サポート終了」の有無を示す欄があります。

ケースA6　自社はSaaSだけを提供している

結論：ブラウザ経由でのみ提供するWebアプリであれば、原則としてCRAの対象外です。

根拠：欧州委ガイダンス2.2節「Software as a product with digital elements」のWebアプリに関する項目は、ブラウザ経由でのみ利用するWebアプリは、それだけでは「デジタル要素を持つ製品」に当たらないとしています。

注意点：ローカルにインストールするクライアントを配布している場合、そのクライアントが機能するために必要なサーバー側の処理（遠隔データ処理）は製品の一部になります。

ケースA7　以前から知っていた古い脆弱性が、適用開始後（2026年9月11日以降）に悪用され始めた

結論：報告対象です。「脆弱性をいつ知ったか」ではなく、「悪用をいつ認知したか」を分けて考えます。

根拠：欧州委ガイダンス9.1節「Reporting obligations（報告義務）」の適用開始前から認知していた脆弱性に関する項目は、9月11日より前に悪用を認知していた脆弱性は遡って報告する必要はないとしています。一方、脆弱性自体は以前から知っていても、悪用を認知したのが9月11日以降であれば報告対象になります。

実務では：「前から知っていた脆弱性だから対象外」とまとめず、脆弱性を把握した時点と悪用を認知した時点を分けて記録します。

2．24時間はいつから動き始めるか

欧州委ガイダンス9.1節「Reporting obligations（報告義務）」の「認知（becoming aware）」に関する項目は、「認知」を次のように整理しています。すなわち、顧客、当局、メディアなどから疑わしい事象を知らされた製造業者は、直ちにその事象を評価すべきであり、その初期評価の結果として、悪用または重大インシデントについて合理的な程度の確実性を得た時点で、認知したものとみなされます。

つまり、第一報を受けた瞬間に24時間が始まるわけではありません。一方、同じ「認知」に関する項目では、初期評価を速やかに行うことに重点を置くべきだとしています。筆者の見解では、評価を遅らせても、その分だけ時計を遅らせたことにはなりません。

実務上の課題は、認知時刻を自社で説明できるようにしておくことにあります。ENISAのGlossary（v1.4）では、AEVの「認知日時」欄は24時間時点の必須項目とされながら、「次回リリースで利用可能」と注記されています。

つまり現行のSRPでは、AEVの認知日時欄はまだ画面に実装されていません。SIには対応する欄がありますが、画面上は「検知日時（Date and time when the incident was detected）」という名称で表示されています。

実務上は、次の時刻を社内で記録しておくことが有効です。

1. 疑わしい事象を受け取った時刻と、情報源
2. 初期評価を始めた時刻
3. 自社判断において「合理的確度」に達したと判断した時刻、判断者、その根拠

まとめ（第1回）

第1回では、CRA14条の報告対応を「何を報告するのか」「いつから期限が動くのか」という2つの層に分けて整理しました。公式資料が法文・欧州委のFAQとガイダンス・ENISAの各種資料に分散しているため、まず問いの層を分けることが、実務では遠回りに見えて近道になります。

第一に、脆弱性が存在することと、14条の義務的報告の対象になることは別です。悪意ある悪用の信頼できる証拠があるか、その悪用が自社製品で起きているかが分かれ目になります（ケースA1〜A4）。

一方で、開発環境も担当者も残っていない旧製品やサポート終了後の製品も報告対象であり（ケースA5）、以前から把握していた脆弱性でも、悪用を認知したのが2026年9月11日以降であれば報告対象になります（ケースA7）。

逆に、ブラウザ経由でのみ提供するWebアプリは、それだけでは「デジタル要素を持つ製品」に当たらず、原則としてCRAの対象外です（ケースA6）。第二に、24時間は第一報を受け取った瞬間ではなく、初期評価で合理的な確度に達した時点から動きます。

ただし評価を遅らせた分だけ時計が遅れるわけではなく、現行のSRPにはAEVの認知日時欄がまだ実装されていないため、認知時刻を自社で説明できる記録が要になります。

第2回では、報告対象と起算点が決まったあとの段階、すなわち「誰が、どこへ、どうやって出すのか」と、SRPの画面で戸惑いやすい初期リリース固有の仕様を扱います。報告先のCSIRTの特定、主担当と夜間・休日の引き継ぎ、入力テンプレートの準備は、いずれもインシデントが起きる前に決めておけることです。

最後に

欧州IoTセキュリティ法規への対応は、条文を読むだけでは進みません。

実際には、自社製品がどこまで対象になるのか、既存製品をどう扱うのか、PSIRTやSBOMをどう整えるのか、といった実務設計が重要になります。

NRIセキュアでは、こうした論点を踏まえた「欧州IoTセキュリティ法規準拠支援サービス」を提供しています。CRA対応の進め方に悩まれている場合は、ぜひご相談ください。（弊社では脆弱性トリアージ作業の代行も実施しております）

欧州IoTセキュリティ法規準拠支援サービス

参考文献

• Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), EUR-Lex.

• European Commission, Frequently Asked Questions on the Cyber Resilience Act implementation.

• European Commission, Draft guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act).

• Commission Delegated Regulation (EU) 2026/881.

• ENISA, CRA Single Reporting Platform (SRP).”Single Reporting Platform (SRP) | ENISA”

• ENISA, CRA Single Reporting Platform (SRP) – FAQ, Guidance, Glossary and User Manual.

関連ブログ

CRA Article 14とは？｜2026年9月11日に先行適用される報告義務とPSIRT対応を解説【第一回】

CRA Article 14とは？｜2026年9月11日に先行適用される報告義務とPSIRT対応を解説【第二回】