今すぐ対策を！欧州サイバーレジリエンス法（CRA）対策の手順と注意点を解説

欧州サイバーレジリエンス法（CRA）の全面適用は2027年12月11日ですが、報告義務はその15ヶ月前にあたる2026年9月11日から先行して開始されます。対応期限は想像以上に近づいています。

準備に十分な時間があると判断し、着手を先延ばしにすれば、制裁金やリコールといったリスクを招きかねません。早期に全体像を把握し、段階的に対応を進める必要があります。

本記事では、CRA対策の具体的な手順と実務上の注意点を整理して解説します。

欧州サイバーレジリエンス法（CRA）とは

欧州サイバーレジリエンス法（CRA）とは、EU市場で販売されるデジタル要素を備えた製品（PDE:Products with Digital Elements）に対し、共通のサイバーセキュリティ基準を満たすことを義務付けるEUの規則です。

その正式名称はEU Cyber Resilience Act（EU CRA）と表記されることもありますが、一般的に「CRA」は法令そのものを指し、「EU CRA」はそのEU版の正式名称という位置付けです。

本記事では以降、法令そのものを「CRA」と表記します。

CRAは2024年11月20日にEU官報（Official Journal）に掲載され、その20日後の2024年12月10日に発効しました。製品のライフサイクル全体にわたってサイバーセキュリティを確保することを目的としており、ハードウェア・ソフトウェアを問わず、ネットワーク接続機能を持つ幅広い製品が適用対象となります。

CRAが注目される背景には、IoTデバイスや産業用機器へのサイバー攻撃が世界的に急増しているというデジタル環境の変化があります。

従来のEU法規制は製品そのもののセキュリティを直接規定するものではなかったため、CRAによって製品に対する横断的なサイバーセキュリティ基準が初めて設けられることになりました。

日本の製造業にとっても、EU向けに製品を販売・輸出する場合はCRA対応が必須です。とくに精密機器や産業用機器を扱う企業は、自社製品の欧州展開に向けた準備を早急に進める必要があります。

CRAの対象となる製品

CRAの対象は広く、ネットワークへの直接的または間接的なデータ接続機能を持つほぼすべてのソフトウェアおよびハードウェア製品、リモートデータ処理ソリューションなどが含まれます。

ただし、医療機器（MDR/IVDR）、自動車（UNECE WP.29）、航空機（EASA規制）など、既存のEU法規制が適用される一部製品は適用除外となる場合があります。

CRAでは製品をリスクレベルに応じて以下のように分類しています。

自社製品がどのカテゴリに該当するかを正確に把握することが、CRA対策の第一歩です。リスク分類を誤ると、適合性評価の方法が変わり、対応コストや所要期間に大きな影響が生じます。

CRAが求める3つの要件

CRAは、対象製品のメーカーに対して大きく3つの要件を求めています。

• サイバーセキュリティ管理要件
• 脆弱性の継続的な管理と報告義務
• 文書化・記録保存要件

製品のセキュリティ確保から市場流通後の継続管理まで、ライフサイクル全体をカバーしている点が特徴です。自社の対応状況を整理するための基準として、まずはこの3要件を押さえておきましょう。

サイバーセキュリティ管理要件

製品の設計・開発段階から、セキュリティ対策を組み込まなければいけません。具体的には以下3つの対応が必要です。

【1．セキュリティ・バイ・デザイン】

設計の初期段階からセキュリティを考慮し、既知の脆弱性を持たない状態でリリースすることです。なお、設計における安全性の確保は、後述するリスクアセスメントの結果を踏まえた上で行います。

リスクアセスメントと設計対応は別プロセスであり、アセスメントでリスクを特定・評価し、その結果に基づいて具体的なセキュリティ設計を行うという流れになります。

【2．攻撃対象領域の最小化】

不必要な機能・ポート・サービスを排除し、リスクを低減することです。製品には、本来の提供価値に直接関係しない管理機能や通信機能、初期設定のまま有効になっているサービスが残っていることがあります。

こうした不要な要素は、利便性のために追加されたものであっても、攻撃者にとっては侵入口になり得ます。そのため、利用しないポートを閉じる、不要なプロトコルを無効化する、デバッグ機能やテスト用アカウントを本番環境に残さないといった対応が重要です。

【3．インシデント対応能力の確保】

セキュリティインシデント発生時に影響を最小化できる設計であることです。どれだけ対策を講じても、すべてのインシデントを完全に防げるとは限りません。

そのため重要なのは、万が一問題が起きた際に、被害の拡大を抑え、迅速に原因を把握し、復旧につなげられる状態をあらかじめ設計に組み込んでおくことです。

これらの要件は製品のリリース前だけでなく、サポート期間全体にわたって維持することが求められます。

