CRA（Cyber Resilience Act、規則(EU) 2024/2847）は、2027年12月11日から全面適用されます（Article 71(1)）。ただし、製造業の実務担当者にとって先に気を付けるべきなのは、Article 14に基づく報告義務が2026年9月11日から先行して適用される点です（Article 71(2)）。
CRA Article 14（規則(EU) 2024/2847）は、自社製品で確認された「悪用が確認された脆弱性（actively exploited vulnerability）」と「重大インシデント（severe incident）」を、ENISAおよび各国CSIRTへ報告する義務を定めた条文です。
そのため、CRA対応を2027年のCEマーキングや技術文書整備の話だけとして捉えていると、2026年9月までに必要となるPSIRT（Product Security Incident Response Team）の運用準備が遅れかねません。加えて、Article 69(3)により、2027年12月11日より前に欧州市場に上市された製品にも、2026年9月11日からArticle 14の報告義務が及びます。既存製品を多く抱える製造業では、ここを見落とせません。
本記事では、Article 14の全体像と、製造業がPSIRT体制を整えるうえで押さえておきたいポイントを確認します。具体的には、報告対象をどう見極めるか、awareをいつ判断するか、ユーザー通知をどう考えるか、known exploitable vulnerabilityとactively exploited vulnerabilityの違い、SBOMやupstream連携との関係、さらに既存製品への適用までを扱います。
CRAは、対象製品（products with digital elements）について、上市時のサイバーセキュリティ要求、適合性評価、CEマーキング、技術文書、脆弱性ハンドリングなどを包括的に定める規制です。
そのうちArticle 14に基づく報告義務は、CRA全体に先行して2026年9月11日から適用されます（Article 71(2)）。
Article 14が定めているのは、メーカーが自社製品について認識した一定の脆弱性やインシデントを、CSIRT designated as coordinator（各加盟国で指定された調整役のCSIRT）とENISAに対し、Article 16に基づくsingle reporting platform（単一報告プラットフォーム）を通じて通知する義務です。Article 14(8)に基づくユーザーへの情報提供義務も、この時点から始まります。
CRA全体が本格的に適用されるのは2027年12月11日です。そのため、2026年9月の段階では、CEマーキングや適合性評価といった上市時の要求はまだ全面適用されていません。ただ、Article 14は出荷後のセキュリティ運用に関する規定です。これを実際に回すには、製品ライフサイクル全体を見渡せるPSIRT機能が事実上欠かせません。
この点を踏まえると、CRA対応の最初の実務課題は、2027年の上市時要求に備えることだけではありません。2026年9月までにPSIRTを実際に運用できる状態にしておくことが先に来ます。
では、2026年9月11日に何が始まり、何がまだ始まらないのか。先行適用の範囲と、2027年12月11日の全面適用との関係を整理すると、次のとおりです。
ここで特に重要になるのが、Article 69のtransitional provisions（経過措置）の読み方です。
つまり、2026年9月11日の時点ですでに欧州市場に出ている製品でも、actively exploited vulnerability（実際に悪用が確認されている脆弱性）やsevere incident（重大なインシデント）が生じれば、メーカーには報告義務が発生します。CEマーキングや技術文書をさかのぼって整備する必要はありませんが、PSIRTのカバレッジは既存製品まで含めて設計しておく必要があります。
ここを見落とすと、「2027年に向けて新規製品の準備を進めれば足りる」という誤った時間感覚で動いてしまいます。その結果、2026年9月以降に既存製品でactively exploited vulnerabilityが判明したとき、必要な対応が間に合わなくなるおそれがあります。
Article 14は、「自社製品に関する脆弱性が見つかったら、すべて当局に報告する制度」と受け取られがちです。しかし、条文の立て付けはそこまで単純ではありません。
CRA本文のArticle 14(1)・Article 14(3)を見ると、メーカーがCSIRT designated as coordinatorとENISAにsimultaneously（同時に）通知すべき対象は、次の2類型に限られています。
ここでいうactively exploited vulnerabilityについては、CRA Recital (68)に説明があります。メーカーが市場に出した製品のflawを悪意ある攻撃者が利用し、その結果としてユーザーや他の自然人・法人にsecurity breachが生じたと判断する事象を指す、という整理です。
要するに、PoCの存在やCVEの公開だけでは足りず、実際の悪用が観測されていることが要件になります。
したがって、PSIRTが受け付けた脆弱性情報のすべてが、そのままArticle 14の報告対象になるわけではありません。実務では、受け付けた情報を少なくとも次の4つに切り分けて考える必要があります。
この4分類を維持できないPSIRT運用では、過剰報告による運用負荷や当局側の負担と、過少報告による規制適合上の問題の両方が起こりえます。Article 14は、メーカーに対して「何を報告し、何を内部対応にとどめるか」を見極める責任を求めている、と理解するのが正確です。
この見極めを実務で回すには、PSIRTが情報受付から判断、通知までの流れをあらかじめ設計しておく必要があります。
このフローで押さえておきたいのは、CVEやCVSSスコアを確認しただけでは、exploitable、actively exploitedの判定は終わらないという点です。Article 3(41)のexploitable vulnerabilityは、実運用条件のもとで攻撃者が実際に利用しうる脆弱性として理解されます。
European CommissionのFAQでも、すべての脆弱性がexploitableに当たるわけではなく、ラボ環境や理論上の条件でしか成立しないものは、自社製品の実運用環境では悪用可能とは限らないと明示されています。
severe incidentの認識については、Article 14(5)が二つの要件を置いています。
これらのいずれかに当たる事象が、Article 14(3)の報告対象になります。CRA Recital(68)では、製品そのものの脆弱性に限らず、メーカーがユーザーにセキュリティアップデートを配布する経路に攻撃者が侵入し、悪意あるコードを混入させるケースも典型例として挙げられています。
以下のアクションは、その場しのぎではなく、定型プロセスとしてあらかじめ整備しておく必要があります。
これらは事前に社内で整備し、担当者が明確な定型プロセスとして実際に動かせるようにしておく必要があります。24時間・72時間という短い時間軸のなかで、その都度判断手順を作りながら対応するのは現実的ではありません。施行前から回せる状態にしておくことが重要です。
Article 14の 当局通知の期限は、メーカーが当該脆弱性またはsevere incidentについて「aware（becoming aware）」になった時点から起算されます。awareを考えるうえでは、次の2点が重要です。
一つ目は、情報を受け付けた瞬間に直ちにawareになるとは限らないことです。
二つ目は、だからといってawareの判断を不当に引き延ばしてよいわけではない、という点です。
ガイダンス草案では、疑わしい事象を検知した場合や、第三者・顧客・当局・メディアなどから潜在的な脆弱性またはインシデントの情報を受けた場合には、メーカーは直ちに初期評価を始めるべきだと整理されています。
そのうえで、自社製品に含まれる脆弱性がactively exploitedであること、またはsevere incidentが発生して製品のセキュリティが侵害されていることについて、合理的な確度（reasonable certainty after an initial assessment）を持った時点でawareとみなされる、という整理です。完全なフォレンジック確認まで待つことは求められていません。
このタイムラインに関しては、特に次の3点を押さえておく必要があります。
Article 14対応で説明責任を果たすには、PSIRTが少なくとも次の時刻を記録できるようにしておくことが重要です。
これらの記録は、単なる運用管理のためだけのものではありません。事後的に「いつawareになったのか」「合理的な初期評価をいつ終えたのか」を問われたときに、メーカーとして合理的な対応を取っていたことを説明する根拠になります。
以上見てきたように、CRA Article 14対応の実務でまず問われるのは、報告対象を正しく見極めたうえで、aware判断から24時間・72時間通知までを遅滞なく回せるPSIRT運用を、2026年9月11日までに整えておけるかどうかです。
もっとも、実務上の論点はここで終わりません。ユーザー通知の範囲、upstream連携、SBOMとの関係など、さらに詰めておくべき点があります。
欧州IoTセキュリティ法規への対応は、条文を読むだけでは進みません。実際には、自社製品がどこまで対象になるのか、既存製品をどう扱うのか、PSIRTやSBOMをどう整えるのか、といった実務設計が重要になります。
NRIセキュアでは、こうした論点を踏まえた「欧州IoTセキュリティ法規準拠支援サービス」を提供しています。CRA対応の進め方に悩まれている場合は、ぜひご相談ください。
Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act), EUR-Lex.