サイバーレジリエンス法がハードウェアに問うもの

二つの日付、そして近いほうが見落とされる

規則 (EU) 2024/2847、いわゆるサイバーレジリエンス法（Cyber Resilience Act、CRA）は、EU 市場で提供される「デジタル要素を持つ製品」を対象とします。実務的にはファームウェアを積んだものすべてであり、民生機器と家庭用ヘルスケア機器では、今日出荷されているほぼ全部が該当します。

多くの計画資料に載っている日付は一つです。2027 年 12 月 11 日。完全適合が求められ、適合しない製品は市場に投入できなくなります。ロードマップはこの日に向けて引かれています。

先に来るのはもう一方です。2026 年 9 月 11 日、第 14 条の報告義務の開始日。これが見落とされるのは、製品設計の期限ではないため、ハードウェアの工程表に載らないからです。

載せるべきです。理由は以下のとお⁠り⁠で⁠す⁠。

報告の時計は過去にさかのぼる

2026 年 9 月 11 日以降、製造者が自社製品に現に悪用されている脆弱性があること、またはセキュリティに影響する重大インシデントが発生したことを知った場合、段階的な時計が動き出します。

段階	認知からの期限
早期警告	24 時間
技術的通知	72 時間
最終報告	14 日（悪用されている脆弱性）／1 か月（重大インシデント）

提出先は ENISA と該当国の CSIRT です。

二度読むべき部分はここです。**報告義務は、すでに EU 市場で提供されている製品に適用されます。**期限より前に投入された個体も含みます。附属書 I の設計要件は 2027 年 12 月 11 日以降に投入される製品に及び、それ以前の製品には実質的な変更があった場合にのみ及びます。報告義務にはこの区切りがありません。

したがって 2026 年 9 月にブランドが答えるべき問いは、もはや「次の製品は適合しているか」ではありません。こうな⁠り⁠ま⁠す⁠。

2023 年に出荷した機器で脆弱性が現に悪用されている。24 時間以内に把握できるか。そして中身を、問題を説明できるだけ把握しているか。

多くのハードウェアブランドにとって、後半への正直な答えは「いいえ」です。それはセキュリティの問題である前に、製造記録の問題です。

→ 筐体の設計判断に変わるもう一つの EU 期限：EU 電池規則 2027：取り外せる電池

サポート期間は部品表の判⁠断⁠で⁠あ⁠る

附属書 I は最低五年のサポート期間の宣言を求めます。想定使用期間がそれより短ければその期間となり、終了日は購入時点で買い手が知っている必要があります。その期間、製造者は脆弱性に対応し、セキュリティパッチを無償で提供します。

これは調達上の制約として読んでください。実際そうだからです。

設計に使う無線モジュールがベンダー SDK の上で動いていて、その SDK が三年目にセキュリティパッチを受け取らなくなれば、その上に載るものにパッチを当てられません。販売時点で五年のサポートを宣言しておきながら、三年目にそれを守る能力を失う。原因は部品選定段階の判断です。

そこで、価格・リードタイム・第二調達先と並んで、二つの問いがモジュール選定に加わります。

• **このベンダーはこの部品に何年間セキュリティパッチを出すのか。**書面で。そして供給終了時はどうなるのか。
• **移行先になりうるスタックを走らせる第二調達先はあるか。**そのとき基板を作り直さずに済むか。

どちらも通常は部品表レビューに載りません。しかし供給リスクと同じ会話に属します。同じ種類のリスクだからです。部品が使えなくなる。一方は商業的に、もう一方は法的に。

→ 部品をどう等級づけするか、そして赤が出たときに何を意味するか：OEM 案件の部品供給リスク・マトリクス

SBOM は中身を実際に記述しなければならない

附属書 I 第 II 部は、広く使われている機械可読形式のソフトウェア部品表を求め、少なくとも第一階層の依存関係を対象と⁠し⁠ま⁠す⁠。