脆弱性の継続的な管理と報告義務

製品を市場に出した後も、以下のような脆弱性の管理と迅速な対応が義務付けられます。

• 脆弱性の継続的な追跡・管理: リリース後に発見された脆弱性を継続的にモニタリングする
• インシデントの迅速な報告: 脆弱性が発見された場合、24時間以内にENISA（欧州ネットワーク・情報セキュリティ機関）に初期報告を行い、72時間以内に詳細報告を行う
• セキュリティアップデートの無償提供: サポート期間中（製品の想定ライフサイクル全体または最低5年間のいずれか短い方）は、セキュリティパッチを無償で提供する義務がある

文書化・記録保存要件

CRAへの適合を証明するための文書化も必要です。

• 技術文書（Technical Documentation）の作成: リスクアセスメントの結果、セキュリティ設計方針、テスト結果、適合性評価手順などを文書化する
• SBOM（Software Bill of Materials:ソフトウェア部品表）の管理: 製品に含まれるソフトウェアコンポーネントの一覧を作成・維持管理する。なお、SBOMの一般公開はCRAでは義務付けられていないが、規制当局から要求があった場合には提出する必要がある
• EU適合宣言書（DoC）の作成: CRAの要件を満たすことを宣言する文書を整備し、製品にCEマークを付与する
• 記録の長期保持: 関連文書を製品の市場投入後10年間保存する義務がある

CRAの具体的な対策手順

CRA対応をどこから始めればよいか迷う担当者も多いでしょう。ここでは、具体的な対応の流れをステップごとに解説します。

自社製品のリスク分類をする

まず行うべきは、自社製品がCRAのどのリスクカテゴリに該当するかを確認することです。一般製品（デフォルトカテゴリ）であれば自己宣言のみで適合性を証明できますが、重要な製品（クラスI・II）に分類された場合は第三者機関による審査が必要になります。

リスクレベルに応じて認証対応の難易度・費用・所要期間が大きく変わるため、早い段階でのリスク分類が対策全体のスケジュールを左右します。

CRAの附属書（Annex III・IV）に記載されたリストと自社製品を照合し、判断が難しい場合は専門家の助言を得ながら正確に分類しましょう。

開発段階からセキュリティを組み込む

リスク分類が確定したら、開発プロセスに以下のセキュリティ対策を組み込んでいきます。

まずは製品が抱えるサイバーセキュリティリスクを体系的に特定・分析し、どのリスクに、どう対応するかを評価・判断するリスクアセスメントを行います。この結果が、以降のセキュリティ設計の方向性を決定します。

リスクアセスメントで特定・評価したリスクに対し、セキュリティ・バイ・デザインの導入により、具体的にどのような設計上の対策を講じるかを決定し、開発仕様に組み込みます。

その後、製品に使用しているOSSやサードパーティ製ソフトウェアコンポーネントを一覧化し、既知の脆弱性（CVE）との継続的な突合を可能にする環境を整えましょう。

適合性を証明する

開発・設計段階での対応が完了したら、適合性確認の手続きを進めます。具体的には、以下の項目を推進します。

• 技術文書の作成: 設計仕様書、リスクアセスメント報告書、テスト報告書などをまとめた技術文書一式を整備する
• 適合性の確認・評価: リスク分類に応じた方法（一般製品は自己評価を実施、重要な製品は第三者機関による審査を受ける）で適合性を確認する
• CEマークの付与: 適合が認められたら製品にCEマークを付与し、EU適合宣言書（DoC）を作成・保管する

なお、CEマークの取得はCRAだけでなく、他のEU指令（機械指令、電波指令など）との整合も考慮する必要があります。すでにCEマーク取得済みの製品を欧州向けに転用する場合でも、CRAの要件を別途確認することが不可欠です。

継続的な運用体制を構築する

製品のリリース後も、CRAへの継続的な対応が求められます。

• 24時間以内の報告体制の整備: 悪用されている脆弱性を発見した場合、24時間以内にENISAへ初期報告できる社内プロセス・連絡体制を構築する
• サポート期間中のセキュリティアップデート提供体制の確立: 製品の想定ライフサイクル全体または最低5年間のいずれか短い期間にわたり、セキュリティパッチを無償で継続提供できる開発・リリース体制を整備する
• 脆弱性管理プロセスの確立: OSSや外部コンポーネントの脆弱性情報を継続的にモニタリングし、迅速に対応できる仕組みを構築する

とくに製品リリース後の運用体制づくりは、製品開発部門だけでなく、品質保証・情報セキュリティ・法務など複数部門が横断的に連携することが不可欠です。

CRA施行スケジュールと早期対策の重要性

