要約

  • 2026年9月11日から、Cyber Resilience Act第14条の報告義務が対象製品の製造者に適用される。実際に悪用されている脆弱性または製品の安全に重大な影響を与える事故を認識した後、24時間以内に早期警告を出し、72時間以内に詳しい通知を提出する。
  • Single Reporting Platformは提出を一回にするが、権限まで一本化しない。製造者が国別の調整CSIRTを選び、そのCSIRTが通常の配信を判断し、ENISAが基盤を運用する。初期版は英語のみでAPIがなく、自発的な報告やオープンソース・ソフトウェア・スチュワードの義務にはまだ対応していない。

新しい制度が最初に要求するのは、安全であるという証明ではない。危険を知った時刻を確定し、報告を始めることである。

European Commissionの実施日程によれば、Cyber Resilience Actの主要な製品要件が一般に適用されるのは2027年12月11日だ。設計段階のセキュリティ、脆弱性対応、適合性評価などに先立ち、第14条の報告義務だけが2026年9月11日に始まった。

製造者が、製品に含まれる脆弱性が悪意ある主体に実際に使われていると認識した場合、または可用性、真正性、完全性、機密性に重大な影響を与える事故を認識した場合、早期警告を不当に遅らせず、遅くとも24時間以内に出す。72時間以内には一般情報と初期評価を含む通知が必要になる。

European Commissionの報告解説は、その先も二つに分ける。悪用中の脆弱性については、修正または緩和策が利用可能になってから14日以内に最終報告を出す。重大事故は72時間通知から1か月以内に最終報告を出す。

基準になるのは製造者の「認識」である。ポータルにログインした時刻でも、経営会議が開かれた時刻でも、フォレンジック調査が最終結論に達した時刻でもない。したがって、法的な時間管理は行政窓口に入る前、企業内部の技術判断から始まる。

提出は一回でも、受け手の役割は一つではない

ENISAのSingle Reporting Platformは、同じ事象を加盟国ごとに入力する負担をなくす。EU域内に複数の支店や子会社がある企業、域外に親会社がある企業でも、ある脆弱性または事故について必要な通知は一件である。どの法人と担当者が提出するかは、企業が内部で調整する。

提出時には、調整役として指定されたCSIRTを選ばなければならない。原則として製造者の主要な設立地が基準になり、正しく選ぶ責任は製造者に残る。ENISAが公開する指定調整CSIRT一覧は、単なる問い合わせ先ではなく、報告の制度的な宛先表だ。

通常の経路では、選ばれたCSIRTとENISAが通知を受ける。最初のCSIRTは、製品が提供されている他の加盟国の関係CSIRTへ遅滞なく配信する。執行に必要な範囲で、市場監視当局にも情報が渡る。

ここには四つの支配面がある。製造者は製品と社内の認識事実を管理する。国のCSIRTは最初の評価と配信を管理する。ENISAは共通基盤を運用し、欧州全体の流れを扱う。市場監視当局は調査や是正の必要性を判断する。

「一度報告すればよい」という説明は正しい。しかし、それを「ENISAだけが判断する」と読み替えるのは誤りだ。受付完了の表示も、管轄選択が正しかったことや、すべての後続機関が同一内容を受け取ったことまでは証明しない。ENISAのFAQは、誤ったCSIRTを選ぶと通知が無効となり、再提出が必要になり得ると説明している。

例外は企業が提案し、公的機関が決める

悪用中の脆弱性の詳細を直ちに広く共有すると、攻撃機会を増やす場合がある。そのため、72時間通知にはParticularly Exceptional Circumstances（PEC）という限定的な遅延経路がある。

ENISAのPEC手順では、製造者側の代表者が該当可能性を示し、理由を記載できる。だが、配信を遅らせるかを決めるのは調整CSIRTである。受け入れられた場合、ENISAには当初、限定情報だけが渡り、完全な通知をいつ関係CSIRTとENISAへ共有するかは調整CSIRTが引き続き管理する。

