EUサイバーレジリエンス法（CRA）の報告義務が9月11日開始　悪用中の脆弱性は24時間以内にENISAへ通知

EUのCyber Resilience Act（CRA、サイバーレジリエンス法）で定める脆弱性・インシデントの報告義務が、2026年9月11日から適用されます。

対象となる製造者は、EU市場で提供する「デジタル要素を備える製品」について、実際の攻撃で悪用されている脆弱性を把握した場合、原則24時間以内に早期警告を提出し、72時間以内により詳しい通知を行う必要があります。製品のセキュリティへ重大な影響を及ぼすインシデントも同じ24時間・72時間の報告対象です。

報告には、EUサイバーセキュリティ機関ENISAが運用する「CRA Single Reporting Platform（SRP）」を利用します。ENISAの2026年9月8日更新FAQによると、SRPは9月11日に稼働予定で、開始時点ではArticle 14に基づく義務的な報告のみを受け付けます。

重要なのは、2027年12月11日に始まるCRAの全面適用を待たず、報告義務だけが先行する点です。しかも、報告義務は2027年12月11日より前にEU市場へ投入された製品にも適用されます。

BleepingComputerは9月8日、ActiveStateによるスポンサー記事として「何を出荷したのか」「いつ問題を把握したのか」を把握できる体制が実務上の焦点になると指摘しました。一次情報を確認すると、SBOM（Software Bill of Materials）を含むCRAの主要な製品・脆弱性管理要件は2027年12月11日から全面適用される一方、9月11日から始まる報告に対応するには、対象製品・バージョン・依存コンポーネント・脆弱性認知時刻を社内で追跡できる状態が必要になります。

CRAの報告義務開始のサマリー

確認できている内容：

• CRAのArticle 14に基づく報告義務は2026年9月11日から適用されます。
• 報告対象は「actively exploited vulnerability（実際に悪用されている脆弱性）」と「製品のセキュリティへ重大な影響を及ぼすインシデント」です。
• すべての既知脆弱性やCVEを24時間以内に報告する制度ではありません。
• 実悪用脆弱性については、製造者が認知してから24時間以内に早期警告、72時間以内に脆弱性通知を提出します。
• 修正・緩和策が利用可能になった後、14日以内に最終報告を提出します。
• 重大インシデントについても24時間以内の早期警告、72時間以内の通知が必要です。
• 重大インシデントの最終報告は、72時間通知から1カ月以内です。
• 報告にはENISAが運用するCRA Single Reporting Platform（SRP）を利用します。
• SRPへの通知は、原則として製造者のEU域内の主たる拠点に対応するCSIRTを選択して提出し、ENISAにも同時に共有されます。
• EU域内に主たる拠点がない企業にも、認定代理人、輸入者、販売者、ユーザー数の順で担当加盟国を決めるルールがあります。
• 報告義務は2027年12月11日より前に市場投入された対象製品にも適用されます。
• 2026年9月11日より前から実悪用を把握していた脆弱性を遡って報告する義務はありません。
• 9月11日以降に実悪用を認知した場合は、その脆弱性自体が以前から存在していても報告対象になります。
• CRA全体の主要要件は2027年12月11日に全面適用されます。
• SBOM作成などAnnex Iの主要な脆弱性管理要件も、9月11日の報告義務開始とは適用時期が異なります。

項目	内容
規則	Regulation (EU) 2024/2847（Cyber Resilience Act）
報告義務開始	2026年9月11日
全面適用	2027年12月11日
主な報告対象	実際に悪用されている脆弱性、重大なセキュリティインシデント
早期警告	認知から24時間以内
詳細通知	認知から72時間以内
脆弱性の最終報告	修正・緩和策が利用可能になってから14日以内
インシデントの最終報告	72時間通知から1カ月以内
報告先	担当CSIRT、ENISA
報告方法	CRA Single Reporting Platform（SRP）
既存製品	2027年12月11日以前に市場投入された製品もArticle 14の報告対象
SBOM等の主要製品要件	原則2027年12月11日から全面適用

9月11日から始まるのは「実悪用脆弱性」と重大インシデントの報告

CRAのArticle 14は、製造者が「actively exploited vulnerability」を認知した場合の報告を義務付けています。

CRAではactively exploited vulnerabilityを、「悪意ある主体がシステム所有者の許可なく実際に悪用したことを示す信頼できる証拠がある脆弱性」と定義しています。

つまり、次のような情報をすべて24時間以内に報告する制度ではありません。

• 新しいCVEが公開された
• 自社製品に脆弱なOSSが含まれている可能性がある
• PoCが公開された
• CVSSがCriticalだった
• セキュリティ研究者から脆弱性報告を受けた

これらだけで「実悪用脆弱性」に該当するとは限りません。

