欧州サイバーレジリエンス法（EU CRA）―製造業が今取るべき対策―

あらゆるコネクテッド製品が対象となる

CRAの対象となるデジタル要素を含む製品とは、2027年12月11日以降に欧州市場で販売されるコネクテッド製品です。より正確には、製造者が意図した目的または合理的に予見可能な使用において、デバイスまたはネットワークへ論理的あるいは物理的にデータ接続するハードウェアやソフトウェア、遠隔データ処理ソリューション製品です。製品自体が直接接続する場合だけなく、OSを介してネットワーク接続をするテキストエディターのような、他システムなどを通じて間接的に接続する製品も対象に含まれます。

対象品の具体例として、PC、スマートフォン、スマート家電、産業IoT機器の他、アプリストア経由でダウンロードしてデバイスにインストールするようなソフトウェアや、機器へのインストールを目的とした単体で流通する、あるいは製品に同梱されているソフトウェアなどの製品があります。加えて、製造者が設計・開発、あるいはその責任下で設計・開発させたソフトウェアによる遠隔でのデータ処理であって、それがなくては当該製品の機能の一部が実行できなくなるような遠隔データ処理ソリューションも対象となっている点に注意が必要です。

対象製品の該非判断は図表1のとおりです。

図表1：対象製品の判断

CRA規制対象外製品とその例外

まず、接続機能を有さない製品はCRAの対象外となります。例えば、ある食器洗浄機が洗浄サイクルを制御する組み込みファームウェアを搭載していたとしても、それが直接あるいは間接的に他のデバイスやネットワークに接続する機能を持たない場合はCRAの適用を受けません。また、製品の機能をサポートしないウェブサイトや製造者の責任範囲外で設計されたSaaS、クライアントソリューションも規制の対象外です。その他に、2027年12月11日以前に上市された製品や、自社用の製品、テスト用の未完成品、国家安全保障国防関連製品、航空、船舶など欧州個別法令によって規制される製品なども原則としては規制対象外となります。

ただし、図表2で示すようにこれらのケースには例外が存在します。例えば、CRAが全面適用される2027年12月11日以前に上市された製品について、2027年12月11日以降に新しい機能の追加など製品のリスクプロファイルを変化させるような実質的な変更やアップデートが行われた場合には、改めて適合性評価を行う必要が生じます。

また、CRA規制対象外である自社用の製品を市場に流通させた場合や、テスト用の未完成製品について、想定される使用期限や方法などを超えて使用させた場合などは規制の対象となる可能性があります。加えてテスト用の未完成ソフトウェアについては、上記に該当しない場合であってもリスク評価を実施した上で公開し、可能な限りCRAに基づいたセキュリティ要件と脆弱性対応要件を実装するべき旨が定められている点に注意が必要です。

他にも、国家安全保障、国防に使われる「デュアルユース」製品を民間用に流通させる場合や、航空、船舶などに関する製品で、欧州個別法令で直接規制されてない場合はCRAの適用対象となります。

図表2：対象外となるケースとその例外

製造業者が対応すべきCRAの法令要件の範囲

CRAは8つの章、71の条項により構成されています。この中で、製造業者に直接的な影響を及ぼす範囲は、主に第Ⅱ章（13条～15条）となります（図表3）。輸入業者や販売代理店に対しても、その輸入、販売するデジタル要素を含む製品のCRA準拠状況を確認する義務を課しています。また、CRA上の義務履行の実効性を確保するため、欧州域外から直接製品を上市する製造者に対しては域内に輸入者、認定代理人、フルフィルメントサービスプロバイダーのいずれかを設置することが求められます。

図表3：製造業者が対応すべきCRAの法令要件の範囲

CRAで製造者に求められる対応は、リスク評価の実施、製品に関する必須セキュリティ要件の実装、脆弱性ハンドリング要件の実装、製品コンポーネントに関するデューディリジェンスの実施、製品のサポート期間の設定、積極的に悪用された脆弱性や重大インシデントの報告の6つに大別されます。

リスク評価の実施

CRA第13条2項と3項に基づき、製造者は遠隔データ処理ソリューションを含む製品全体についてその特性や用途を踏まえた脅威モデリングを含む自身が決定したアプローチでリスク評価を行います。そして、その結果に基づいて製品の企画から出荷後の保守までを含めたライフサイクル全体でリスクを最小化し、インシデントとその影響を防止し最小化するための適切なリスク管理と対策を実装します。その結果は、規制当局が確認できるように文書化することが求められます。また、リスク評価は製品のサポート期間を通じて継続的に更新される必要があります。

