EU Cyber Resilience Actの2026年9月報告開始とEOL部品の扱い

TL;DR

---

EU Cyber Resilience Act（CRA、Regulation (EU) 2024/2847）は、全体適用の2027年12月11日より前に、2026年9月11日から報告義務が始まる。
欧州委員会のCRAページも、主な義務は2027年12月11日から、報告義務は2026年9月11日からと分けて書いている。

この前倒し部分では、報告窓口の準備より先に部品の把握が必要になる。
製品に入っている部品を知らないと、実際に悪用された脆弱性が自社製品に含まれるかを短時間で判断できない。
EOL（End of Life、サポート終了）部品を含む製品では、上流から修正が来ない状態で、報告と緩和策の説明を組むことになる。

2026年9月11日に適用が始まるのはArticle 14

EUR-Lexの正式条文では、Article 71が適用日を分けている。
CRA全体は2027年12月11日から適用されるが、Article 14は2026年9月11日から適用される。
Article 14は、製品に含まれるactively exploited vulnerability（実際に悪用されている脆弱性）と、製品のセキュリティに影響するsevere incident（重大インシデント）の報告義務だ。 なお、適合性評価機関の通知などを定めるChapter IV（Articles 35〜51）は、Article 14より先に2026年6月11日から適用されている。

Article 14(5)の重大インシデントは、製品が機微・重要データや機能の可用性、真正性、完全性、機密性を守る能力へ悪影響を与えた、または与える可能性がある場合と、製品または利用者のネットワーク・情報システムへ悪意あるコードを導入・実行させた、またはその可能性がある場合を指す。

Article 14の報告期限は時間単位で設定されている。
製造者が実際の悪用または重大インシデントを把握したら、不当な遅延なく、遅くとも24時間以内にearly warning（初期警告）、72時間以内に追加通知を出す。
最終報告の期限は二つで異なる。悪用された脆弱性では修正または緩和策が利用可能になってから14日以内、重大インシデントでは72時間通知の提出から1か月以内になる。
ENISAのSingle Reporting Platformページも、SRP（Single Reporting Platform、単一報告基盤）は2026年9月11日に稼働予定で、CSIRT（Computer Security Incident Response Team、コンピュータセキュリティ事故対応チーム）とENISAへ同時に送る入口になると説明している。

SRPでは、製造者のEU内の主たる拠点を担当するCSIRTの電子窓口へ出し、ENISAからも同時に参照できる。主たる拠点は登記住所ではなく、製品のサイバーセキュリティに関する意思決定を主に行う加盟国で判断し、特定できなければEU内で従業員数が最も多い拠点の国になる。EU内に主たる拠点がない製造者は、Article 14(7)に従い、最も多くの製品を担当する認定代理人の所在国、最も多くの製品を扱う輸入者、流通業者の所在国、最も多くのユーザーがいる国の順で担当加盟国を決める。
受領したCSIRTは、製品が提供されている他の加盟国の担当CSIRTへ原則として遅滞なく展開する。機密性が高い報告には、サイバーセキュリティ上の正当な理由に基づく展開の延期手続きがあり、例外的に72時間通知の一部だけが当初ENISAへ共有される場合もある。SRPへの報告が直ちに一般公開されるという意味ではない。

ここで言う「把握」は、公開CVE（共通脆弱性識別子）を見た瞬間と同義ではない。actively exploited vulnerabilityは、悪意ある者がシステム所有者の許可なく悪用したという信頼できる証拠がある脆弱性を指す。
ENISAのFAQにあるSRP入力項目では、24時間段階で製造者名と製品名などが必須だが、CVE IDとEUVD IDは任意だ。悪用と脆弱性の一般情報、実施済み対策、ユーザーが取れる対策は72時間段階で必須になる。初期警告までに完全な原因分析を終える義務ではないが、脆弱性情報の受信、製品への影響判定、ユーザー向け緩和策の文書化を並行して進める必要がある。
またArticle 14(8)は、影響を受けるユーザーと、必要に応じて全ユーザーへ、脆弱性またはインシデントと対策を知らせるよう製造者に求める。

移行規定のArticle 69(3)も見落とせない。Article 14は、2027年12月11日より前に上市された対象製品にも適用される。
欧州委員会の実装FAQは、古い製品ではビルド環境や依存関係を再現できない場合でも報告は必要だが、2027年より前に上市され、その後にsubstantial modification（実質的変更）を受けていない製品には、CRAの他の脆弱性処理義務まで遡って適用されるわけではないと説明している。2026年9月11日より前から製造者が悪用を把握していた脆弱性を、開始日に遡って報告する義務もない。

