はじめに

2026年9月11日、EU サイバーレジリエンス法（CRA）の脆弱性・重大インシデントの報告義務が予定どおり適用を開始しました。同じ日に、報告の窓口になる 単一報告プラットフォーム（SRP: Single Reporting Platform） を ENISA（欧州連合サイバーセキュリティ機関）が稼働させています。プレスリリースの表現は「初期運用能力（initial operating capability）を配備した」——つまり、最初の段階が動き出した、という言い方です。

当サイトは7月に「9月11日から何が始まるのか・個人開発者は対象か」を書きました。あの記事が「対象か」の話なら、この記事は「動き出した仕組み」の話です。法律の条文ではなく、ポータルの画面・登録の手順・24時間で入力を求められる項目・まだ実装されていない機能、という実務の単位で見ていきます。

同じ9月11日には Raspberry Pi も「mandatory reporting requirements」と題した記事を出しました。部品を供給する側と、それを組み込んだ製品を EU で売る側の義務がどう分かれるかは、自作基板や ESP32 製品を作る読者にいちばん近い論点なので、§6 で欧州委員会の FAQ と突き合わせて整理します。

この記事では次の6点を扱います。

  1. 報告義務のおさらい — 何を・誰が・いつまでに・どこへ（7月の記事の要約）
  2. SRP とは何か — 一度の報告が、誰にどう届くのか
  3. 9月11日に実際に動いたもの — ポータルの画面、登録の手順、24時間で要る項目
  4. まだ無いもの — 「初期運用能力」の中身。任意報告・API・多言語・カウンターの既知の制限
  5. 支援資料とヘルプデスク — FAQ・マニュアル・用語集・ファクトシート・各国 CSIRT の一覧
  6. Raspberry Pi の整理 — 部品供給者と製品製造者、そして自分の立ち位置
⚠️ この記事の性格と時点

本記事は 2026年9月12日時点の一次資料（ENISA・欧州委員会・CRA 本文・Raspberry Pi 公式）にもとづく整理で、法的助言ではありません。 自社製品が対象かどうか、どの CSIRT に報告するかといった個別の判断は、ENISA のヘルプデスクや専門家に確認してください。ポータルは筆者が画面を見ただけで、アカウントの作成や報告の送信はしていません。

📌 この記事の3行まとめ
  • SRP は9月11日に稼働。 製造者は EU Login（MFA 必須）で登録し、報告先の CSIRT を1つ選び、24時間以内の早期警告から3段階で報告する。登録は「報告が必要になったとき」でよいと ENISA が明記
  • まだ無いもの：任意報告（第15条）、API、英語以外の画面。72時間カウンターは「早期警告提出から48時間後」を期限表示する既知の制限あり。オープンソース・スチュワードの義務は 2027年12月11日から
  • 部品の脆弱性が自分の製品でも悪用されているなら、部品メーカーと製品製造者の両方が報告する（欧州委員会 FAQ 5.4）。Raspberry Pi の CE 適合はあなたの製品には移転しない

🧭 1. 報告義務のおさらい — 何を・誰が・いつまでに・どこへ

CRA（Regulation (EU) 2024/2847）は、「デジタル要素を持つ製品」を EU 市場に出す製造者に、設計から脆弱性対応までの義務を課す規則です。本体の義務は2027年12月11日からですが、第14条の報告義務だけが2026年9月11日から先行して適用されます（第71条(2)）。背景と「自分は対象か」の論点は7月の記事に書いたので、ここでは仕組みを追うのに必要な分だけ再掲します。

問い 答え（CRA 第14条）
何を ①悪用中の脆弱性（actively exploited vulnerability）②製品のセキュリティに影響する重大インシデント（severe incident）
誰が 製造者。所在地は問わない。オープンソース・スチュワードは第24条(3)により 2027年12月11日から
いつまでに 認知から 24時間以内に早期警告、72時間以内に通知、最終報告は脆弱性なら是正措置の提供から14日以内、インシデントなら 72時間通知から1か月以内
どこへ SRP を通じて一度だけ。 主たる事業所の国の「調整役 CSIRT」宛で、ENISA にも同時に共有される