リスク評価において脅威モデリングを行う際には製造者が意図した製品の使用目的のみならず、製品の合理的に予見可能な使用と誤使用も踏まえて行うことが求められています。それぞれの具体的な定義は以下のとおりです。「意図された目的」とは、使用説明書、販売資料、技術文書などで製造業者が示した具体的な使用事例や使用条件などを指します。「合理的に予見可能な使用」とは、意図された目的とは必ずしも一致しないものの、合理的に予見可能な人間の行動または技術的な操作などから生じる可能性のある使用事例です。この例としては、川下における他部品の組み込みや専門家ではないユーザーによる使用が挙げられます。一方で、「合理的に予見可能な誤使用」とは製品をその意図された目的とは異なる方法であって、かつ、合理的に予見可能な人間の行動または他のシステムとの相互作用から生じる可能性のある方法で使用することです。例としては、製造者の指示に反して安全ではないネットワークへ製品を接続することや製品に対するセキュリティ研究、ハッキングなどが挙げられます。製造者は設計などを通じてこのようなケースに対応した上で、想定利用や設定から逸脱した場合のリスクについてユーザーに明確に通知することが求められます。

製品に関する必須セキュリティ要件の実装

CRAでは付属書IのPart.1において対象製品が満たすべき必須セキュリティ要件が規定されており、前述のリスク評価に基づいて適切に実装されることを求めています。リスク評価の結果として、付属書IのPart.1における特定の要件について製品の性質上実装が難しい、あるいは製品の意図された使用目的や合理的に予見可能な使用・誤使用において軽減すべきリスクが存在しないと判断できる場合、リスク評価文書にその旨を明示した上で要件を適用しないという対応も認められる可能性が高いです。

CRA 付属書I Part.1 必須セキュリティ要件

1. デジタル要素を含む製品は、リスクに応じた適切なレベルのサイバーセキュリティを確保するように設計、開発、生産されなければならない
2. リスク評価に基づき、デジタル要素を含む製品は、以下のようにしなければならない

a. 悪用可能な既知の脆弱性がない状態で市販されること

b. デフォルトでセキュアな設定および設定のリセット機能（ユーザーと別途合意可能）

c. 更新による脆弱性への対処の保証（該当する場合、デフォルトで自動更新＜オプトアウト可能＞および更新のユーザー通知を含む）

d. 不正アクセスからの保護（例：認証、ID、アクセス管理）と報告

e. データの機密性保護（例：暗号化）

f. データの完全性保護（改ざん防止／対応）

g. 処理するデータの最小化

h. サービス妨害（DoS）攻撃対策を含む重要な機能の可用性を保護

i. 周辺機器・ネットワークへの可用性への影響最小化

j. 外部インターフェースを含む攻撃面への対策

k. インシデントの影響を軽減するための対策

l. システムの監視

m. データの完全削除、転送の場合のセキュリティ保証

これらの要件のうち、特に注意が必要な点について補足します。まず、a.の既知の悪用可能な脆弱性がない状態とは、実際の製品の運用環境において技術的あるいは現実的に悪用可能な既存の脆弱性が製品に含まれない状況を指します。例えば、攻撃者が被害者のスマートフォンを獲得した上で機器を分解して物理的に改ざんを加えることで初めて悪用可能になるといった、現実的な悪用が想定しがたい脆弱性の解消までは求められていません。

a.に関連してもう1点重要なのが、流通過程にあってユーザーの手元に届いていない製品の脆弱性が判明した場合に回収の必要はあるのかという点です。このようなケースについて製品の回収までは求められません。しかし、後述するようにCRAではサポート期間中の製品についての脆弱性対応を求めています。そのため、ユーザーが製品を使用開始した直後から、当該脆弱性に対処するためのセキュリティアップデートを利用できるようにするといった対応は求められます。

次に、b.の製品をデフォルトでセキュアな状態で提供するという要件について、製品のコンポーネントの製造者とそのコンポーネントを組み込んだ完成品の製造者の責任範囲はどのように考えればよいのでしょうか。この場合、コンポーネントの製造者はコンポーネント自体がデフォルトでセキュアな状態で市場に提供されることを保証する必要があります。一方で、コンポーネントを統合した完成品に対しては完成品の製造者が責任を負います。また、特定の顧客向けのテーラーメイド製品（図表4）については、後述するCRA 付属書I Part.2 脆弱性ハンドリング要件8.と併せて、顧客と合意の上で適用しないことを選択できます。

