LASSIC Media らしくメディア
EUサイバーレジリエンス法(CRA)とは|対象と義務
自社の製品やソフトウェアを、EU(欧州連合)市場でも売っている。あるいは、EU向けに製品を出す取引先のために、組み込みソフトウェアやアプリを受託開発している——。そんな企業にとって、見過ごせない規制が動きだしています。EUサイバーレジリエンス法(CRA)です。ソフトウェアやハードウェアといった「デジタル要素を持つ製品」に、サイバーセキュリティの要件を義務づける規制で、2024年12月に発効しました。そして2026年9月には、脆弱性などの報告義務が始まります。
この規制もまた、EUの個人データ保護規則(GDPR)やEU AI規制と同じように、EUの外にある企業にも及ぶ場合があります。つまり、日本の製造業やソフトウェア開発の現場にとっても、決して他人事ではないのです。本記事では、製品開発やその委託に関わる情報システム部門・事業部門の担当者に向けて、CRAとは何か、誰が対象になるのか、どんな義務があるのか、受託・委託開発で何を押さえるべきかを整理します。なお、本記事は一般的な情報の整理であり、法的な助言ではありません。個別の適否は、公式文書や専門家にご確認ください。
目次
EUサイバーレジリエンス法(CRA)とは
EUサイバーレジリエンス法(CRA=Cyber Resilience Act)とは、EUが定めた、デジタル要素を持つ製品のサイバーセキュリティに関する規制です。ここでいう「デジタル要素を持つ製品」とは、ソフトウェアやハードウェアのうち、機器やネットワークと直接または間接につながる使い方が想定されるものを指します。身近な例でいえば、業務用のアプリケーション、IoT機器、組み込みソフトウェアを載せた装置などが幅広く当てはまります。
ねらいは、こうした製品がサイバー攻撃の穴になりにくいようにすること。そのために、製品を作る側に、設計から開発、保守にいたるまでのセキュリティ対策を求めます。これまで製品のセキュリティは、作り手の自主的な取り組みに委ねられる部分が少なくありませんでした。CRAは、そこに横断的な共通ルールを敷き、守るべき水準を定めた規制だといえます。全体像を図にまとめました。
この記事のポイント
- CRAは、デジタル要素を持つ製品にサイバーセキュリティ対策を義務づけるEUの規制で、設計から保守まで全体を対象とします。
- GDPRやEU AI規制と同じく域外適用があり、EU市場に製品を出す日本企業も対象になりえます。
- 受託・委託開発では、サポート期間の取り決めと脆弱性対応の体制づくりが要になります。
対象になる製品と事業者
CRAの対象は、デジタル要素を持つ製品をEU市場に出す事業者です。具体的には、製品を作る「製造者」、EU域外の製品をEUに持ち込む「輸入者」、それを売り広める「流通者」が、それぞれの立場で義務を負います。ここで押さえておきたいのが、対象は所在地では決まらない、という点です。拠点が日本にあっても、自社の製品がEU市場に出るのであれば、対象になりうるわけです。輸入者を通じてEUで売られる製品も含まれるため、直接の輸出でなくても関わってくる場面があります。
いっぽうで、対象から外れる、あるいは軽い扱いになるものもあります。たとえば、商業的に提供されるのではないオープンソースソフトウェアは、原則として対象の外に置かれます。また、オープンソースを世に送り出す担い手(スチュワード)には、製造者よりも軽い義務が用意されているのです。自社が扱うソフトウェアやハードウェアが、そもそも対象になるのか。まずはその見極めから始めるとよいでしょう。
製品の区分と適合性評価
CRAは、すべての製品を一律に扱うわけではありません。製品のリスクの高さに応じて区分を設け、確かめ方(適合性評価)の厳しさが変わるのです。おおまかに整理すると次のようになります。
| 区分 | おおまかな性格 | 適合性評価の傾向 |
|---|---|---|
| 一般の製品 | 大半の製品が該当 | 自己評価でよい場合が多い |
| 重要な製品(クラスⅠ) | リスクがやや高い | 整合規格に沿えば自己評価、沿わなければ第三者評価 |
| 重要(クラスⅡ)・重大な製品 | リスクが高い | 第三者による評価などが求められる |
一般の製品であれば、決められた要件を満たしているかを自分たちで確かめる自己評価で足りる場合が多くなります。これに対して、リスクがより高いと位置づけられた「重要な製品」や「重大な製品」では、第三者による評価が必要になることがあります。どの区分に当たるかによって、備えるべき手間や時間が変わってくるわけです。要件を満たした製品には、EUで流通させるための「CEマーキング」を付けます。自社の製品がどの区分に置かれるのかを早めに見極めておくと、後の段取りが立てやすくなります。
事業者に求められる主な義務
製造者に課される義務は、製品ライフサイクルの全体にわたります。おもだったものを挙げてみましょう。まず、設計・開発の段階から、定められたセキュリティの要件を満たすように作ること。いわゆる「セキュリティを前提にした設計」の考え方です。あわせて、製品にどんなリスクがあるかを評価し、その結果を対策に反映させることが求められます。外部から取り込む部品やソフトウェア(サードパーティのコンポーネント)についても、素性を確かめる目配りが要ります。ここは、部品構成を一覧にするSBOM(ソフトウェア部品表)の考え方とも重なる部分です。
加えて、技術文書を整えて当局に示せるようにすること、適合性評価を経てCEマーキングを付けること、そして製品を支える「サポート期間」を定めて利用者に明示することなどが挙げられます。サポート期間とは、セキュリティ更新などの手当てを続ける期間の目安です。売って終わりではなく、いつまで面倒を見るのかをはっきりさせる、という発想が根っこにあります。これらは、開発が終わってから慌てて足すより、初めから見込んで進めるほうが、負担を小さく抑えられるものです。
脆弱性・重大事象の報告義務(2026年9月から)
CRAのなかでも、早い時期に効いてくるのが報告の義務です。2026年9月から、悪用が確かめられた脆弱性や、製品のセキュリティに関わる重大な事象について、当局へ知らせることが求められます。報告には段取りがあり、まず早期の警告を短時間のうちに、続いて詳しい通知を、そして最終的な報告をまとめる、という流れです。連絡先は、各国のCSIRT(セキュリティ対応の窓口となる組織)や、EUの機関であるENISAとされています。
報告の期限は短く、体制のないまま迎えると立ち行かなくなりがちです。脆弱性が見つかったとき、誰が、どの順で、どこへ連絡するのか。この流れをあらかじめ決めておくことが、いざというときの支えになります。製品のセキュリティに関する事象を受け止め、対応する社内の体制、いわゆるPSIRT(製品セキュリティ対応の体制)を整えておくと、報告の義務にも向き合いやすくなるでしょう。なお、すでに市場に出ている製品についても、報告の義務は関わってくるとされているため、既存の製品を持つ企業も無縁ではありません。
日本企業に関わる理由とEU AI規制との関係
くり返しになりますが、CRAは所在地ではなく「EU市場に製品を出すか」で対象が決まります。だからこそ、EUに拠点を持たない日本企業にも及ぶ場合があるのです。自社製品を直接EUで売るケースはもちろん、EU向けの製品に載せる部分を受託開発するケースでも、求められる水準は関わってきます。作り手の義務は、部品やソフトウェアを供給する側にもつながっていくためです。
ここで、EUのもう一つの規制と整理しておくと分かりやすくなります。EU AI規制(AI Act)がAIのリスクに応じた義務を定めるものだとすれば、CRAは製品全般のサイバーセキュリティを対象とするものです。ねらいや対象は違いますが、どちらもEU市場を軸に域外へ及ぶ点は共通しています。AIを組み込んだ製品をEUに出す場合、両方の規制が同時に視野に入ることも考えられます。片方だけを見て済ませず、自社の製品がどの規制に触れるのかを、あわせて棚卸ししておきたいところです。
まとめ:CRAで押さえる3つの視点
EUサイバーレジリエンス法(CRA)は、製品のサイバーセキュリティに、EUの共通ルールを敷く規制です。押さえておきたい視点は三つに整理できます。第一に、CRAはデジタル要素を持つ製品に、設計から保守までのセキュリティ対策を義務づけるものであり、製品の区分に応じて確かめ方の厳しさが変わること。第二に、GDPRやEU AI規制と同じく域外適用があり、EU市場に製品を出す日本企業も対象になりうること。第三に、受託・委託開発では、サポート期間の取り決めや、脆弱性対応の体制づくり、外部部品の目配りが対応の要になることです。まずは、自社の製品やソフトウェアがCRAの対象になるのか、なるとしてどの区分に当たるのかを見極めるところから。判断に迷う部分があれば、公式文書の確認とあわせて、外部の知見を頼るのも堅実な選び方といえます。
よくある質問
EUに拠点がない日本企業も、CRAの対象になりますか。
なりうると考えるのが妥当です。CRAは拠点の所在地ではなく、デジタル要素を持つ製品をEU市場に出すかどうかで対象が決まります。自社製品を直接EUで売る場合はもちろん、輸入者を通じてEUで売られる製品も対象に含まれるのです。まずは、自社の製品がEU市場に出ているか、出る予定があるかを棚卸しすることをおすすめします。
「デジタル要素を持つ製品」とは、具体的に何を指しますか。
ソフトウェアやハードウェアのうち、機器やネットワークと直接または間接につながる使い方が想定されるものを指します。業務用アプリケーション、IoT機器、組み込みソフトウェアを載せた装置などが幅広く当てはまるものです。いっぽう、商業的に提供されないオープンソースソフトウェアは、原則として対象の外に置かれます。
いつから何が始まりますか。
CRAは2024年12月に発効しました。段階的に適用が進み、2026年9月からは脆弱性や重大な事象の報告義務が始まります。そして2027年12月から、主な義務が本格的に適用される見込みです。報告の義務は早い時期に効いてくるため、体制づくりを前倒しで進めておくと危なげがありません。
受託開発でソフトを作る立場でも、関係しますか。
関わる場面があります。EU向けの製品に載せるソフトウェアや部分を受託開発する場合、作り手に求められるセキュリティの水準は、供給する側にもつながっていくのです。契約の段階で、どこまでの範囲を担い、脆弱性対応やサポートをどう分担するのかを取り決めておくと、後の食い違いを防ぎやすくなります。
まず何から着手すればよいですか。
自社の製品やソフトウェアがCRAの対象になるかの見極めから始めるとよいでしょう。対象になる場合は、どの区分に当たるか、求められる義務は何かを整理します。そのうえで、セキュリティを前提にした設計や、脆弱性対応の体制、サポート期間の取り決めを進めていきます。判断に迷う部分は、公式文書の確認と専門家への相談を組み合わせるのが堅実です。
著者:テレリモ総研編集部 鈴木 亮佑
EU市場向け製品のセキュリティ対応はLASSICへ
元請(プライムベンダー)として、CRAの対象の見極めから、セキュリティを前提にした設計・脆弱性対応の体制づくりまで、貴社の製品開発に合わせてご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 参考:European Commission「Cyber Resilience Act|Shaping Europe’s digital future」(https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act)。制度の概要・対象・義務の一般的な参考として。
- *2 参考:European Commission「The Cyber Resilience Act – Summary of the legislative text」(https://digital-strategy.ec.europa.eu/en/policies/cra-summary)。製品区分・報告義務・適用時期の参考として。