EUサイバーレジリエンス法:2026年9月の脆弱性報告義務、日本のメーカーが知らない「既存製品にも適用される」という事実

EU CRAの脆弱性・インシデント報告義務(第14条)は2026年9月11日から発効。第69条第3項により既存製品にも適用されます。24時間報告期限と稟議文化の構造的矛盾、EU認定代理人の確保、ENISAへの報告体制構築など、2026年9月11日までに準備すべき8つのステップを解説。

CRA Evidence Team
著者
2026年3月24日
3 分で読む
EU CRA第14条の脆弱性報告期限2026年9月11日を示すコンプライアンス文書と日本の印鑑
この記事の内容

2026年9月11日。あと約5カ月で、この日からEU市場に製品を供給する全メーカーに対し、脆弱性の悪用を認識してから24時間以内にENISAへ報告する義務が生じます。

見落とされがちな事実があります。この義務は「2027年12月の新製品」だけを対象としていません。今日EU市場で流通している既存製品にも、2026年9月11日から適用されます。

このブログでは、CRA第14条が何を求めているのか、なぜ日本企業にとって構造的に難しいのか、そして2026年9月11日までに準備すべき8つのステップを解説します。

要約

  • 2026年9月11日:ENISA脆弱性・インシデント報告義務が発効
  • 既存製品にも適用:CRA第69条第3項により、2027年以前に市場投入した製品も対象
  • 24時間:悪用を認識してからENISAへの早期警告までの法定期限
  • 72時間:詳細通知の期限(24時間以内の早期警告に続く)
  • 14日 / 30日:最終報告の期限(脆弱性 / インシデント)
  • 日本特有の課題:稟議・根回し文化と24時間期限の構造的矛盾
  • JC-STAR取得だけでは対応できない:第14条の報告義務はJC-STARの範囲外
  • 今すぐ準備を:体制構築には最低6〜12カ月かかります

CRA第14条とは何か

CRA(EU規則2024/2847)第14条は、デジタル要素を含む製品のメーカーに対し、以下の2つの事象について当局への通知を義務付けています。

対象となる2つの事象

1. 積極的に悪用されている脆弱性(Actively Exploited Vulnerability)

製品の脆弱性が悪意のある行為者によって実際に使用されていることが判明した場合。公開された脆弱性や研究者からの報告だけでは対象になりません。実際の悪用が要件です。

2. 深刻なインシデント(Severe Incident)

製品のセキュリティに影響を与えるインシデント、開発環境の侵害、または広範なユーザーへの影響が確認された場合。

3段階の報告タイムライン

ENISAインシデント報告タイムライン — 24時間、72時間、14日

早期警告(24時間以内):悪用を認識してから24時間以内にENISAと国家CSIRTへ通知。詳細な分析は不要ですが、製品の特定・深刻度の初期評価・悪用の確認状況を含む必要があります。

詳細通知(72時間以内):脆弱性の技術的詳細、影響バージョン、悪用手法(判明している場合)、対応状況を提出。

最終報告(脆弱性:修正後14日以内 / インシデント:通知後30日以内):根本原因分析、対応措置、影響評価を含む完全な報告書。

報告先:ENISAが運営する単一報告プラットフォーム(SRP)と、製品が流通する国の国家CSIRT。


日本企業が見落としている事実:既存製品にも適用される

CRAの一般的な認識として「2027年12月まで猶予がある」という理解が広まっています。これは部分的にしか正しくありません

CRA第69条第2項は確かに「2027年12月以前に市場投入した製品はCRA要件の適用除外」と規定しています。しかし、同条第3項はこの除外から第14条を明示的に除いています

つまり:

製品の状況 CE認証・技術ファイル等 第14条報告義務
2026年9月以前から市場投入済み 2027年12月まで猶予(大規模変更なければ) 2026年9月11日から適用
2026年9月〜2027年12月に市場投入 CRAフル対応が必要 適用
2027年12月以降に市場投入 CRAフル対応が必要 適用

警告: 「2027年まで猶予がある」という理解は部分的に正しいにすぎません。CE認証・SBOMの猶予は存在しますが、脆弱性報告義務の猶予は存在しません。今日EU市場で販売しているIoT機器、産業用機器、組み込みシステムは、5カ月後から報告義務の対象です。


日本企業にとってなぜ特に難しいのか:稟議文化と24時間の壁

