CRAは「まだ先の話」ではない —組込み開発現場が今すぐ動くべき理由—

CRA（Cyber Resilience Act、規則 EU 2024/2847）は2024年12月に発効し、IoT・組込み機器を含むデジタル要素を持つ製品全般を対象とするEUのサイバーセキュリティ規制です。完全適用は2027年12月ですが、脆弱性・インシデント報告義務は2026年9月11日に発効します。報告できる体制がそのまま事業継続性に直結する今、組込み開発現場が今すぐ動くべき理由と実務対応を解説します。

1. そもそもCRAとは何か、なぜ組込み機器が対象になるのか

CRA（Cyber Resilience Act、規則 EU 2024/2847）は、2024年12月10日に発効された、デジタル要素を含む製品全般を対象とするEUのサイバーセキュリティ規制です。IoT機器、産業用ルーター、組込みファームウェア、産業用制御機器など、デジタル要素を持つ多くの製品が対象となります。

一方で、医療機器や自動車など、CRAで明示的に除外されている既存の分野別EU法令の適用対象製品は、原則としてCRAの対象外です。ただし、それらの分野で使用されるソフトウェアやハードウェアコンポーネントが単独で市場に提供される場合にはCRAの対象となるケースもあるため、自社には関係ないと早期に結論付けるのは避けるべきでしょう。

CRAでは製品カテゴリに応じて求められる適合性評価の厳格さが異なり、一部の製品にはEU市場への投入前に認証規格による第三者評価を受ける必要があります。次の表は、公表されている情報をもとにした概要の参考イメージです（最終的な分類は個別製品ごとに判断が必要であり、詳細は欧州委員会の公式資料をご確認ください）。

2025年12月1日には、この「重要」「クリティカル」の線引きを具体化する欧州委員会実施規則（EU 2025/2392）が公表され、判断基準が製品を構成するコンポーネントの性質ではなく、製品の中核機能（core functionality）にあることが明確になりました。組込み機器に暗号ライブラリやOSSコンポーネントを組み込んでいるからといって、直ちに製品全体の区分が引き上げられるわけではないという整理は、実務上の見通しを立てやすくする要素と言えるでしょう。

2. 全体スケジュール：2025年後半～2027年

CRAの適用は段階的に進みます。本稿執筆時点（2026年9月）から今後1年半ほどの間には、いくつもの節目が控えています。

現在、複数のETSI製品別（垂直）標準ドラフトがパブリックコメント段階にあり、2026年後半にかけて意見募集が行われています。対象製品によってスケジュールが異なるため、最新状況はETSIの公開情報を確認することをお勧めします。標準そのものの完成にはまだ時間がかかりますが、報告義務のように先に発効する項目があることを見落とせません。

3. 今、最も重要な最新動向：報告義務の発効（2026年9月11日）

上表のとおり、現場が今すぐ意識すべき最重要の動きが2026年9月11日の報告義務発効です。悪用が確認された脆弱性については、認知から24時間以内に初期通知、72時間以内に詳細評価、14日以内に最終報告を行う必要があります。重大なセキュリティインシデントについても、24時間・72時間・1か月という同様の枠組みが適用されます。報告はいずれもCRA Single Reporting Platform（SRP）経由で提出されることになっており、対象はEU域内の製品だけでなく、EU市場に製品を投入するすべてのメーカーです。ただし、報告義務への対応はCRAが求める取り組みの入り口に過ぎず、報告した脆弱性を確実に検知・是正できる体制と製品になっているかどうかが本質的な課題です。

この報告フローを回すには、自社製品にどのようなコンポーネントが含まれ、どこに脆弱性が潜んでいるかを即座に把握できる体制が求められ、こうした対応を支える有力な手段がソフトウェア部品表（SBOM）の整備です。SBOMがなければ24時間以内に何が起きたかを特定すること自体が難しい、という指摘は多くの専門家が共通して挙げている点です。

もっとも、報告義務への対応ばかりに意識が向くと、議論はSBOMやPSIRTといった体制・プロセスの整備に偏りがちです。しかしCRAが本来求めているのは、そもそも脆弱性が作り込まれていない堅牢な製品を市場に出すことであり、ファジングやペネトレーションテストによる動的検証は、その堅牢性を出荷前に実証する手段として、SBOM整備やPSIRT運用とあわせてセキュア開発体制を支える重要な取り組みの一つといえるでしょう。

4. もう一つの動き：7月27日の欧州委員会ガイダンス

2026年7月27日、欧州委員会はコンプライアンス支援のための実務ガイダンスを公表しました。リモートデータ処理やOSSの適用範囲、実質的な変更の定義、サポート期間の考え方、報告義務の実務手順などを67の具体例やフローチャートで解説し、マイクロ企業・中小企業への配慮も明記されています。組込み機器メーカーの多くは中小規模のサプライヤーであることを踏まえると、実務上参考になるガイダンスと言えるでしょう。

5. 開発プロセスに何が求められるのか

CRAが組込みソフトウェア開発の現場に求める変化は、大きく四つに整理できます。