最後に、c.のセキュリティアップデートによる脆弱性への対応については、可能な限り機能アップデートとの抱き合わせは避けるべき旨が定められています。ただし、セキュリティアップデートを実施する上で機能アップデートが不可欠な場合などの正当な理由がある場合は逸脱が認められています。

図表4：テーラーメイドの該当例

^{CRA法案に基づきPwC作成}

脆弱性ハンドリング要件の実装

CRAでは付属書IのPart.2において、脆弱性ハンドリング要件が規定されています。

CRA 付属書I Part.2 脆弱性ハンドリング要件

1. デジタル要素を含む製品に含まれる脆弱性とコンポーネントを特定し、文書化する。これには、少なくともデジタル要素を含む製品のトップレベルの依存関係を網羅する、一般的に使用され機械で読み取り可能な形式のソフトウェア部品表（SBOM）を作成することを含む。
2. 脆弱性への対処。技術的に可能な場合、セキュリティ更新は、機能の更新とは別に提供すること。
3. デジタル要素を含む製品のセキュリティについて、効果的かつ定期的なテストとレビューを実施
4. 原則として、セキュリティアップデートが提供された後、修正された脆弱性についての情報（脆弱性の説明、影響を受けるデジタル製品を特定できる情報、脆弱性の影響、深刻度、脆弱性を修正するための情報を含む）を一般に公開
5. 脆弱性の協調的な開示に関するポリシーを導入し、実施
6. デジタル製品およびその製品に含まれる第三者のコンポーネントの潜在的な脆弱性に関する情報の共有を促進するための措置を講じること（デジタル技術を用いた製品で発見された脆弱性を報告するための連絡先を提供することを含む）
7. デジタル要素を含む製品の更新を安全に配布し、脆弱性が適時に修正または緩和され、セキュリティ更新に該当する場合は、自動的な方法で修正または緩和されることを保証する仕組みを提供すること
8. 特定されたセキュリティ問題に対処するためのセキュリティパッチやアップデートが利用可能な場合、それらが遅滞なく、かつ無償（別途合意ある場合を除く）で、ユーザーが取るべき潜在的な措置を含む関連情報を提供する勧告メッセージを添付して普及されることを保証する

リスク評価に基づいて実装されるCRA 付属書I Part.1 必須セキュリティ要件とは異なり、Part.2 脆弱性ハンドリング要件は全ての製品について対応が必要です。製造者は製品ライフサイクル全体を通じて脆弱性の修正を実施し、それができない場合は合理的なリスク緩和策を実施する必要があります。特に、ハードウェア製品などの脆弱性で侵害された場合に重大なリスクをもたらすものについて、修正あるいは緩和のいずれでも対処できない場合については、製品のリコールなどが求められる可能性があります。

一方で、全ての脆弱性に対して網羅的にパッチを提供することが求められているわけではなく、脆弱性のリスクレベルに応じた対応が認められています（図表5）。また、要件7.で定める自動のセキュリティ更新についても、主に他製品のコンポーネントとして統合されることを意図した製品や、OT環境などの自動更新が困難あるいは業務の継続に影響を与え得る環境で利用される製品については適用されません。加えて、ユーザーが提供されたパッチや自動あるいは自動ではないセキュリティ更新の適用を拒否あるいは延期する場合については、製造者は責任を負わないと想定されます。

図表5：脆弱性のリスクレベルに応じた対応

^{CRA法案に基づきPwC作成}

その他の注意点として、複数のソフトウェアバージョンが存在する際の対応と製品コンポーネントの製造者の責任範囲が挙げられます。前者について、サポート期間内にある全てのソフトウェアのバージョンが脆弱性管理の対象となります。ただし、最後に市場に投入したバージョンがその前のバージョンと比べて大幅に変更されており、以前投入したバージョンのユーザーが最新版のバージョンを無償で導入可能な場合については最新版に対してのみの対応で十分です。

後者について、原則として完成品の製造者が製品全体としてCRAの要件を満たすように対応する義務を有します。ただし、CRAに適合した上で市場に投入されたコンポーネントを組み込んだ場合、当該コンポーネント自体の脆弱性対応についてはコンポーネントの製造者による適合を根拠とすることが可能です。

製品コンポーネントに関するデューディリジェンスの実施