「悪用中」の定義は第3条で「悪意ある行為者がシステム所有者の許可なく悪用したという信頼できる証拠がある脆弱性」。単に CVE が公開されただけでは対象になりません。「重大」の基準は第14条(5)で、機密性・完全性・可用性・真正性を損なう（おそれがある）か、悪意あるコードの導入や実行につながる（おそれがある）かの2つです。

なぜ国の CSIRT と ENISA に報告させるのか。 欧州委員会の FAQ（5.4）は、調整役 CSIRT と ENISA が悪用中の脆弱性の全体像を持ち、NIS2 指令上の任務や市場監視を機能させるためだと説明しています。多くの製品は EU 域内全体で売られるので、1製品の悪用は域内市場全体への脅威とみなす（前文66）——これが「一度の報告を全部の当局に配る」設計の根拠です。

💡 ワード解説：CSIRT／調整役 CSIRT（CDaC）／ENISA／AR
  • CSIRT：Computer Security Incident Response Team。インシデント対応の組織で、EU 各国に置かれている
  • 調整役 CSIRT（CDaC: CSIRT Designated as Coordinator）：CRA の報告を最初に受け取り、他国の CSIRT へ配る役割を各国が1つ指定したもの。SRP では報告するときに製造者が自分で選ぶ
  • ENISA：欧州連合サイバーセキュリティ機関。SRP を開発・運用し、報告は同時に ENISA にも届く
  • AR（Assigned Representative）：SRP 上で製造者（または OSS スチュワード）に代わって報告を提出する個人。SRP の用語で、法律上の「認定代理人（authorised representative）」とは別物

🔀 2. SRP とは — 一度の報告が、誰にどう届くのか

SRP の法的根拠は CRA 第16条(1)です。原文はこうです。

For the purposes of the notifications referred to in Article 14(1) and (3) and Article 15(1) and (2) and in order to simplify the reporting obligations of manufacturers, a single reporting platform shall be established by ENISA. The day-to-day operations of that single reporting platform shall be managed and maintained by ENISA. （第14条(1)・(3)と第15条(1)・(2)の通知のため、また製造者の報告義務を簡素化するため、ENISA が単一報告プラットフォームを設置する。その日常の運用は ENISA が管理・維持する）

報告が届く先を、ENISA の FAQ（1・8・20）と第16条(2)・(3)から図にするとこうなります。