CRAの施行スケジュールは以下のとおりです。

• 2024年11月20日: EU官報（Official Journal）への掲載
• 2024年12月10日: CRA発効
• 2026年6月11日: 通知機関（Notified Bodies）に関する条項の適用開始
• 2026年9月11日: 脆弱性・インシデントの報告義務が先行適用開始
• 2027年12月11日: CRAの全面適用（認証義務を含むすべての要件）

「全面適用は2027年末だから、まだ時間がある」と考えるのは危険です。万が一対応できなかった場合、以下のような深刻な影響が生じます。

• 巨額の制裁金: 売上高の最大2.5%、または最大1,500万ユーロの制裁金が科される可能性がある
• 製品の販売停止・リコール: 市場監視当局が製品のリスクを認定した場合、販売停止・回収命令が下される可能性がある
• EU市場からの排除: CRAに準拠できなければCEマークを取得できず、EU市場での製品流通が認められなくなる

また、製品開発から認証取得までには一般的に1〜3年程度の期間を要します。スケジュールを逆算し、計画的にセキュリティ対策を強化していきましょう。

CRA対策をする上での注意点

CRA対応を進める中で、見落とされがちな重要ポイントを以下に整理します。対応漏れが重大なリスクにつながりかねないため、あらかじめ認識しておきましょう。

報告義務が先に開始される

CRAの全面適用（認証義務）は2027年12月11日ですが、報告義務は15ヶ月前である2026年9月11日から先行して開始されます。

多くの企業が「全面適用まで対策は不要」と誤解しがちですが、報告義務への対応は2026年9月から求められます。対象となるのは、悪用されている脆弱性や重大なセキュリティインシデントです。

これらが発生した場合、24時間以内の初期報告・72時間以内の詳細報告が義務付けられており、遅延した場合は制裁の対象となります。

さらに注意が必要なのは、すでに市場に出ている既存製品も報告義務の対象になるという点です。CRA発効以前にリリースした製品であっても、2026年9月11日以降に脆弱性が発覚・悪用された場合は報告義務が生じます。

新製品の開発対応と並行して、既存製品の脆弱性管理体制の整備を、今すぐ着手することが不可欠です。

サプライチェーンの責任も負うことになる

自社で開発していないソフトウェア部品（OSSや他社製コンポーネント）についても、製品メーカーがセキュリティ上の責任を負います。

CRAでは、「製品に組み込まれた外部部品が製品全体のセキュリティを損なわないか確認する義務」がメーカーに明確に課されています。この義務を果たすためには、SBOMの整備が事実上必須となります。

SBOMを整備しておくことで、以下の対応が可能になります。

• 既知の脆弱性（CVE）との継続的な突合: 使用しているOSSやコンポーネントに新たな脆弱性が生じていないかを継続的に確認できる
• 影響範囲の迅速な特定: 新たな脆弱性情報が公開された際に、自社製品への影響を素早く特定し対応できる

また、外部コンポーネントに脆弱性を発見した場合には、その部品のメーカー（上流サプライヤー）に報告し、修正を促すプロセスの構築も必要です。自社だけでは解決できない問題も含まれるため、サプライチェーン全体を巻き込んだ対応体制の整備が欠かせません。

CRA対策のために今すぐ行うべきこと

CRA対策を効果的に進めるには、段階的かつ計画的なアプローチが重要です。

まず行うべきは、自社製品が自己宣言で済む「一般製品」（約90%）に該当するか、または「重要な製品（クラスI・II）」として第三者機関による審査が必要になりそうかを仕分けすることです。

この分類によって、必要な対応の難易度・コスト・スケジュールが大きく変わります。その後は、以下のアクションを優先的に進めることを推奨します。

• 現状のギャップ分析の実施: CRAが求める要件と現状の製品・開発プロセスとのギャップを可視化する
• SBOMの整備着手: 製品に含まれるソフトウェアコンポーネントのリストアップを早期に開始する
• 報告体制の構築: 2026年9月からの報告義務に対応できる社内フロー・連絡体制を整備する
• 社内リソースの確保: セキュリティ専門人材の採用情報を公開し、育成体制を整える。または外部専門家の活用を検討する

CRA対応は、品質保証部門・開発部門・法務部門・経営層が一体となった取り組みが不可欠です。社内にセキュリティ技術者が不足している場合は、専門コンサルタントや認証機関による支援を活用することも有効な選択肢です。

自社のCRA対応状況の診断や具体的な対策の進め方についてお悩みの場合は、ぜひお気軽にご相談ください。

2026年6月19日公開
※この記事に掲載されている内容、および製品仕様、所属情報（会社名・部署名）は公開当時のものです。予告なく変更される場合がありますので、あらかじめご了承ください。