これは日本特有の問題であり、欧州向けのCRAコンテンツでは一切触れられていない論点です。

標準的な日本企業のインシデント対応フロー

多くの日本企業でセキュリティインシデントが発生した場合の標準的な対応は次のような流れをたどります:

  1. 脆弱性・インシデントの検知
  2. 事実確認・社内調査(1〜3日)
  3. 担当部署での報告準備・稟議書作成(2〜5日)
  4. 部長・役員への稟議回覧と承認取得(3〜7日)
  5. 法務・広報への確認(+2〜3日)
  6. 経営判断・対外発表(14〜30日以降)

このプロセスは「根回し」と「稟議」という日本企業の意思決定文化を反映したものであり、合理的かつ実績のあるアプローチです。しかし、CRA第14条の24時間という期限とは根本的に相容れません。

JPCERT/CCモデルとCRA第14条:異なる哲学

日本のセキュリティコミュニティが慣れ親しんでいるJPCERT/CC主導の協調的脆弱性開示(CVD)モデルは、ベンダーが修正パッチを準備する時間を確保した上で開示するという「ベンダー優先」の思想に基づいています。標準的な調整期間は45日以上です。

CRA第14条は根本的に異なります。修正が完了していなくても、悪用を認識した時点から24時間以内に当局へ通知することを義務付けています。「解決策が出てから発表する」という文化的規範とは正面からぶつかります。

稟議フローとCRA第14条報告の比較

構造的に必要なこと

24時間のカウントダウンは次のことを前提としています:

  1. 事前承認された報告者:稟議の完了を待たずにENISAへ早期警告を提出できる権限を持つ担当者
  2. 24時間365日の対応体制:ゴールデンウィーク・年末年始・週末も含む
  3. EU向けインフラENISA SRPへのアカウント登録、EU拠点のない場合はEU認定代理人の確保
  4. 「解決策なしでの開示」の受容:早期警告は速報であり、詳細や修正は後続の通知で提供できる

「悪用が確認された」とはどういう意味か

日本企業に多いパターンとして、「確実な証拠が出るまで待つ」という傾向があります。しかしCRAの基準は**「合理的な根拠(reasonable belief)」**であり、法的証明ではありません。

シナリオ 報告必要? 理由
セキュリティ研究者から非公開で脆弱性報告 不要 悪用なし — CVDプロセスで対応
GitHubにPoC公開 不要 PoC公開 ≠ 悪用
顧客から不審な動作の報告(脆弱性と一致) 悪用の証拠
脅威インテリジェンスが自社製品を標的と示唆 合理的な根拠あり
SBOMコンポーネントに既知の悪用済み脆弱性 評価が必要 自社製品への影響を確認

注記: 「確実性」を待つ必要はありません。24時間の期限は合理的な根拠が生じた時点から始まります。詳細通知(72時間)で状況を更新できます。不確かな場合は早めに報告する方が、期限超過よりはるかに良い結果をもたらします。


報告のタイムライン

flowchart LR
    A["🔴 悪用を認識\n(Day 0)"] -->|"24時間以内"| B["📤 早期警告\nENISA + 国家CSIRT"]
    B -->|"72時間以内"| C["📋 詳細通知\n深刻度・範囲・\n初期対応状況"]
    C -->|"修正後14日以内\n(インシデントは30日)"| D["📁 最終報告書\nENISAへ提出"]

社内トリアージフロー

flowchart TD
    A["🔔 脆弱性報告の受信\n(内部発見・外部報告)"] --> B{"悪用の証拠はあるか?"}
    B -->|"あり"| C["⏰ 24時間カウントダウン開始\n事前承認済み報告者へ即エスカレーション"]
    B -->|"不明"| D["技術トリアージ\n(4時間以内)"]
    B -->|"なし"| E["通常のCVDプロセスへ\nJPCERT/CC連携など"]
    D --> F{"悪用の合理的な\n根拠はあるか?"}
    F -->|"あり"| C
    F -->|"なし"| E
    C --> G["ENISAへ早期警告提出\n(24時間以内)"]
    G --> H["詳細通知準備\n(72時間以内)"]
    H --> I["修正・最終報告\n(14日/30日以内)"]

自社は対象か:日本企業の4つのケース

ケースA:EU向け輸出メーカー(EU拠点なし)

