CRAセキュリティとは？対象製品と企業が取るべき対策を解説
EUで施行が迫る「CRA（サイバーレジリエンス法）」は、IT製品のセキュリティ要件を大幅に強化する新たな規制です。デジタル製品の普及に伴いサイバー攻撃が増加しており、社会的、経済的に深刻な問題となっていることが背景となっています。
CRAの施行は、EU向け製品を扱う日本企業に大きな影響を及ぼすことから、日本国内でもCRAへの関心が急速に高まっています。
「自社製品は対象か？」
「何をいつまでに準備すべきか？」
と悩んでいる企業の担当者も多いのではないでしょうか。
この記事では、CRAの概要や施行スケジュール、附属書に基づく要求事項、企業への影響、日本企業が直面する特有の課題などを解説します。今後の対応に必要な知識と、対策の方向性を決定するための情報としてご活用ください。
CRAとは何か？概要と規制の全体像
CRA（サイバーレジリエンス法）とは、EUにおけるデジタル製品のサイバーセキュリティを強化するために導入された新しい法制度です。ここでは、CRAの目的や対象製品、施行スケジュール、そして例外規定について順に解説します。
CRAの目的と製品対象の範囲
CRAは、ネットワーク接続機能を持つあらゆるデジタル製品に対し、製品ライフサイクル全体においてサイバーセキュリティ要件を満たすことを義務付ける法的な制度です。
具体的には、パソコン、スマートフォン、ルーター、センサー、業務用アプリケーションなど、ハードウェアやソフトウェア製品が対象となります。個人向け・法人向けを問わず、EU市場で流通する製品が対象です。
CRAの狙いとして、製造者、輸入業者、販売業者がそれぞれの立場でセキュリティ対策を講じる責任を負うことで、製品の信頼性と透明性の向上が期待されています。
施行スケジュールと適用期間
CRAは2024年12月10日に施行され、そこから36カ月の移行期間を経て、2027年12月11日に完全適用されます。（※）
ただし、製品に関する脆弱性やセキュリティインシデントの報告義務は、それより早い2026年9月11日から一部開始となります。企業側としては、スケジュールに応じた計画的な対策が必要といえるでしょう。
※出典：日本貿易振興機構「新たなセキュリティ規則、サイバーレジリエンス法施行」
対象から除外される項目
CRAは広範なデジタル製品に適用されますが、すべての製品が対象というわけではありません。例えば、商業活動を伴わないオープンソースソフトウェア（OSS）や、SaaSのようなクラウドベースのサービスは適用外です。また自動車、医療機器、航空機器など、すでに厳格なEU規制を受けている産業製品も除外対象となります。
適用の有無を誤認すると、法令違反や市場排除といった大きなリスクにつながる可能性があるため、自社製品が該当するかどうかを正確に判断する必要があるでしょう。
CRAが設置された背景と狙い
CRAの導入は、単なる製品規制ではなく、EU全体のサイバーセキュリティ政策と連動しています。IoTの急速な普及や脅威の増加に対応し、デジタル製品に求められるセキュリティ要件を統一化する必要性が高まったことが背景です。ここでは、CRAが設置された背景と狙いについて、具体的に解説します。
IoT普及とサイバー攻撃の激化
近年、IoTデバイスの急増により、家庭用機器から産業システムに至るまで、サイバー攻撃の対象範囲が大きく広がっています。そのため、個人情報の漏えいやサービス停止などの深刻なリスクが顕在化している状況です。
従来の自主基準では、こうしたリスクに対応しきれなくなってきています。製品レベルでの統一的なセキュリティ要件の整備が急務となっており、CRAを導入することで、サイバー攻撃の予防・対応能力の底上げを狙っています。
EU内のセキュリティ規制との連携
CRAは、EU内ですでに施行されているほかのサイバーセキュリティ関連規制と連携しながら、法体系として一貫性を持たせるよう設計されています。例えば、重要インフラを対象とする「NIS2指令」や、製品の安全認証を扱う「EUCC（EUサイバーセキュリティ認証制度）」との整合性の確保です。（※）
これにより、デジタル製品のセキュリティを包括的にカバーすることが可能となります。EU域内のサプライチェーン全体において、より堅牢で透明性の高いサイバーセキュリティ環境の実現が期待されています。
※出典：
経済産業省「EU NIS2指令概要」Page-4
経済産業省「IoT 製品に対するセキュリティ適合性評価」Page-15
オープンソースの対応と反発の動向
CRAが対象とするのは商用利用されるデジタル製品であり、商業活動に直接関係しないオープンソースソフトウェア（OSS）は原則として除外されます。
しかし、商用製品にOSSを組み込んでいる場合は適用対象となる可能性もあるため、「定義があいまいで適用範囲が不明確」「イノベーションを妨げる」といった懸念の声が挙がっている状況です。OSSとの適切な関係性の理解と運用ルールの明確化が、今後の重要な課題といえるでしょう。
CRAの具体的な要件と企業への影響
CRAは、製品の設計から出荷後の保守まで、セキュリティに関する明確な義務を定めています。具体的にまとめたものが「附属書Ⅰ」で、「Part1」「Part2」で構成されています。ここでは、「附属書Ⅰ」に基づくセキュリティ要件や脆弱性対応、報告義務、リスク分類、罰則規定について解説します。
附属書Ⅰ Part1：セキュリティ特性要件
CRAの附属書Ⅰ「Part1」では、製品に求められるセキュリティの基本特性が定められています。例えば、アクセス制御、暗号化通信、ソフトウェアアップデートの整備といった、設計・開発段階での安全対策の義務化です。またユーザーが安全に使用できるようなUI設計も含まれます。
これらの要件は、システムや製品の設計段階にセキュリティ要件を組み込む「Security by Design」の実現を促すものです。
附属書Ⅰ Part2：脆弱性処理要件
附属書Ⅰ「Part2」では、出荷後の製品が直面する脆弱性への対応が焦点です。企業は、セキュリティ脆弱性を早期に検知し、更新プログラムや修正パッチを提供する体制を整備する必要があります。
またユーザーや監督機関への通知体制も義務化されており、単なる技術対応だけでなく、情報共有・説明責任も必要です。そのため、製品出荷後も継続的なセキュリティの維持が求められます。
報告義務の詳細とタイムライン
CRAでは、脆弱性やインシデントが発生した際、ENISA（欧州ネットワーク・情報セキュリティ機関）などの関係当局に対し「24時間以内」に初報を提出する義務があります。（※）
また14日以内には対処状況を含めた最終報告を行う必要があり、タイムラインに沿った迅速かつ正確な報告が求められる状況です。（※）
この報告義務は2026年9月から有効となるため、多くの企業にとって報告体制の整備が急務となります。適切なログ管理、連絡体制など、文書化された手順が不可欠といえるでしょう。
※出典：
経済産業省「経済産業省のサイバーセキュリティ政策について」Page-12
UNITIS「サイバーレジリエンス法における報告義務の内容と具体策」
製品リスク分類と適合評価
CRAでは製品ごとにリスクが分類されており、通常の「デジタル製品」と「重要なデジタル製品」のうち「クラスI」と「クラスII」の3つに分けられます。「デジタル製品」は自己評価での適合確認が可能ですが、「クラスI」はEUCCやEN規格の対象外であれば第三者機関による審査と認証が必要で、「クラスII」についてはすべて第三者機関による審査と認証が必須です。
例えば、産業用のルータ・モデム・スイッチやセキュアエレメントなど、社会インフラに影響を及ぼす製品が「クラスII製品」に該当します。製造者は自社製品がどのカテゴリに該当するかを正確に判断し、適切な適合評価手続きを進める必要があります。
罰則・遵守義務
CRAに違反した場合、企業に対して非常に重い罰則が科される可能性があります。具体的には、最大で1500万ユーロまたは全世界売上の2.5%に相当する制裁金です。（※）
また、EU市場から製品撤去命令が出されたり、企業評判へ悪影響を及ぼしたりする可能性もあります。
違反を防ぐには、内部監査体制の強化や、全社的な法令順守体制の構築が不可欠となるため、CRA対応は経営課題として捉える必要があるといえるでしょう。
※出典：経済産業省「経済産業省のサイバーセキュリティ政策について」Page-12
企業が対策すべき体制とプロセス
CRAは単なる技術対応にとどまらず、企業全体で取り組むべき体制づくりを求めています。ここでは、ガバナンスの構築から開発体制、文書管理、適合評価、教育に至るまで、現場が直面する実務的な対策を整理します。
ガバナンスと体制整備
CRAへの対応は、単なるセキュリティ担当者の仕事ではありません。経営層を含めた全社的なガバナンス体制が不可欠です。
具体的には、製品ごとのリスクアセスメント体制の構築、法令遵守に向けた役割分担、セキュリティ方針の明文化などが必要となります。CRAの対応状況を可視化・監査する体制を整備することで、社内外への信頼性確保が可能となるでしょう。
セキュア開発とSDLの導入
CRAでは、SDL（セキュア開発ライフサイクル）の導入が必須となります。SDLは、設計・開発・テスト・リリース・保守の各段階においてセキュリティ要件を組み込む手法で、脆弱性の早期発見と予防が目的です。
具体的には、脅威モデリング、コードレビュー、自動化されたセキュリティテストなどが含まれます。CRAでは、これらの手法を標準化して製品に組み込むことが求められます。
SBOM整備と脆弱性発見体制の構築
CRAでは、SBOM（ソフトウェア部品表）の整備が求められます。SBOMとは、製品内で使用しているすべてのソフトウェア構成要素のリストを指し、脆弱性の影響範囲を特定する上で不可欠なものです。
また、脆弱性の発見・報告・修正までを一貫して実行できる体制の構築も求められています。内部プロセスだけでなく外部通報の受け入れ窓口を設けて、透明性と信頼性を確保する必要があります。
適合評価・第三者認証準備
「クラスI製品」「クラスII製品」を扱う場合は、第三者機関による審査と認証が必要です。そのため、技術文書の整備や内部評価の記録、試験結果の保管が必要となります。
認証機関との連携や準備期間を見越して、準備を進める必要があるといえるでしょう。
保守・監査・教育体制
製品出荷後も、保守・監査・教育という「持続的セキュリティ管理体制」が必要です。CRAでは、リリース後も脆弱性対応・パッチ配信の義務があり、監査・記録する体制の整備が求められます。また従業員への継続的なセキュリティ教育も義務の一部です。
これらの対応を継続することで、信頼ある製品ブランドの維持につながります。
日本企業特有の課題
CRA対応はEU法準拠という視点だけでなく、日本国内の規格や規制との整合性も考慮が必要です。ここでは、制度的な整合性や産業課題、情報共有体制の現状を解説します。
日本国内制度との整合性
日本には、サイバーセキュリティ基本法や産業サイバーセキュリティ推進事業などの枠組みがあります。しかし、CRAはそれらを上回る詳細かつ包括的な製品セキュリティ規制です。
CRA対応を進めるには、まず日本国内の規制や指針との違いを整理し、ギャップを特定することが重要となります。JIS規格や経済産業省のガイドラインなどを確認しながら、社内ルールや開発プロセスを調整していくことが必要です。そのため、国内外の法制度を横断的に理解する力が求められるでしょう。
産業機器メーカーにおける実務的課題
日本の産業機器メーカーは、製品の脆弱管理、サプライチェーンの連携、長期視点でのセキュリティ対策など、固有の課題を抱えています。CRAが求めるようなセキュリティサポートや、SBOMを即時提供できる体制を整備するには、製品開発だけでなく保守部門や営業部門とも連携した全社的な改革が不可欠です。
脆弱性情報共有フレームワークとの連携
CRAでは、脆弱性情報の迅速な共有と対応が強く求められる状況です。日本国内でも、セキュリティ事象を管理している「JPCERTコーディネーションセンター」への報告や「脆弱性情報データベース」といった仕組みがあります。しかし、CRAが求める基準に比べると情報公開のタイムラインが異なる場合があります。そのため、日本国内とCRA両方の要件を満たし、二重報告を防ぐ仕組みの構築が必要です。
またOSS利用企業においては、ソフトウェアサプライチェーン全体を意識した、CRAとの連携が不可欠です。
まとめ
CRA（サイバーレジリエンス法）は、EUで販売されるあらゆるデジタル製品に対して、設計から出荷後の保守まで包括的なサイバーセキュリティ対応を義務付ける新たな規制です。
対象範囲が広く、報告義務や第三者認証など厳格な要件が設定されており、EU市場に製品を提供する日本企業にとっては対応が急務となります。
具体的には、SBOMの整備、セキュア開発体制の導入、インシデント報告体制の構築など、従来の開発文化を見直す必要があるといえるでしょう。
こうした複雑な要件への対応には、セキュリティ、法務、技術文書、社内教育といった多面的な支援が不可欠です。
弊社が提供する「ワンストップ型セキュリティ認証取得支援サービス」では、CRAの要求に沿った現状分析から適合評価、文書化、内部体制整備まで一括で対応しています。CRA対応を進めたい企業の信頼できるパートナーとして、実効性のある支援をご提供します。
詳細資料をご希望の方には送付させていただきますので、以下フォームよりメールアドレスをご登録ください。
[2025年07月09日 時点]
