2026年9月11日、CRAの報告義務が開始 — ソフトウェア企業の24時間early warningにどう備えるか

    2026/9/14

    この記事の著者

    プライバシーエキスパート

    栗原 宏平

    【免責事項】  本記事は筆者個人の見解に基づき執筆したものであり、筆者は弁護士資格を有しておりません。法律上のアドバイスを目的としたものではありませんので、あらかじめご了承ください。

    はじめに

    2024年10月23日に欧州サイバーレジリエンス法(以下、EU CRA)が成立しました。この法律は、欧州域内でデジタルエレメント(通信)に接続する製品がサイバーセキュリティに求められる要求を満たしていることを求めるように設計されています。

    欧州に製品を展開する企業にとっては、サイバーセキュリティに関するルールが変更されることになるため、今後のスケジュールを確認した上で、対応すべき項目を整理する必要があります。特に9月11日以降は報告義務が発生するため、まずは初期対応が必要な内容について確認することが大切です。

    サイバーレジリエンス法の施行背景と今後のスケジュール

    法律が成立した背景としては、欧州域内で特定の製品に適用した制度は定められていたものの、横断的に法適用を求める制度は存在しなかったため、2013年1月15日成立したLカテゴリ枠組み規則、2019年6月20日に成立した欧州市場監視規則、そして2020年11月25日に成立した消費者団体訴訟指令を修正する形で、EU CRAが成立することになりました。

    企業がEU CRAを注視すべきポイントとして、本法律についてはデータ及び消費者保護とも連動する点がいくつか見受けられるというということです。2024年11月20日に発行された欧州連合官報によると、サイバーセキュリティ対策を講じることによって、消費者や組織の個人データを保護することになり、個人のプライバシーを守ることにも言及しています。

    一見すると、サイバーセキュリティ強化の法律のように見える部分もありますが、市場を監督する規制当局はデータ保護の規制当局とも連携して監督を行うとも明記されており、製品を利用する消費者の観点からサイバーセキュリティ対策を検討することも求められます。

    2027年12月11日の施行に向けて、標準化を含めた環境整備が進んでいます。今後のスケジュールについては、 i46 s.r.o.社が公開しているサイトを参考に筆者が時系列でタイムラインを作成しました。

    ※本タイムラインは現時点での予測スケジュールであり、必ずしもこのスケジュール通りに進められるとは限りません。

    日付

    マイルストーン

    詳細・対応事項

    2026年9月11日

    報告義務の適用

    ・製造業者の報告義務: 悪用が確認された脆弱性や重大なインシデントが発生した場合、欧州連合サイバーセキュリティ機関(以下、ENISA)および各国のCSIRTへの報告が義務付けられます。    
    ・Platform準備: ENISAは第16条で定められたSingle Reporting Platform(以下、SRP)を期限までに運用できるよう準備を進めます。

    2026年10月31日

    初期の中心となる標準の開発・整備

    ・中心となる二つの標準規格(セキュリティ開発および脆弱性対応)の開発終了を見込みます。※当初期限の2026年8月30日から、2026年7月のドラフト改正で2ヶ月後ろ倒しされた日程です。

    2026年12月31日

    製品ごとの標準の開発・整備

    ・製品ごとの標準開発と整備を行います。※当初の期限は2026年10月30日でしたが、2026年7月の欧州委員会によるドラフト改正で2026年12月31日へ2ヶ月後ろ倒しされました。

    2027年10月30日

    横断的な標準の開発・整備

    ・横断的な標準開発と整備を行い、1年前から取り組んできた標準項目に製造業者が対応できるように準備を行います。

    2027年12月11日

    法律の全面施行・完全適用

    ・全条件への対応: 法律で求められる全ての条件への対応が求められます。
    ・CEマーク取得: 製品を欧州域内へ展開する場合には必須項目への対応とCEマークの取得が求められます。

    想定のタイムラインに沿って考えると、年内には凡その標準開発が進み、施行前には製品標準に限定せず、横断的な標準開発も進んでいくことが予測されます。まずは、9月11日から開始される「レポート義務への適用」をゴールとし、順次対策を進めていくことが妥当だろうと考えられます。

    報告義務への適用で求められること

    EU CRAでは第14条で製造業者に対して、CSIRTをコーディネーターとして脆弱性に関する状態についてENISAへ報告義務について定めています。第14条では、報告義務を履行する目的に沿った上で、ENISAが提供するSRPを通じて以下の内容の報告を求めています。

    ※CSIRTとはComputer Security Incident Response Teamの略称であり、「一般社団法人日本シーサート協議会」によると、「コンピュータセキュリティにかかるインシデントに対処するための組織の総称です。インシデント関連情報、脆弱性情報、攻撃予兆情報を常に収集、分析し、対応方針や手順の策定などの活動」をするTeamであると紹介しています。

    段階

    期限

    報告の目的

    主な報告内容
    ・実行事項例

    第1段階:初期報告

    24時間以内

    早期状況共有

    ・事象の発覚通知
    ・欧州域内における影響範囲(展開製品や地域)

    第2段階:中間報告

    72時間以内

    現状の状況アップデート

    ・脆弱性の詳細情報
    ・暫定的なリスク軽減策(回避策やユーザー側の対策)

    第3段階:最終報告

    修正措置または軽減措置が利用可能になってから14日以内

    事後検証と恒久対策の報告

    ・軽減策の実行(セキュリティアップデート等の適用)
    ・脆弱性の根本原因および影響範囲・悪意のある攻撃者に関する情報(判明している場合)
    ・セキュリティパッチや具体的な対策内容

    ※表については欧州連合官報で公表されている情報を下に、筆者が作成

    また、製品に関する脅威となるセキュリティインシデントについても報告義務について定めています。第14条では、報告義務を履行する目的に沿った上で、ENISAが提供するSRPを通じて以下の内容の報告を求めています。

    段階

    期限

    報告の目的

    主な報告内容
    ・実行事項例

    第1段階:初期報告

    24時間以内

    早期状況共有

    ・脅威・インシデントの発覚通知   

    ・欧州域内における影響範囲(展開製品や被害状況)

    第2段階:中間報告

    72時間以内

    状況評価と対応方針の共有

    ・インシデントの詳細と評価情報   

    ・暫定的な被害軽減
    ・被害抑制の方法

    第3段階:最終報告

    72時間報告の提出から1ヶ月以内

    事後検証と軽減策の実行報告

    ・被害軽減策の実行完了   ・インシデントの詳細・影響範囲の確定   

    ・インシデントを引き起こした脅威の具体的な内容 
    ・現在対策中及び実施済みのインシデント削減措置

    ※表については欧州連合官報で公表されている情報を下に、筆者が作成

    脆弱性及びインシデント報告の届け先となるCSIRT(コーディネーター)は、製造業者がサイバーセキュリティに関する意思決定を主に行っている欧州域内の拠点(主たる事業所)が所在する加盟国のCSIRTとなります。なお、報告のために欧州拠点の設置そのものが義務付けられているわけではありません。製造業者が欧州域内に主たる事業所を持たない場合には、以下の優先順位に従って管轄となる加盟国(CSIRT)が決定されます。

    優先度

    決定の基準

    該当する加盟国(管轄CSIRT)

    第1優先

    認定代理人

    製造業者に代わって行動する認定代理人が事業所を置く加盟国 (対象製品の取扱数が最も多い代理人が基準)

    第2優先

    輸入業者

    製造業者の製品を最も多く市場に流通させている輸入業者が事業所を置く加盟国

    第3優先

    販売業者

    製造業者の製品を最も多く市場に供給している販売業者が事業所を置く加盟国

    第4優先

    エンドユーザー

    製造業者の製品のユーザーが最も多く所在する加盟国

    ※表については欧州連合官報で公表されている情報を下に、筆者が作成

    当該製造業者は製品の脆弱性や脅威のあるセキュリティインシデントについて、適切に消費者に対して通知を行う必要があります。通知内容については、脆弱性かインシデントであるかということに加えて、リスクの低減策や修正対応についても通知することが求められます。加えて、消費者自身で脆弱性やインシデントに対応できるように、構造化され、機械が読み解くことができる仕様を持って通知することが必要になります。

    製造業者が直接消費者へ通知ができない場合には、CSIRTをコーディネーターに指定して、消費者に対して適切な通知を行います。

    ENISAが提供するSingle Reporting Platformへの対応

    ここまで紹介してきた報告義務をシステム上で簡易に対応するために、サイバーレジリエンス法の第16条ではENISAがSRPを設置することを定めています。SRPの設計や管理はENISAが行い、電子通知で報告を実施できるように設計される予定です。

    ※ENISAの公表資料を下に “Single Reporting Platform(SRP)” の全体像を筆者で作成

    SRPから報告通知が行われた後に、当該欧州市場のCSIRTへ通知が届くことに合わせて、ENISAにも同様の通知が届くことになります。また、CSIRTを通じて当該国の市場監察当局へ報告が届き、執行を行うか否かの判断が行われます。

    前述のスケジュール通り、2026年9月11日よりSRPを利用した報告義務の適用が開始されるため、事前に報告の有無を含めて、対応状況を整理しておく必要があります。

    Single Reporting Platform(SRP)の登録手順

    ここからは9月11日以降に利用ができるようになるSRPの登録手順について、順番に紹介していきます。

    1. 代理人となる担当者を選定し、EUログインへ登録する

    SRPを利用するにあたり、Assigned Representativeと呼ばれる代理人(以下、AR)を立てて報告を行うことが必要になります。ARは事前にメールとパスワードを用いてEUログインを行い、登録情報を書き込みます。

    ※筆者が登録したEUログインのページ

    事前にARを登録し、登録内容を検証しておくことで製造業者又は、オープンソーススチュワードはARを通して報告を行うことができるようになります。ARについては、 CSIRTによって検証が行われる(報告を行う場合の義務ではない)ことになりますが、当該対象国のCSIRTによって検証プロセスが異なるので特別に通知を行う必要がある場合については、製造業者やオープンソーススチュワード側で検証を行うことが求められます。

    2. SRPに登録する

    SRPに登録するにあたり、フォーム登録の手順に沿って必要な情報を記載する必要があります。

    ステップ

    実施する作業

    詳細・入力内容

    準備

    EU Login 認証

    EU Loginアカウントを使用してシステム認証を行う

    手順1

    同意事項の確認

    法的な同意事項(利用規約・プライバシーポリシー等)を確認し、同意する

    手順2

    アカウント情報の確認

    事前登録済みの基本情報(姓、名、メールアドレス、法人の正式名称)に誤りがないか確認する

    手順3

    製造業者情報の入力

    企業の詳細情報(法的名称、所在地住所、その他必要な追加情報)を記載する

    手順4

    役割の設定(AR登録)

    登録手順内で利用者の役割としてAR(Assigned Representative)を選択・登録し、「続き」をクリック

    手順5

    管轄CSIRTの選択

    ドロップダウンメニューから、指定すべき当該CSIRTを選択し、「続き」をクリックして完了

    ※記事の寄稿時点では、SRPのウェブサイトが公開されていないため、ENISAが公開している登録ガイダンス(2026年7月31日公開・8月3日更新版)を参考に筆者が記載しています。ENISA自身が「内容は変更される可能性がある」としているため、実際の登録時には最新のガイダンスをご確認ください。

    登録が完了し、承認されるとARが製造業者と連携したことになり、アカウントがアクティブになることに加えて、ARの主要な役割が任命されることになります。確認メールと共に、製造業者の情報を記載している場合には、製造業者の情報もSRPに登録されることになります。

    ※主要ARの登録が済んだ後に、サブ(主要ARがメインである場合のサブAR)のARに向けて招待メールを送って登録する場合もあります。この場合は主要ARから送られてきたメールをサブARが開封して、登録作業を行います。その際に、主要ARから招待がお送りされることになるため、サブAR招待を承諾し、登録が完了することになります。登録後は、サブARを主要ARバックアップユーザーとして活動することになります。

    Single Reporting Platform(SRP)での報告手順

    ARはSRPを通じて報告通知を行う必要があります。報告内容には脆弱性の報告(Actively Exploited Vulnerability。以下、AEV)及び脅威のあるインシデント(Severe Incident。以下、SI)の2種類があります。この報告は当該CSIRTにレビューを依頼し、今後の対応について検討することを目的としています。報告については、初期報告及び72時間、最終報告についてそれぞれ以下の手順で対応を行います。

    報告フェーズ

    事前確認・操作内容

     記載内容

    通知内容決定・提出

    事後処理・備考


    初期報告

    SRPより「新規報告通知」を選択(事前登録済みAR情報を読み込み)

    • 初期報告通知に必要な情報 
    • 製造業者(既存選択または新規登録)   
    • 追記事項(任意:「追記項目」へ記載)

    「報告通知を行う」または「記載内容を保存する」を選択

    提出後、CSIRTが検証を実施。完了後に「検証終了」および「対応日時」が表示される

    72時間報告

    SRPへログイン後、ダッシュボードを開き、初期報告内容を確認の上、該当の「初期報告」を選択

    72時間報告タブ内の必須項目

    「報告通知を行う」または「記載内容を保存する」を選択

    最終報告

    SRPへログイン後、ダッシュボードを開き、72時間報告内容を確認の上、該当の「最終報告」を選択

    最終報告タブ内の必須項目

    「報告通知を行う」または「記載内容を保存する」を選択

    ※表についてはENISAのウェブサイトで公表されている情報を下に、筆者が作成

    報告通知フェーズの手順に加えて、報告通知の修正期限に到達していない場合や最終報告が提出されていない場合については報告通知内容を修正することができます。

    報告内容テンプレートを確認し、9月11日にSRPが公開されるまでに準備をしましょう

    ここまで紹介してきたように、SRPを活用することによって簡易に報告通知を実施できるようになるので、事前に報告通知手順を確認した上で、9月11日の公開までに準備をしていくことが必要になります。

    以下はENISAがFAQで公表している報告通知の際に記載すべき項目のテンプレートです。

    共通項目

    初期報告(24時間以内)

    72時間報告

    最終報告

    1

    通知タイプ (脆弱性/インシデント)

    X

    C

    C

    2

    通知タイプ (初期報告/72時間報告/最終報告)

    X

    X

    X

    3

    報告時間 - 初期報告

    A

    A

    A

    4

    報告時間 - 72時間報告

    A

    A

    A

    5

    報告時間 - 最終報告

    A

    A

    A

    6

    報告者

    A

    A

    A

    7

    製造事業者もしくはオープンソースソフトウェアスチュワード名

    X

    C

    C

    8

    製品

    X

    C

    C

    9

    製品タイプ (デフォルト/重要/危機)

    O

    C

    C

    10

    製品分類 (製品タイプがデフォルトか否か CRA Annex III/IVを参照)

    O

    C

    C

    11

    製品を展開している欧州地域

    I

    C

    C

    12

    タイトル

    X

    C

    C

    脆弱性項目

    v13

    CVE ID(共通脆弱性識別子)

    O

    C

    C

    v14

    欧州脆弱性データベース

    O

    C

    C

    v15

    一般的な情報

    O

    X

    C

    v16

    a. 脆弱性(セキュリティ上の欠陥)がどのような本質や特徴、仕組みを持っているかの説明

    O

    X

    C

    v17

    b. 攻撃手法(エクスプロイト)が、「どのような仕組みで、何を標的にし、どのような影響を与えるのか」を大まかに説明した基本情報

    O

    X

    C

    v18

    対応済みの脆弱性の修正及び削減方法

    O

    X

    C

    v19

    ユーザーが対応できる脆弱性の修正及び削減方法

    O

    X

    C

    v20

    考えられるセンシティブな情報

    O

    I

    C

    v21

    対応済みの脆弱性の修正及び削減方法が導入される日付

    O

    O

    X

    v22

    脆弱性に関する詳細記述

    O

    O

    X

    v23

    a. 脆弱性の深刻度合い

    O

    O

    X

    v24

    b. 脆弱性による影響

    O

    O

    X

    v25

    脆弱性を悪用する要因

    O

    O

    I

    v26

    セキュリティ更新状況の詳細と修正方法

    O

    O

    X

    脅威のあるインシデント項目

    i13

    インシデントの違法性と悪意性

    X

    C

    C

    i14

    インシデントに関する一般的な情報

    O

    X

    C

    i15

    インシデントを検知した日と時間

    O

    X

    C

    i16

    インシデントが発生した日と時間

    O

    X

    C

    i17

    初期のインシデント評価内容

    O

    X

    C

    i18

    対応済みのインシデントの修正及び削減方法

    O

    X

    C

    i19

    ユーザーが対応できるインシデントの修正及び削減方法

    O

    X

    C

    i20

    考えられるセンシティブな情報

    O

    I

    C

    インシデントの詳細情報

    O

    O

    X

    i21

    a. インシデントの深刻度合い

    O

    O

    X

    i22

    1) デジタル要素を含む製品の、機密性または重要なデータもしくは機能の可用性、真正性、完全性、または機密性を保護する能力に悪影響を及ぼす、または及ぼすおそれがある場合;
    2) デジタル要素を含む製品、またはその製品のユーザーのネットワークおよび情報システムにおいて、悪意のあるコードが導入または実行されることにつながった、またはつながるおそれがある場合

    i23

    b. インシデントによる影響

    O

    O

    X

    i24

    インシデント発生原因となった脅威の種類とルート

    O

    O

    X

    i25

    既にインシデント削減を実施している内容と現在取り組んでいる方法

    O

    O

    X

    ※表についてはENISAのFAQで公表されている情報を下に、筆者が作成

    A - 自動で記載(提出者には表示されない)

    X - 必須項目 

    C - 前手順もしくは更新情報に関する報告内容のコピーがデフォルトで上書き対応

    O - 選択項目 

    I - 情報を取得できていれば必須項目

    この記事では、9月11日に向けて企業が準備すべきポイントについて順を追って紹介してきました。現地のARを誰に担ってもらうのかという問題や、SRPが公開された後に何を基準に準備すればいいのかお困りの方が多いのではないかと推測します。

    SRPで報告を行うだけでも、事前に数多くの審査を行う必要があるため、まずは欧州で展開している製品を一度見直し、脆弱性と脅威のあるインシデントについては注視して確認しておくことが大切です。

    その際には、インシデント対応で報告が必要な内容を事前テンプレートを参考に準備し、自社特有のポイントについては随時追加していきながら網羅的なドキュメントとして残しておくことが最適だと考えます。

    また、2027年12月11日の完全施行に向けては時間的に余裕もあるため、引き続き、欧州側での発表や標準化動向等についても確認しておく必要があります。

    参考資料

    この記事の著者

    プライバシーエキスパート

    栗原 宏平

    大学在学時に政治家の事務所で働き、卒業後は楽天に入社。2年間の営業経験を経て起業。国外のデジタルサービスの日本展開や国内のサービスの国外展開を支援。2017年より米国の非営利法人Government Blockchain Associationの日本代表を務める。

    その後、スタートアップの創業に関わる傍ら、ユネスコを始めとした国際会議でブロックチェーン関連で登壇を経験。2020年に一般社団法人Privacy by Design Labを立ち上げ、プライバシーに関するアドボカシー活動を中心に国際的な場づくりに取り組む。専門領域は、データ保護(個人情報保護)、デジタルマーケティング、ブロックチェーン。国内外のプライバシー業界のリーダーへ直接お話を聞くインタビューメディア“Privacy Talk”を運営。

    この記事をシェア

    facebookシェアボタンXシェアボタン
    keyboard_backspace

    お役立ち記事一覧