規則（EU）2024/2847に関する独立したガイド · ステータス：発効中
このページは自動（AI）翻訳であり、人によるレビューは行われていません。
CRAの理解・報告

CRAのインシデント・脆弱性報告

2026年9月11日から、製造者は第14条に基づき、積極的に悪用されている脆弱性および重大なインシデントを報告しなければなりません。報告すべき内容、24時間・72時間・最終報告の期限、報告先、そしてENISAの単一報告プラットフォームが実際にどのように機能するのかを、稼働開始前に取り得る対応も含めて解説します。

約19分で読了第14条 · 16 · 182026年9月11日から適用2026年9月9日 レビュー済み

01報告しなければならないもの

次の文書の Art. 14 Cyber Resilience Act は、デジタル要素を含む製品の製造者に2つの報告義務を課しています。これらの義務は一見するよりも狭く、日常的な不具合や通常のパッチは対象外です。 Art. 14

  • 積極的に悪用されている脆弱性：所有者の許可なく悪意ある行為者がシステム内でそれを悪用したという信頼できる証拠がある、自社製品の脆弱性を指します。悪用される前に発見して修正した脆弱性は、通常の 脆弱性対応プロセス、この報告チャネルではありません。
  • 重大なインシデント：データまたは機能の可用性、真正性、完全性または機密性を保護する製品の能力に悪影響を及ぼす、または及ぼすおそれのあるインシデントを指します。重大性の基準は第14条(5)に定められています。

これらの義務は商業的な製造者に限られません。 オープンソースソフトウェアの管理者 も、デジタル要素を含む製品に関与する限りにおいて、独自の報告義務を負います。 Art. 24(3)

テスト

製品のセキュリティ上の弱点が積極的に悪用されている場合、またはセキュリティインシデントが製品に重大な影響を与えた場合、Art. 14の時計が動き始めます。それ以外はすべて日常的な脆弱性対応の範囲内です。

報告義務は過去に遡及しません

報告義務が適用される 2026年9月11日より前に積極的な悪用をすでに認識していた脆弱性については、通知する必要はありません。義務は 認識した時点から生じるため、その日以降に把握した事項が対象となり、それより前には遡りません。

ただし、すでに販売した製品には及びます

ここが多くの企業の見落とす点であり、正確に押さえておく価値があります。 第69条(2) は一般的な経過措置を定めています。すなわち、 2027年12月11日 より前に市場に投入された製品は、 実質的な変更 が同日以降に加えられた場合にのみ規則の適用対象となります。これだけを読むと、既存の製品カタログには影響がないように思われます。

第69条(3) は、そこから第14条を直ちに除外し直しています。明示的な適用除外により、報告義務は、 すべての 規則の適用範囲に含まれ、2027年12月11日より前に市場に投入されたデジタル要素を含む製品に、変更が加えられたか否かにかかわらず適用されます。

つまり、2つの規定は異なる軸で動いています。2025年に販売した製品はCRAの下でCEマーキングを必要としないかもしれませんが、その製品の脆弱性が積極的に悪用され、2026年9月11日以降にそれを認識した場合、その脆弱性は報告の対象です。自社の 設置済み製品は報告の対象となります 。製品要件の対象外である場合であっても同様です。欧州委員会も、CRA実施に関するFAQの5.3節で同じ結論を示しています。 Art. 69(2)–(3)

023つの期限

各報告は3つの段階で展開され、 認識した時点から 起算されます。悪用された脆弱性や重大なインシデントの報告期限は短く、だからこそ準備が重要になります。 Art. 14(2)–(4)

  • 24時間以内早期警告。 積極的に悪用されている脆弱性または重大なインシデントが発生した旨の最初の通知です。インシデントについては、違法または悪意ある行為によるものと疑われるか否かも記載します。
  • 72時間以内脆弱性・インシデントの通知。 より詳細な報告です。脆弱性および悪用の一般的な性質、初期評価、講じた是正措置または緩和措置、ならびに利用者が取り得る措置を記載します。
  • 最終報告最終報告。 対象が 脆弱性の場合は、 14日 以内。是正措置または緩和措置が利用可能となった時点から起算します。対象が 重大なインシデントの場合は、72時間通知から 1か月 以内。完全な説明、重大性、影響および適用された是正内容を記載します。

最後の行の非対称性に注意してください。脆弱性の起算点は修正が存在することであり、インシデントの起算点は先行する通知です。仕組みが異なるため、社内のランブックには別々に書き込んでおくべきです。

03開始時期

報告義務はCRAの中で最も早く発効する主要な部分です。大部分の規定は2027年12月11日から適用されますが、Art. 14は 2026年9月11日：法の発効から21か月後です。ENISAは、単一報告プラットフォームを同じ日までに稼働させる予定としています。 Art. 71

状況 · 2026年9月7日

プラットフォームは まだ稼働していません 。公開URLも公表されていません。ENISAは、稼働開始前に単一報告プラットフォームのページで通知すると述べています。ユーザーテストとセキュリティテストは実施済みで、CSIRTsネットワークの複数のCSIRTsが参加しました。

