# EUサイバーレジリエンス法（CRA）と組込み機器｜STM32での実務対応ガイド｜株式会社テクノスフィア

> EUサイバーレジリエンス法（CRA）の対象判定・クラス分け・2026年9月11日開始の脆弱性報告義務を整理し、STM32のRDP・セキュアブート・TrustZone・SBOM作成まで組込みエンジニア向けに実務対応を解説。組込み受託開発20年超のテクノスフィアが解説。

URL: https://technosphere.co.jp/blog/embedded-cra-compliance-stm32

** 目次
1. はじめに：なぜ「いま」CRAなのか
2. CRAの適用スケジュール（期日の全体像）
3. 自社製品はCRA対象か？ 判定フロー
4. クラス分け：default / important / critical
5. 2026年9月11日までにやるべきこと：脆弱性報告体制
6. 2027年12月11日に向けて：必須要件（附属書I）の概観
7. STM32での技術対応：RDP・セキュアブート・TrustZone・更新機構
8. SBOMの現実的な作り方
9. FreeRTOS・ZephyrなどOSS利用時の扱い
10. 実務チェックリスト
11. まとめ

## はじめに：なぜ「いま」CRAなのか

 **EUサイバーレジリエンス法（Cyber Resilience Act / CRA、Regulation (EU) 2024/2847）**は、EU市場に上市される「デジタル要素を持つ製品（products with digital elements）」に対して、設計段階からのセキュリティ確保（セキュリティ・バイ・デザイン）と、販売後の脆弱性対応・報告を法的義務として課すEU規則です。2024年12月10日に発効済みで、対象製品は最終的に**CEマーキングの要件としてサイバーセキュリティ適合が求められる**ようになります。

 重要なのは、これが「EU企業の話」ではないことです。CRAは**EU市場に製品を上市するすべての製造者**に適用されるため、日本からEUに機器を輸出しているメーカーも当事者です。そしてマイコン1個で動く計測器・産業用コントローラ・IoTセンサーノードのような、これまで「セキュリティ規制とは無縁」だったB2B組込み機器の多くが対象に含まれます。

 特に急ぐべき理由が期日です。**2026年9月11日から、第14条の脆弱性・インシデント報告義務が適用開始**されます。本記事執筆時点（2026年7月）で残り2か月。しかもこの報告義務は、後述のとおり**すでにEUで販売中の既存製品にも適用**されます。「2027年12月の全面適用まで時間がある」という理解は、この点で誤りです。

 本記事では、法律の一般論ではなく「STM32ベースの製品を持つ組込みエンジニア・品質保証担当が、何を・いつまでに・どうやるか」に絞って解説します。STM32のRTOS開発の基礎は [STM32 + FreeRTOS 入門](https://technosphere.co.jp/blog/stm32-freertos-intro)、通信ペリフェラルの実装は [STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can) も併せてご覧ください。   ** 免責事項（必ずお読みください）

本記事は組込み開発の実務者向けに、規制原文の該当条項と実務での一般的解釈を整理した技術解説であり、**法的助言ではありません**。条文の解釈には幅があり、整合規格・ガイダンスも今後更新されます。自社製品の該当性・適合方針の最終判断は、必ず**弁護士（EU法務）や認証機関・Notified Bodyに確認**してください。

## CRAの適用スケジュール（期日の全体像）

CRAは段階適用です。エンジニアリング計画に直結するため、まず期日を正確に押さえます（第71条）。
| 期日 | 何が起こるか | 実務への意味 |
|  **2024年12月10日** |  CRA発効（entry into force） |  規則として成立済み。猶予期間中 |
|  2026年6月11日 |  適合性評価機関（Notified Body）の通知に関する章が適用開始 |  第三者評価の受け皿が立ち上がる |
|  **2026年9月11日** |  **第14条：脆弱性・インシデント報告義務が適用開始** |  積極的に悪用された脆弱性・重大インシデントの24時間以内の早期警告等。**既存製品にも適用** |
|  **2027年12月11日** |  残りの主要義務が全面適用 |  セキュリティ・バイ・デザイン（附属書I）、SBOM、サポート期間、適合性評価＋CEマーキング。以降に上市する製品はフル対応必須 |

### 既存製品の扱い（第69条）— 実務上の最重要ポイント

経過措置（第69条）は次の構造です。
- **第69条2項：**2027年12月11日より前に上市済みの製品は、それ以降に**大幅な改変（substantial modification）**を行わない限り、CRAの要件の対象外（次項の第14条報告義務を除く）
- **第69条3項：**ただしその**例外として、第14条の報告義務は上市済み製品にも適用**される

 つまり「古い製品だから関係ない」は報告義務については通用しません。逆に、ファームウェアの大幅な機能追加は「大幅な改変」として既存製品を丸ごとCRAの適用対象に引き込む可能性があるため、2027年12月以降の既存製品のアップデート計画は法務と併せて設計する必要があります（何が「大幅な改変」に当たるかはガイダンスの解釈が分かれる領域です）。

なお、違反時の制裁金は必須要件違反で**最大1,500万ユーロまたは全世界年間売上高の2.5%のいずれか高い方**（第64条）と、GDPR同様の域外企業にも効く水準です。

## 自社製品はCRA対象か？ 判定フロー

CRAの対象は「デジタル要素を持つ製品」＝**ハードウェアまたはソフトウェアであって、デバイスやネットワークへの直接的または間接的な論理的・物理的データ接続を持つもの**（第2条・第3条の定義）です。実務では次の順で判定します。
1. **EU市場に上市（placing on the market）するか？**
EU域内の顧客・代理店経由で販売するならYes。日本国内専用モデルは対象外。ただし同一ファームをEU向けと共用しているなら実質的に対応が必要です。
2. **デジタル要素とデータ接続があるか？**
マイコン搭載機器はほぼ該当します。Ethernet/Wi-Fi/BLEはもちろん、**USB・UART・CANなどのローカル接続も「デバイスへの接続」**に含まれ得るというのが一般的な解釈です。スタンドアロンで一切の外部接続を持たない機器のみが外れます。
3. **他のEU法制の適用除外に該当するか？**
医療機器（MDR/IVDR）、自動車（型式認証規則）、航空、船舶用機器など、既にサイバーセキュリティ要件を持つセクター規制の対象製品はCRAから除外されます（第2条）。産業機器は多くの場合除外に該当せず、CRA対象です。
4. **純粋なサービス（SaaS）か？**
クラウドサービス単体はNIS2の領域ですが、製品の機能に不可欠な「遠隔データ処理（remote data processing solutions）」は製品側のCRA適用範囲に含まれます。機器＋専用クラウドの構成は要注意です。
  ** 実務の勘所

迷いやすいのは「B2Bの産業機器」「モジュール・基板単体での販売」です。CRAは消費者製品に限定されず**B2B製品も対象**です。また、他社製品に組み込まれる部品（マイコンボード等）を上市する場合、その部品自体が「デジタル要素を持つ製品」として義務を負い得ます。自社が「最終製品メーカー」なのか「コンポーネント供給者」なのかで負う義務の整理が変わるため、この線引きこそ認証機関・法務への確認事項です。

## クラス分け：default / important / critical

CRA対象と判定されたら、次は製品カテゴリの確認です。カテゴリによって適合性評価の重さが変わります。
| カテゴリ | 根拠 | 例 | 適合性評価 |
|  **default（デフォルト）** |  附属書III/IVに該当しないすべて |  一般的な産業機器、計測器、IoTセンサー、家電の大半 |  **自己適合宣言（内部管理、モジュールA）**が可能 |
|  **important Class I** |  附属書III Class I |  OS、ブートマネージャ、VPN機能を持つ製品、パスワードマネージャ、スマートホームのセキュリティ機器、**セキュリティ関連機能を持つマイクロコントローラ／マイクロプロセッサ** など |  整合規格に完全準拠すれば自己適合宣言可。そうでなければ第三者評価 |
|  **important Class II** |  附属書III Class II |  ファイアウォール・IDS/IPS、ハイパーバイザ、**耐タンパー性マイクロコントローラ／マイクロプロセッサ** など |  第三者（Notified Body）評価が必須 |
|  **critical（重要）** |  附属書IV |  セキュリティボックスを備えたハードウェア、スマートメーターゲートウェイ、スマートカード・セキュアエレメント |  将来的に欧州サイバーセキュリティ認証（EUCC等）の取得を義務付け得る |

 「マイコンが附属書IIIに載っている」と聞いて驚くかもしれませんが、これは**セキュリティ関連機能を持つMCU/MPUそのものを上市する半導体メーカー等に向けた分類**です。STM32を「使った」最終製品の分類は、最終製品の機能・用途で判定します。一般的な産業機器・計測機器の多くは**defaultカテゴリに落ち、自己適合宣言で対応可能**というのが現時点の一般的な整理です。なお、各カテゴリの技術的定義は実施規則（Commission Implementing Regulation (EU) 2025/2392、2025年12月発効）で定められているため、境界事例は必ず同規則と最新ガイダンスで確認してください。

## 2026年9月11日までにやるべきこと：脆弱性報告体制

第14条が求めるのは、次の2種類の事象の報告です。
- **積極的に悪用されている脆弱性（actively exploited vulnerability）：**自社製品に含まれる脆弱性で、実際に悪用されている信頼できる証拠があるもの
- **製品のセキュリティに影響する重大インシデント（severe incident）：**製品がデータや機能の機密性・完全性・可用性等を保護する能力に悪影響を与える（与え得る）インシデント

### 報告のタイムライン（第14条）
| 期限 | 提出物 | 内容 |
|  **認知から24時間以内** |  早期警告（early warning） |  悪用/インシデントの発生事実。詳細不要、まず「知らせる」 |
|  認知から72時間以内 |  脆弱性/インシデント通知 |  概要、深刻度・影響、是正・緩和策の状況 |
|  脆弱性：是正措置提供後14日以内
インシデント：72時間通知の提出後1か月以内 |  最終報告 |  脆弱性の詳細・根本原因、講じた是正措置等 |

 提出先は、ENISAが整備する**単一報告プラットフォーム（Single Reporting Platform）**経由で、主たる拠点のある加盟国の**CSIRT**に報告し、原則として同時に**ENISA**にも共有されます（第16条）。EU域内に拠点を持たない日本メーカーの場合、どの加盟国のCSIRTが窓口になるか（授権代理人の設置を含む）を事前に整理しておく必要があります。

### 「24時間」を守れる体制を逆算する

24時間という期限は、技術対応ではなく**組織対応の速度**の問題です。9月11日までに最低限、次を整備してください。
1. **脆弱性受付窓口の開設：**製品セキュリティ専用の連絡先（例：`psirt@自社ドメイン`）を用意し、Webサイトに**脆弱性開示ポリシー（CVD：協調的脆弱性開示）**を掲載する。`/.well-known/security.txt` の設置も外部研究者からの通報経路として有効です。なおCVDポリシーの整備自体、附属書I第II部が求める項目です
2. **トリアージ基準の文書化：**「積極的に悪用されている」「重大インシデント」に当たるかを誰がどう判断するか。判断者・代理者・休日夜間の連絡網を決める（24時間の起点は「認知」です）
3. **報告テンプレートの準備：**早期警告・72時間通知・最終報告の3段階それぞれについて、埋めるべき項目を日英で雛形化しておく
4. **製品−ファーム−顧客の追跡性：**「どの製品のどのファームバージョンがEUのどこで稼働しているか」を答えられる台帳。SBOM（後述）はこの基盤になります
5. **机上訓練：**「FreeRTOSのCVEが公表され、自社製品への影響をX時間で判断→24時間以内に早期警告」という想定でリハーサルを1回やっておくと、穴が具体的に見えます
  ** よくある誤解

第14条の報告対象は「積極的に悪用されている」脆弱性であり、**すべての脆弱性を24時間以内に報告する義務ではありません**。ただし悪用有無の判断には脆弱性情報の収集・トリアージ体制が前提になるため、実務上は「全脆弱性を受け付け、悪用兆候を判定するプロセス」を作ることになります。

## 2027年12月11日に向けて：必須要件（附属書I）の概観

2027年12月11日以降に上市する製品には、附属書Iの必須要件（essential requirements）への適合と、技術文書・適合性評価・CEマーキングが求められます。組込み機器に効いてくる主要項目を挙げます。

### 第I部：製品の性質に関する要件（設計・開発・製造段階）
- リスクアセスメントに基づく設計（サイバーセキュリティリスク評価は技術文書の一部）
- **既知の悪用可能な脆弱性がない状態**で上市すること
- **セキュア・バイ・デフォルト**の構成（初期パスワード共通化の禁止など）
- **セキュリティアップデート**による脆弱性対処の仕組み（原則、自動更新または容易な更新手段）
- 不正アクセスからの保護（認証・アクセス制御）、保存・伝送データの暗号化等による機密性・完全性の保護
- 攻撃対象領域（アタックサーフェス）の最小化、悪用緩和メカニズム
- セキュリティ関連イベントの記録・監視機能

### 第II部：脆弱性ハンドリング要件（販売後も継続）
- 製品に含まれる脆弱性・コンポーネントの特定・文書化——**少なくともトップレベル依存関係をカバーするSBOM**を機械可読形式で作成
- 脆弱性の遅滞ない修正と**無償のセキュリティアップデート**提供
- 協調的脆弱性開示（CVD）ポリシーの整備・公開
- 修正済み脆弱性の情報公開、更新の配布メカニズム

 これらを**サポート期間**にわたって続ける義務があります。サポート期間は製品の想定使用期間を反映して製造者が定めますが、**原則として最低5年**（想定使用期間がそれより短い場合を除く）です（第13条8項）。産業機器は10年以上使われることが珍しくないため、「5年でサポート終了」と宣言できるかは顧客契約・市場実態と併せた経営判断になります。

## STM32での技術対応:RDP・セキュアブート・TrustZone・更新機構

ここからが本題です。附属書Iの要件を、STM32ベースの製品でどう実装に落とすか。STMicroelectronicsはセキュリティ機能群を**STM32Trust**という枠組みで整理しており、CRA対応の技術的な部品はかなり揃っています。ただし冒頭から強調しているとおり、**マイコンの機能を有効化しただけではCRA準拠にはなりません**。以下は「要件→STM32側の対応部品」のマッピングです。
| CRA要件（附属書I） | STM32側の対応機能 | 備考 |
|  不正アクセスからの保護、知財・鍵の保護 |  RDP（リードアウト保護）、WRP、TrustZone、HUK、OTFDEC |  量産時はRDP設定を製造工程に組み込む |
|  完全性の保護、改ざんファームの実行防止 |  セキュアブート（署名検証つきブートローダ）、Secure Manager、TF-M |  ルート・オブ・トラストの確立 |
|  セキュリティアップデートの仕組み |  SBSFU/署名付きファーム更新、デュアルバンクFlash、アンチロールバック |  配布インフラ・鍵管理は製品側の設計 |
|  暗号化・認証 |  AES/PKAハードウェアアクセラレータ、TRNG、工場書込みUID |  個体識別・デバイス認証の基盤 |

### 1. RDP（Read-out Protection）— 最低限ここから

 RDPはFlash内容のデバッガ経由読み出しを防ぐ機能で、従来品種では**レベル0（保護なし）／レベル1（デバッグ経由のFlash読み出し禁止）／レベル2（デバッグポート恒久無効・不可逆）**の3段階です。量産品をRDPレベル0のまま出荷すると、ファームウェアを吸い出されて脆弱性を探索される・クローンされる入口になります。実際、保護の甘いマイコンからのファーム解析がどこまで可能かは [ルネサスRL78のリバースエンジニアリング解説](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering) で扱ったとおりで、「読み出せる＝解析できる」が現実です。CRAの文脈では、攻撃対象領域の最小化・知財と鍵材の保護の観点で、**量産機のRDPレベル1以上は事実上の出発点**と考えるべきです。なおレベル2は不可逆でフィールドでのデバッグ手段を失うため、故障解析フローとセットで判断します（近年のTrustZone対応品種では、パスワード付きでの保護解除（リグレッション）や、H5系の「製品状態（Product State）」による段階管理など、より運用しやすい仕組みが導入されています。品種ごとのリファレンスマニュアルで確認してください）。

### 2. セキュアブートと更新機構 — 「アップデートの仕組み」要件の中核

 附属書Iが求める「セキュリティアップデートで脆弱性に対処できること」は、組込み機器では**署名検証つきのブートローダ＋安全なファーム更新パス**として実装するのが定石です。STM32では次の選択肢があります。
- **SBSFU / STM32Cube拡張パッケージ：**STが提供するセキュアブート＋セキュアファーム更新のリファレンス実装。署名検証、暗号化イメージ、アンチロールバック（バージョン巻き戻し防止）を含む
- **TF-M（Trusted Firmware-M）：**TrustZone対応品種（後述）向けのArm標準セキュアファームウェア。MCUboot系のセキュアブートを含み、PSA APIでセキュアサービスを提供
- **Secure Manager：**STM32H5系などで提供される、STがバイナリ提供・保守するターンキーのセキュアファームウェア。自前でセキュア側を書かずにルート・オブ・トラストを確立できる

 設計上の要点は3つ。(1) **デュアルバンク／デュアルスロット構成**で更新失敗時に旧イメージへフォールバックできること、(2) **アンチロールバック**で脆弱性のある旧バージョンへの意図的な書き戻しを防ぐこと、(3) **署名鍵の管理**（HSMでの保管、開発鍵と量産鍵の分離、漏えい時のローテーション手順）。CRA監査の観点では「更新をどう配るか」（USB持ち込みか、ゲートウェイ経由OTAか）と「サポート期間中それを誰が運用するか」まで技術文書に書ける状態にします。

### 3. TrustZone対応品種の選定

 Cortex-M33以降の**Arm TrustZone**は、鍵材・暗号処理・ブート検証を「セキュア世界」に隔離し、アプリケーション側の脆弱性が直ちに鍵漏えいに直結しない構造を作れます。STM32では**STM32L5 / STM32U5 / STM32H5 / STM32WBA（無線）**などがTrustZone対応で、STM32U5・H5は**SESIP Level 3 / PSA Certified Level 3**といった第三者セキュリティ認証を取得した品種を持ちます。SESIPは欧州規格（EN 17927）として標準化されており、CRAの整合規格が固まっていく中で、**認証取得済みプラットフォームの採用は適合性評価の説明材料として有利**に働くと見られます（認証がそのままCRA適合を意味するわけではありません）。

 既存製品がSTM32F4/F1などTrustZone非対応品の場合でも、RDP＋署名検証ブートローダ＋暗号化更新は実装可能です。「新規設計はTrustZone品種＋TF-M/Secure Manager、既存設計はRDP＋SBSFU系で底上げ」が現実的な使い分けです。   ** マイコン機能で「できないこと」

STM32の機能では、**脆弱性受付窓口の運用、CVE監視とトリアージ、SBOM整備、技術文書・適合宣言、報告義務の履行**は代替できません。これらは製品を上市するメーカーのプロセス整備そのものです。「セキュアなMCUを選んだからCRAはOK」という営業トークには根拠がありません。

## SBOMの現実的な作り方

 附属書I第II部は、製品の脆弱性・コンポーネントを文書化する手段として、**少なくともトップレベル依存関係をカバーするSBOM（ソフトウェア部品表）を、一般に使用される機械可読形式で作成**することを求めています。公開義務はなく、市場監視当局の要求に応じて提出できる状態にしておくのが基本です。

### フォーマットは SPDX か CycloneDX

機械可読形式のデファクトは**SPDX**（Linux Foundation系、ISO/IEC 5962として標準化）と**CycloneDX**（OWASP系、脆弱性管理との連携が強い）の2つです。組込みでは、脆弱性スキャンツールとの接続性からCycloneDXを選ぶチームが多い印象ですが、どちらでも要件は満たせます。

### ビルド環境別の現実解
- **Zephyr RTOSの場合：**ビルドシステムに統合済みで、`west spdx --init -d build` → `west build -d build` → `west spdx -d build` でアプリ・Zephyr本体・モジュール依存を含むSPDX文書が自動生成されます。組込みSBOMとしては最も整備された環境です
- **STM32CubeIDE + FreeRTOS / HALの場合：**自動生成の仕組みがないため、**「依存コンポーネントの棚卸し→CycloneDX JSONを半手動で作成→CIで検証」**が現実解です。STM32ファームの典型的なトップレベル依存は、FreeRTOSカーネル、STM32Cube HAL/LLドライバ、CMSIS、ミドルウェア（LwIP、mbedTLS、FatFs等）、ブートローダ（MCUboot/SBSFU）と、意外に少数です。各コンポーネントの名称・バージョン・サプライヤ・ライセンスをJSONに起こし、Gitでファームと同一リポジトリ管理します
- **補助ツール：**`syft`（ソースツリー/コンテナのスキャン）、`cve-bin-tool`（コンパイル済みバイナリから既知コンポーネントとCVEを検出）、CycloneDXの各言語ツールチェーン。組込みCではパッケージマネージャがない分、自動検出の精度は限定的で、「ツール＋人手の棚卸し」の併用が前提です

### SBOMは「作って終わり」ではない

SBOMの本当の価値は第14条対応との接続です。**「FreeRTOS x.y.zにCVEが出た。影響する自社製品はどれか」を数分で答えられる**ことがゴールで、そのためには (1) 製品×ファームバージョン×SBOMの対応表、(2) NVD/ベンダーアドバイザリの定期監視（cve-bin-toolやDependency-Track等での自動照合）、(3) 「影響なし」を表明するVEX（Vulnerability Exploitability eXchange）の運用、までをセットで設計します。

## FreeRTOS・ZephyrなどOSS利用時の扱い

組込みファームの大半はOSSコンポーネント（FreeRTOS、Zephyr、LwIP、mbedTLS…）を含みます。CRAにおける整理は明確で、**OSSを統合した最終製品の責任は、上市するメーカーが負います**。FreeRTOSの開発元やZephyrプロジェクトが自社製品の脆弱性報告義務を肩代わりすることはありません。
- **統合時のデューデリジェンス（第13条）：**第三者コンポーネント（OSS含む）を統合する際、そのコンポーネントが製品のセキュリティを損なわないよう相当の注意（due diligence）を払う義務があります。実務では「保守が生きているか（最終リリース日・メンテナ体制）」「既知CVEの有無と対応速度」「セキュリティアドバイザリの発行体制」をコンポーネント選定基準に含めます
- **上流への報告：**自社製品に統合したコンポーネントに脆弱性を発見した場合、そのコンポーネントの保守者（OSSプロジェクト）へ報告することも求められます。PSIRTプロセスに「上流への通報」ステップを組み込んでください
- **OSSプロジェクト側の扱い：**CRAは営利目的で提供されないOSSそのものには原則適用されず、一定の関与を行う「OSSスチュワード」には軽減された義務のみが課されます。つまり「FreeRTOSがCRA対応してくれるのを待つ」戦略は成立しません
- **バージョン規律：**「動いているから触らない」で5年以上前のカーネルを使い続ける文化は、サポート期間中の脆弱性対処義務と正面衝突します。LTSリリース（FreeRTOS LTS、Zephyr LTS）への追従計画と、更新の回帰テスト自動化を今のうちに整えるのが、結局いちばん安上がりです

## 実務チェックリスト

### フェーズ1：2026年9月11日まで（報告義務対応）
- ☐ EU向け製品の一覧化（型番・ファームバージョン・販売経路・EU域内の責任者/授権代理人）
- ☐ 各製品のCRA対象判定（適用除外の確認）を実施し、判定根拠を文書化した
- ☐ 脆弱性受付窓口（psirt@等）とCVDポリシーをWebに公開した（security.txt設置）
- ☐ 「積極的に悪用された脆弱性／重大インシデント」のトリアージ基準と判断者・24時間対応の連絡網を定めた
- ☐ 早期警告（24h）/詳細通知（72h）/最終報告のテンプレートを準備した
- ☐ 報告先（主たる拠点の管轄CSIRT・単一報告プラットフォーム）の登録・提出手順を確認した
- ☐ 主要製品のSBOM（暫定版でよい）を作成し、CVE監視を開始した
- ☐ インシデント対応の机上訓練を1回実施した

### フェーズ2：2027年12月11日まで（全面適用対応）
- ☐ 製品ごとのサイバーセキュリティリスクアセスメントを実施・文書化した
- ☐ クラス分け（default/important/critical）を確認し、適合性評価ルート（自己宣言/第三者評価）を決めた
- ☐ 量産ファームのRDP（またはTrustZone品種の製品状態管理）を有効化した
- ☐ 署名検証つきセキュアブート＋アンチロールバックつきファーム更新を実装した
- ☐ 署名鍵の管理体制（保管・分離・ローテーション）を整備した
- ☐ セキュア・バイ・デフォルト設定（共通初期パスワード廃止、不要ポート閉塞等）を確認した
- ☐ サポート期間（原則最低5年）を製品ごとに定義し、無償セキュリティ更新の提供体制を確保した
- ☐ SBOMをビルドパイプラインに統合し、リリースごとに自動生成・保管される状態にした
- ☐ 技術文書・EU適合宣言（DoC）・CEマーキングの準備を開始した
- ☐ 弁護士・認証機関に判定と適合方針のレビューを受けた

## まとめ

###  この記事のまとめ
- CRAはEU市場に上市する「デジタル要素を持つ製品」全般が対象。日本メーカーのB2B組込み機器も含まれる
- **2026年9月11日から第14条の報告義務が適用開始**。悪用された脆弱性・重大インシデントは24時間以内の早期警告が必要で、**既存製品も対象**（第69条3項）
- 2027年12月11日から必須要件・SBOM・サポート期間・CEマーキングが全面適用。一般的な産業機器の多くはdefaultカテゴリで自己適合宣言が可能
- STM32側の技術部品は揃っている：RDP、SBSFU/TF-M/Secure Managerによるセキュアブートと署名付き更新、TrustZone対応のL5/U5/H5/WBA、SESIP/PSA認証取得品種
- SBOMはSPDX/CycloneDXで「トップレベル依存」から現実的に始め、CVE監視・第14条報告と接続してこそ意味がある
- FreeRTOS/Zephyr等のOSSを使っても責任は最終製品メーカー。デューデリジェンスとLTS追従の規律を今から作る

繰り返しになりますが、本記事は技術実務の観点からの整理です。自社製品の該当性・クラス分け・適合性評価ルートの最終判断は、必ず弁護士や認証機関にご確認ください。そのうえで、技術側の実装——セキュアブート、更新機構、SBOMパイプライン、PSIRT運用の仕組み化——はエンジニアリングの仕事です。お困りの際はお気軽にご相談ください。

STM32のセキュアブート実装・ファーム更新機構の設計、既存製品のCRA対応改修、SBOM整備まで [組込み制御・マイコン開発](https://technosphere.co.jp/embedded) として対応しています。   ／CRA対応・組込みセキュリティのご相談はこちら＼

### 組込み機器のCRA対応・セキュリティ実装を受託開発で支援

STM32のセキュアブート・署名付きファーム更新・RDP/TrustZone活用設計から、SBOM整備・脆弱性対応プロセスの仕組み化、既存製品のセキュリティ改修まで。20年超のマイコン受託開発実績で、EU向け製品のセキュリティ実装を一貫サポートします。  [組込み開発サービスを見る](https://technosphere.co.jp/embedded) [CRA対応・セキュリティ実装の相談](https://technosphere.co.jp/contact)

## よくある質問（FAQ）   ** CRA（EUサイバーレジリエンス法）の対象になるのはどんな組込み製品ですか？

EU市場に上市される「デジタル要素を持つ製品」、すなわちネットワークや他のデバイスに直接または間接にデータ接続できるハードウェア・ソフトウェアが対象です。B2Bの産業機器も含まれ、日本メーカーがEUに輸出する製品にも適用されます。医療機器（MDR）や自動車など既存のEU法制でサイバーセキュリティが規律される製品は適用除外です。最終判断は弁護士や認証機関への確認をおすすめします。   ** 2026年9月11日から具体的に何が義務になりますか？

CRA第14条の報告義務が適用開始されます。自社製品で「積極的に悪用されている脆弱性」または「製品のセキュリティに影響する重大インシデント」を認知した場合、**24時間以内の早期警告**、72時間以内の詳細通知、事後の最終報告（脆弱性は是正措置提供後14日以内、インシデントは72時間通知の提出後1か月以内）を、単一報告プラットフォーム経由で管轄CSIRTとENISAに提出する必要があります。   ** すでにEUで販売中の製品にもCRA対応は必要ですか？

設計要件（セキュリティ・バイ・デザインやCEマーキング等）は、2027年12月11日より前に上市済みの製品には、それ以降に大幅な改変（substantial modification）を行わない限り適用されません（第69条2項）。ただし**第14条の脆弱性・インシデント報告義務は例外で、上市済みの製品にも適用されます**（第69条3項）。つまり2026年9月11日以降は既存製品も報告体制が必要です。   ** STM32のセキュリティ機能を使えばCRAに準拠したことになりますか？

なりません。RDP・セキュアブート・TrustZoneなどのマイコン機能はCRAの必須要件を満たすための技術的な部品にすぎず、CRAの義務は最終製品を上市するメーカーが製品全体として負います。脆弱性対応プロセス、SBOM、サポート期間中のアップデート提供、技術文書、適合性評価は製品レベルで整備する必要があります。   ** SBOMは一般公開する必要がありますか？

CRAはSBOMの一般公開までは要求していません。附属書I第II部は、少なくとも製品の**トップレベル依存関係**をカバーするSBOMを、一般に使用される機械可読形式（SPDXやCycloneDX等）で作成することを求めており、市場監視当局から要求があれば提出できる状態にしておく必要があります。   ** FreeRTOSやZephyrなどのOSSを使っている場合、脆弱性対応の責任は誰が負いますか？

最終製品としてEU市場に上市するメーカーが負います。OSSプロジェクト側ではありません。メーカーはOSSを含む第三者コンポーネントの統合にあたりデューデリジェンス（保守状況・脆弱性履歴の確認、バージョン管理、CVE監視）を実施し、自社製品に影響する脆弱性を発見した場合は当該コンポーネントの保守者への報告も求められます。      # CRA # サイバーレジリエンス法 # STM32 # セキュアブート # TrustZone # SBOM # 脆弱性管理 # 組込みセキュリティ

##   次に読む｜組込みセキュリティ・STM32関連記事
-  [組込みセキュリティ ルネサスRL78のリバースエンジニアリング 「保護されていないファームは読める」現実を知る。RDP設定の重要性が腹落ちする実例](https://technosphere.co.jp/blog/renesas-rl78-reverse-engineering)
-  [STM32 シリーズ STM32 + FreeRTOS 入門｜タスク・キュー・セマフォを使ったRTOS実装ガイド SBOMのトップレベル依存になるFreeRTOSの基礎。まずここから](https://technosphere.co.jp/blog/stm32-freertos-intro)
-  [STM32 シリーズ STM32マイコンのUART・I2C・SPI・CAN通信 実装ガイド CRA対象判定に関わる「デバイスへの接続」を支える通信実装の定番ガイド](https://technosphere.co.jp/blog/stm32-uart-i2c-can)
-  [開発実績 組込み制御・マイコン開発 実績紹介 STM32・FreeRTOS採用案件含む20年超の受託開発事例](https://technosphere.co.jp/embedded-achievements)
    [技術コラム一覧に戻る](https://technosphere.co.jp/blog/)