サイバーレジリエンス法：2026年9月11日は本物の期限

多くのEU規則は、適合日と、その間に皆が静かに態勢を整える移行期間を与えてくれます。サイバーレジリエンス法は違います。最初の強い義務は 24時間の通報の時計 で、それは2026年9月11日に動き出します。

24時間の時計は段階的に導入できません。その日にプロセスが存在するか、間に合わないかのどちらかです。

サイバーレジリエンス法とは何か

規則(EU)2024/2847は、EU市場で提供される デジタル要素を持つ製品 にサイバーセキュリティ要件を課します。この用語が覆う範囲は最初に思うよりずっと広い。意図された用途または合理的に予見可能な用途に直接または間接のデータ接続を含む、あらゆるソフトウェアまたはハードウェア製品と、その遠隔データ処理ソリューションです。

コネクテッド機器は範囲内です。商用ソフトウェアの大半、OS、ブラウザ、モバイルアプリ、ファームウェア、そして他の製品の中にある部品も同じです。

規則は2024年11月に公布され、段階的に適用されます。

• 2026年6月11日：適合性評価機関の義務。
• 2026年9月11日：実際に悪用されている脆弱性と重大インシデントの通報義務。
• 2027年12月11日：全面適用。必須サイバーセキュリティ要件、CEマーキング、技術文書、ソフトウェア部品表を含む。

計画の基準にすべきは真ん中の日付です。先に来るからであり、あなたがまだ持っていないかもしれない能力に依存するからです。

2026年9月11日に何が起きるか

その日から、製造者は次を通報しなければなりません。

デジタル要素を持つ製品における 実際に悪用されている脆弱性、および

それらの製品のセキュリティに影響する 重大インシデント。

通報はENISAが運営するサイバーレジリエンス法の単一通報プラットフォーム経由で、製造者の主たる事業所がある加盟国の指定CSIRTへ提出され、そこから他の関係CSIRTとENISAへ共有されます。

タイムライン：

• 認知から24時間以内：早期警告。
• 72時間以内：本通報。実施した是正または緩和措置を含む。
• 是正措置が利用可能になってから14日以内：実際に悪用された脆弱性の最終報告。
• 1か月以内：重大インシデントの最終報告。

認知から24時間であって、確認からでも、修正からでもありません。製品内の部品の脆弱性が土曜に実環境で悪用されたなら、時計は土曜に動きます。

なぜ見た目より難しいのか

通報義務そのものはフォームです。難しいのは、それを記入できるようになるまでに用意しておくべきすべてです。

製品の中に何が入っているかを知っている必要がある

製品内の脆弱性が実際に悪用されていると通報するには、その脆弱な部品が自社製品の中にあることを知っていなければなりません。数百の推移的依存を持つ現代のアプリケーションについて、これは人が記憶で答えられる問いではありません。

だからチームは、2027年12月の正式なSBOM要件より1年以上前のいま、ソフトウェア部品表のパイプラインを作っています。SBOMは目的ではありません。目的は「これは自分たちに関係するか」に数時間で答えられることで、SBOMはその問いを答えられるものにするものです。

厄介なのは、これが何年も前に出荷した製品にも当てはまることです。誰も記録しなかった依存ツリーから2022年にビルドしたファームウェアの、サポート中の機器が稼働しているなら、それを再構成するのは本物の作業です。

監視している必要がある

認知が時計を動かし、その認知は偶然ではなく能動的であることが期待されます。つまり脆弱性の情報源を監視し、使っている部品のアドバイザリを購読し、既知悪用脆弱性のカタログを追い、セキュリティ研究者があなたに到達して返答を得られる経路を持つことです。

意思決定の経路が必要

一日のどの時間でも、あるインシデントが閾値に達しているか、時計が動き出したかを判断できる人がいなければなりません。指名された役割とエスカレーション経路がなければ、最初の数時間は誰が判断できるのかを探すことに費やされます。

サポートのない依存は負債になる

製品内の部品がセキュリティ更新を受けなくなっても、それが悪用されたときの通報義務は残り、指し示せる上流の修正はありません。サポートのない依存の棚卸しは準備段階で最も有用な作業のひとつです。答えが、それ自体のリードタイムを持つ移行を前倒しさせることがあるからです。

2027年12月の全面適用が持ち込むもの

2027年12月の義務はより大きなプログラムで、ずっと前から始める必要があります。

設計によるセキュリティとデフォルトのセキュリティ。 製品は、リスクに基づく適切なサイバーセキュリティ水準を確保するように設計、開発、製造されなければなりません。既定のパスワードなし。箱から出した状態で安全な構成。攻撃面の最小化。転送中と保存時のデータ保護。