ENISAは 2026年9月4日 にSRPのFAQをほぼ全面的に書き直し、長らく公表が待たれていた 調整役として指定されたCSIRTsの一覧を公表しました。対象は全 27 加盟国です。この一覧は下記のセクション08にリンクしています。FAQと並んで、ENISAは現在、ファクトシート、項目ごとの SRP用語集（2026年9月5日にバージョン1.1へ改訂、新しいアドレスへ移転）、および 3 つの段階的なガイダンスページ（代表者向け）を公開しています。これらのガイダンスページには今も 8月3日 および 2026年8月14日 の日付表示が残っており、FAQまたは用語集と食い違う場合は、古い日付のほうが負けます。ENISAは、利用者マニュアルとチュートリアル動画を稼働開始時に公開すると述べており、公開済みのガイダンスはすべて変更されうるものとしています。

ENISAが今回、公開初日には 決して 利用できないことを確認した点が2つあります： 任意の報告 （第15条に基づくもの）。これは日付の定めのない将来の段階に先送りされます。もう一つは報告用の APIです。これは後の段階で検討される可能性があります。脆弱性の取扱いを支える 整合規格 は依然として未整備です。欧州委員会が2026年7月に標準化要請M/606の改正案を示し、2026年の期限を2か月後ろ倒ししたことを受け、現在は2026年10月30日ごろが見込まれており、まだ官報に引用されていません。

これが最初に重要な期限である理由

一度限りで完了するCEマーキングとは異なり、報告は2026年9月に始まり、その後いつでも発動し得る継続的な義務です。準備は一度きりのプロジェクトではありません。社内の検知・報告プロセスを今から構築してください。ツールの整備が終わっているか否かにかかわらず、義務は2026年9月11日から適用されます。

04報告先

報告の提出先： ENISA および次に対して コーディネーターとして指定されたCSIRTに対して、各国当局に個別に提出するのではなく、単一の窓口を通じて行います。その窓口が 単一報告プラットフォームであり、ENISAが第16条に基づき設置・管理・維持します。 Art. 14 · 16

どのCSIRTが自社の担当となるかは、 主たる事業所 が連合内のどこにあるかによって決まります。EU域内に設立されていない場合は、 授権代理人の所在によって決まります。受領したCSIRTは、その通知を製品が提供されている加盟国のCSIRTsに、また必要に応じて市場監視当局に展開します。 Art. 14(7) · 18

調整役の一覧は2026年9月4日に公表されました

それ以前、すなわち 2026年9月4日 までは、このページで最も実務的な問い、すなわちどの国のチームが実際に自社の提出を受け取るのかについて、公表された答えはありませんでした。ENISAは現在、 調整役として指定されたCSIRTsの一覧 を公表し、全 27 加盟国のそれぞれについて1つ以上の連絡先URLを示しています。アイルランドはCRA向けの専用NCSCページを示し、スペインはINCIBEの2つの別々の窓口、すなわちインシデント用と脆弱性調整用の窓口を示しています。

この一覧は各加盟国の調整役が誰かを示します。そのうちどれが自社の調整役かは示しておらず、第14条(7)のテストは多くの組織が想定するより狭いものです。自社の 主たる事業所 とは、デジタル要素を含む自社製品のサイバーセキュリティに関する決定が 主として行われる加盟国であり、登記上の本店や最大の商業拠点ではなく開発拠点である場合もあります。これを判断できない場合は、EU域内の従業員数が最も多い加盟国が代替基準となります。EU域内に拠点がまったくない場合の順序は、自社の授権代理人が最も多くの製品について行為する加盟国、次に最も多くの製品を市場に投入する輸入業者、次に最も多くを利用可能にする流通業者、次に利用者が最も多い加盟国となります。これは将来のすべての提出先を固定するものですから、事前に、法務の助言を得たうえで確定し、その理由を書き留めておいてください。

支援は双方に用意されています。 ENISA は、特に中小企業に配慮したヘルプデスクを運営しており、 調整役として指定されたCSIRTs も第14条の義務についてヘルプデスク支援を提供することが求められています。ENISAはまた、修正済みの脆弱性を 欧州脆弱性データベースに登録し、2年ごとに技術動向報告書を公表します。第1回は報告義務の開始から24か月以内の予定です。 Art. 17(6)

通知した脆弱性の展開はCSIRTが止められますが、自社が止めることはできません

受領したCSIRTは、正当なサイバーセキュリティ上の理由により、厳密に必要な期間に限って、その後の展開を遅らせ、または差し控えることができます。たとえば、脆弱性が協調的開示手続の中にある場合です。欧州委員会はその条件を、 委任規則（EU）2026/881で定めました。同規則の採択日は 2025年12月11日に採択された委任法で定めました。CSIRTが通知を差し控える場合は、直ちにENISAに伝え、理由と展開の予定時期を示さなければなりません。

これとは別に、 特に 例外的な状況では、 第16条(2) の限定的な条件のいずれかを72時間通知で選択できます。すなわち、悪用が自社のCSIRTの加盟国内にとどまっていること、さらなる展開が当該加盟国の本質的利益に反すること、または展開が差し迫った高いサイバーセキュリティリスクをもたらすことです。選択した場合、CSIRTが完全な通知を公開するまで、ENISAは限定的な情報(通知が行われたこと、製品に関する一般的情報、悪用の一般的性質、セキュリティ上の理由が主張されたこと)のみを受け取ります。

PECは脆弱性にのみ利用でき、切り替えスイッチではなく要請である