CRA第13条1項に基づき、製造者は第三者から調達する製品コンポーネントに関するデューディリジェンスを実施する必要があります。製造者は、当該コンポーネントを統合することで製品のサイバーセキュリティが損なわれることがないかを確認することが求められます。市場で提供されていない無償およびオープンソースのソフトウェアのコンポーネントを統合する場合もデューディリジェンスは必要です。関連する動向として、欧州委員会はオープンソースのソフトウェアに関する任意のセキュリティ認証プログラムの策定を検討しています。

デューディリジェンスの方法としては、例えばCEマーク取得状況の確認を通したCRAへの適合状況の確認、当該コンポーネントのセキュリティ更新状況、既知の脆弱性の有無、追加的なセキュリティテストの実施などが挙げられます（図表6）。

図表6：デューディリジェンスの方法例

^{CRA法案に基づきPwC作成}

製品のサポート期間の設定

CRA第13条8項に基づき、製造者は製品のサポート期間を設定する必要があります。サポート期間は原則として製品寿命と同等であり、類似製品のサポート期間、利用環境の可用性、統合されているコンポーネントのサポート期間、技術の陳腐化の可能性、製造者が意図するあるいは合理的に予期される利用方法などを考慮して設定することが求められます。ただし、製品寿命が5年未満である場合を除いて最低限5年のサポート期間の設定が求められる点には注意が必要です。

積極的に悪用された脆弱性や重大インシデントの報告

CRA第14条に基づき、製造者は製品についての悪用された脆弱性や重大インシデントを認識した際に、当局に対して24時間以内の早期通知と72時間以内の報告を実施する義務を有します。この報告要件は、2027年12月11日以前に上市された製品にも適用されます。

CRAの第14条はあくまでも製造者が積極的に悪用された脆弱性や重大インシデントを報告する義務を課すものであり、これらの報告対象となる事象を監視するための具体的な体制や活動について規定していません。製造者が積極的に悪用された脆弱性や重大インシデントを把握する上での経路の例としては、図表7で示すように第三者からの通知や、脅威インテリジェンス活動者からの報告、製造者の監視活動、スキャン活動などが考えられます。製造者がこのような活動を通して把握した事象が報告対象であると判断した時点が、積極的に悪用された脆弱性や重大インシデントを認識した時点になると想定されます。

図表7：悪用された脆弱性や重大インシデントを認識する手段の例

^{CRA法案に基づきPwC作成}

CRA上で報告義務の対象として定められる重大なインシデントとは、以下のいずれかに該当するものです。

A）デジタル要素を備えた製品の、製品の機能、機密あるいは重要なデータの可用性、真正性、完全性、機密性を保護する製品の能力に悪影響を及ぼす、またはその可能性がある

B）デジタル要素を備えた製品、またはそのユーザーのネットワークおよび情報システムに悪意のあるコードが挿入あるいは実行される、またはその可能性がある

報告対象となる悪用された脆弱性とは、当該脆弱性を突いた侵害が発生している可能性があり、それを認識した場合に該当します。存在が確認されているものの実際に悪用されている証拠がない、あるいは前述したように製品の実際の運用において攻撃することが現実的でないと考えられる脆弱性は対象ではありません。また、バグハンティングやセキュリティテストなどで発見されたゼロデイ脆弱性なども14条に基づく報告対象には含まれません。ただし、第15条に基づいてこれらの脆弱性を当局に対して自主的に報告することは認められています。

水平・垂直で組み合わせるサイバーセキュリティ要件

前のセクションで紹介した内容のうち、CRA 付属書I Part.1 必須セキュリティ要件とPart. 2 脆弱性ハンドリング要件については、整合規格の整備が進められています。整合規格自体は法定必須要件ではありませんが、これらの規格に準拠した製品はCRA27条に基づき付属書Iが定める要件へ適合していると推定されます。製品特性を踏まえて部分的な適用によって適合性推定を行うことも可能ですが、その場合は部分適用によってCRA要件に適合できる根拠を技術文書に含める必要があります。

整合規格には、水平的整合規格（Horizontal standards）と垂直的整合規格（Vertical standards）が存在します。水平的整合規格は、製品種類に関係なく必要となる普遍性の高いセキュリティ要件です。一方で、個別製品の特性を踏まえて適用されるのが垂直的整合規格です。垂直的サイバーセキュリティ要件は、主にCRA付属書Ⅲ、Ⅳに列挙されている製品ごとに規定されるセキュリティ要件であり、その対象製品の特性に合わせて水平的サイバーセキュリティ要件を補完するものと考えられます。例えば、製品のセキュリティアップデートについて水平的セキュリティ要件では迅速に自動アップデートを求めるのに対して、自動アップデートが困難であるような産業機器については従来のアップデートの方法を用いるなど、サイバーセキュリティ必須要件からの逸脱を認めることなどが想定されます。

