ブログ|NRIセキュア

EU CRA報告義務の実務対応|SRPの報告先・担当者体制・入力時の注意点【第2回】

作成者: 江藤 修|2026/10/15

第1回では、その事象がCRA14条の報告対象になるかの切り分けと、24時間の起算点となる「認知」の考え方を整理しました。

 

第2回では、実際に報告を出す段階を扱います。ここで詰まりやすいのは、フォームの入力そのものよりも、報告先の特定、24時間で動ける担当者体制、提出後の情報共有です。いずれもインシデントが起きる前に決めておけることです。あわせて、SRPの初期リリース固有の仕様で戸惑いやすい点も取り上げます。

 

※第1回はこちらからご覧ください。

EU CRA脆弱性報告義務が開始されました【第1回】|その事象は報告対象か、24時間はいつから始まるか

 

はじめに

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

 

第一に、報告先のCSIRTは14条7項の優先順位で決まり、誤ると通知が無効になって再提出が必要になり得るため、事前の確認が欠かせません。通知は1事象につき1件で、担当者は主担当1名・副担当最大20名という制約があります。

 

第二に、SRPは法令上の義務をそのまま映した画面ではありません。期限カウンターの表示や入力仕様は初期リリース固有の制約を含むため、自社で記録した認知時刻と切り分けて扱う必要があります。

 

なお第1回の内容のうち、報告期限だけは第2回でも繰り返し参照するため、下表に再掲します。報告対象の定義や「認知」の考え方については、第1回をご参照ください。

AEVおよび重大インシデントの報告期限(第1回より再掲)

段階

AEV

SI

早期警告

認知から24時間以内

認知から24時間以内

通知

認知から72時間以内

認知から72時間以内

最終報告

是正・緩和策が利用可能になってから14日以内

72時間通知から1か月以内

誰が、どこへ、どうやって出すか

第1回で扱った報告対象と24時間の開始点が決まったら、次は実際に報告を出す段階です。この段階で必要になる判断は、いずれもインシデントを認知してから短時間で決められる性質のものではなく、平時のうちに決めて社内で共有しておくものです。

 

以下では、その判断を次の3点に分けて整理します。

報告先と責任主体:どのCSIRTに、どの法人・担当者が提出するか

24時間で動ける担当者体制:Primary/Secondary ARと、夜間・休日の引き継ぎをどうするか

提出後の情報の広がり:他国のCSIRT・ENISA・ユーザーへ、どの情報がどう共有されるか

 

以下では、この3つを「報告先と責任主体」「担当者体制」「提出後の共有・周知」の順に見ていきます。

ケースB1〜B5の一覧

ケース

こんなとき

要点

報告先と責任主体

B1

日本本社で、EUに拠点がない

14条7項の優先順位で決める

B2

EU域内に複数の子会社がある

1事象につき通知は1件

担当者体制

B3

深夜・休日に認知したが、提出できる担当者が限られる

認知した側で提出可。当番設計が要

提出後の共有・周知

B4

パッチ提供前に、情報が他国へ広がるのを抑えたい

任意には止められない(16条2項)

B5

ユーザーにはどう知らせるか

当局報告とは別に周知が必要

報告先と責任主体を決める

ケースB1 日本本社で、EUに拠点がない

結論:EU域内に拠点がない場合、14条7項の優先順位に従って報告先のCSIRTを決めます。

 

優先順位:次の順で、該当する加盟国を特定します。

  • 1.認定代理人が最も多くの製品を扱っている国

  • 2.輸入者が最も多くの製品を上市している国

  • 3.販売業者が最も多くの製品を流通させている国

  • 4.ユーザー数が最も多い国

EUに拠点がある場合:原則として、製品のサイバーセキュリティに関する意思決定を主に行っている事業所が所在する国が報告先です。それを特定できない場合は、EU域内で最も従業員数の多い事業所が所在する国になります(14条7項)。

 

実務では:ENISAは、報告先を誤ると通知が無効になり、再提出が必要になり得るとしています。インシデント発生後に調べ始めるのではなく、自社の報告先を事前に確認しておくことが有効です。

ケースB2 EU域内に複数の子会社がある

結論:通知は、1つの事象につき1件です。子会社ごとに重複して提出するものではありません。

 

根拠:グループ内で調整し、確実に1件だけ提出することは製造業者の責任とされています。

 

実務では:どの法人の誰が提出するかを、事前に規程で決めておくことが有効です。

24時間で動ける担当者体制をつくる

ケースB3 深夜・休日に認知したが、提出できる担当者が限られる

結論:報告義務を負うのは製造業者(法人)であり、提出そのものは認知した側の担当者が行えます。報告先のCSIRTが欧州にあっても、欧州側の担当者の応答を待つ必要はありません。注意すべきは、初回登録時の担当者設計と、提出後の引き継ぎです。

 