2026年9月9日に ENISAは特に例外的な状況（PEC）に関する専用のガイダンスページを公表しました。これにより、これまでの資料が未解決のまま残していた適用範囲の問題に決着がつきました。PECを援用できるのは、 積極的に悪用されている脆弱性の72時間通知に限られます。同等の仕組みは 重大なインシデントには存在せず、インシデント通知にPECの操作項目はプラットフォーム上にありません。

仕組みとしては72時間フォームの末尾にあるトグルで、これを有効にすると3つの遅延理由と、任意の自由記述による理由欄が表示されます。この理由欄は飾りではありません。ENISAによれば、これは CDaC が当該提出をPECとして受け入れるかどうかを判断する助けになります。したがってPECの援用は、制限を適用するのではなく制限を求めるものであり、記録は単に 72h Submitted under PEC という状態に移り、コーディネーターの判断を待ちます。理由欄は、他の加盟国に速やかに伝えるべき事情と比較衡量しなければならない人に読まれるものとして書いてください。実際に読まれるからです。

重要な区別

いずれの仕組みも、 自社の 期限を止めるものではありません。遅らせることができないのは 提出です。24時間、72時間、最終報告の期限は認識時点から進行します。できるのは機微性を申告することであり、それにより制限されるのは 内容を閲覧できる範囲です。展開を差し控える判断は、受領したCSIRTに委ねられています。

05プラットフォームへの登録

ENISAのガイダンスは、 2026年8月3日 に更新され、さらに 2026年8月14日にインターフェースのページが追加されたもので、実際の画面を示した最初の資料です。プラットフォームが稼働するまで登録そのものはできませんが、誰がアカウントを保有するかを今のうちに決め、認証情報を準備しておくことはできます。また、24時間の期限の下で初めて向き合う前に、手順を把握しておくべきです。

必要になる前に2名を指名する

プラットフォームは、各製造者に 2種類 のユーザーアカウントを付与します。誰が担うかは今日決められます。 主 たる代表者がまず登録し、プラットフォーム上に製造者の登録情報を作成します。その担当者が次に、 副 たる代表者を招待します。この代表者は同一の製造者に対するバックアップの役割を担い、その製造者に代わって提出できます。いずれも自社の指名された個人です。提出は手動であるため、指名された報告者が1名だけで、その人物が休暇中、就寝中、または退職済みである場合は現実的な運用リスクとなります。2つ目の席は任意ではなく必要なものとして扱ってください。

認証情報はEU Loginであり、2名とも今日作成できます

プラットフォームのアカウントは EU Loginで認証します。これは欧州委員会のオンラインシステム全体で使われる共通のサインインサービスです。ENISAはアカウントを事前に作成できるとしており、これは今すぐできる最も有用な対応です。主たる代表者用に1つ、副たる代表者用に1つを、 ecas.ec.europa.euで作成してください。1年後も存在している業務用メールアドレスを使用します。欧州委員会は、EU Loginとは何か、より広い電子的アイデンティティの枠組みにどう位置づけられるかを、 信頼できるデジタルID のページで説明しています。

登録の流れ

プラットフォームへの初回アクセス時に、自分の役割を選択し、 指定されたCSIRT をドロップダウンから選び、EU Loginで認証し、法的合意を読んで承諾し、事前入力された個人情報(名、姓、メールアドレス、法人名)を確認したうえで、製造者の名称、住所および追加情報を入力します。製造者の必須項目を省略すると手続は進みません。完了すると、アカウントのステータスは "Active" となり、 "AR Primary User" の役割が付与され、確認メールが届き、プラットフォーム上に製造者エンティティが作成されます。

次の 副 たる代表者は、 メールによる招待 によって主たる代表者から加わり、事前入力された個人情報および製造者情報を確認し、同一の製造者に対して "AR Backup User" の役割で登録されます。この招待は 7日で失効し、その後、記録は「Invitation Expired」と表示され、新たに送り直す必要があります。バックアップの設定は主たる代表者と同じ機会に済ませてください。インシデントの最中に失効した招待を見つけるのは、避けられる問題です。

CSIRTは代表者を手作業で確認しますが、それによって提出が妨げられることはありません

ある人物が本当に特定の製造者を代表して報告できるのかは、誰かが確認しなければならず、その確認は調整役として指定されたCSIRTが担います。ENISAは現在これを次のように略記しています： CDaC。これは手作業の工程であり、手続はCSIRTごとに異なり、各CSIRTが独自の方法を定めています。重要なのは、それが 後 に行われ、報告と 並行して 報告と並行して行われる点です。 2026年8月3日 の更新で、ENISAはこの点に疑いの余地をなくしました。CDaCによる検証は CRAの報告義務を果たすための前提条件ではなく、通知を提出する能力に影響することもありません。検証されていないアカウントでも、24時間の期限内に提出できます。

ENISAが、市場全体を事前に登録してCSIRTsを推測に基づく確認で埋めるのではなく、実際に提出が必要になった時点で登録と検証を開始するよう勧めているのも、このためです。事前に行う準備は、EU Loginアカウントと2つの席を誰が担うかの決定であって、プラットフォームへの登録そのものではありません。

ただし、未検証のアカウントは通知20件が上限