以前、NIST NVDの優先度付きenrichmentの記事で、NVD、KEV、GHSA、OSV、EUVD、SRPが別々の役割を持ち始めた話を書いた。
今回のCRAは、その中でもSRPが「EU市場向け製品の報告入口」として動き始める日付の話になる。
NVDにCPEが付くのを待ってから自社製品への影響を拾う運用だと、24時間の初期警告には間に合わないケースが出る。

EOL部品では報告時の説明材料が先に問題になる

CRAのArticle 13は、製造者に対して、サポート期間中に製品全体と、統合されたすべての部品の脆弱性を扱うことを求めている。
条文上は、第三者由来の部品やOSS部品を組み込むときのdue diligence（相当な注意義務）も明記されている。
サポート期間は製品の想定利用期間などを踏まえて決め、原則として少なくとも5年とされる。想定利用期間が5年未満の製品だけは、その想定利用期間まで短縮できる。逆に、5年を超えて使われると合理的に見込まれる製品では、5年で打ち切るとサポート期間が不足する。

EOL部品では、修正パッチが来ないことに加えて、報告の場面で答える材料が問題になる。
その部品がどの製品ビルドに入っているか、その脆弱性が製品のどの機能に影響するか、上流修正がない場合に製品側で回避できるか、ユーザーにどの緩和策を案内できるか。

CRAはEOL部品を一律に禁止する条文ではない。しかし、製品側のサポート期間中に統合部品の上流サポートが終わっても、製品製造者の義務は消えない。
欧州委員会の実装FAQは、緩和策で十分に直せないなら、部品の交換や製造者自身によるパッチ開発など、別の方法で修正する必要があると説明している。それでも適合状態へ戻せない例外的な場合には、市場からの撤回または回収が必要になりうる。第三者部品由来の脆弱性でも、自社製品内で実際に悪用可能であり、製造者がその悪用を把握したなら、自社製品についてArticle 14の報告が必要になる。統合後の製品では悪用できない脆弱性なら、強制報告の対象ではない。
Article 13(6)は、統合部品に脆弱性を見つけた製造者へ、部品の製造者または保守者への報告も求める。自社で修正を開発した場合は、適切なときに修正コードや関連文書も共有する。

製品そのもののサポート終了日には、購入者への表示義務もある。Article 13(19)とAnnex II(7)は、購入時にサポート期間の終了年月を明確で容易にアクセスできる形で示し、技術的に可能なら終了到達時にユーザーへ通知するよう求めている。

endoflife.aiの原記事は、この点をEOL部品の在庫問題として扱っている。
例として Debian 10、AngularJS、OpenSSL 3.0、.NET 8 を挙げている。一次資料で見ると、Debian 10の公式LTSは2024年6月30日に終了し、AngularJSの公式サポートは2022年1月に終了している。Debian 10には第三者による有償のELTS（Extended LTS、延長サポート）もあるが、公式Debian LTSとは別物だ。
OpenSSLの公式ロードマップでは3.0 LTSのサポート終了が2026年9月7日で、CRA報告義務の開始日である9月11日の4日前になる。2026年6月9日更新の.NET公式サポートポリシーでは、.NET 8 LTSと.NET 9 STS（Standard Term Support、短期サポート）はいずれも2026年11月10日終了だ。EOLデータ集約サービスの値だけでなく、製品ごとに上流のライフサイクル表と、有償延長サポートの範囲を確認する。

このブログでも、.NET 8/9 と Windows Server 2012 の2026年EOL期限で関連する移行期限を扱った。Microsoftの汎用的な「2026年サポート終了一覧」には.NET 9を2026年5月12日終了とする古い記載が残るが、現在の.NET製品別ポリシーではSTSのサポート期間が2年とされ、.NET 8と.NET 9は11月10日に同時終了する。
あの記事で分けた.NETのターゲットフレームワークとWindows ServerのホストOSに加え、CRAでは「EU市場へ出している製品の部品として、どのビルドに残っているか」までが対象になる。
.NET 8のWeb API、古いWindows Server上の管理コンソール、OpenSSL 3.0を含むアプライアンス、AngularJSの管理UIは、別々の移行表ではなく製品単位の部品表で扱う。

SBOMを製品単位で引ける状態にする