脆弱性の取り扱い。 特定、是正、テスト、配布、開示を含む文書化されたプロセス。セキュリティ更新は遅滞なく無償で提供されなければならず、サポート期間は製品の想定寿命を反映し、5年が一般的な参照値です。

ソフトウェア部品表。 機械可読な形式で、少なくとも最上位の依存を網羅し、最新に保つこと。

技術文書と適合性評価。 多くの製品は自己評価です。パスワードマネージャー、VPN、OS、産業用制御システムなどを含む重要および重大なカテゴリは第三者の関与を要します。

CEマーキング。 適合を宣言する物理的な標識のデジタル版。

協調的脆弱性開示のポリシー。 公開されており、実際に機能する連絡先があること。

実際に誰が範囲内なのか

いくつかの境界事例が繰り返し出てきます。

商業活動の外で開発された自由およびオープンソースソフトウェア はおおむね範囲外です。規則はオープンソースソフトウェアのスチュワードという概念を導入し、より軽い義務を課します。ただし、オープンソースを商業化したり、販売する製品の中に同梱したりするなら、製品の義務はあなたのものです。

サービスとしてのソフトウェア は一般にサイバーレジリエンス法の範囲外で、むしろNIS2の下に入ります。ただしデジタル要素を持つ製品と統合された遠隔データ処理ソリューションは引き込まれます。機器が動くのにクラウドのバックエンドが必要なら、そのバックエンドは製品と一緒についてきます。

輸入者と流通業者 も義務を負います。第三者の製品を自社の名称や商標でEU市場に出すなら、製造者として扱われます。

すでに他で規制されている製品、医療機器、車両、航空機器などは、それぞれの枠組みで扱われます。

適用範囲の問いは実際には自明ではなく、ここは弁護士と1時間過ごすことで、方向を誤った開発の数か月が浮く場所です。

残された時間で私たちがすること

範囲内でいまから始めるなら、この順序が機能します。

まず、製品台帳を作る。 EU市場に実際に何を出しているか。まだ稼働している旧バージョン、ホワイトラベルの派生、他社のために流通させている製品も含めて。このリストはたいてい誰の予想より長くなります。

次に、SBOM生成をCIに組み込む。 ビルドごとにSBOMを生成し、CycloneDXまたはSPDX形式で、リリース成果物と一緒に保存し、検索可能に保つ。目的は「出荷済みのどのリリースにこのライブラリが含まれているか」と問えて数分で答えが返ることです。

次に、脆弱性の監視をつなぐ。 SBOMのデータを、アドバイザリと既知悪用脆弱性カタログを追うスキャナに流し、アラートを誰かが読むチャンネルへ送る。

次に、インシデント対応の手順書を書く。 誰が宣言し、誰が評価し、誰が通報し、誰が対外的に伝えるか。名前のある担当、代理、時間外の連絡先。それから架空のアドバイザリで一度演習する。通報プラットフォームのアクセス権を持つ人が休暇中だと気づくのは、演習の中です。

次に、脆弱性開示ポリシーを公開する。 security.txtファイル、監視されているアドレス、公表した応答時間。半日の作業で、問題を研究者から聞くか記者から聞くかの差になります。

最後に、2027年12月に向けた作業を始める。 安全な既定値、更新メカニズム、サポート期間の決定、文書化は、書類仕事ではなくアーキテクチャの問題です。2026年に設計する製品は2028年にもまだ市場にあります。

誰も使っていない重なり

サイバーレジリエンス法と他の制度の間には相当な重複作業があり、多くの企業はそれぞれ別々に対応していて、それは無駄です。

サイバーレジリエンス法のために作ったSBOMは、NIS2 のサプライチェーンの問いの大半に答えます。インシデント手順書はNIS2の24時間早期警告と GDPR の72時間侵害通知と重なります。脆弱性取り扱いのプロセスは、顧客のセキュリティ質問票と大企業の調達に直接流れ込みます。

これをプラットフォームの能力として一度作ってください。代替案は、三つのチームが同じ資産台帳の三つのバージョンを作ることです。

助けを得るには

私たちはEUに販売する企業向けにソフトウェアを構築・保守しており、それはますます、サイバーレジリエンス法が前提とするサプライチェーンの可視性と更新の基盤を作ることを意味します。範囲内かどうかを整理しようとしている場合や、9月の日付がカレンダーにあるのに監視がない場合は、office@c9group.dev までご連絡ください。

レガシーシステム保守サービスがこの出発点になることが多いのは、依存の可視性が最も悪い製品はたいてい最も古いものだからです。規制の全体像は2026年EUデジタル規制ガイドにあります。

私たちはエンジニアであって弁護士ではありません。適用範囲と分類の判断はあなたの弁護士のもので、私たちはその答えに沿って作ります。