代表者が Association Managementを通じて自分のアカウントを製造者に紐づけると、その関連付けは Unverified というステータスで作成され、検証要求がCDaCに送られます。 2026年8月14日 付のインターフェースガイダンスは、上限を10件の通知としていました。 2026年9月4日 に書き直されたFAQはこれを倍にしています。検証されていない代表者は、 1つの製造者につき最大20件の通知を提出できます が、その後は検証が必須になります。

この2つの記述は両立します。検証は最初の提出を妨げるものではありませんが、無期限に先送りできるものでもありません。ENISAは、21件目でどうなるのか、また上限が事象を数えるのか個々の提出を数えるのかを述べていません。ガイダンスページには今も古い数字が残っている点にも注意してください。8月に社内手順へ「10」と書き写したのであれば、修正してください。20件は単一製品の企業には十分ですが、複数の事業体にまたがって提出するグループには有限です。心当たりがあるなら、インシデントに迫られてからではなく、今のうちに調整役のCSIRTと話を始めてください。

1つのアカウントで複数の製造者を扱える

同じガイダンスは、2つの席まわりの運用も定めています。主たる代表者はメールアドレスでバックアップを招待し、これにより "Pending Invitation" と表示された記録が作成されます。承諾されるまで役割は付きません。副代表者は主たる代表者への昇格を申請でき、その申請はCDaCの審査に回されます。いずれの側も関連付けを解除でき、解除された関連付けには "Deleted"と表示されます。また、1つのアカウントで 複数の製造者との関連付けを保持でき、いずれも Association Management を通じて追加され、それぞれ個別に検証されます。

この最後の点は、複数の製造事業体を持つグループや、EU域外に設立された製造者のために第18条に基づいて行為する企業にとって重要です。後述の名称の落とし穴が最も強く効いてくるのもここです。

早めに気づいておきたい名称の落とし穴

ENISAのガイダンスは「Assigned Representatives」(AR)を対象に書かれており、主たる利用者とバックアップ利用者が登場します。これは プラットフォーム上のアカウントの役割です。これは 決して CRA第18条に基づき書面の委任により選任される 授権代理人 ではありません。前者は後者なしでも成り立ちます。社内手続では両者を明確に区別してください。さもなければ、必要なのは2つ目のログインだけなのに、法的な選任について議論する羽目になります。

06報告の提出

報告はダッシュボードから行います。通知を作成し、3つの別々のものを提出するのではなく、各段階で同じ記録に追記していきます。各段階には専用のタブがあり、いずれもまず下書きとして保存できます。ダッシュボードは通知ID、製造者、タイトルで検索でき、タイトルまたは最終更新で並べ替えられ、加盟国、提出種別、または "Action Required" フラグで絞り込めます。

バックアップ担当者は自分の下書きを見られない

この点について、 2026年8月14日 付のインターフェースガイダンスは明確です。ダッシュボードに表示される下書きは 自分が作成したものだけであり、同じ製造者に関連付けられた別の代表者が作成した下書きは閲覧できません。下書きは作成者だけのもので、社内で共有されるわけではありません。

結果を思い浮かべてください。ある担当者が24時間の早期警告を書き始め、下書きを保存し、その後連絡が取れなくなります。バックアップ担当者がダッシュボードを開いても何も見つからず、その間ずっと24時間の期限は認識時点から進行しています。文面は プラットフォームの外で 、インシデント対応チームがすでに共有している文書上で作成し、プラットフォームは書き写すために使ってください。

  • 早期警告ダッシュボードから新しい通知を開始し、必須項目を入力して、既存の製造者を選択するか新たに追加します。提出すると、指定されたCSIRTがアクセスでき、自動的にENISAもアクセスできます。メールとアラートによる確認は、CSIRT、ENISA、そしてその製造者に登録された すべての 代表者に届きます。提出した本人だけではありません。
  • 72時間早期警告が存在する場合にのみ利用できます。同じ通知を開き、72時間のタブを入力します。ENISAは自動的にこれを受け取りますが、 ただし 第16条(2)の条件を援用した場合は、記録に "72h Submitted under PEC" と印が付き、CSIRTが公開するまでENISAの閲覧範囲は制限されます。
  • 最終報告先行する2つの段階が存在する場合にのみ利用できます。第16条(2)の条件が援用されていない限り、ENISAは自動的に受領します。
他の加盟国に届けるのは、どの段階でも手作業

ENISAの 2026年8月3日 の指針は、他の関係CSIRTsが早期警告、72時間通知および最終報告を受け取るのは、調整役として指定されたCSIRTによる 手作業による展開の後に限られる と述べています。7月31日の記述は、これを最終報告についてのみ述べていました。自社の義務は何も変わらず、CDaCは今も第16条(2)により 遅滞なく展開する義務を負っていますが、自社の報告と、製品が販売されている他の市場との間に、ある一国のCSIRTの担当者が挟まっていることは知っておく価値があります。

何が必須で、いつ必要になるか

