CRA（Cyber Resilience Act、規則(EU)2024/2847）のArticle14に対応するには、まず報告対象を正しく見極め、認識（aware）判断を起点に24時間・72時間の通知を回せるPSIRT運用を整えておく必要があります。
そのうえで実務では、ユーザー通知をどこまで行うか、known exploitable vulnerabilityとactively exploited vulnerabilityをどう区別するか、SBOMをどう位置づけるか、上流への報告や既存製品への適用をどう考えるか、といった論点が残ります。
本記事（第二回）では、こうした後半の実務論点に絞って、ユーザー通知、known exploitable vulnerabilityとactively exploited vulnerabilityの違い、SBOMや上流への報告との関係、既存製品への適用、そして2026年9月11日までに整備すべきPSIRT対応を整理します。
第一回では、Article14の先行適用、報告対象の見極め、認識（aware）判断と24時間・72時間通知の基本構造を整理しました。第二回では、その前提を踏まえ、実務運用で詰めておきたい後半の論点を見ていきます。
Article14(8)では、メーカーがactively exploited vulnerabilityまたはsevere incidentを認識した後、ユーザーに情報提供を行う義務が定められています。
CRAのArticle14(8)では、要旨として次の内容が定められています。
Article14(8)では、“where appropriate”や“where necessary”という限定が繰り返し使われています。
ここから分かるのは、ユーザー通知義務が一律の全面公開を求めるものではない、ということです。通知の範囲は、影響の及ぶユーザーやリスクの性質に応じて、必要かつ相当な範囲で決める前提になっています。
この点はガイダンス草案でも具体化されており、ユーザー通知はrisk-based and proportionate（リスクベースかつ比例的）に行うべきだとされています。
例えば、製品の性質、影響を受けるユーザー、潜在的な影響を踏まえると、詳細情報の提供先を関連するユーザーや顧客に限定できる場合があります。機微性の高い環境や重要な環境で利用される製品では、技術的な詳細を早期に公開すると追加の悪用を招くおそれもあるため、公開範囲やタイミングは慎重に設計すべきだとされています。
ただし、CRA本文のArticle14(8)の最後の一文には注意が必要です。メーカーがtimely（不当な遅延なく）通知を行わない場合には、CSIRTs designated as coordinatorsが、proportionate and necessary（その状況に照らして過度でない範囲）と判断される範囲で、ユーザーに直接情報提供を行うことができます。
つまり、メーカー側が「機微だから通知を遅らせる」「全ユーザーへの公開は避ける」と判断できるとしても、その裁量が無制限に認められるわけではありません。
あくまで合理的な範囲で通知の内容や方法を調整できるのであって、不当な遅延まで許されるわけではない、ということです。
こうした項目を重大事案の発生後にゼロから設計するのは、24時間・72時間の通知期限を考えると現実的ではありません。Article14が先行適用される2026年9月11日までに、雛形と判断基準をあらかじめ整えておく必要があります。
CRAの脆弱性関連概念の中でも、特に整理しておきたいのがknown exploitable vulnerabilityとactively exploited vulnerabilityの違いです。
用語が近いため混同されやすいのですが、CRAの中で果たしている役割は明確に異なります。
要するに、known exploitable vulnerabilityは「市場に出すかどうか」を判断するための軸であり、actively exploited vulnerabilityは「市場に出した後、当局やユーザーへの報告が必要かどうか」を判断するための軸です。
European CommissionのFAQでも、known exploitable vulnerabilityに関する義務はplacing on the marketの時点で課されるものであり、市場に出した後に新たに見つかった脆弱性は、Annex I Part IIに基づく脆弱性ハンドリング義務（サポート期間中の対応）の中で扱うと明記されています。
PSIRT運用では、両者を同じ流れで扱うのではなく、別のフローとして設計するのが望ましいといえます。
この2つを混同したままフローを設計すると、報告対象の見極めと出荷判定の両方で判断を誤るおそれがあります。
なお、knownとなる契機は、CVE Listだけに限りません。欧州脆弱性データベース（European Vulnerability Database、Directive(EU)2022/2555 Article12(2)に基づき設置）、セキュリティ研究者による協調開示、顧客や第三者からの非公開情報、自社の内部テストや分析、信頼できるメディアや専門性の高いサイバーセキュリティ媒体での顕著な報道なども含まれると整理されています（ガイダンス草案）。
ただし、ある脆弱性がexploitableだと報告されていても、それだけで直ちに自社製品に当てはまるとは限りません。メーカーには、情報の真実性と自社製品への適用可能性を、合理的かつ迅速に見極めることが求められます。
SBOM（Software Bill of Materials）については、「2026年9月11日から一律の提出義務が始まる」と受け取られることがありますが、実務上は注意が必要です。CRAでは、SBOMはAnnex I Part II（脆弱性ハンドリング要求）の一部として位置づけられており、本格適用は2027年12月のCRA全面適用に合わせたものです。
なお、Recital(77)では、メーカーにSBOMの公開義務は課されないことが明記されており、市場監視当局への提示義務（Article13(25)等）と公開義務は別の論点であることも押さえておく必要があります。
ただし、2026年9月時点ではSBOMが不要だと整理するのは適切ではありません。Article14に対応するには、自社製品に該当コンポーネントが含まれているか、どのバージョンか、どの顧客や製品系列に影響するかを特定する必要があるためです。
具体的には、SBOMと構成管理は、次のような判断や運用を支える基盤になります。
このため、SBOMは、CRA上の正式な対応物（Annex I PartII対応）として整備するよりも前に、Article 14対応を支える実務上の仕組みとして整えておくことが重要です。これは、Article 14 の直接義務というより、Article 14 を履行するための前提条件として位置づけるべき事項です。
実務上は、製品系列ごとのSBOM管理、バージョン差分の管理、構成変更履歴、顧客導入実績との突合（どの顧客にどのバージョンが導入されているか）、サプライヤーから受領したSBOMの統合といった項目を、Article14対応の前提条件として整えていくことが望まれます。
Article13(6)では、自社製品に組み込んだ外部ソフトウェアや部品そのものに原因がある脆弱性について、メーカーがその開発元や保守元に連絡し、情報提供を行うことが求められています。
こうした上流の製造者・保守者への通知や情報共有をupstream reporting（上流への報告）と呼びます。
あわせて、当該コンポーネントの脆弱性に対する修正や設計変更（いわゆるsoftware/hardware modification）を自社で実施した場合には、関連するコードやドキュメントを上流の製造者・保守者と共有することが求められます。
必要に応じて、これらを機械可読形式で提供することも想定されています。こうした修正内容の上流共有をsecurity fix sharingと呼びます。
ガイダンス草案を踏まえると、上流への報告（upstream reporting）と修正内容の上流共有（security fix sharing）については、次の点を実務上の留意点として押さえておく必要があります。
なお、Article13(6)の本格適用は2027年12月11日からですが、Article14(2)(b)・(4)(b)で求められる"corrective or mitigating measures taken"（講じた修正措置又は緩和措置）の中身を具体化するには、コンポーネント側との連携が事実上前提になります。そのため、PSIRTは2026年9月時点で、次の項目を整えておくのが望まれます。
繰り返しになりますが、Article69(3)により、CRAの適用範囲に入るすべての製品には、2027年12月11日より前に上市されたものを含めて、Article14の報告義務が適用されます。
これは実務上、見落とせないポイントです。
このセクションで押さえておきたいのは、「2026年9月のArticle14対応は新規製品だけの話ではない」という点です。既存ポートフォリオこそが、2026年9月時点でPSIRTが対象としなければならない範囲になります。
ここまでの整理を踏まえ、2026年9月11日までに最低限整えておきたいPSIRTの実務項目を、現場で使いやすいチェックリストとしてまとめます。
要点は3つです。（1）報告対象を見極められること、（2）24時間・72時間の通知を回せること、（3）ユーザー通知と既存製品対応まで含めて運用を設計すること。
この3点がそろえば、Article14対応は実際に動き始めます。
チェックリストはカテゴリごとに、整備しておくべき項目を並べています。
上記の中には、既存のCSIRT/SOC運用と重なる部分もあります。
ただし、CRA Article14で問われるのは、製品メーカーとしての説明責任（判断・通知・記録・ユーザー連絡）です。
コーポレートIT中心の体制を前提にしつつも、製品ライフサイクルに即したPSIRTとして何が足りないのかを、早めに棚卸ししておくことが重要です。
CRA対応の出発点は、2027年12月のCEマーキングや技術文書整備だけではありません。
2026年9月11日に先行適用されるArticle14に対応するには、PSIRTが脆弱性やインシデントの情報を受け付け、報告対象を見極め、期限内に通知し、ユーザー通知や上流への報告まで実行できる体制を整える必要があります。
特に、Article69(3)により既存製品もArticle14の対象に含まれるため、PSIRTのカバレッジは過去のポートフォリオまで視野に入れて設計する必要があります。
SBOMや構成管理、顧客導入情報、サプライヤー連絡先、通知テンプレートなどの実務インフラは、Article14の直接義務というより、それを履行するための前提条件として位置づけるのが適切です。
Article14対応は、CRA全面適用に向けた最初の実務課題です。2027年に向けた運用整備が実際に機能するかどうかを測る、試金石ともいえます。
2026年9月11日までに、PSIRTを単なる受付窓口ではなく、判断と運用を担える体制として整備できるかが、製造業におけるCRA対応の大きな分かれ目になります。
欧州IoTセキュリティ法規への対応は、条文を読むだけでは進みません。
実際には、自社製品がどこまで対象になるのか、既存製品をどう扱うのか、PSIRTやSBOMをどう整えるのか、といった実務設計が重要になります。
NRIセキュアでは、こうした論点を踏まえた「欧州IoTセキュリティ法規準拠支援サービス」を提供しています。CRA対応の進め方に悩まれている場合は、ぜひご相談ください。