一方、自社製品に含まれる脆弱性について、攻撃者が許可なく実環境で悪用したことを示す信頼できる証拠を把握した場合、24時間の報告時計が動き始めます。

ENISAのSRPでは、製造者が実悪用を認知した日時を入力する項目も必須として用意されています。

実悪用脆弱性は24時間、72時間、修正後14日の3段階で報告

実際に悪用されている脆弱性を認知した場合、CRAは段階的な報告を求めます。

タイミング	主な内容
24時間以内	早期警告。該当する場合、製品を提供している加盟国などを通知
72時間以内	対象製品、脆弱性・悪用の一般的な内容、実施済みの対策、利用者が取れる対策など
修正・緩和策提供後14日以内	脆弱性の深刻度・影響、判明している攻撃主体、セキュリティアップデートなどの最終報告

72時間時点ですべての調査が完了している必要はありません。

Article 14は「利用可能な範囲」の情報を提出する構造になっており、ENISAのSRPでも、24時間時点では任意の項目が72時間通知や最終報告で必須になる設計が採用されています。

一方、最初の24時間を「調査が終わるまで待つ」ことはできません。早期警告と、その後の詳細通知を分けることが前提になっています。

重大インシデントも24時間・72時間以内に報告

CRAが義務付けるもう1つの対象が、製品のセキュリティへ重大な影響を及ぼすインシデントです。

Article 14(5)では、次のいずれかに該当する場合を「severe」としています。

• 製品が、機密性・完全性・真正性・可用性の観点から重要または機微なデータや機能を保護する能力へ悪影響を与える、または与える可能性がある
• 製品や利用者のネットワーク・情報システムへマルウェア等の悪意あるコードを導入・実行する、またはその可能性がある

重大インシデントの場合も、認知から24時間以内に早期警告、72時間以内に通知します。

最終報告は72時間通知から1カ月以内で、インシデントの詳細、深刻度・影響、原因となった可能性のある脅威や根本原因、実施済み・継続中の緩和策などを提出します。

影響を受けた利用者への通知も必要

Article 14には、当局への報告だけでなく利用者への情報提供も定められています。

製造者が実悪用脆弱性または重大インシデントを認知した場合、影響を受けた利用者、必要に応じてすべての利用者へ、その脆弱性やインシデント、利用者が実施できる緩和・修正措置を通知する必要があります。

製造者が利用者へ適時に通知しなかった場合、必要かつ相当と判断されれば、担当CSIRTが利用者へ情報提供することもできます。

そのため、CRA対応では「ENISAへ報告できるか」だけでなく、「対象バージョンを利用している顧客を特定し、連絡できるか」も運用上の確認事項になります。

Single Reporting Platformは9月11日に稼働予定

報告にはENISAが構築したCRA Single Reporting Platform（SRP）を使用します。

ENISAの9月8日更新FAQによると、SRPは2026年9月11日に稼働予定です。

製造者はSRP上で担当するCSIRT Designated as Coordinatorを選択して通知します。通知内容は原則としてENISAにも同時に共有され、担当CSIRTから製品が提供されている他の加盟国のCSIRTへ展開されます。

1つの実悪用脆弱性や重大インシデントについて、EU各国へ個別に同じ報告を提出する必要はありません。

ENISAによると、開始時点のSRPはArticle 14に基づく義務報告のみをサポートします。

Article 15の任意報告機能は後日追加される予定です。

また、開始時点ではAPIが提供されません。社内側で報告判断やデータ集約を自動化することはできますが、SRPへの提出自体はWebインターフェースから行う必要があります。

報告担当者はEU LoginとMFAが必要

ENISAはSRPの実務手順も公開しています。

製造者のAssigned Representative（AR）は、EU Loginアカウントを作成し、MFAを有効にしてSRPへ登録します。

1社につきPrimary ARは1人、Secondary ARは最大20人まで登録できます。

Primary ARとSecondary ARはいずれも通知を提出できますが、Primary ARは製造者との関連付け管理など追加の管理権限を持ちます。

24時間以内の報告が必要になることを考えると、特定担当者1人だけがSRPを操作できる状態は避けた方が運用しやすくなります。

企業では、休日・夜間・担当者不在時も含めて、誰が実悪用の判断を行い、誰がSRPへ報告するのか決めておく必要があります。

日本企業などEU域内に本拠がない製造者も担当CSIRTを決める必要がある

EU域内に主たる拠点を持つ製造者は、原則としてその加盟国の担当CSIRTへ報告します。

ENISAは「主たる拠点」を、製品のサイバーセキュリティに関する意思決定が主に行われる場所と説明しています。

EU域内に主たる拠点がない場合は、次の順序で担当加盟国を決定します。