まず、報告自体は可能です:SRPには担当者個人のEU Loginアカウント(多要素認証付き)が必要です。担当者の枠は、主担当(Primary AR)が1名、副担当(Secondary AR)が最大20名です。担当者がEU域内に所在している必要はなく、日本の担当者が自ら提出できます。担当者と製造業者の紐付けは報告先CSIRTが検証しますが、検証は報告と並行して進むため、紐付けが未検証の状態でも通知を提出できます。この未検証状態で提出できる件数の上限も20件で、副担当の人数の上限(20名)とは別の制限です。

 

欧州側の関与が要るのは:EU子会社が製品のサイバーセキュリティに関する意思決定を担っている場合、その子会社が自社ブランドで上市し製造業者に当たる場合、認定代理人や外部事業者に担当者アカウントを預けている場合です。逆にいえば、これらに当てはまらなければ、時差を理由に提出が遅れる理由はありません。

 

次に、引き継ぎが問題になります:副担当を招待できるのは、主担当の紐付けが「検証済み」になってからです。また、下書きは作成者本人にしか見えません。提出済み通知についても、ENISAのFAQ(9月17日更新)は「同じ製造業者の担当者なら誰が出した通知も閲覧・更新できる」とする一方、画面操作ガイダンスは「副担当は他の担当者が出した通知を見られない」としており、記述が一致していません。

 

実務では:ENISAは、SRPへの登録は通知が必要になった時点で行うよう勧めていますが、EU Loginのアカウント自体は事前に作成できます。副担当の枠は製造業者(法人)単位で最大20名です。製品群ごとに細かく担当者を割り当てるほど枠は逼迫するため、どの単位で担当者を置くかを先に決めておくことが有効です。そのうえで、24時間の早期警告と72時間の通知が別の担当者にまたがり得る場合に備え、誰を主担当とするか、主担当が不在のとき誰が対応するかを決めておきます。

提出後の共有とユーザー周知を整理する

ケースB4 パッチ提供前に、情報が他国へ広がるのを抑えたい

結論:共有を任意に止めることはできませんが、16条2項には、一定の条件で共有を遅らせたり、ENISAに送る情報を限定したりする仕組みがあります。

 

通常は:SRPに提出した通知は、報告先のCSIRTとENISAに同時に届き、報告先のCSIRTから、製品が提供されている他の加盟国のCSIRTへ共有されます。

 

一般的な遅延:例外的な事情がある場合、とりわけ製造業者から要請がある場合には、製造業者が示した情報の機微性も踏まえて、報告先のCSIRTは正当なサイバーセキュリティ上の理由があれば、他国への共有を必要最小限の期間遅らせることができます。協調的脆弱性開示(CVD)の手続き中であることも理由として明示されています。

 

特に例外的な事情(PEC):AEVの72時間通知に限り、次のいずれかに当たることを示せば、ENISAに同時送付される情報を限定できます。

  • 1.報告先の国でしか悪用されていない

  • 2.これ以上共有すると、その国の本質的利益に反する情報の提供につながる

  • 3.これ以上共有すること自体が、差し迫った高いリスクを生む

PECを主張した場合、ENISAに届くのは限定情報のみです。他国のCSIRTへの共有と、ENISAへの全文の共有は、報告先CSIRTが判断して手動で行います。

ケースB5 ユーザーにはどう知らせるか

結論:当局への報告とは別に、影響を受けるユーザーへの周知が必要です。

 

根拠:14条8項は、影響を受けるユーザーに周知する義務を定めています。適切な場合は全ユーザーが対象になります。製造業者が適時に周知しない場合、CSIRTがユーザーに直接知らせることもあります。

 

実務では:誰に、いつ、どこまで知らせるかについても、事前に判断基準を決めておくことが有効です。

SRPの落とし穴

ここまでで、報告対象、24時間の起算点、報告先・担当者体制まで整理できても、実際にSRPへ入力する段階では、画面の表示や初期リリース固有の仕様に戸惑う場面があります。SRPは法令上の義務をそのまま映した画面ではないため、「画面にどう表示されるか」と「CRA上どう対応すべきか」を切り分けて使うことが重要です。

 

実務上は、特に次の3点を事前に押さえておくと迷いにくくなります。

  • 画面表示と障害時対応:期限カウンターやSRP障害時に、何を基準に動くか
  • 入力仕様:APIの有無、使用言語、文字数上限など、入力前に知っておくべき制約は何か
  • 24時間時点の不確実性:原因や悪意性が確定していない段階で、どこまで入力できるか

以下では、この3つを「画面表示・障害対応」「入力仕様」「不確定情報の扱い」の順に見ていきます。

ケースC1〜C5の一覧

ケース

こんなとき

要点

画面表示・障害対応

C1

画面上「期限超過」と表示された