ENISAは、各段階でどの項目が必須かを公表しています。この表は、広く見られる思い込みに対する有益な訂正となります。24時間の早期警告は アラートであって、調査ではありません。

  • 24時間の時点：通知の種別とレベル、製造者またはスチュワードの名称、製品、および表題です。インシデントについては、違法または悪意ある行為が疑われるか否かも記載します。製品が提供されている加盟国は、すでに把握している場合にのみ必要です。
  • 72時間の時点：脆弱性および悪用の一般的な性質、講じた是正措置または緩和措置、利用者が取り得る措置です。インシデントについては、検知の時期と発生の時期、および初期評価を記載します。機微性の申告もこの段階で行います。
  • 最終報告の時点：完全な説明、重大性と影響、是正措置が利用可能となった日付、およびセキュリティアップデートの詳細です。インシデントについては、推定される根本原因と継続中の緩和策を記載します。

任意項目でも記録しておく価値があるのは CVE ID および EUVD IDで、いずれも最初の段階から入力できます。

すべての項目に文字数の上限があり、そのうち1つは非常に短い

ENISAのSRP用語集（2026年9月5日にバージョン1.1へ改訂）は、各入力欄の大きさを公表した最初のENISA文書です。深夜2時にそれを知ることになるのではなく、社内テンプレートをこれらの上限に合わせて作成してください。

  • 4000文字 ――説明文の入力欄、すなわち概要、脆弱性またはインシデントに関する一般情報、利用者が講じられる是正措置、深刻度と影響の詳細な説明、および初期評価。
  • 2000文字 ――すでに講じた是正措置または緩和措置。
  • 255文字 ――タイトル、製品名、製品バージョンの範囲、コンポーネント名、攻撃ベクトル、機微性の理由、および想定される根本原因。
  • 100文字 ――脆弱性を悪用した悪意ある行為者。おおむね1行分なので、攻撃キャンペーンを説明するのではなく、行為者名を挙げるか指標への参照を示す想定で準備してください。

用語集は、ちょっとした便宜も裏付けています。すなわち、 製品が提供されている加盟国 の項目には自社の調整役CSIRTがあらかじめ入力されており、その他の市場は自分で追加します。

編集と、後戻りできない地点

提出済みの通知は更新でき、プラットフォームは自社のCSIRT、ENISA、および展開によってすでに受領したCSIRTsに、アラートとメールを自動的に送信します。制約は2つあります。 クローズされた 通知は更新できません。また、記録は 最終報告を提出すると編集できなくなります.

アラートタブは週末も含めて監視する

各アカウントには アラート タブがあり、色分けされています。未読のアラートは水色で、開くと灰色になります。また、赤いアラートは例外的なことが起きた場合にのみ表示されます。ENISAが挙げている例は、指定されたCSIRTが 提出を無効にした場合です。したがって提出はやり取りの終わりではなく、通知が差し戻されたからといって第14条の期限が動くこともありません。そのタブを見る担当者は時間外にも見ている必要があり、これは2つの席の背後に個人アドレス2つではなく監視されたチーム用メールボックスを置くべき理由がもう一つ増えるということです。

プラットフォームの72時間カウンターは認識時点から数えていない

また、 2026年9月4日 のFAQは、画面上のカウントダウンが実際にどう動くかを明らかにしています。それらは法的な期限を追ってはいません。現行リリースでは、 72時間カウンター が表示する期日は 24時間報告を提出してから48時間後であり、認識してから72時間後ではありません。ENISAは、そのため通知が認識から72時間経つ前に 期限超過 と表示されることがあり、その項目が必須になった時点で「認識した日時」欄から数えるようにロジックを後のリリースで変更する、と明言しています。

最終報告のカウンターはまた別です。 重大なインシデント の場合、カウンターは72時間通知から1か月後を示します。一方、 積極的に悪用されている脆弱性 の場合は カウンターがまったくありません。期限は是正措置が利用可能になる時期に左右され、プラットフォームにはそれを知る術がないためです。

自分の時計を持つこと

ENISAは、カウンターは可視性のためにあり、第14条の義務を 置き換えるものではない と明言しています。自分の時計は認識の時点から動かし、インシデント記録に残してください。法が求めているとおり早期警告を速やかに提出すると、画面上のカウンターは法的な期限よりも 厳しく なります。画面上の「期限超過」表示は不適合の認定ではなく、緑のカウンターは抗弁にもなりません。

稼働開始時点では、プラットフォームは認識した時点を記録しない

2026年9月5日に ENISAは、項目ごとのSRP用語集をバージョン1.1に更新しました。そこに含まれる2つの脚注は、このページの他のどの内容よりも重要です。積極的に悪用されている脆弱性については、 Date/time when you become aware という項目には、 プラットフォームの次のリリースで利用可能になるという注記が付いています。重大なインシデントについては、現行リリースにおける同等の項目の名称は Date/time the incident was detected.

上記のカウンターの論理と並べると、これで円が閉じます。FAQは、認識の項目が必須になれば72時間カウンターが修正されると述べていました。用語集は、その項目が9月11日に稼働するリリースには含まれていないことを裏付けています。つまり初日には、プラットフォームは脆弱性について認識のタイムスタンプをまったく取得せず、インシデントについては検知の時点を記録します。それは認識の時点ではありません。

検知は認識ではなく、その差を立証するのはあなたです