CRAにおける「メーカー」として直接義務を負います。EU拠点がない場合はEU認定代理人(Authorized Representative)の契約が必要です。この代理人はENISA報告プロセスの連絡窓口となるため、24時間対応できる体制の確認が必要です。

ケースB:欧州現地法人経由で販売

現地法人が「輸入者」として機能している場合、一次的な義務は現地法人に生じますが、日本の親会社は技術文書・脆弱性情報の提供義務を負います。24時間の報告チェーンを日本本社と欧州子会社間で事前に確立しておく必要があります。

ケースC:OEM供給(EU顧客がラベルを貼って販売)

EU顧客が自社ブランドで市場投入する場合、CRA上の「メーカー」はEU顧客になります。ただし、OEM元の日本企業はSBOMデータおよび脆弱性情報を迅速に提供する契約上の義務が生じます。EU顧客が24時間のカウントダウン中に情報を求めてくることを想定した体制が必要です。

ケースD:産業機器・B2B製品(直接エンドユーザーに販売しない)

B2B製品もCRAの対象外ではありません。「大手システムインテグレーターにしか販売していない」という事実は、メーカーとしての地位を変えません。IEC 62443認証は第14条の報告義務を充足しません。


2026年9月11日までに準備する8つのステップ

□ ステップ1:CRAスコープ確認
  EU市場に出荷している全製品を一覧化。「デジタル要素を含む製品」に該当するか確認。
  ファームウェアを含む組み込み機器、ネットワーク接続製品、スマート家電はほぼ該当。

□ ステップ2:EU窓口の確保
  EU拠点がない場合、EU認定代理人(Authorized Representative)を契約。
  代理人が24時間対応できることを確認。ENISA SRPへの登録を代理人と共に進める。

□ ステップ3:事前承認済み報告権限者の設定
  24時間以内にENISAへ通知する権限を持つ人物を事前に指定。
  「稟議なしで報告できる人」を決める。これは経営判断が必要な組織変更です。

□ ステップ4:脆弱性受付チャネルの整備
  security.txtの設置、セキュリティ報告フォーム、専用メールアドレスの確認。
  JPCERT/CCとの連携プロセスも確認し、CRAの24時間義務との調整ルールを文書化。

□ ステップ5:悪用判断フローの文書化
  「悪用されたか否か」を誰がどう判断するか、社内プロセスを文書化。
  24時間後が土日祝日・ゴールデンウィーク・年末年始でも動作するプロセスにする。

□ ステップ6:ENISAへの報告テンプレート準備
  早期警告・詳細通知・最終報告書のテンプレートを事前に用意。
  インシデント中にゼロから作成する時間はない。英語対応も確認する。

□ ステップ7:24時間対応体制の構築
  オンコール体制、代理対応者の確認。ゴールデンウィーク・年末年始も含む。
  欧州の国家CSIRTへの連絡先も確認・登録しておく。

□ ステップ8:卓上演習(TTX)の実施
  2026年6月〜8月の間に最低1回実施。
  推奨シナリオ:「金曜17時に顧客から自社製品の不審動作の報告を受けた。
  翌月曜はゴールデンウィーク明けの最初の営業日。どう対応するか。」

JC-STARを取得済みの場合

JC-STAR(経済産業省・IPA主導のIoTセキュリティ適合性評価制度、2025年3月開始)に取り組んでいる企業へ:

重要: JC-STARはIoT製品のセキュリティ要件(ETSI EN 303 645等に準じた要件)を対象とした制度ですが、CRA第14条の報告義務はJC-STARの対象範囲外です。