自社の認知時刻で管理する

C2

SRPにつながらない

復旧後の提出が必要

入力仕様

C3

大量の通知を自動化したい

APIはなく画面入力のみ

C4

自由記述欄に何をどれだけ書くか

文字数上限あり。事前にひな形を

不確定情報の扱い

C5

原因がまだ分からない

「不明」で提出できる

画面表示と障害対応に振り回されない

ケースC1 画面上「期限超過」と表示された

結論:SRPのカウンターではなく、自社の「認知時刻」を基準に法定期限を管理します。

 

なぜ?:ENISAによると、現行版の72時間カウンターは、早期警告を提出してから48時間後を期限として表示します。そのため、法定期限(認知から72時間)より前に「超過」と表示されることがあります。AEVの最終報告にはカウンター自体がありません。

 

実務では:ENISA自身も、カウンターは目安であり、14条の期限遵守の責任を置き換えるものではないとしています。画面表示ではなく、自社で記録した認知時刻から期限を管理します。

ケースC2 SRPにつながらない

結論:原則として復旧を待ってSRPから提出します。緊急の連絡が必要な場合は、その間にCSIRTへ直接連絡できます。

 

注意点:CSIRTへ直接連絡した場合でも、それだけでSRPへの提出が完了したことにはなりません。復旧後のSRP提出は必要です。

入力仕様を事前に押さえる

ケースC3 大量の通知を自動化したい

結論:現時点ではAPIはなく、すべてSRPの画面から入力します。

 

注意点:画面は英語のみです。大量の通知が発生する場合も、初期リリースでは画面入力を前提に対応する必要があります。

ケースC4 自由記述欄に何をどれだけ書くか

結論:自由記述欄には文字数上限があります。事前にテンプレートを合わせておくと、24時間対応がしやすくなります。

 

主な上限:概要と一般情報は4,000文字、タイトルは255文字、機微性の理由は255文字、悪意ある行為者の情報は100文字です。

 

実務では:社内の報告テンプレートを、あらかじめこの形式に合わせて作っておくことが有効です。

24時間時点で確定していない情報をどう扱うか

ケースC5 重大インシデントかもしれないが、原因がまだ分からない

結論:24時間の時点で原因を確定させる必要はありません。

 

根拠:SIの早期警告では、「違法・悪意ある行為の疑い」を「不明」として提出できます。原因究明が終わるまで早期警告を待つ必要はありません。

まとめ(第2回)

第2回では、CRA14条の報告対応のうち「誰が、どこへ、どうやって出すのか」と「SRPの画面で何に戸惑うのか」という2つの層を整理しました。第1回で扱った報告対象の切り分けと起算点の考え方と合わせて、4つの層で捉えると全体像がつかみやすくなります。

 

まず、提出の段階で詰まりやすいのは、フォームの入力よりも体制側です。報告先のCSIRTは14条7項の優先順位で決まり、誤ると再提出になり得るため事前確認が欠かせません。

 

通知は1事象につき1件で、グループ内の調整は製造業者の責任です(ケースB1・B2)。担当者は主担当1名・副担当最大20名で、下書きは作成者本人にしか見えず、提出後の引き継ぎに関する資料間の記述も一致していないため、主担当を軸に設計しておくのが安全です(ケースB3)。提出後の共有は任意には止められませんが、16条2項に遅延やPECの仕組みがあり、当局報告とは別に14条8項のユーザー周知が必要です(ケースB4・B5)。

 

次に、SRPは法令上の義務をそのまま映した画面ではありません。72時間カウンターは法定期限より前に「超過」と表示されることがあり、期限は自社で記録した認知時刻を基準に管理します(ケースC1)。

 

初期リリースではAPIがなく画面入力のみ、表示は英語のみで、自由記述欄には文字数上限があります(ケースC3・C4)。逆に、原因や悪意性が24時間時点で確定していなくても「不明」として提出でき、原因究明を待つ必要はありません(ケースC5)。

 

第1回・第2回を通して見てきたとおり、24時間という期限そのものよりも、報告先の特定、主担当と夜間・休日の引き継ぎ、テンプレートの準備、認知時刻の記録といった「事前に決めておけること」が対応の成否を分けます。

 

69条3項により2027年12月11日より前に上市した製品も対象であり、64条2項は14条違反に最大1,500万ユーロまたは全世界年間売上高の2.5%という行政罰金の上限を定めています(ただし第1回で触れたとおり、先行適用された14条の違反にこの制裁金規定がいつから適用されるかは、別途確認が必要です)。

 

インシデントが起きてから調べ始めるのではなく、いま手元で決められる範囲を先に固めておくことが、2027年のCRA全面適用に向けた最初の一歩になります。

最後に

欧州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) – FAQ, Guidance, Glossary and User Manual.

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

関連ブログ

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

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