企業に一方的な秘匿権を与える仕組みではない。あらゆる扱いにくい事故に使える汎用ボタンでもない。悪用中の脆弱性の72時間通知において、危険な拡散を避けるための例外である。

監査可能な記録には、企業が例外を求めた時刻と根拠、CSIRTの判断、限定情報の範囲、完全配信に切り替えた時刻が必要だ。この二段階を保存しなければ、慎重な協調開示と単なる未報告を後から区別できない。

初期版は制度全体の縮図ではない

9月10日に更新されたENISAのFAQは、開始時点の機能を具体的に限定している。受け付けるのは、製造者による悪用中の脆弱性と重大事故の義務的な通知である。第15条の自発的な報告機能は後の段階に回された。製造者以外が脆弱性を知らせたい場合、当面は関係する国のCSIRTへ直接連絡する。

オープンソース・ソフトウェア・スチュワードの報告義務も2027年12月11日からである。将来の利用者として案内に登場していても、現在の製造者義務と同じ開始日だと考えてはいけない。

初期版の画面は英語だけで、APIも提供されない。企業は自社内の検知、分類、承認を自動化できるが、法定の提出は画面操作になる。大量の製品を持つ企業にとって、人員配置と代理担当者の準備はシステム容量の一部になる。

担当者は、多要素認証を有効にした個人のEU Loginを使う。担当者と製造者の結び付きは調整CSIRTが確認するが、確認は報告と並行して進み、最初の緊急提出を妨げない。未確認の担当者は、確認が必須になるまで、その製造者について最大20件を提出できる。登録ガイドを読むと、事故前の準備項目が見える。法人、主たる設立地、正副担当者、EU Login、認証手段を平時に決める必要がある。

画面の時計は法律の時計ではない

開始時点で最も重要な実装上の注意を、ENISA自身が公開している。現在の72時間カウンターは、24時間早期警告を提出した時点から48時間後を期限として表示する。法律は認識時点から72時間を数える。そのため、早期警告を早く出したケースでは、実際の72時間が経過する前に画面上で期限超過に見える可能性がある。ENISAは、今後、登録された認識時刻を使うよう更新するとしている。

これは法律の短縮ではない。画面が規範の代わりになれないことを示す実例である。製造者は、認識の根拠と時刻、早期警告の提出、独自に計算した72時間、画面の期限表示、受領記録を別々に保存すべきだ。

逆に、画面の通知が遅いからといって法定時間が延びるわけでもない。インターフェースは作業を助けるが、Article 14を改めない。

一時的にプラットフォームが使えない場合も、二つの経路を混ぜないことが重要だ。ENISAは復旧後の提出を求め、緊急連絡が必要なら指定CSIRTへ直接連絡できるとする。直接連絡しても、後のプラットフォーム提出は残る。単発の接続失敗だけで、サービス全体の停止を推定することもできない。

脆弱性を公開せず、運用規則を可視化する

制度を検証するために、未修正の脆弱性や製造者名を公開する必要はない。必要なのは、その時点で窓口がどの機能と規則を実行していたかという記録である。

ENISAは、報告内容を含まないサービス状態・規則バージョン履歴を公開できる。稼働上の障害、受付可能な提出者と報告種別、対応言語、APIの有無、カウンター計算方式、変更の発効時刻を記録する。機密性を守りながら、企業と監査者が当時の実行条件を再現できる。

これは私の編集上の提案であり、現行CRAの義務でもENISAの公約でもない。The Policy Mirrorが示す権限の連鎖、Running Code Primaryが求める実装の確認、Why BTW Media Existsの事実と主張の分離を、この報告基盤に当てはめたものだ。

EUは共通の入口を作った。そこを通る認識、提出、判断、配信の責任まで一つにしたわけではない。初日から必要なのは、その違いを証拠として残すことである。

情報源