1. 最も多くの対象製品について製造者を代理する認定代理人が所在する加盟国
2. 該当しない場合、最も多く製品を市場投入する輸入者が所在する加盟国
3. 該当しない場合、最も多く製品を提供する販売者が所在する加盟国
4. いずれも該当しない場合、対象製品の利用者が最も多い加盟国

EUへソフトウェア、IoT機器、ネットワーク機器、組込み製品などを提供している日本企業も、自社の担当CSIRTを事前に特定しておく必要があります。

誤ったCSIRTを選択した場合、ENISA FAQでは通知が無効とされ、正しいCSIRTへ再提出する可能性があると説明されています。

2027年12月以前に出荷した既存製品も報告対象

今回の報告義務で見落としやすいのが、既存製品の扱いです。

CRAの主要な製品セキュリティ要件は2027年12月11日に全面適用されます。

通常、2027年12月11日より前にEU市場へ投入された製品について、CRAの主要要件は、その後に「substantial modification（実質的な変更）」が行われた場合などを除き、一律に遡及適用されるわけではありません。

しかしArticle 14の報告義務は別です。

欧州委員会とENISAは、2026年9月11日からの報告義務について、CRAの対象となる「デジタル要素を備える製品」であれば、2027年12月11日より前に市場へ投入された製品も含まれると明記しています。

したがって企業側では、新製品だけをCRA対応台帳へ登録するのでは不十分です。

現在EUで利用されている過去の製品・バージョンについても、実悪用情報を把握した際に影響有無を判断できる状態が必要になります。

9月11日以前に把握済みの実悪用は遡及報告不要

ENISA FAQによると、製造者が2026年9月11日より前から実悪用を把握していた脆弱性について、Article 14に基づき遡って報告する必要はありません。

一方、脆弱性そのものが以前から存在していた場合でも、9月11日以降に初めて実悪用を把握した場合は報告義務が発生します。

基準になるのは「脆弱性が作り込まれた日」「CVEが公開された日」「PoCが公開された日」ではなく、製造者が実悪用を認知した時点です。

このため、PSIRTやCSIRTでは実悪用を示す情報を受け取った日時を記録しておく必要があります。

SBOM義務は9月11日開始ではない

BleepingComputerのスポンサー記事は、「何を出荷したのか」を把握する手段としてSBOMを取り上げています。

CRAには実際にSBOMに関する要件があります。

Annex I Part IIは、製造者に対し、製品に含まれる脆弱性とコンポーネントを識別・文書化し、一般的に利用される機械可読形式で、少なくともトップレベルの依存関係を含むSBOMを作成するよう定めています。

ただし、このSBOM要件と2026年9月11日に始まるArticle 14の報告義務は、適用開始日が同じではありません。

CRAの主要な製品・脆弱性管理要件は2027年12月11日に全面適用されます。

そのため、「2026年9月11日からすべての対象企業に最新SBOMの法的提出義務が始まる」と理解するのは正確ではありません。

また、CRAは原則としてSBOMを一般利用者へ常時公開することも求めていません。Annex IIでは、製造者が利用者へSBOMを提供することを選んだ場合、そのアクセス先を案内する仕組みになっています。

一方、実務上はSBOMや同等の製品構成管理がなければ、第三者コンポーネントに実悪用脆弱性が見つかったときに「どの製品・どのバージョンへ含まれているか」を72時間以内に把握するのが難しくなります。

SBOMは9月11日からの報告義務そのものではなく、短時間で影響製品を特定するための基盤として位置付ける方が正確です。

「何を出荷したか」だけでなく「いつ知ったか」の記録が必要

BleepingComputerの記事が示した「What shipped, and when did you know?」という問いは、CRAの報告実務を考えるうえでは的を射ています。

ただし、法令上はさらに細かく分ける必要があります。

企業側で追跡したいのは、少なくとも次の情報です。

• EU市場へ提供した製品名
• 製品バージョン
• 各バージョンの提供期間
• 利用している自社・第三者コンポーネント
• 各コンポーネントのバージョン
• 脆弱性を最初に把握した日時
• 実悪用を示す情報を把握した日時
• 実悪用と判断した根拠
• 影響する製品・バージョン
• 提供しているEU加盟国
• 修正・緩和策を利用可能にした日時
• 顧客への通知日時
• ENISA／CSIRTへの24時間・72時間・最終報告日時

単にCVE一覧を保存するだけでは、「いつ実悪用を知ったか」というArticle 14の起算点を説明できません。

PSIRT、SOC、脅威インテリジェンス、製品開発、法務・コンプライアンスの間で、誰が実悪用情報を受け取り、誰が報告時計の開始を判断するかを決めておく必要があります。

OSSを利用しているだけでOSS開発者がすべて報告義務を負うわけではない

BleepingComputerの記事は、オープンソースのメンテナーが従来から脆弱性報告へ対応してきた経験を例にしています。

