前回は、CRAにおける「脆弱性」（製品に内在する弱点）と「インシデント」（防御機能を低下/無効化しうる出来事）の違いを、玄関の鍵にたとえて整理しました。
今回はその続編として、「結局どのケースを報告するのか？」を実務パターンで整理します。
Article 14の報告義務は2026年9月11日から適用され、認識から24時間以内の早期警告が起点となるため、迷わず判定できる基準を事前に用意しておくことが重要です。
報告義務は2種類
① 能動的に悪用されている脆弱性の報告（Art. 14(1)）
「その脆弱性が自社製品に含まれている」×「悪意ある者が実際に悪用したという信頼できる証拠がある」の両方を満たすと報告対象です。
ポイントは、悪用の場所が自社製品上に限定されないこと（Art. 3(42)は「あるシステムで」悪用された証拠と定義）。
② 重大インシデントの報告（Art. 14(3)）
製品のセキュリティに影響するインシデントのうち、「機微・重要なデータや機能を守る能力への悪影響」または「悪意あるコードの導入・実行」に該当するものが対象です（Art. 14(5)）。
いずれも「〜しうる」段階、つまり実害が確定する前でも対象になりうる点に注意してください。
パターン別判定
| ケース | 判定 | ポイント |
|---|---|---|
| 自社製品で攻撃が発生（脆弱性が悪用された） | 脆弱性として報告 （Art. 14(1)） | 最も明確なケース。被害の内容次第では重大インシデントとしての報告にも同時該当しうる |
| 他社製品で攻撃が発生。悪用されたのは、自社製品にも含まれる同一の脆弱性で、自社製品でも悪用可能なもの（同一コンポーネント・同一CVE） | 脆弱性として報告 （Art. 14(1)） | 悪用の場所は問われない。共通コンポーネントのケースは公式FAQも報告義務ありと明言 |
| 他社製品で攻撃が発生したが、自社の脆弱性は「似ているが別物」 | 義務なし | ただし脆弱性としての調査・修正（Art. 13(8)）は必要 |
| 研究者からの報告やPoC公開のみで、悪用の証拠がない | 義務なし | 善意の発見は義務的報告の対象外（前文68）。悪用の証拠が出た瞬間に上記へ移行するため継続監視 |
| 顧客環境で自社製品を足がかりにマルウェアが実行された・実行のおそれ | インシデントとして報告 （Art. 14(3)） | Art. 14(5)(b)に直接該当 |
| 故障や停電でファイアウォールなどのセキュリティ機能が停止し、守るべき重要なデータ・機能が無防備な状態のまま製品が動き続けている | インシデントとして報告 （Art. 14(3)） | 攻撃や実害がなくても該当。重要なデータ・機能を守る能力が損なわれた状態の継続はArt. 14(5)(a)を満たす。原因が悪意ある行為かは問われない |
| 自社の開発環境やアップデート配信チャネルが侵害された | インシデントとして報告 （Art. 14(3)） | 製品自体が無傷でも対象になりうる（前文68）。見落としやすい |
| 製品と分離された社内IT（経理システム等）の被害 | 義務なし | 「製品のセキュリティに影響」しないため。分離の有効性検証が前提。NIS2等の別法令は別途確認 |
| 2027年12月11日より前に上市した既存製品での上記各ケース | 報告（区分は上記と同じ） | Article 14はサポート中のレガシー製品にも2026年9月11日から適用（Art. 69(3)） |
設計への示唆：セキュリティ機能は「フェイルセキュア」に
この報告義務は、製品設計にも重要な示唆を与えます。
たとえば、産業機械に組み込んだファイアウォールが機能停止した際、通信を素通しにするバイパス機能を入れておく設計を考えてみてください。
製品の稼働は止まらないので、機能面では一見フェイルセーフです。
しかしセキュリティの観点では、これは防御機能の無効化を製品自らが許容する設計です。
バイパスが作動した状態は、まさに「データや機能を守る能力が損なわれた事象」＝インシデントです。
上の表のとおり、故障や停電が原因で攻撃を受けていなくても、重要なデータ・機能が無防備のまま稼働を続けていれば重大インシデントに該当し、作動のたびに24時間以内の報告対応を迫られることになります。
玄関の例でいえば「停電すると自動で開錠するドア」――住人は閉め出されませんが、家を守る力は失われており、そのたびに事件簿へ記録するようなものです。
したがって、セキュリティ機能が故障・停止した場合は安全側＝遮断側に倒れる（フェイルセキュア／フェイルクローズ）設計を原則とすべきです。
可用性を優先したい箇所では、冗長化や縮退運転など「防御を保ったまま稼働を続ける」設計手段を先に検討します。
あわせて、万一の際に24時間以内の判定を可能にするため、「各セキュリティ機能が何を保護しているか（保護対象の重要度）」を設計段階で棚卸しし、報告判定基準に落としておくことをお勧めします。
なお産業機械では、非常停止などの安全機能とセキュリティ機能が競合する場合は安全機能を優先するのが機械規則側の原則ですので、その整合は個別に設計判断が必要です。
まとめ
CRAの第14条で報告対象となる「脆弱性」と「インシデント」のパターンについて説明しました。
- 脆弱性の報告は「自社製品に含まれる」×「どこかで悪用された証拠がある」。他社での攻撃事例でも、同一の脆弱性で悪用可能なら報告対象
- 重大インシデントの報告は実害の一歩手前（〜しうる）も含む。自社の開発・配信環境の侵害も対象になりうる
- 防御機能の無効化を許容する設計（フェイルオープン）は、作動のたびに報告事案を生む。セキュリティ機能はフェイルセキュアを原則に