JC-STARが対応するもの JC-STARが対応しないもの
製品設計・開発のセキュリティ要件
ENISAへの24時間報告プロセス
EU認定代理人の任命
SBOMの技術ファイル(EU形式)
EU適合性宣言(EU DoC

JC-STARの取得はCRA準備の重要な土台となりますが、第14条への対応は別途必要です。

[関連記事:JC-STARとEU CRAの差分ガイド(近日公開予定)]


SME(中小企業)向けの注意事項

EU SMEの定義(従業員250名未満、売上高5,000万ユーロ以下)に該当する場合、24時間・72時間の期限違反に対する罰則は猶予されます。ただし、これは報告義務の免除ではありません

日本の中小メーカーに特有の課題として:

  • 報告義務の体制を構築する専任のセキュリティチームがない場合が多い
  • EU SME向け「SECURE補助金」(最大3万ユーロ)はEU域内企業が対象であり、日本のメーカーには適用されない
  • 罰則猶予は「報告が遅れても罰金を免除される」というものであり、報告プロセス自体を構築する必要はなくならない

注記: SMEであっても最終報告書の提出義務は残ります。また、EU市場監視機関が調査に入った際に対応できる体制が必要です。罰則の免除は準備コストを下げるものではありません。


CRA Evidenceに相談する

CRA Evidenceは、EU CRAへの対応を検討している日本のメーカー向けに、専門家によるコンサルティングサービスを提供しています。

  • 第14条対応に必要な社内体制の整備支援
  • EU認定代理人の選定・連携アドバイス
  • ENISA報告プロセスの文書化と卓上演習の実施支援
  • JC-STARとEU CRAのギャップ分析

CRA Evidenceに問い合わせる →


関連記事

  • JC-STARとEU CRAの差分ガイド(近日公開予定)— 本記事の続編
  • CRA実装タイムライン2025〜2027(近日公開予定)
  • CVDポリシーテンプレート(近日公開予定)

用語集

本記事で使用した主要用語の解説です。各用語の詳細は用語集ページをご参照ください。

第14条(Article 14 CRA(EU規則2024/2847)第14条。製造業者に対し、積極的に悪用されている脆弱性をENISAに24時間以内に報告することを義務付ける。詳細報告(72時間以内)および最終報告(脆弱性:14日以内、インシデント:30日以内)も必要。→ 用語集で詳しく

ENISA EU サイバーセキュリティ機関(European Union Agency for Cybersecurity)。CRAの下、製造業者は積極的に悪用されている脆弱性を2026年9月から24時間以内にENISAへ報告しなければならない。ENISAが運営する単一報告プラットフォーム(SRP)が報告窓口となる。→ 用語集で詳しく

CSIRT コンピュータセキュリティインシデント対応チーム(Computer Security Incident Response Team)。CRA第14条に基づき、製造業者が脆弱性・インシデントを通知すべき各国指定サイバーセキュリティ機関。ENISAとEUレベルの脆弱性対応を調整する。→ 用語集で詳しく

CVD(協調的脆弱性開示) Coordinated Vulnerability Disclosure。修正パッチを準備する時間を確保した上でベンダーに脆弱性を責任を持って開示するプロセス。CRA第13条第8項が要求。日本のJPCERT/CCモデルはこの思想に基づくが、CRA第14条の24時間義務とは別の概念。→ 用語集で詳しく

CVE 共通脆弱性識別子(Common Vulnerabilities and Exposures)。MITRE社が管理する公知のサイバーセキュリティ脆弱性の標準化された識別子。SBOMコンポーネントのCVEが自社製品に影響するかの評価がCRA第14条の報告判断に関係する。→ 用語集で詳しく

SBOM ソフトウェア部品表(Software Bill of Materials)。製品内のソフトウェアコンポーネントと依存関係の正式な機械可読インベントリ。CRA第13条第4項が要求。脆弱性管理の基盤となり、第14条の報告判断にも必要。→ 用語集で詳しく

技術ファイル(Technical File CRA適合性を証明する完全な文書パッケージ(リスク評価、SBOM、テスト結果を含む)。10年以上の保管が必要。EU市場監視機関の調査時に提示を求められる。→ 用語集で詳しく

製造業者(Manufacturer) デジタル要素を含む製品を開発または製造し、自社名またはブランドでEU市場に投入する事業者。CRAの主要義務(SBOMの維持管理、脆弱性対応、第14条の報告義務)を負う。EU拠点のない日本メーカーも該当する。→ 用語集で詳しく

EU適合性宣言(EU Declaration of Conformity) 製品がCRAを含む適用EU法に準拠していることを表明する正式文書。CEマーキングに必要。附属書VIIに規定された最低記載事項を含む必要がある。→ 用語集で詳しく


本記事は情報提供を目的としており、法的アドバイスを構成するものではありません。EU製品規制に関する具体的なコンプライアンス対応については、EU規制に精通した法律の専門家にご相談ください。

この記事をシェア

CRAはあなたの製品に適用されますか?

6つの質問に答えるだけで、あなたの製品がEUサイバーレジリエンス法の適用範囲に該当するかどうかがわかります。2分以内で結果を確認できます。