ただしCRAでは、無償のOSS開発者全員を通常の製造者と同じ扱いにはしていません。

欧州委員会によると、市場で商業活動として提供されるOSS製品はCRAの対象になりますが、収益化されていないOSSや、自ら責任を負わないOSSへコードを提供するだけの開発者は通常の製造者としてCRAの対象にはなりません。

また、商用利用を想定したOSSを継続的に支援し、存続に主要な役割を果たす法人については「open-source software steward」という別の法的区分があります。

OSS stewardのArticle 24(3)に基づく報告義務は2027年12月11日から適用され、製造者のArticle 14とは開始時期が異なります。

Article 64の最大1,500万ユーロ罰金は9月11日から全面適用されるわけではない

CRA Article 64は、Annex IやArticle 13、Article 14への違反について、最大1,500万ユーロ、企業の場合は前年度の全世界年間売上高の2.5％のいずれか高い方を上限とする行政制裁金を定めています。

ただし、この罰金額を「2026年9月11日から24時間報告に遅れると即座に最大1,500万ユーロ」と説明するのは正確ではありません。

CRA Article 71は、2026年9月11日から先行適用する条文としてArticle 14を明示しています。一方、Article 64は先行適用条文には含まれず、CRA全体の全面適用日は2027年12月11日です。

したがって、2026年9月11日に始まるのはArticle 14の報告義務そのものです。CRA Article 64の行政制裁金制度と、報告義務の開始日を同一の日付として扱わないよう注意が必要です。

また欧州委員会は、マイクロ企業・小企業について、24時間の早期警告期限を守れなかったことのみを理由とする行政制裁金に例外があることも説明しています。

実際の執行は加盟国の制度とも関係するため、EU向け製品を提供する企業は担当国の当局情報も確認する必要があります。

既存のCRA解説記事とは「報告義務開始」のニュースとして分離

セキュリティ対策Labでは、CRAの対象製品、適合性評価、罰則、日本企業への影響を扱う恒常解説を公開しています。

• EUサイバーレジリエンス法(CRA)とは-対象製品・罰則や日本企業への影響

今回の9月11日施行は、CRA全体の全面適用ではなくArticle 14の報告義務が先行して始まるタイミングです。

EU向けに製品を提供している企業では、制度全体の適合準備とは別に、現在販売・サポートしている製品について24時間以内の早期警告を実行できる運用があるかを確認する必要があります。

製品セキュリティ・PSIRT部門が9月11日までに確認したいポイント

報告義務は、セキュリティ部門だけで完結するプロセスではありません。

少なくとも次の項目を確認できます。

• EU市場へ現在提供している製品・バージョンを一覧化できるか
• 2027年12月以前に販売した既存製品も台帳に含まれているか
• 各製品で利用している第三者コンポーネントを追跡できるか
• 脆弱性情報と製品バージョンを紐付けられるか
• 「脆弱性を知った日時」と「実悪用を知った日時」を分けて記録できるか
• 実悪用と判断する責任者・部門が決まっているか
• 24時間以内にSRPへ早期警告を提出できる担当者が複数いるか
• Primary AR、Secondary ARの登録準備ができているか
• 担当するEU加盟国のCSIRTを特定しているか
• EU域内に主たる拠点がない場合の担当国を確認しているか
• 72時間以内に製品、影響、悪用、対策情報を集約できるか
• 修正・緩和策の提供日時を記録できるか
• 影響ユーザーを特定し、通知できるか
• 法務、PSIRT、SOC、開発、サポート、経営層のエスカレーション経路が決まっているか
• 休日・夜間に実悪用情報を把握した場合の報告フローがあるか
• SRPが一時停止した場合の担当CSIRTへの連絡手順を準備しているか

ENISAによると、SRPが一時的に利用できない場合でも、復旧後にSRPから正式な通知を提出する必要があります。緊急に連絡が必要な場合は担当CSIRTへ直接連絡できますが、それだけでSRP提出を代替することはできません。

9月11日以降、CRA対応の最初の実務的な論点は、製品開発の全面的な適合証明ではなく、「実悪用を把握した時点から24時間以内に対象製品と担当CSIRTを特定し、初報を出せるか」です。

出典

• Regulation (EU) 2024/2847 – Cyber Resilience Act – EUR-Lex
• Cyber Resilience Act – Reporting obligations – European Commission
• The Cyber Resilience Act – Summary of the legislative text – European Commission
• Cyber Resilience Act – Manufacturers – European Commission
• Cyber Resilience Act – Open source – European Commission
• Cyber Resilience Act implementation – Frequently asked questions – European Commission
• Single Reporting Platform (SRP) – ENISA
• Frequently Asked Questions – CRA Single Reporting Platform – ENISA
• CRA SRP guidance – AR Notification submission and update – ENISA