CRAはSBOM（Software Bill of Materials、ソフトウェア部品表）を明示的に定義し、Annex I Part II(1)で、製品内の脆弱性と部品を特定・文書化するため、少なくともトップレベル依存関係を含む、一般的な機械可読形式のSBOMを作るよう求めている。Article 13(24)は、その形式と要素を欧州委員会が実施法で指定できるとしている。
一方、SBOMを全ユーザーへ一律に公開する義務ではない。Annex II(9)は、製造者がユーザーへSBOMを提供すると決めた場合に、その参照先を案内する項目だ。SBOMは技術文書の一部になり、監視当局は適合確認に必要な場合、理由を示して提出を求められる。

24時間の初期警告で必要になるのは、きれいな部品一覧ファイルではなく、今どの製品に何が入っているかを引ける状態だ。
ビルド済みコンテナ、組み込みファームウェア、Electronアプリ、管理画面のフロントエンド、CIで生成した同梱バイナリまで、同じ製品名の下でまとめて扱う。
依存マニフェストだけを集めても、ベースイメージやOSパッケージ、静的リンクされたライブラリが抜ける。

サプライチェーン記事で追ってきたnpm汚染は、主に「インストール時に何が走るか」の話だった。
CRAのEOL問題では、実行時に侵害されたかどうかより前に、「出荷した製品の中にその部品がある」と短時間で言えるかが問われる。
たとえばnpmなら package-lock.json や pnpm-lock.yaml、コンテナならイメージダイジェスト、OSならパッケージ一覧、組み込みならファームウェアのビルド成果物を、製品バージョンへ結びつけておく。

ここでNVDのCPEだけに頼ると、前に書いた通り Deferred やCPE未付与のCVEで拾えない。
GHSAやOSVのパッケージ名、ベンダーアドバイザリ、ディストリビューションのセキュリティトラッカー、EUVDの悪用状態を別経路で当てる。
「CVEがあるか」ではなく、「この製品ビルドの部品に、悪用確認済みまたは重大インシデントに関係する情報が入ったか」で判断する。

支援ベンダー記事として読むときの注意点

今回のDEV Community記事は、endoflife.aiが自社のEOLデータベースやAPIへつなげる記事でもある。
そのため、挙げられている部品と日付は判断材料になるが、組織の規制対応と外部サービスの導入は別の判断になる。

CRAで先に固定されているのは、日付と報告期限だ。
2026年9月11日、24時間、72時間、脆弱性では修正または緩和策の利用可能後14日、重大インシデントでは72時間通知後1か月。
それに対して、EOL管理の実装は組織ごとに分かれる。
既存のSCA、コンテナスキャン、SBOM生成、社内CMDB、リリース台帳、顧客向けサポート期間の表示をつないで、悪用情報を受けたときに製品単位で判断できるかを確認する。

製品がEU市場に提供されていない自社利用専用ツールは、原則として「市場への提供」に当たらず、CRAの直接対象ではない。
一方で、EU向けに販売するハードウェア、デスクトップアプリ、モバイルアプリ、組み込みソフト、接続機器、管理用ソフトを含む製品では、販売元がEU外でも対象になりうる。
独立したSaaSやクラウドサービスは、それだけで「デジタル要素付き製品」になるわけではない。ただし、製造者が設計・開発し、それがなければ製品の機能を果たせないリモートデータ処理は製品の一部としてCRAの対象になる。
医療機器・体外診断用医療機器、対象となる自動車、認証済み航空製品、舶用機器、同一仕様の交換部品、国家安全保障・防衛専用製品など、Article 2が除外する製品もある。
OSS steward（OSSの継続的支援主体）はArticle 24の対象で、開発に関与する範囲のactively exploited vulnerabilityと、OSS開発用に自ら提供するネットワーク・情報システムに影響する重大インシデントを報告する。

Article 64は、Annex Iの必須サイバーセキュリティ要件とArticle 13・14の義務違反について、最大1,500万ユーロまたは全世界年間売上高の2.5%の高いほうを上限とする行政罰を置いている。
ただし、microenterprise（零細企業）とsmall enterprise（小企業）は24時間の初期警告期限違反について行政罰の対象外で、OSS stewardはCRA違反の行政罰対象外になる。報告義務自体がなくなるという意味ではない。
2026年9月11日までに、どの製品に何が入っているか、上流サポートが切れている部品をどう扱うか、悪用を把握したとき誰がSRPへ出すかを、製品チームとセキュリティチームが同じ一覧で共有しておく。