委員会の 2026年7月27日 付けガイダンスの下では、初期評価によって 合理的な程度の確実性 が得られた時点で、自社製品の脆弱性が悪用されている、または重大なインシデントが発生したと認識したことになります。検知は通常それより早く、ときにはかなり早く訪れます。プラットフォームが記録するのは検知の時点であって評価の時点ではないため、そこに保持される記録は第14条が起算点とする時点ではありません。初期評価がいつ終わり、誰がその判断を下したのかを、時刻付きで自ら記録しておいてください。市場監視当局から、早期警告がなぜそのタイミングで届いたのかを問われたとき、証拠になるのはプラットフォームではなくその記録です。

プラットフォームが使えなくても、時計は動き続ける

ENISAは 2026年9月4日に障害に関する回答を追加しました。SRPが一時的に利用できない場合は、復旧を待ってから提出してください。その間に直ちに連絡する必要がある場合は、指定されたCSIRTに直接連絡してもかまいませんが、サービス復旧後に通知をプラットフォーム経由で提出する必要があることに変わりはありません。

ENISAが述べていないので、はっきり記しておきます。CRAには、障害中に24時間、72時間、14日、1か月の期限を止める規定はありません。障害の発生時刻と、行った直接連絡の時刻を記録し、いずれも認識時刻の記録と併せて保管してください。

現時点ではAPIはありません

ENISAは、 初回リリースではアプリケーションプログラミングインターフェースは提供されないと述べており、API機能は将来の段階で検討される可能性があるとしています。検知、トリアージ、起草は社内で自動化できますが、提出そのものは人がブラウザのフォームに入力する作業です。この引き継ぎを意図的に設計し、時間外や週末でも複数の担当者が実行できるようにしてください。

任意の報告は稼働開始時には利用できない

プラットフォームは最終的には、製造者に限らずあらゆる自然人または法人による、脆弱性、サイバー脅威、インシデントおよびニアミスの任意の報告も受け付ける予定です。2026年7月31日のFAQは、これが2026年9月11日より後に有効になるとしていました。 2026年9月4日 の書き直しはより明確で、時期も後ろにずれています。9月11日の時点でプラットフォームが受け付けるのは、第14条および第24条に基づく義務的な通知 のみ であり、 第15条 に基づく任意の報告は、日付の定めのない将来の段階に先送りされます。法的に必要なものが欠けているわけではありませんが、低リスクで練習する機会はなく、悪用されていない脆弱性をSRP経由で流す想定だった開示プロセスには、まだ送り先がありません。

07今日できること

24時間の期限を守ることは、書類上の問題ではなく運用上の問題であり、準備のほとんどはすでに着手できます。以下のいずれも、プラットフォームの稼働に依存しません。

  • EU Loginアカウントを作成する。 主たる報告者と、少なくとも1名のバックアップの分を作成します。所要は数分で、 ecas.ec.europa.eu から行えます。インシデントの最中に気づきたくない手順を1つ減らせます。
  • 指定されたCSIRTを特定する。 ENISAは 調整役の一覧 を2026年9月4日に全27加盟国分について公表しました。したがってこれは今すぐ完了できる作業です。第14条(7)の主たる事業所テストを適用し、自社に該当する行を選び、その理由を書き留めてください。
  • 24時間用のフォームを社内で作る。 ENISAの早期警告の必須項目に対応した短い雛形を用意しておけば、最初の実際の提出は文章を考える作業ではなく、書き写す作業になります。プラットフォーム上の下書きは作成者にしか見えないため、両方の代表者が開ける場所に置いてください。
  • 担当者を、時間外も含めて指名する。 報告が必要かを判断する人、起草する人、提出する人を決めてください。APIがない以上、最後の工程はキーボードに向かう特定の担当者です。
  • 正確なSBOMを維持する。 出荷したことを知らなかった構成要素については報告できません。ソフトウェア部品表を整備し、リリースの変更に合わせて最新の状態に保ってください。
  • 継続的に監視する。 構成要素を既知脆弱性の情報源と突き合わせ、積極的に悪用されている欠陥が数週間ではなく数時間で表面化するようにします。当社の SBOMと脆弱性アナライザー は、部品表をNVDおよびEU脆弱性データベース(EUVD)と照合します。
  • 実際に対象となる範囲を確認する。 72時間の段階では製品の種類と附属書IIIまたはIVの区分が問われるため、必要になる前に分類を確定しておきましょう。 分類ツール がその答えを示します。また、 コンプライアンスマトリクス 報告をAnnex Iの脆弱性対応義務全体の中に位置付けます。
  • 時間外にアラートタブを見る担当者を決めておく。 指定されたCSIRTは提出を無効にすることができ、それを伝えるアラートは受信箱ではなくプラットフォームに届きます。両方の代表者の席の背後に、監視されたメールボックスを置いてください。
  • プラットフォームのカウントダウンに頼らない。 認識時刻は自分で記録してください。画面上の72時間カウンターは、認識時点ではなく24時間報告の提出時点から進むため、法的な期限が過ぎる前に提出を期限超過と表示することがあります。
  • 稼働開始時の資料に注意する。 ENISAによれば、利用者マニュアルとチュートリアル動画は、公開URL自体とともに、プラットフォームの稼働開始時に公表されます。
脆弱性アナライザーを開く →CRAの解説 →

08一次情報で追う

