EUサイバーレジリエンス法（CRA）の条文を読んでいると、「脆弱性（vulnerability）」と「インシデント（incident）」という2つの言葉が繰り返し登場します。
似たような文脈で出てくるため混同されがちですが、CRAではこの2つは明確に別の概念であり、しかもそれぞれ別の報告義務のトリガーになっています。
2026年9月11日にはArticle 14の報告義務が適用開始となるため、この区別はメーカーにとって「知っておくと便利」ではなく「知らないと困る」レベルの基礎知識です。
今回は、玄関の鍵にたとえて整理してみます。
玄関の鍵にたとえると
脆弱性＝製品が持つ「弱点」です。
たとえば安価な南京錠を思い浮かべてください。
- ピッキングが容易
- 切断や殴打で壊れてしまう
これらは南京錠という製品そのものに内在する構造的な弱さです。
誰かに攻撃されるかどうかに関係なく、その錠前が存在する限りずっとそこにあり続ける「状態」――それが脆弱性です。
インシデント＝防御機能を低下/無効化しうる「出来事」です。
今度は、ピッキング困難な頑丈な電子錠を付けた玄関を考えます。製品としての弱点はほとんどありません。
それでも、こんなことは起こりえます。
- 停電で電子錠が施錠できなくなった
- 鍵を紛失した・盗まれた
錠前自体はどこも壊れていません。しかし「その家を守る能力」は現に損なわれています。
このように、ある時刻に実際に発生し、防御の力を低下・無効化させる事象がCRAにおけるインシデントです。
ポイントは、弱点のない頑丈な鍵でもインシデントは起きるということです。
脆弱性をゼロに近づける努力（セキュアな設計）と、インシデントに気づいて対応する備え（検知・報告・復旧）は、どちらか一方では足りない、車の両輪の関係にあります。
CRAの条文ではどう定義されているか
たとえ話を条文に戻します。CRA（Regulation (EU) 2024/2847）のArticle 3では、おおむね次のように定義されています。
脆弱性（Art. 3(40)）：サイバー脅威によって悪用されうる、デジタル要素を持つ製品の弱点・欠陥。まさに「製品に潜む弱点」です。
インシデント（Art. 3(43)）：NIS2指令（Directive (EU) 2022/2555）Art. 6(6)の定義を参照しており、データやサービスの可用性・真正性・完全性・機密性を損なう事象を指します。
さらにCRAは「製品のセキュリティに影響するインシデント」（Art. 3(44)）として、製品がデータや機能を保護する能力に「悪影響を与える、または与えうる」事象と定義しています。
この「与えうる」が実務上のポイントです。
停電で施錠できなくなった玄関も、鍵を盗まれた玄関も、まだ泥棒には入られていません。
それでも「守る能力」は現に損なわれているため、インシデントに該当しうるのです。
実害が出てから初めてインシデント、ではありません。
なぜこの区別が重要か ― Article 14の2つの報告トラック
CRAのArticle 14は、メーカーに2種類の報告義務を課しています。
Art. 14(1)：能動的に悪用されている脆弱性の報告。
自社製品に含まれる脆弱性が、悪意ある者によって実際に悪用されているという信頼できる証拠を把握した場合の報告です。
玄関の例でいえば「同型の南京錠が実際にピッキング被害に遭っているという確かな情報を得た」状況です。
弱点が存在するだけでは足りず、「現に使われている」ことがトリガーになります。
Art. 14(3)：重大インシデントの報告。
製品のセキュリティに影響する重大なインシデントを把握した場合の報告です。
玄関の例でいえば「施錠できなくなった」「鍵が盗まれた」に相当します。
いずれも、認識から24時間以内の早期警告を皮切りとする段階的な通知が求められます。
この報告義務は2026年9月11日から適用され、しかも同日以降はサポート期間中のレガシー製品（過去に上市済みの製品）にも及びます。
「脆弱性」と「インシデント」のどちらの話をしているのかを区別できないと、社内の報告判定フローそのものが組み立てられません。
まとめ
CRAにおける「脆弱性」と「インシデント」について説明しました。
- 脆弱性は製品に内在し続ける「弱点（状態）」
- インシデントは防御機能を低下・無効化しうる「出来事（事象）」。実害の一歩手前も含む
- 両者は別概念だが相互に転化しあう関係にあり、CRA Article 14では別トラックの報告義務として扱われる
自社製品について「何が脆弱性で、どんな事象がインシデントにあたるのか」を具体例で棚卸ししておくことが、9月11日のArticle 14適用開始に向けた第一歩です。