ウェブアプリケーションならビルドツールの出力です。物理製品では組立の問題になります。ファームウェアがすべて自社製であることはまずないからです。典型的な接続型民生機器には次のものが入って⁠い⁠ま⁠す⁠。

• この製品のために書かれたアプリケーションファームウェア
• 無線モジュールに同梱されて届いたベンダー製の SDK
• バイナリで提供されるプロトコルスタック（Bluetooth、Wi-Fi、Thread）
• リアルタイム OS
• 上記のいずれかが引き込んだオープンソースライブラリ

ブランドが所有しているのは通常は最初の一つだけで、残りは見えていません。工場とそのモジュール供給者を経由して入ってきたものだからです。実効性のある SBOM を組み立てるとは、工場に尋ね、工場からその供給者に尋ねてもらうことです。

この依頼は、インシデント発生後よりも開発中のほうがはるかに安く済みます。同時に、モジュールメーカーが自社バイナリの中身を開示するかどうかも分かります。設計に組み込む前に知っておきたい情⁠報⁠で⁠す⁠。

既定で安全であること、そして更新を受け取れること

附属書 I の要件のうち二つは、ハードウェアのごく初期の判断に降りてきます。

既定で安全とは、製品が安全な設定で出荷されることです。共通の初期パスワードがない、不要なサービスや開放ポートがない、攻撃面が最小化されている。これらはファームウェアの既定値であり、既定値を決めるのは通常ファームウェアを書く側です。それが受託製造側であれば、実装は先方の仕事、仕様化はこちらの仕事にな⁠り⁠ま⁠す⁠。

サポート期間中の無償セキュリティ更新は、製品が更新を受け取れることを前提とします。受け取れるかどうかはソフトウェアの判断ではありません。

• **フラッシュ容量。**安全な無線更新のための二面構成は、ファームウェアの必要容量をおおむね倍にします。部品表の凍結後に気づけば、メモリ変更か無線更新の断念しか残りません。
• **通信手段。**インターネットへの経路がない機器は、現地作業かコンパニオンアプリでしか更新できません。どちらも完了率は、五年の義務が前提とする水準をはるかに下回ります。
• **電力。**残量が少ない状態で走って機器を使用不能にする更新は、更新しないより悪い。だから更新ロジックには電力の下限が要り、そのためには残量計が要⁠り⁠ま⁠す⁠。

いずれも後付けは安く済みません。いずれも金型を切る前の技術審査で決まります。

→ こうした制約が表に出る審査：金型を切る前の DFX リスク審査

案件で実際に変わること

いま開発に入り、EU に売る製品では、三つのことが変わります。

1. **モジュール選定にパッチ提供年数の問いが加わる。**ベンダーのセキュリティ支援の約束を書面でもらい、「公表していません」という返答をその通りの答えとして扱うこと。
2. **SBOM が納入物になる。**図面や試験報告書と並べて開発契約に明記し、24 時間の時計の下で再構築するのではなく製品とともに届くようにすること。
3. **更新可能性を金型の前に仕様化する。**フラッシュの余裕、パーティション構成、更新経路は、構想段階なら安く、筐体ができてからは高くつきます。

すでに市場にある製品については、当面の問いはもっと狭く、もっと急ぎます。中に何が入っているか調べられるか。どれくらいの速さで。

適用範囲についての注記

これは公表された法令の読み方であり、法的助言ではありません。CRA の実施細目は規格やガイダンスを通じて今も補われている最中です。これを土台に計画を立てる前に、自社の製品区分と対象市場への適用について、有資格の法務に確認してください。設計の前提にできる程度に定まっているのは方向性です。セキュリティ支援は宣言され日付の入った約束になり、それを可能にも不可能にもする判断は、ハードウェア側で、しかも早い段階で行われます。

→ 基板レベルの詳細、回路図から SMT ラインまで：民生用電子機器の受託製造