CRA製品分類とクラス別セキュリティ対策ガイド

CRA製品分類の重要性

2024年に正式採択されたサイバーレジリエンス法（Cyber Resilience Act：CRA）は、ネットワーク接続機能を持つハードウェア・ソフトウェア製品に対して、設計・運用・更新・廃棄のすべての段階でサイバーセキュリティ要件の実装を義務づけるEUの新しい規制です。前回（CRA法とは？知っておくべき新たなセキュリティ義務と対応ポイント）の記事では、CRAの背景、対象となる製品の概要、そしてなぜ今、欧州が本気でセキュリティ強化に乗り出したのかを解説しました。この記事から読み始める方にとっても問題ありません。今回のテーマは、CRAの全体像の中でも「製品分類とそれに応じた対応策」にフォーカスを当てた実務的なガイドです。

CRAでは、すべての製品をそのサイバーリスクのレベルに応じてクラスを分けて、それぞれに異なる評価方式とセキュリティ要件が求められます。特に「自社製品がどのクラスに該当するのか」を理解することは、CRA対応の第一歩です。本記事では、以下の3点を軸に、法令に基づく実践的な視点で解説します。

• CRAにおける製品クラスの違いと分類方法
• 各クラスごとに求められる具体的なセキュリティ対策
• 適合性評価の進め方と準備のポイント

CRA対応は、単なる法令遵守にとどまらず、製品価値の向上と市場競争力を強化するチャンスでもあります。CRA対応を進めるうえで避けて通れない「製品分類」と「クラスごとの対応要件」について、実務に役立つ視点で解説していきます。

CRAにおける製品分類

サイバーレジリエンス法では、すべての製品が一律に同じセキュリティ対策を求められるわけではありません。製品の特性やリスクの程度に応じて、求められる対応や評価方法が異なります。その判断の基準となるのが、製品の「分類」です。CRAでは、対象製品を大きく以下の4カテゴリに分類しています。

• 一般製品（デフォルトカテゴリ）：特に高いリスクを持たない製品

• 重要製品（Class I）：中リスクを持つ製品。（Annex III）

• 重要製品（Class II）：高リスクを持つ製品。（Annex III）

• クリティカル製品：社会インフラ・国家安全に関わる製品（Annex IV）

この分類によって、適合性評価においてどのような対応が求められるか、どのモジュールを使うべきかが決定されます。たとえば、Class IIやクリティカル製品では、EU認定のNotified Body（認証機関）による正式な評価が必要となるなど、手続きの負荷も大きく変わります。この分類により、リスクが高い製品ほど、より高度なセキュリティ対策と厳格な評価プロセスが必要となります。それぞれに応じた適合性評価とセキュリティ要件が定められています。以下では、それぞれのカテゴリに属する製品の特徴と、代表的な例を紹介します。

■ 一般製品（デフォルトカテゴリ）

• 対象：CRA上で特に「重要製品（Class I/II）」または「クリティカル製品」として明示されていない製品

• 特徴：比較的リスクが低く、家庭用のスマート家電（スマート冷蔵庫、スマートスピーカー、Wi-Fi接続された照明など）やネットワーク機能付き玩具が該当

• ポイント：自己責任で適合宣言が可能（自己適合評価）

■ Class I 製品（Annex III Part A）

• 対象：中リスクとみなされる製品で、ユーザーの個人情報やネットワークへの影響が懸念されるもの

• 主な製品例：

  • パスワードマネージャー、VPNアプリ

  • IoTゲートウェイ、車載インフォテインメント

  • デジタルIDソフト、SIEM、スマートセキュリティ機器（スマートドアロック等）

• ポイント：整合規格に準拠すれば自己評価が可能だが、それ以外は第三者評価が必要

■ Class II 製品（Annex III Part B）

• 対象：高リスク製品で、他のシステムやネットワーク全体へのセキュリティ影響が極めて大きいもの

• 主な製品例：

  • OS（Windows、Linux等）

  • ハイパーバイザー、仮想化ソフト

  • 暗号鍵管理システム、認証局（CA）

  • IDS/IPS、ファイアウォール

• ポイント：Notified Body（認証機関）による正式な型式審査が義務。Class Iの評価より厳格な評価が必要

■ クリティカル製品（Annex IV）

• 対象：Class IIの中でも国家インフラや安全保障に深く関わる製品。EUが特に高いセキュリティ対応を求めるカテゴリ。

• 主な該当分野：

  • 政府用ID認証・国民認証インフラ（eID）

  • 公共インフラ制御ソフト、暗号モジュール

• ポイント：Module Hによる品質保証体制が必須で、非常に厳格な外部監査を伴う

製品がどのカテゴリ（一般製品、Class I、Class II、クリティカル製品）に分類されるかによって、求められるセキュリティ対策の厳しさや、適合性評価の方法は大きく異なります。次に、それぞれのクラスに応じて企業が満たすべき評価方式と技術的・管理的要件を比較しながら見ていきましょう。実際にどのような対策が求められるのかを把握することで、自社製品に必要な準備と対応の全体像が明確になります。

評価方式とセキュリティ要件の比較表（CRA Annex I + Article 24〜26）