このページは 2026年9月9日時点の状況を反映しています。プラットフォームは今も動いており、ENISAは変更のたびに告知するのではなく静かにページを更新します。FAQが書き直されたのは 2026年9月4日で、このときコーディネーターの一覧も公表されました。用語集がバージョン1.1に達したのは 2026年9月5日、特に例外的な状況（PEC）に関する5番目のガイダンスページが公表されたのは 2026年9月9日です。サポートに関する問い合わせ先として、ENISAはハブページにヘルプデスクのアドレスを掲載しています。すなわち cra-srp-helpdesk [at] enisa.europa.euです。これらが一次情報であり、上記はすべて当社による読み解きです。

「最終更新」表示は信頼できるバージョンの目印ではない

以前、社内手順に書き写す内容にはこの日付表示を併記するようお勧めしました。この助言には留保が必要です。 2026年9月7日から9日にかけて の間に、ENISAは AR Notification submission and update のページを大幅に書き直しましたが、そのページの日付表示は 3/08/2026のままでした。用語は全体を通じて CDaC という表記に置き換えられ、各国エンドポイントのデータ層への言及は削除され、提出確認の通知は、提出者だけでなく当該製造者の すべての Assigned Representative に届くようになり、早期警告が他の関係CSIRTsに届くのは 手作業の 展開の後に限られることが明記されました。ガイダンスページが自社の手順にとって重要であるなら、ENISAがページに表示する日付を信頼するのではなく、そのテキストの日付入りの写しを自分で保管してください。

拘束力のある条文としては、第14条から第17条が報告のエコシステムを定め、第16条がプラットフォームを設置します。当社の 規則リーダーでお読みいただけます。節目となる日付は 現況 のページで追跡しています。

09よくある質問

CRAに基づいて何を、どのくらい迅速に報告しなければなりませんか？

自社製品のセキュリティに影響する、積極的に悪用されている脆弱性および重大なインシデントです。認識から24時間以内に早期警告、72時間以内により詳細な通知、そして脆弱性については是正措置が利用可能となってから14日以内、重大なインシデントについては72時間通知から1か月以内に最終報告を行います。 Art. 14

報告義務はいつから始まりますか？

2026年9月11日。法律の発効から21か月後であり、2027年12月11日の完全適用よりも大幅に先行します。

誰に報告しますか？

ENISAと、調整役として指定された各国CSIRTに、第16条に基づき設置される単一報告プラットフォームを通じて報告します。担当のCSIRTは、連合内の主たる事業所によって決まり、EU域内に設立されていない場合は授権代理人の所在によって決まります。

調整役のCSIRTsの一覧は公表されていますか？

はい、2026年9月4日以降は公表されています。ENISAは全27加盟国の連絡窓口を公表しています。この一覧は各加盟国の調整役を示すものであり、そのうちどれが自社の調整役かは、依然として第14条(7)の主たる事業所テストによります。このテストは、自社製品のサイバーセキュリティに関する決定が主としてどこで行われるかによって決まります。

すべてのバグや脆弱性を報告しなければなりませんか？

いいえ。報告が必要なのは積極的に悪用されている脆弱性および重大なインシデントのみです。悪用される前に発見・修正した脆弱性は通常の脆弱性対応プロセスで管理されます。

ENISAの単一報告プラットフォームはすでに利用可能ですか？

2026年9月7日時点ではできません。プラットフォームは稼働しておらず、公開URLも公表されていません。ENISAは稼働開始前にSRPのページで告知します。2026年9月11日から稼働する予定で、ENISAはユーザーテストとセキュリティテストを実施済みであり、複数のCSIRTsが参加したと述べています。

提出が必要なときにプラットフォームが停止していたらどうすればよいですか？

2026年9月4日に追加されたENISAの回答は、待って、再び利用できるようになってから提出せよ、というものです。その間に直ちに連絡する必要がある場合は、指定されたCSIRTに直接連絡してもかまいませんが、通知はその後もプラットフォーム経由で提出する必要があります。なお、CRAには障害中に期限を止める規定はないため、障害と直接連絡の時刻を記録してください。

プラットフォームのカウントダウンは法的な期限と一致しますか？

厳密には一致しません。現行リリースでは、72時間カウンターが示す期日は、認識してから72時間後ではなく、24時間報告を提出してから48時間後です。そのため、法的な期限が過ぎる前に提出が期限超過と表示されることがあります。ENISAは、ロジックは後のリリースで変更されること、またカウンターは第14条の義務を置き換えるものではないことを述べています。認識時点から始まる自分の時計を持ってください。

プラットフォームは、私が認識した時点を記録しますか。

稼働開始時点では記録しません。2026年9月5日のSRP用語集は、積極的に悪用されている脆弱性についての認識の項目は後のリリースで初めて登場し、重大なインシデントについては現行の項目が検知の時点を記録すると述べています。検知は通常、認識に先立ちます。委員会の2026年7月のガイダンスは、認識を、合理的な確実性に達した初期評価と結び付けています。その評価がいつ終わったのかを自ら記録しておいてください。

重大なインシデントについてPECを援用できますか？

できません。2026年9月9日のENISAのガイダンスは、特に例外的な状況が適用されるのは積極的に悪用されている脆弱性の72時間通知に限られるとしています。重大なインシデントの通知にPECの操作項目はありません。さらに、PECの援用は要請である点にも注意してください。受け入れるかどうかを判断するのは調整役のCSIRTであり、その判断は任意で提出する理由欄が助けとなります。

各項目はどれくらいの長さにできますか。

