正常に動くチップで、何を追加確認するのか
出荷前の試験記録をその後の保守に活用する方法を、本稿の管理案として示します。本稿の仮想例では、設計チームが鍵へのアクセスや起動・更新時の拒否動作を試験し、対象版と条件を記録します。本稿では、試験記録を完成品の版と結び付け、影響調査や配布先の判断に使う管理案を示します。
設計チームは、ネットワークで測定値を送る架空の温度センサーを想定します。搭載するMCU（機器の計算や制御を担う小型チップ）が、温度を計算し、鍵を使ってデータを読めない形にする暗号化処理も正しく行えているとします。
この正常動作の確認で分かるのは、想定した測定や暗号化の動作です。設計チームは、権限のないプログラムが鍵を読み出せるかを追加で確認します。出荷時のデバッグ端子（機器内部の動作を調べる接続端子）の設定や、改変した起動・更新データを拒否する条件も確かめます。
設計チームは、仕様にセキュリティ条件を含め、機能検証（仕様どおりに動くかを確かめる試験）でも拒否動作を試験できます。課題は、正常な操作を想定した仕様確認に、想定する攻撃、試験対象の版、出荷後の担当をどう加えるかです。ここで示す試験は、この架空機器の使用条件を踏まえた説明用の例です。製造者は、製品ごとに適用範囲と要件を確認し、法令適合を判断します。
EUのサイバーレジリエンス法（Cyber Resilience Act、CRA）の対象は、デジタル要素（データを扱うハードウェアやソフトウェアなど）を備え、商業活動としてEU市場に供給される製品です。製造者は、製品が意図する使い方や、合理的に予測できる使われ方に、機器やネットワークへの直接・間接のデータ接続が含まれるかどうかも確認します。製造者は、チップの接続形態（直接接続か、接続可能なシステムを介した間接接続か）と製品の供給条件を確認します1。欧州委員会の製造者向け説明
脅威、対策、試験、版を結び付ける
CRAは、使用条件や保護する資産（鍵や利用者データなど）を踏まえたリスク評価を求めます。リスク評価では、想定する攻撃や被害の大きさを見積もり、結果を文書化します2。附属書Iの要件には、権限外アクセスの防止と、許可されていない改変からの完全性保護が含まれます。完全性とは、データやプログラムが不正に変えられていない状態です3。
脆弱性は、攻撃者に悪用される可能性がある製品の弱点です。製造者は、製品の設計や試験、適合状況を記録する技術文書を作成します。製造者は、製品の識別情報や適合に影響するソフトウェア版を記載します。製品そのものの試験報告と、脆弱性に対応するプロセスの試験報告も、この文書に含めます4。どのハードウェア版や設定と試験結果を対応付けるかについて、本稿では製品のリスクや構成を踏まえて設計する方法を提案します。
ENISA（欧州連合サイバーセキュリティ機関）の公式手引きは、実務の出発点となる考え方を示します。法的助言や、遵守を保証する網羅的なチェックリストではありません。
固定版の手引き01は、信頼してよい領域の境界と脅威を整理し、対策を検証と対応付ける方法を説明しています。手引き01は、権限外アクセスを試みたときに拒否するかを確かめる試験や、出荷判断に必要な記録も推奨しています。
ファームウェアは機器を制御するソフトウェアです。温度センサーの設計チームなら、次のように記録を作ることが考えられます。
- 想定：アプリから鍵を読み出す経路、開発用端子、起動・更新データを扱う経路を整理します。
- 対策：鍵へのアクセス権、出荷時の端子設定、起動・更新データの検証条件を決めます。
- 試験：許可した操作と拒否すべき操作について、条件、期待する動作、実際の結果を残します。
- 対象版：チップの設計版、機器のファームウェア版、設定、試験記録の対応を残します。
- 出荷判断：未解決の問題、対応する担当、完成品側へ渡す情報を確認します。
たとえば「チップ設計版A・ファームウェア1.2・出荷設定Xで試験した」という記録が、完成品のどの出荷版に対応するかまで分かるようにします。これは架空の製品構成を使った管理案です。
EE Timesの論評が扱う「セキュリティ上の最終承認（security sign-off）」は、こうした出荷判断を考える設計実務上の表現です。設計チームは、製品が必須要件を満たすかを確認する法定手続きである適合性評価と、社内で設ける出荷判定の関門を区別して扱います。
チップの供給者と完成品メーカーの責任
CRA上の製造者は、自ら開発・製造した製品、またはそれらを委託した製品を、自社名や商標で供給する者です5。再利用可能な回路設計データである半導体IPの提供者や受託製造者についても、供給する製品と名義などを確認します。
以下の部品分類は、部品が別個に市場へ供給され、CRAの適用対象となる場合を前提にしています。製造者は、完成品の中核機能に基づいて、その製品のCRA上の区分を判断します。6 中核機能は、製品が中心的に担う機能です。
MPUは演算用のマイクロプロセッサです。ASICは特定用途の集積回路、FPGAは回路構成を変更できる集積回路です。セキュアエレメントは、暗号鍵などの重要情報を保存・処理する専用部品です。指定認証は、所定のEUサイバーセキュリティ認証を指します。
自己評価は、製造者が必須要件との適合を確認する方式です。以下は所定の技術定義を満たす製品の例です。欧州委員会の評価経路の説明と実施規則2025/2392で、製品自身の機能と条件を確認します。
| 区分 | 半導体の例 | 評価経路の要点 |
|---|---|---|
| 通常区分 | 重要製品・クリティカル製品に該当しないメモリチップなど | 製造者による自己評価を利用可能 |
| Class I・重要製品 | チップ外も保護する所定のセキュリティ機能付き演算・制御チップなど | 規格等を必要範囲に適用する条件で自己評価。それ以外は第三者評価など |
| Class II・重要製品 | Class Iのセキュリティ機能と、所定の改ざん耐性・保護水準を満たすMPU・MCU | 自己評価の経路はなく、第三者評価など |
| クリティカル製品 | 所定の高い保護設計を満たすセキュアエレメント | 指定認証が適用される場合はその経路。それ以外はClass II相当の厳しい経路 |
通常のメモリチップは自己評価を使える製品例です。自己評価でも、必須要件への適合と技術文書は必要です7。Class Iには、所定のセキュリティ機能を持つMPU・MCU・ASIC・FPGAが該当し得ます。製造者は、チップの外にある製品・ネットワーク・サービスも保護する所定の機能に基づいて、Class Iへの該当性を判断します8。
Class Iでは、整合規格、共通仕様（EUが定める共通の技術要件）、利用可能で適用可能なEU認証スキーム（EU共通の認証制度）などを所定の範囲で適用する条件を確認します。整合規格はEU法令への適合性の推定に使う規格です。自己評価の条件を満たさない要件には、EU加盟国が指定する評価機関による評価などが必要になります9。製造者は、認証経路を利用可能性や適用条件も含めて判断します。
完成品メーカーは、欧州委員会の説明に沿って、統合する第三者部品について相応の確認を行います。自社製品全体の脆弱性対応は、サポート期間（製造者が脆弱性対応を担う期間）中、組み込み部品にも及びます10。部品の適合宣言（法令要件への適合を製造者が示す文書）や技術文書は、完成品メーカーの判断材料です。完成品メーカーは、自社製品への統合によるリスクに応じて、確認方法を選びます。
版の記録を、影響製品の特定と更新へ使う
完成品メーカーが同じMCUを複数の完成品に搭載しているとします。完成品メーカーが、供給者から特定の版に脆弱性があると知らされたとします。この仮想例で構成情報が不足した場合、完成品メーカーは影響製品や配布先の調査に手間を要する可能性があります。完成品メーカーは、版の対応記録を手掛かりに、製品識別子や出荷・配布記録を照合して対象を調べます。
部品側の設計・保守担当は、影響する版や修正・緩和策（悪用による影響を抑える対策）を説明します。完成品メーカーは、自社製品の構成記録と照合し、影響する出荷版を調べて、統合後の修正と再試験、利用者への更新を計画します。これは担当分担を説明する架空の流れです。
完成品メーカーが組み込み部品の脆弱性を特定した場合は、その部品を製造・保守する者へ報告し、自社製品で対処します。完成品メーカーは、該当する場合、適用した修正を部品の保守者へ共有します11。
ENISAの手引き13は、問題の受付、担当、修正、試験、リリース版、配布確認を結び付ける管理を説明しています。手引き20は、更新を導入する前の配布元と改変の有無の確認、更新に失敗した場合に危険な状態へ移らない処理などを推奨します。
製造者は、必要なときに機器を使える状態（可用性）や安全性を踏まえ、管理者の承認や段階配布（対象機器を分けて順に更新する方法）も検討します。本稿では、電子署名（データの作成元と改変の有無を確認する仕組み）を採用する場合の設計例を示します。製造者は、信頼する配布元と署名検証鍵（署名を検証する鍵）の対応を確認してから、署名と改変の有無を検証します（信頼の考え方の例（RFC 5280））。プログラムの動作は、試験した構成と条件の範囲で確認します。
後輩合格記録は、将来の欠陥がゼロである証明にはならないわけですね。
先輩試験した範囲の証拠として使い、出荷後の情報も受け付けて、修正や再評価へつなげるんだ。
日程と保守期間は、別々に確認する
CRAは2024年12月10日に発効しました。報告義務は2026年9月11日から既に適用され、主要な製品適合義務は2027年12月11日に適用されます12。出荷前の記録と、問題を受け付けて判断する担当の整備は、期限への対応にも関わります。
サポート期間は予想使用期間を反映し、原則として最低5年です。予想使用期間が5年未満の場合も、サポート期間は少なくともその予想使用期間以上とします13。製造者は、技術文書とEU適合宣言（EU法令への適合を製造者が宣言する文書）を保存します。保存期間は、製品がEU市場に初めて供給された時点から10年間と、サポート期間の終了までのうち長い方です。技術文書とEU適合宣言の保存期間は、脆弱性対応を担うサポート期間とは別に定められています。CRA原規則
製造者が悪用されている脆弱性、または製品セキュリティに影響する重大インシデントを認知した場合、24時間以内の早期警告、72時間以内の通知が必要です。最終報告は、脆弱性では是正・緩和策が利用可能になってから14日以内、重大インシデントでは72時間通知後1か月以内です14。
製造者は、市場投入前に法定の適合性評価を行います。出荷後は、試験・レビューと脆弱性対応を続けます。対象版の記録を修正対象の調査に使う方法は、本稿の管理案です。