第一に、Secure by Designの徹底です。設計段階からセキュリティ要件を組み込み、出荷時点で既知の脆弱性が含まれていないことを保証する必要があります。これは開発の後工程でセキュリティを付け足す従来型のやり方からの転換を意味します。

第二に、SBOMの生成と継続的な管理です。OSS・商用を問わずすべてのソフトウェアコンポーネントを把握し、脆弱性情報が公開された際に自社製品への影響を迅速に特定できる仕組みが求められます。ドイツBSIのTR-03183などを参照し、依存関係の記述粒度を検討する国内企業も出てきています。

第三に、脆弱性ハンドリングプロセス、いわゆるPSIRT（Product Security Incident Response Team）機能の整備です。受付から評価・修正・開示・規制当局への報告までを一気通貫で回せる体制がなければ、9月11日以降の報告義務には対応できません。加えて、サポート期間中はセキュリティアップデートの継続提供も義務化され、出荷したら終わりという開発文化からの脱却が迫られます。

第四に、静的解析と動的セキュリティ検証を組み合わせた多層的な検証です。CRAは特定の検証手法を義務付けているわけではありませんが、リスクに応じた適切なセキュリティ評価を実施することが求められます。静的解析はソースコード上に潜む、脆弱性となりうるコードパターンを早期かつ網羅的に検出できる有用な手段です。ただし、解析対象はソースコードという限られた資源にとどまるため、実行環境やシステム全体としての振る舞いまでは検証できず、また解析範囲内でツールが検出できたパターンしか捉えられないという限界もあります。そこで、ファジングやペネトレーションテストによる動的テストを組み合わせることで、Secure by Designの実効性を裏付け、出荷前に脆弱性をつぶしておくことができます。

6. 今、現場で始めるべきこと

完全適用が2027年12月であることに変わりはありませんが、9月11日以降は報告できる体制があるかどうかがそのまま欧州市場での事業継続性に直結します。開発者・QA担当者の立場でまず着手できることは、次の5点に整理できます。

• 自社製品がCRAの適用対象に該当するか、該当する場合はどのリスク区分に位置づけられそうかの一次評価
• 使用しているOSS・サードパーティコンポーネントの棚卸しとSBOM整備の着手
• 脆弱性を受け付けてから報告・是正までの社内フロー（PSIRT機能）の明文化
• 7月に公表された欧州委員会ガイダンスを開発・品質保証部門で読み合わせ、自社の解釈にずれがないかの確認
• ファジングやペネトレーションテストなど、動的なセキュリティ検証を開発・QAプロセスに組み込むための計画づくり

いずれも一朝一夕には終わらない取り組みですが、早く始めた分だけ選択肢が残ります。CRAは、対応必須の規制であると同時に、製品開発の品質管理そのものを見直す機会でもあります。すべてを自社の人員・知見だけで賄おうとせず、脅威分析や動的テストなど専門性が求められる部分は外部の力を借りるのも現実的な選択肢です。

おわりに：CRA対応は、ここからご相談いただけます

CRA対応は、規制文書を読むだけでは終わりません。リスク区分の見極め、SBOM整備、脆弱性ハンドリング体制の構築、そして製品が求められるセキュリティレベルを満たしているかの検証まで、一連の実務が求められます。

ユビキタスAIは、「パートナー企業と連携した脅威分析を含むコンサルティング」「静的解析ツール やファジング・ペネトレーションテストツールなどの各種セキュリティ関連製品」「実機を用いたIoT機器セキュリティ検証サービス」を提供し、CRA対応を迫られている製造業の皆様の体制構築から検証までを一気通貫で支援しています。

• 脅威分析コンサルティング（パートナー企業との協業） — リスク区分の見極めや脅威モデリングなど、体制構築の初期段階から伴走します。
  → サービス詳細を見る
• 高精度静的解析ツール CodeSonar — ソースコード上の脆弱性やコーディング規約違反を、開発初期の段階から高精度かつ網羅的に検出します。
  → 製品詳細を見る
• セキュリティ関連製品・ツール（ファジング・ペネトレーションテストツール Penzzer など）— 製品の堅牢性をご自身で確認いただける各種ツールを取り揃えています。
  → 製品詳細を見る
• IoT機器セキュリティ検証サービス — 実機を用いた動的テストで、報告義務や適合性評価に耐えうるセキュリティレベルかどうかを検証します。
  → サービス詳細を見る

CRA対応の進め方や、自社製品がどのリスク区分に該当するかなど、ご不明点やご相談がございましたら、お気軽にお問い合せください。

このコラムの著者

株式会社ユビキタスAI

エンベデッド第3部

永井 玲奈​（ながい れな）

長年、組込みソフトウェアの営業・製品マーケティングに携わる。現在はユビキタスAIでIoT機器セキュリティ検証サービス事業の営業およびプロダクトマーケティングを担当。医療機器、車載製品、民生品などあらゆる機器を製造する大手製品ベンダーの多岐に渡るセキュリティ課題解決に取り組む。

より詳しく技術や​関連製品について​知りたい方へ

本コラムに関係する技術や関連する製品について知りたい方は、お気軽にご相談ください。

お問い合わせはこちらから