用語集は上限を公表しています。説明文の入力欄は4000文字、すでに講じた措置は2000文字、タイトル、製品、コンポーネント、攻撃ベクトル、根本原因は255文字、悪意ある行為者はわずか100文字です。社内テンプレートはこれらの大きさに合わせて作成してください。

今から登録や準備はできますか。

できますし、そうすべきです。プラットフォームが使用する EU Login アカウントを、主たる報告者とバックアップの分だけ作成してください。プラットフォームが稼働するまで登録そのものはできません。また、調整役のCSIRTは初回アクセスより前ではなくその後にアカウントを検証するため、ENISAは実際に提出が必要になった時点でプラットフォームへの登録を始めるよう勧めています。ENISAは2026年8月3日に、この検証は報告義務を果たすための前提条件ではなく、提出を妨げるものでもないことを確認しました。

CSIRTの検証を受ける前の提出に上限はありますか？

はい、そして数字は変わりました。2026年8月14日のENISAのインターフェースガイダンスは10件の通知としていましたが、2026年9月4日に書き直されたFAQは、検証されていない代表者は1つの製造者につき最大 20 件の通知を提出でき、その後は検証が必須になるとしています。検証は最初の提出を妨げるものではありませんが、無期限に先送りできるものでもありません。

バックアップの報告者は、自分が書き始めた下書きを見られますか？

見られません。ダッシュボードに表示されるのはログイン中の代表者が作成した下書きだけなので、書きかけの早期警告はバックアップ担当者には見えません。起草はプラットフォームの外で、インシデント対応チームが共有する文書上で行い、プラットフォームは書き写すために使ってください。

APIで報告を提出できますか。

できません。ENISAは、現段階ではアプリケーションプログラミングインターフェースは提供されないと述べています。社内の検知と起草は自動化できますが、提出は人がブラウザのフォームに入力する作業です。

24時間の早期警告には実際に何を含める必要がありますか。

多くの人が想像するよりも少ない内容です。必須項目は、通知の種別とレベル、製造者またはスチュワードの名称、製品、表題、そしてインシデントの場合は違法または悪意ある行為が疑われるか否かです。実質的な分析は初日ではなく72時間の時点で求められます。

報告のための標準フォーマットやテンプレートはすでにありますか？

データ項目は公表されています。ENISAのFAQは、24時間、72時間、最終報告の各段階でどれが必須かを示しており、これに対応する社内の雛形を今日から用意できます。欧州委員会は、実施法によって書式と手続をさらに定める可能性があります。

開示にリスクがある場合、報告を遅らせることはできますか。

提出は遅らせられません。24時間、72時間、最終報告の期限は認識時点から進行し、これを止めるものはありません。機微性の申告は可能です。第16条(2)に基づき限定的な条件を選択すれば、CSIRTが完全な通知を公開するまでENISAが見られる範囲を制限できます。その後の展開を遅らせる判断は、2025年12月11日に採択された委任規則（EU）2026/881に基づき、受領したCSIRTに委ねられています。

2026年9月より前にすでに認識していた悪用も報告しなければなりませんか。

その必要はありません。義務は認識した時点から適用され、2026年9月11日より前に積極的な悪用をすでに認識していた脆弱性には及びません。

何年も前に市場に投入した製品にも報告義務は適用されますか。

適用されます。第69条(2)は、2027年12月11日より前に市場に投入された製品は同日以降に実質的な変更が加えられた場合にのみ規則の対象となると定めていますが、第69条(3)は第14条についてこれを明示的に適用除外しています。すなわち、報告義務は2027年12月11日より前に市場に投入された適用範囲内のすべての製品に、変更の有無を問わず適用されます。したがって、CRAの製品要件の対象外であっても、報告の対象となる製品はあり得ます。 Art. 69(2)–(3)

これらはオープンソースプロジェクトにも適用されますか。

オープンソースソフトウェアのスチュワードは、第24条(3)に基づき、デジタル要素を含む製品に関与する限りにおいて報告義務を負います。欧州委員会の2026年7月27日付ガイダンスが、オープンソースについてより詳しく扱っています。

小規模な企業の場合、どこで支援を受けられますか。

ENISAは特に中小企業に配慮したヘルプデスクを運営しており、調整役として指定されたCSIRTsも第14条の義務についてヘルプデスク支援を提供することが求められています。ENISAは、FAQやガイダンスページで答えの得られない質問のために、ヘルプデスクのアドレス cra-srp-helpdesk [at] enisa.europa.euを公表しており、利用者マニュアルとチュートリアル動画は稼働開始時に続くとしています。

続きを読む

関連する参照

§CRAの解説

適用範囲、クラス、義務、および完全なタイムラインをわかりやすく解説。

→§SBOMと脆弱性アナライザー

24時間の期限を満たすために、コンポーネントをNVDおよびEUVDと照合して追跡してください。

→§委員会ガイダンス

欧州委員会の第26条ガイダンスが、報告および脆弱性処理の義務をどう読み解いているか。

→§現在の状況

プラットフォーム、規格、委任法が実際にどこまで進んだか。

→§規則の全文

規則(EU)2024/2847の拘束力ある条文における第14条から第17条。

→§よくある質問

参照付きのステークホルダーからのよくある質問に対する簡潔な回答。

→