すべての製品に対して基本的なセキュリティ要件（Annex Iで規定）が定められています。これらは「設計段階でのセキュリティ組み込み（Secure by Design）」から「脆弱性の報告・管理」、「ソフトウェア構成（SBOM）の可視化と保守」、「アップデート提供体制」など、ライフサイクル全体にわたる対策です。

製品のクラスが上がるほど、これらの要件はより高度で包括的な実施が求められ、外部機関による審査や品質管理体制（QMS）の整備も義務化されます。以下の表では、各クラスにおける評価方式と、求められるセキュリティ要件の違いをまとめています。この比較により、自社製品がどのカテゴリに該当し、どのような準備と審査が必要かが一目で理解できます。特にClass II・クリティカル製品では、外部機関による厳格な品質保証や包括的なセキュリティ管理体制が要求されるため、早期の体制整備が鍵となります。

補足：Module A/ B / C / Hと選択基準とは？

• Module A：整合規格に完全準拠している場合、自己適合宣言が可能。

• Module B：EU型式審査。設計・技術文書をNotified Body（認証機関）が審査し「設計承認書」を発行。

• Module C：内部生産管理。Module Bで認証された設計通りに生産できているかを企業内で確認。

• Module H：完全品質保証。製品のQMS（品質マネジメントシステム）全体を第三者が審査。

実践的な対応ステップ：CRA準拠に向けた行動ガイド

サイバーレジリエンス法（Cyber Resilience Act：CRA）は単なる規制ではなく、製品の設計から販売後の運用に至るまで、サイバーセキュリティを組織的に取り入れるための包括的な仕組みです。対応が必要な領域は多岐にわたるため、「まず何から始めればよいのか？」という疑問を抱える企業も多いのではないでしょうか。そこで以下では、CRA準拠に向けて企業が押さえておくべき5つのステップを、実務の視点から順を追って整理しました。各ステップには、現場で役立つチェックポイントも付け加えています。自社の対応状況を確認しながら、段階的な準備を進める際の参考にしてください。

ステップ① 自社製品の分類を明確にする

CRAでは、製品の機能や用途に基づいて「一般製品」「Class I」「Class II」「クリティカル製品」に分類され、それぞれ異なるセキュリティ要件と適合評価が課されます。まずは、Annex III・IVを参照し、自社製品がどのカテゴリに該当するかを確認しましょう。

実務ポイント：

• 製品のネットワーク接続機能、暗号機能、ID管理機能の有無を確認

• 他のEU法（MDR、UN-R155等）でカバーされていないか併せて検討

ステップ② セキュリティ要件を整理する

Annex Iでは、全製品に求められる基本的なサイバーセキュリティ対策が定められています。自社の現行体制と比較し、どの部分に対応が必要かを可視化することが重要です。

実務ポイント：

• Secure by Design、脆弱性報告体制、SBOM整備の有無を点検

• 社内の品質管理・情報セキュリティ体制との整合性を確認

ステップ③ 適合性評価の準備を進める

Class I以上の製品では、自己適合だけでなく、第三者機関による評価が求められる場合があります。評価方式（モジュールB/C/H）の確認と、必要に応じた外部連携が不可欠です。

実務ポイント：

• 自社製品に適用される評価モジュールを特定

• Notified Body（認証機関）や評価機関との早期の接点構築

• 設計書・試験記録など技術文書の整理を開始

ステップ④ 技術文書・SBOMの作成

SBOM（Software Bill of Materials）は、製品に含まれるソフトウェア構成を明示する文書で、CRAでは継続的な管理と保管が義務付けられています。

実務ポイント：

• SPDXなど標準フォーマットに対応したSBOM管理ツールの導入

• 技術文書の保管・更新体制を構築（10年間の保存が必要）

ステップ⑤ アップデート提供体制の構築

CRAでは、製品リリース後に最低5年間、無償でセキュリティアップデートを提供する義務があります。長期サポートを見越した体制設計が求められます。

実務ポイント：

• セキュリティパッチ配布のプロセスを社内で明文化

• エンドユーザー通知・更新トリガーの仕組みの整備

• アップデート管理に関する社内ポリシー策定

今後のCRA準拠に向けて

CRAはリスクベースで製品を分類し、段階的な対応を企業に求めています。特にClass I・II・クリティカル製品に該当する企業は、2027年までの準拠に向けた体制整備を早急に始めることが求められます。本記事では、製品の分類ごとの違い、それぞれに求められるセキュリティ要件、そして適合性評価の進め方について、実務的な観点から解説しました。これにより、CRA対応の全体像と、自社がどのような体制整備を行うべきかが明確になったのではないでしょうか。まずは自社製品のクラスを正しく把握し、必要な評価手法と社内準備のギャップを見える化することが第一歩です。

AutoCryptでは、CRAへの準拠に必要な各種支援をワンストップでご提供しています。設計段階でのリスク評価、SBOM管理、セキュリティテスト、技術文書作成、そして第三者機関との適合性評価まで幅広くサポート可能です。自社だけでの対応に不安がある場合は、ぜひお気軽にご相談ください。サイバーレジリエンス法への対応ソリューションの詳細はこちらをご覧ください。