flowchart TD M["製造者の担当者（AR）
EU Login でログイン"] --> S["SRP
portal.cra-srp.enisa.europa.eu"] S --> C["調整役 CSIRT（CDaC）
製造者が報告時に1つ選ぶ"] S -. 提出と同時に閲覧可能 .-> E["ENISA"] C -- "遅滞なく配布
PEC なら遅延可" --> O["製品が出回っている
他の加盟国の CSIRT"] C --> MS["自国の市場監視当局
（執行に必要な情報）"] O --> MS2["各国の市場監視当局"]

ポイントは3つです。

  • 製造者が連絡するのは1か所。調整役 CSIRT を選んで提出すれば、他国の CSIRT への配布は CSIRT 側の仕事（第16条(2)「遅滞なく配布する」）
  • ENISA には提出と同時に見える。例外は、製造者が72時間通知で「特に例外的な事情（PEC）」を立てた場合で、そのときは ENISA に部分情報だけが渡り、全文は調整役 CSIRT の判断後に届く（第16条(2)第3段落。§4 で触れます）
  • 市場監視当局にも情報が回る。CSIRT は執行に必要な情報を自国の市場監視当局に渡す（第16条(3)）。報告は「CSIRT に助けてもらう」ためだけでなく、執行の入口でもあります

FAQ 8 には、複数の子会社や EU 域外の親会社を持つ製造者でも「1つの悪用中脆弱性・重大インシデントにつき通知は1回」と書かれています。社内でどこが出すかを決めておくのは製造者の責任、という整理です。

🟢 3. 9月11日に実際に動いたもの — ポータル・登録・24時間で要る項目

ポータルの入口

portal.cra-srp.enisa.europa.eu を開くと、最初の画面は「What User are you?」——Assigned Representative（製造者側の担当者）か、CSIRT Representative かを選ぶだけのページです。9月12日に筆者が見た画面がこれです（アカウント作成・入力・送信はしていません）。

SRP ポータルの最初の画面。What User are you? の見出しの下に Assigned Representative と CSIRT Representative の2つのカードと Continue ボタン

SRP ポータルの入口（2026年9月12日・筆者撮影）。AR の脚注に「第14条・16条・24条(3)の義務報告を製造者または OSS スチュワードに代わって提出する個人」とある

AR を選んで進むと、次は「Select your designated CSIRT」——報告先の調整役 CSIRT をドロップダウンから1つ選ぶ画面です。並んでいるのは EU 加盟27か国の CSIRT（Austria から Sweden まで）で、ENISA が公開している調整役 CSIRT の一覧（ドイツなら BSI の CERT-Bund、フランスなら CERT-FR）と対応しています。ここで選ぶ前に EU Login の認証はまだ求められません。筆者はこの画面で止め、選択も認証もしていません。

SRP ポータルの CSIRT 選択画面。CSIRT Designated as Coordinator (CDaC) のドロップダウンを開いた状態で、CSIRT Austria から CSIRT Sweden まで27か国が並ぶ

調整役 CSIRT の選択（2026年9月12日・筆者撮影）。ドロップダウンには27か国。この先が EU Login の認証

登録の手順 — ENISA のガイダンスどおりに

ENISA の「AR User Registration」（2026年9月10日更新）と FAQ 9 に、登録の流れが手順で書かれています。画面の確認は上の2枚までで、3番目以降は ENISA の記述です。

flowchart TD A["① 役割を選ぶ
Assigned Representative"] --> B["② 調整役 CSIRT を選ぶ"] B --> C["③ EU Login で認証
MFA 必須"] C --> D["④ 利用規約に同意"] D --> E["⑤ 氏名・メールを確認
EU Login から転記・編集不可"] E --> F["⑥ 製造者の情報を入力
製造者名・補足"] F --> G["登録完了・Active
AR Primary User
CSIRT が関連付けを検証"]

要点を ENISA の記述から拾います。

項目 ENISA の説明（FAQ 9・登録ガイダンス）
認証 EU Login のアカウント＋多要素認証（MFA）が必須。EU Login は個人のアカウントで、担当者は自分のアカウントを使う。法人としての追加認証は現時点で使っていない
役割 製造者ごとに Primary AR は1人、Secondary AR は最大20人。Secondary は Primary からのメール招待で登録（招待は7日で失効）
CSIRT による検証 「その人がその製造者を代表してよいか」の検証は登録の後、報告と並行して行われる。検証待ちでも報告は提出できる（検証前は製造者あたり20件まで）
いつ登録するか 「報告が必要になったときに登録し、事前に予防的に登録しないよう」助言。EU Login があれば「登録は数分」
できあがる状態 ユーザーは「Active」、役割は「AR Primary User」。製造者の記録が作られ、関連付けは CSIRT の検証待ち（Unverified）。確認メールが届く

「予防的に登録するな」は意外に思えますが、理由は FAQ に書いてあります——各国 CSIRT の検証作業を増やさないためです。裏を返せば、EU Login のアカウントと MFA だけは先に用意しておけば、必要になった日に数分で登録できる、ということでもあります。

24時間の早期警告で要る項目

SRP の用語集（Glossary v1.3・9月10日更新）は、報告フォームの各項目について「意味・書き方・例・形式」と、早期警告／72時間通知／最終報告のどの段階で必須かを1つずつ定めています。共通18項目に加えて脆弱性用・インシデント用の項目があり、そこから早期警告の時点で必須のものだけを抜くと次のとおりです。

項目 24h 早期警告 72h 通知 最終報告
通知の種別（脆弱性／インシデント） 必須 引き継ぎ 引き継ぎ
タイトル（255字以内） 必須 引き継ぎ 引き継ぎ
概要（4,000字以内・事実ベース） 必須 引き継ぎ 引き継ぎ
製造者名 自動（登録時の情報） 自動 自動
製品が出回っている加盟国 必須（CDaC は自動、他国を追加） 更新可 更新可
製品名・バージョン 必須 引き継ぎ 引き継ぎ
認知した日時 必須 引き継ぎ 引き継ぎ
インシデントが違法・悪意ある行為によると疑われるか（SI のみ） 必須（Yes／No／Unknown） 引き継ぎ 引き継ぎ
悪用・インシデントの一般的な情報 任意 必須 引き継ぎ
取った対策／利用者が取れる対策 任意 任意 必須
深刻度・影響の詳細 任意 任意 必須
是正措置が利用可能になった日（AEV） 任意 任意 必須

24時間で求められるのは「何が・どの製品で・いつ分かったか」までで、原因や対策の詳細は72時間・最終報告に回せます。CVE ID・EUVD ID・攻撃経路・悪用した攻撃者の情報はどの段階でも「あれば」の扱いです。用語集は「必須」「任意」「情報があれば必須」「前段階から引き継ぎ」の4種で書き分けているので、フォームを埋める前に一度読んでおくと迷いません。

提出したあと — 下書き・更新・カウンター

ユーザーマニュアル（v1.1・55ページ）によれば、報告は下書き保存ができ、提出すると状態が「EW Submitted」→「72h Submitted」→「FR Submitted」と進みます。早期警告と72時間通知は提出後も更新できますが、最終報告を出すと AR 側からは編集できなくなります。SRP は72時間通知と最終報告の期限カウンターを持ち、リマインダーのメールと画面上の警告を出します——ただしこのカウンターには既知の制限があり、それは次の節で扱います。

🟡 4. まだ無いもの — 「初期運用能力」の中身

プレスリリースは「今後数か月で、運用経験と利用者のニーズにもとづき機能を改善・拡張する」と明記しています。何が最初の段階に含まれていないかは、ENISA の FAQ とマニュアルにはっきり書かれています。

項目 2026年9月11日時点 出典
義務報告（悪用中の脆弱性・重大インシデント） ✅ 24h／72h／最終の3段階で提出できる FAQ 4・マニュアル 1.2
任意報告（第15条。悪用されていない脆弱性・脅威・ニアミス） ❌ 未実装。将来のフェーズで導入 FAQ 4・6・27
API ❌ 初期リリースでは提供なし。画面から提出する。将来検討 FAQ 15
言語 英語のみ。ファクトシートは順次翻訳、画面の多言語化は次フェーズで検討 FAQ 24
72時間カウンター ⚠️ 現リリースでは「早期警告の提出から48時間後」を期限として表示。認知時刻より前に「期限超過」と出る場合がある。将来「認知した日時」基準に修正 FAQ 26
最終報告カウンター AEV は未実装（是正措置の提供日で決まるため）。SI は72時間通知から1か月で表示 FAQ 26
OSS スチュワードの報告 義務の適用は 2027年12月11日から（第24条(3)・第71条(2)） FAQ 4・29
製造者以外からの報告 対応外。国の CSIRT に直接連絡を。SRP に出しても「invalid」になり得る FAQ 30
SRP が止まっているとき 復旧を待って提出。急ぐなら CSIRT に直接連絡してよいが、復旧後に SRP からも提出が必要 FAQ 25

カウンターの制限を FAQ に書いていることは、筆者は素直に評価したいところです。「期限を守る責任は製造者にあり、カウンターは目安」と FAQ 26 が念を押しているので、自分の側でも認知時刻を記録しておくのが実務上の対処になります。

💡 ワード解説：PEC（特に例外的な事情）

PEC（Particular Exceptional Circumstances） は第16条(2)第3段落の仕組みで、72時間通知（悪用中の脆弱性のみ）で製造者が「①悪用が報告先の国以外で起きていない ②さらなる配布がその国の本質的利益に反する ③配布自体が差し迫った高いリスクを生む」のいずれかを立てると、他国 CSIRT と ENISA への全文の配布を遅らせられる制度です。SRP では72時間通知のフォームにトグルがあり、理由と任意の説明を添えます。ENISA には「通知があったこと・製品の一般情報・悪用の一般的性質・PEC を立てたこと」だけが先に渡り、全文は調整役 CSIRT の判断後に届きます。条件の詳細は欧州委員会の委任規則（(EU) 2026/881・2025年12月11日採択）が定めています。

📚 5. 支援資料とヘルプデスク — 何がどこにあるか

ENISA の SRP トピックページには、9月9日〜11日付で次の資料が並んでいます（すべて英語。ファクトシートのみ DE・EL・FR・HU・LV・NL・RO・SL・SV 版あり）。

資料 内容 更新日
FAQ（31問） 目的・法的根拠・期限・登録・CSIRT の選び方・PEC・カウンター・停止時の扱い・セキュリティ連絡先 2026年9月11日
AR User Manual（PDF・v1.1・55ページ） 登録・ログイン・ダッシュボード・3段階の提出・更新・リマインダーを画面つきで 2026年9月
Glossary（v1.3） 全項目の意味・書き方・例・形式・段階ごとの必須／任意 2026年9月10日
Factsheet（PDF・2ページ・v1.0） 何を・誰が・いつまでに・どこへ、を1枚に。英語版のほか9言語 —
登録／提出／画面機能／PEC のガイダンス（Web） マニュアルの各章を Web 化したもの 9月9〜10日
チュートリアル動画 AR 向けの操作動画 —
調整役 CSIRT の一覧 27か国の連絡先 2026年9月10日
利用規約（PDF・v1.0） アカウント情報の正確性・アクセス手段の管理・虚偽時の停止 2026年9月10日

質問の窓口は2種類に分かれています。報告の内容や使い方は cra-srp-helpdesk@enisa.europa.eu（FAQ 末尾）、プラットフォーム自体のセキュリティ問題は cra-srp-security@enisa.europa.eu（PGP 鍵公開・FAQ 31）です。FAQ 19 によれば、ENISA はヘルプデスクを「特に中小企業向けに」運用し、修正済みの脆弱性を欧州脆弱性データベース（EUVD）に公開し、報告義務の開始から24か月以内に最初の傾向報告を出すことになっています。

法解釈の側は欧州委員会です。「Commission guidance on the application of the CRA」（C(2026) 5252・2026年7月27日承認・付属書84ページ）の第9.1節と、「FAQs on the CRA implementation」（v1.4・2026年9月4日）の第5節が報告義務の解説で、ENISA の FAQ もこの2つを参照先にしています。9月4日の v1.4 で追加された FAQ 5.5 は「OSS スチュワードは報告義務を負うか」（答え：第24条(3)により2027年12月11日から）です。

🍓 6. Raspberry Pi の整理 — 部品供給者と製品製造者、そして自分の立ち位置

Raspberry Pi が9月11日に言ったこと

Raspberry Pi の9月11日の記事は、24時間・72時間・14日（重大インシデントは72時間通知から1か月）の段階を整理したうえで、こう呼びかけています。

If you’re building products with Raspberry Pi hardware and need to understand how this affects your own CRA obligations, here’s where to go: （Raspberry Pi のハードウェアで製品を作っていて、これが自分自身の CRA 上の義務にどう影響するかを知る必要があるなら、行き先はこちら）

行き先として挙がっているのは、同社の CRA ページ、白書、Product Information Portal（データシートと適合文書）、そして3つの窓口——脆弱性の報告・問い合わせは security@raspberrypi.com、技術サポートは applications@raspberrypi.com、製品適合の支援は compliance@raspberrypi.com です。

線引きそのものは、同社の白書（Release 2・2026年9月10日ビルド）のほうがはっきり書いています。

Raspberry Pi Ltd’s own compliance with respect to its boards, modules, and operating system is not transferable to your product, and the CE marking Raspberry Pi Ltd affixes to a computer does not discharge your obligations for the finished product it is integrated into. （Raspberry Pi Ltd 自身のボード・モジュール・OS に関する適合は、あなたの製品には移転しない。Raspberry Pi Ltd がコンピュータに付ける CE マーキングは、それを組み込んだ完成品についてのあなたの義務を免除しない）

Integrating Raspberry Pi hardware, customising the software stack, and shipping the result under your own brand makes you the manufacturer. （Raspberry Pi のハードウェアを組み込み、ソフトウェアスタックをカスタマイズし、その結果を自分のブランドで出荷すれば、あなたが製造者になる）

さらに白書は、第69条(3)により9月11日より前に出荷した製品も報告義務の対象になることを指摘し、「多くの OEM にとって最初の CRA の成果物は2027年の適合宣言ではなく、配備済みの全機を対象にした脆弱性監視とインシデント対応のプロセスだ」と書いています。

「部品の脆弱性」は誰が報告するのか — 欧州委員会の見解

ここが実務でいちばん迷うところで、答えは欧州委員会の FAQ 5.4 と指針の第218段落にあります。

状況 部品の製造者（例：Raspberry Pi Ltd、モジュールメーカー） 完成品の製造者（あなた）
部品に悪用中の脆弱性があり、あなたの製品でも悪用されている 部品が単体で市場に出ていれば報告義務あり 報告義務あり（第14条(1)。自分の製品に含まれる悪用中の脆弱性だから）
部品に脆弱性はあるが、あなたの製品では到達不能、または悪用されていない 同上 義務報告の対象外。任意報告（第15条）はできる。部品の製造者・保守者へ報告する義務はある（第13条(6)）

つまり「部品メーカーが報告するから自分は不要」でも「部品の CVE が出たら全員が24時間以内に報告」でもなく、自分の製品で悪用されているかどうかで決まります。指針の第217段落は、9月11日より前に悪用を認知していたものは遡って報告しなくてよい、ただし脆弱性の存在だけ知っていて悪用を9月11日以降に知ったなら対象、とも整理しています。

自作基板・ESP32 製品を EU で売るなら

Raspberry Pi の整理を当サイトの読者に置き換えると、こうなります。

役割 Raspberry Pi の例 自作基板の例
部品の製造者 Raspberry Pi Ltd（ボード・モジュール・OS） Espressif（ESP32 モジュール）、センサーメーカー
完成品の製造者 Raspberry Pi を組み込んで自社ブランドで EU に出荷する事業者 自分の基板に ESP32 を載せ、ファームウェアを書き、自分の名前で EU 市場に出す人
報告先の CSIRT 主たる事業所の国 EU に拠点がなければ、第14条(7)の順序で決める（下記）

EU に主たる事業所がない製造者の報告先は、第14条(7)第3段落が順序を定めています——①認定代理人がいる国 ②輸入者が最も多く市場に出している国 ③流通業者が最も多く提供している国 ④利用者が最も多い国。FAQ 18 は「間違った CSIRT を選ぶと通知が無効化され、正しい CSIRT に再提出になる」と注意しています。

一方で、7月の記事で確認したとおり、商業活動の過程で供給されていない製品は CRA の対象ではないと欧州委員会は明記しています。趣味で作って自分で使う基板、EU に出していない製品は、この仕組みの想定する対象ではありません。「EU で売る可能性がある」人にとって今日の変化は、義務が増えたことではなく、報告先が1つになり、何を24時間以内に書けばよいかが用語集の粒度で公開されたことです。

📌 筆者の見方（法規制は専門外ですが）

筆者は ESP32 の基板を起こして BOOTH で頒布している立場で、EU 市場には出していません。それでもこの仕組みを一次資料で追ってみて、いちばん引っかかったのは、24時間の起点は「認知」で、一人で作っている人の認知はたいてい自分の検知ではなく利用者からの連絡で始まる、という点でした。ENISA の資料を読むかぎり、SRP 側の作業は「EU Login があれば登録は数分」で、フォームも24時間の時点では「何が・どの製品で・いつ分かったか」まで（事実）。つまり時間を食うのはプラットフォームではなく、知らない人が自分に脆弱性を知らせられる入口があるか、そしてそれを自分が読んでいるかのほうだ、と筆者は受け止めました。7月の記事で「連絡先を1つ作る」と書いたことが、そのまま第14条の実装になります。

もう一つ、ENISA が FAQ に「72時間カウンターは今のリリースでは早期警告の提出から48時間後を期限表示する」と既知の制限を自分で書いていることは、事実として記録しておきたいところです。筆者もファームウェアの README に既知の問題を先に書く派なので、運用初日に制限を隠さず、責任の所在（期限を守るのは製造者）を明示しているやり方には好感を持ちました。これは筆者の感想で、制限そのものが軽いという意味ではありません。自分で認知時刻を控えるという対処は、SRP を使う・使わないに関係なく必要なことです。

「予防的に登録するな」という助言も、筆者には設計思想として面白く読めました。登録を促すサービスは多いのに、SRP はCSIRT の検証コストを守るために、来る人を減らす方向に振っています。用意しておくべきは登録ではなく、EU Login と MFA、SBOM、連絡先、そして「どの CSIRT に出すか」を一度考えておくこと——道具の側が要求しているのは、まさに製品側の日常の備えでした。

まとめ

観点 内容（2026年9月12日時点）
何が起きたか 2026年9月11日、CRA 第14条の報告義務が製造者に適用開始。ENISA が SRP を「初期運用能力」で稼働（ポータル：portal.cra-srp.enisa.europa.eu）
仕組み 製造者の担当者（AR）が EU Login（MFA 必須）で登録し、調整役 CSIRT を1つ選んで報告。ENISA には同時に見え、他国 CSIRT と市場監視当局には CSIRT が配布。PEC で配布を遅らせる例外あり
登録 Primary AR 1人＋Secondary 最大20人。CSIRT の検証は報告と並行、検証前でも20件まで提出可。報告が必要になったときに登録すればよい（ENISA の助言）
24時間で要る項目 種別・タイトル・概要・製品名とバージョン・出回っている加盟国・認知日時（SI は「悪意の疑い」も）。原因・対策の詳細は72時間・最終報告へ
まだ無いもの 任意報告（第15条）、API、英語以外の画面。72時間カウンターは早期警告提出＋48時間で表示（修正予定）。OSS スチュワードは2027年12月11日から
支援資料 FAQ 31問・マニュアル v1.1（55ページ）・用語集 v1.3・ファクトシート（10言語）・動画・CSIRT 一覧（27か国）・ヘルプデスク。法解釈は欧州委員会の指針 §9.1 と FAQ §5
部品と製品 部品の脆弱性が自分の製品でも悪用されているなら両方が報告（欧州委員会 FAQ 5.4）。到達不能・未悪用なら義務報告の対象外だが部品メーカーへの報告義務（第13条(6)）。Raspberry Pi の CE 適合は組み込み先に移転しない（白書）
対象外 商業活動の過程で供給されていない製品は CRA の対象ではない（欧州委員会・7月の記事）

「義務が始まった」と読むより、報告先が1か所になり、24時間で何を書けばよいかまで公開されたと読むほうが、この日の変化の実態に近いと思います。次の節目は、任意報告と API の実装、そして2027年12月11日の本体適用です。

よくある質問（FAQ）

以下は一次資料の整理であり、法的助言ではありません。個別の判断は ENISA のヘルプデスクや専門家に確認してください。

Q. 日本の個人開発者は、今すぐ SRP に登録しておくべきですか？

ENISA は「報告が必要になったときに登録し、予防的に登録しないよう」助言しています（FAQ 9）。そもそも対象かどうかは「EU 市場で商業活動の過程で供給しているか」で決まり、趣味で作って自分で使うもの・EU に出していないものは想定する対象ではありません（7月の記事）。EU で売る可能性があるなら、登録ではなく EU Login のアカウントと MFA、脆弱性の連絡先、SBOM、報告先の CSIRT の見当を先に用意しておくのが、ENISA の資料に沿った準備です。

Q. EU Login とは何ですか。日本からでも作れますか？

欧州委員会の共通ログインで、ENISA の FAQ 9 は「事前に作成できる（ecas.ec.europa.eu）」「個人のアカウントで、MFA が必須」「法人としての追加認証は現時点で使っていない」と説明しています。日本在住者が作れるかどうかは ENISA の資料に記載がなく、筆者も試していません（未確認）。

Q. 24時間の起点はいつですか？

「認知した（becoming aware）」時点です（第14条(2)(a)）。欧州委員会の指針（第217段落）は、9月11日より前に悪用を認知していた脆弱性は遡って報告しなくてよい、ただし脆弱性の存在だけ知っていて悪用を9月11日以降に知った場合は対象、と整理しています。SRP のカウンターは現時点で早期警告の提出時刻を基準にするので、認知時刻は自分でも記録しておくのが安全です。

Q. オープンソースのメンテナは今、何をすべきですか？

CRA の「オープンソース・スチュワード」は法人で（第3条）、その報告義務は 2027年12月11日からです（第24条(3)・第71条(2)・FAQ 29）。個人メンテナはスチュワードの定義に当たりません。悪用を知って知らせたい場合、SRP の任意報告はまだ無いので、国の CSIRT に直接連絡することになります（FAQ 30）。欧州委員会の指針（第216段落）は、スチュワードが悪用を知るのは多くの場合「部品を組み込んだ製造者や研究者からの報告」だと書いており、下流からの連絡経路を持っておくことが実務になります。

Q. Raspberry Pi や ESP32 モジュールに脆弱性が見つかったら、組み込んだ側も報告するのですか？

自分の製品でも悪用されているなら、両方が報告します（欧州委員会 FAQ 5.4）。自分の製品では到達不能・未悪用なら義務報告の対象外ですが、任意報告はでき、部品の製造者・保守者へ報告する義務（第13条(6)）は残ります。Raspberry Pi は脆弱性の連絡先として security@raspberrypi.com を示しています。

Q. 日本の会社で EU に拠点がありません。どの CSIRT に報告しますか？

第14条(7)の順序で決めます——①認定代理人がいる国 ②輸入者が最も多く市場に出している国 ③流通業者が最も多く提供している国 ④利用者が最も多い国。ドロップダウンには27か国が並び、間違えると無効化されて再提出になります（FAQ 18）。④で決めた場合は、以後の報告も同じ CSIRT に出してよいと第14条(7)に書かれています。

Q. SRP が落ちていたら、24時間の期限はどうなりますか？

FAQ 25 によれば、復旧を待って提出します。急ぐなら調整役 CSIRT に直接連絡してよいものの、復旧後に SRP からも提出が必要です。期限の扱いそのものについて ENISA の FAQ は述べていません（未確認）。

関連記事

参考