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 Article 14の先行適用とは
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日に始まるものと、始まらないもの
では、2026年9月11日に何が始まり、何がまだ始まらないのか。先行適用の範囲と、2027年12月11日の全面適用との関係を整理すると、次のとおりです。
2026年9月11日／2027年12月11日の適用関係
既存製品（legacy products）の取り扱い
ここで特に重要になるのが、Article 69のtransitional provisions（経過措置）の読み方です。
- Article 69(2)：2027年12月11日より前に上市された製品は、その日以降に substantial modification を受けない限り、CRAの上市時要求の対象外。
- Article 69(3)：上記の例外として、Article 14の報告義務は、CRAの適用範囲に該当する全ての製品（2027年12月11日より前に上市されたものを含む）に適用される。
つまり、2026年9月11日の時点ですでに欧州市場に出ている製品でも、actively exploited vulnerability（実際に悪用が確認されている脆弱性）やsevere incident（重大なインシデント）が生じれば、メーカーには報告義務が発生します。CEマーキングや技術文書をさかのぼって整備する必要はありませんが、PSIRTのカバレッジは既存製品まで含めて設計しておく必要があります。
ここを見落とすと、「2027年に向けて新規製品の準備を進めれば足りる」という誤った時間感覚で動いてしまいます。その結果、2026年9月以降に既存製品でactively exploited vulnerabilityが判明したとき、必要な対応が間に合わなくなるおそれがあります。
Article 14は「全ての脆弱性」を報告する制度ではない
Article 14は、「自社製品に関する脆弱性が見つかったら、すべて当局に報告する制度」と受け取られがちです。しかし、条文の立て付けはそこまで単純ではありません。
CRA本文のArticle 14(1)・Article 14(3)を見ると、メーカーがCSIRT designated as coordinatorとENISAにsimultaneously（同時に）通知すべき対象は、次の2類型に限られています。
- 自社製品に含まれる actively exploited vulnerability（実際に悪用が確認されている脆弱性）
- 製品のセキュリティに影響を与える severe incident（重大インシデント）
ここでいうactively exploited vulnerabilityについては、CRA Recital (68)に説明があります。メーカーが市場に出した製品のflawを悪意ある攻撃者が利用し、その結果としてユーザーや他の自然人・法人にsecurity breachが生じたと判断する事象を指す、という整理です。
要するに、PoCの存在やCVEの公開だけでは足りず、実際の悪用が観測されていることが要件になります。
したがって、PSIRTが受け付けた脆弱性情報のすべてが、そのままArticle 14の報告対象になるわけではありません。実務では、受け付けた情報を少なくとも次の4つに切り分けて考える必要があります。
受付情報の切り分け
この4分類を維持できないPSIRT運用では、過剰報告による運用負荷や当局側の負担と、過少報告による規制適合上の問題の両方が起こりえます。Article 14は、メーカーに対して「何を報告し、何を内部対応にとどめるか」を見極める責任を求めている、と理解するのが正確です。
PSIRTに求められる報告対象の見極め
この見極めを実務で回すには、PSIRTが情報受付から判断、通知までの流れをあらかじめ設計しておく必要があります。
PSIRTが受け付けた情報をどう仕分けるか
このフローで押さえておきたいのは、CVEやCVSSスコアを確認しただけでは、exploitable、actively exploitedの判定は終わらないという点です。Article 3(41)のexploitable vulnerabilityは、実運用条件のもとで攻撃者が実際に利用しうる脆弱性として理解されます。
European CommissionのFAQでも、すべての脆弱性がexploitableに当たるわけではなく、ラボ環境や理論上の条件でしか成立しないものは、自社製品の実運用環境では悪用可能とは限らないと明示されています。
severe incidentの判定軸
severe incidentの認識については、Article 14(5)が二つの要件を置いています。
- (a)製品の availability（可用性）、authenticity（真正性）、integrity（完全性）、confidentiality（機密性）を、sensitive or important data or functions について保護する能力に、現に悪影響を及ぼしているか、悪影響を及ぼし得る、または
- (b)製品自体、または当該製品を使用するユーザーのネットワーク・情報システムに、悪意あるコードの導入または実行を引き起こした、または引き起こし得る
これらのいずれかに当たる事象が、Article 14(3)の報告対象になります。CRA Recital(68)では、製品そのものの脆弱性に限らず、メーカーがユーザーにセキュリティアップデートを配布する経路に攻撃者が侵入し、悪意あるコードを混入させるケースも典型例として挙げられています。
PSIRTが受付直後に着手すべき9つのアクション
以下のアクションは、その場しのぎではなく、定型プロセスとしてあらかじめ整備しておく必要があります。
- 情報受付の記録（例：受付時刻、情報源、機微度の初期評価）
- 初期評価責任者の自動アサインの仕組み（不在時の代理者・エスカレーション先を含む）
- aware判断の合議・記録（誰が、いつ、どの情報をもってawareと判断したのか）
- 自社製品該当性の確認（SBOM・構成管理との突合、影響バージョン特定）
- 顧客影響範囲の把握（例：どの顧客のどのデプロイメントに影響するのか）
- 当局通知判断（Article 14対象か、対象であれば早期警告開始）
- ユーザー通知判断（impacted users 範囲、all usersへの展開要否、開示範囲・タイミング）
- 修正・緩和策の検討（例：パッチ提供、使用時の構成変更案内）
- upstream reporting/security fix sharingの確認（統合コンポーネントの保守者連絡、自社開発fixの上流共有）
これらは事前に社内で整備し、担当者が明確な定型プロセスとして実際に動かせるようにしておく必要があります。24時間・72時間という短い時間軸のなかで、その都度判断手順を作りながら対応するのは現実的ではありません。施行前から回せる状態にしておくことが重要です。
aware（認識）判断と24時間・72時間通知の考え方
Article 14の 当局通知の期限は、メーカーが当該脆弱性またはsevere incidentについて「aware（becoming aware）」になった時点から起算されます。awareを考えるうえでは、次の2点が重要です。
一つ目は、情報を受け付けた瞬間に直ちにawareになるとは限らないことです。
二つ目は、だからといってawareの判断を不当に引き延ばしてよいわけではない、という点です。
ガイダンス草案では、疑わしい事象を検知した場合や、第三者・顧客・当局・メディアなどから潜在的な脆弱性またはインシデントの情報を受けた場合には、メーカーは直ちに初期評価を始めるべきだと整理されています。
そのうえで、自社製品に含まれる脆弱性がactively exploitedであること、またはsevere incidentが発生して製品のセキュリティが侵害されていることについて、合理的な確度（reasonable certainty after an initial assessment）を持った時点でawareとみなされる、という整理です。完全なフォレンジック確認まで待つことは求められていません。
Article 14に基づく通知タイムライン
このタイムラインに関しては、特に次の3点を押さえておく必要があります。
- 24時間時点で完全な原因分析までは求められない。
CRAの通知制度は、限られた情報での初期通知を出発点とし、その後の調査の進み具合に応じて情報を更新していく構造です。Article 14(2)(b)の"unless the relevant information has already been provided"という文言にも、その考え方が表れています。 - CSIRTからintermediate reportを求められることがある。
Article 14(6)に基づき、CSIRT designated as coordinatorは必要に応じてメーカーに中間報告を求められます。PSIRTには、72時間通知の後からfinal reportまでの間も、途中経過を整理して更新できる運用が必要です。 - vulnerabilityのfinal reportは「修正提供から14日以内」、incidentのfinal reportは「72時間通知から1か月以内」で、
起算点が異なります。混同しやすいため、PSIRTの期限管理ツールでは、事象種別ごとに別々に計算・管理できるようにしておくのが実務上は無難です。
PSIRTで記録すべき時刻
Article 14対応で説明責任を果たすには、PSIRTが少なくとも次の時刻を記録できるようにしておくことが重要です。
- 情報受付時刻
- 初期評価開始時刻
- 初期評価完了時刻
- aware判断時刻
- 24時間early warning通知期限・実通知時刻
- 72時間notification期限・実通知時刻
- 中間報告要求受領時刻・回答時刻（発生した場合）
- corrective or mitigating measure 利用可能化時刻（actively exploited vulnerabilityの場合）
- final report期限・実通知時刻
- ユーザー通知判断時刻・実通知時刻
これらの記録は、単なる運用管理のためだけのものではありません。事後的に「いつ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.
- European Commission, Frequently Asked Questions on the Cyber Resilience Act implementation.
- European Commission, Draft guidance on the application of Regulation (EU) 2024/2847 (Cyber Resilience Act).
- ENISA, ”Single Reporting Platform (SRP) | ENISA”