デジタル要素を含む製品の分類

CRAでは対象製品をその特性に合わせていくつかのグループに分類しており、特定のカテゴリーに属する製品についてはより厳密な適合性評価手順を適用する必要があります（図表8）。付属書ⅢとⅣに分類される製品については、2025年11月28日に公表された実施規則（EU）2025/2392によって補足的な説明と非網羅的な事例が提示されています。付属書IIIに含まれる重要な製品クラスIの例としてはID管理やブラウザ、VPN、OSなどを含む19カテゴリー、クラスIIの例としてはファイアウォールや産業用制御システムを含む6カテゴリー、付属書IVに含まれるクリティカルな製品の例としてはHSMやスマートカード／セキュアエレメント、スマートメータゲートウェイの3カテゴリーが示されています。ただし、これらは当該製品のコア機能に着目した分類であることに注意してください。例えば、PCにセキュアエレメントが組み込まれていたとしても、PC全体がただちにクリティカルな製品に分類されるわけではなく、製品全体としてのコア機能がセキュアエレメントであると判断される場合にのみクリティカルな製品に分類されます。今後も欧州委員会が分類を見直す可能性があり、継続的なモニタリングが推奨されます。

製品分類に関連したCRA対応上のもう1つのポイントとして、同じカテゴリーに分類される製品に画一的に同程度のセキュリティ要件の実装が求められるわけではないという点が挙げられます。CRAでは製造者が対象製品のリスク評価と比例した形で前述したサイバーセキュリティ要件を実装することを求めています。製造者は製品分類に関係なくリスク評価を実施し、たとえ同じカテゴリーに含まれる製品であっても、使用条件などを踏まえて適切な範囲でのセキュリティ要件実装を行う必要があります。例えば、同じVPN製品であっても重要インフラの運用向けに提供する場合と家庭用に提供する場合ではリスク評価とそれに基づく実装は異なる可能性が想定されます。

図表8：デジタル要素を含む製品の分類に係る判断

評価モジュールと適合性評価の流れ

CEマークを利用する製造業者は、デジタル要素を含む製品が付属書Iに定める要件に適合していること証明し、CEマークを取得する上で必要な適合性評価を行わなければなりません。前述のとおり、製品カテゴリーによって利用可能な適合性評価の手順が異なるため、確認が必要です。適合性評価に利用可能なモジュールはA、B＋C、Hの3種類です（図表9）。

図表9：適合性モジュールの概要

モジュールAは、製造業者がデジタル要素を備えた製品がCRAの基本要件に適合していることを検証し、自らの責任において適合を宣言する適合性評価手続きである。

モジュールB＋Cは、製品がCRAの基本要件に適合することを検証し、通知機関（NB）が製品の設計および開発を審査し、製造者が適合を宣言する適合性評価手続である。

モジュールHは、製造者が完全な品質管理システムを実施し、当該システムの対象となる製品が設計段階および生産段階の両方でCRAの基本要件に適合することを保証する適合性評価手続である。

^{CRA法案に基づきPwC作成}

これらのどのモジュールが利用可能かについての場合分けは、以下図表10のように整理されます。

図表10：適合性評価の流れと評価モジュールの選択

タイムライン

CRAは、2024年10月10日に成立し、2027年の全面適用に向けて段階的に適用されます。また、法令自体の適用に加えて、欧州委員会の要請に基づく欧州標準化当局（以下、ESOs）によるCRAの付属書Iの要件に関する整合規格が整備されます。具体的には、ESOsに対して整備されるべき標準のリストが指定され、ESOsは既存規格の改定または新規格の起草で対応を行います。前述したようにCRAの整合規格はCRAの対象となるデジタル要素を含む製品種類に関係なく適用される水平的整合規格と、特定製品に追加で適用される垂直的整合規格がセットで整備される予定です。図表11に示すとおり、全ての整合規格の整備が完了するのは2027年10月頃になる見込みですが、2026年1月現在において一部の整合規格のドラフトが公開されています。

図表11：整合規格のタイムライン

総合的に勘案し、CRAの全面適用までのスケジュールは図表12のタイムラインに示すようなものになると考えられます。

図表12：CRAに関する全体のタイムライン