QUALIこの記事の要点SUMMARY
- CRAはデジタル要素を持つ製品が対象。ソフト単体だけでなく、通信機能を持つ産業機器や家電も含まれる
- 2026年9月11日から脆弱性・重大インシデントの報告義務が先行して始まり、2027年12月11日に主要義務が全面適用される
- 報告は24時間以内の早期警告し、72時間以内の通知、14日以内の最終報告という段階になっている
「サイバーセキュリティの法律」と聞くと、IT企業やソフトウェア会社の話に思えるかもしれません。しかし CRA（Cyber Resilience Act：サイバーレジリエンス法） の対象は、デジタル要素を持つ製品です。通信機能のある産業機器、制御基板の入った装置、アプリと連携する製品——これらを作ってEUへ出しているなら、製造業でも対象になります。この記事では、いつ何が始まり、何をすることになるのかを整理します。
何のための法律か
背景にあるのは単純な問題意識です。売った後に放置される製品が多すぎる、というものでした。
| これまで起きていたこと | CRAが求めること |
|---|---|
| 脆弱性が見つかっても修正されない | サポート期間中は対処する |
| いつまでサポートされるか分からない | サポート期間を明示する |
| 初期パスワードが共通で変更もできない | 安全な初期設定にする |
| 何が入っているか分からない | 構成を把握する（SBOM） |
| 問題が起きても公表されない | 当局へ報告する |
| 買う側が安全性を判断できない | 適合を示してCEマーキング |
製品安全の考え方をサイバーセキュリティに持ち込んだ、と捉えると分かりやすくなります。機械に安全要求があるように、デジタル製品にもセキュリティ要求を課す——という構図です。
対象になる製品
「デジタル要素を持つ製品」という表現は広く、実際かなり広い範囲が入ります。
ソフトウェア単体
OS、アプリケーション、ライブラリ
ハードウェア＋ソフトウェア
**産業用制御機器、計測器、ネットワーク機器、IoT家電、通信機能のある装置**
遠隔データ処理を伴うもの
製品の機能に必要なクラウド側の処理も含まれうる
対象外の例
医療機器・自動車・航空など、**別の法令で同等の要求がかかる分野**は調整される
判断に迷ったら「つながるか」から考える
完全にスタンドアロンで、ソフトウェアの更新手段もなく、外部と一切通信しない製品であれば対象外の可能性があります。逆に、保守用のUSBポートやネットワーク接続があるなら、対象かどうかを確認する価値があります。境界の判断は原文とガイダンスによります。
スケジュール ― 報告義務が先に来る
CRAで注意すべきは、全部が同じ日に始まるわけではないという点です。とくに報告義務が先行します。
| 時期 | 何が始まるか | 実務への影響 |
|---|---|---|
| 2026年6月11日 | 適合性評価機関に関する規定 | 認証を担う機関側の整備が進む |
| 2026年9月11日 | 脆弱性・重大インシデントの報告義務 | 製品を出している企業に、報告の体制が必要になる |
| 2027年12月11日 | 主要義務の全面適用 | セキュリティ要求への適合、CEマーキング、技術文書など |
2行目が見落とされがちです。製品の設計要求より先に、報告の義務が始まります。「2027年まで時間がある」と考えていると、報告体制の準備が間に合いません。
報告の期限は段階になっている
**24時間以内：早期警告**
悪用が確認された脆弱性、または重大なインシデントを知ってから
**72時間以内：通知**
より詳しい情報、状況、講じた措置
**14日以内：最終報告**
脆弱性については、その後の対応を含めた最終的な報告
24時間という期限は、社内の意思決定としてはかなり短いものです。「担当者が気づいてから、上長に報告し、法務が確認し、経営が判断する」という通常のプロセスでは間に合いません。誰が判断し、誰が報告するかを事前に決めておく必要があります。
製造業のインシデント対応とは時間感覚が違う
品質不具合であれば、調査して原因を特定してから顧客へ報告する、という順序が一般的です。CRAの報告は「原因が分かってから」ではなく「知ってから24時間」です。情報が不完全でもまず報告する、という発想の切り替えが要ります。
求められる中身
| 領域 | 求められること | 実務での準備 |
|---|---|---|
| 設計段階 | セキュリティを考慮した設計と開発 | リスク評価、設計レビューへの組み込み |
| 初期設定 | 安全な状態で出荷する | 初期パスワードの個体別化、不要な機能の無効化 |
| 脆弱性管理 | 継続的に把握し、対処する | SBOMの整備（「SBOMとは」）、監視の体制 |
| 更新の提供 | 修正を届ける手段 | 更新の仕組み、可能なら自動更新 |
| サポート期間 | いつまで対応するかを明示 | 製品ごとのサポート方針の決定 |
| 報告 | 当局への報告 | 窓口、判断者、手順の整備 |
| 技術文書 | 適合を示す文書 | 設計・評価の記録 |
サポート期間の明示が地味に重い
見落とされやすいのが、サポート期間を決めて公表するという要求です。産業機器は10年、20年と使われることがあり、「いつまで面倒を見るか」を明言してこなかった企業は少なくありません。
| 決めること | 悩ましい点 |
|---|---|
| 期間の長さ | 短くすると顧客が困り、長くすると自社の負担が続く |
| 旧製品の扱い | すでに売った製品にどこまで遡るか |
| 部品・OSSの寿命 | 使っている部品やライブラリのサポートが先に切れることがある |
| 体制 | 長期間、対応できる要員を維持できるか |
| 費用 | 保守契約に含めるか、別に取るか |
3行目は根が深い問題です。自社製品のサポートを10年と宣言しても、内部で使っているOSやライブラリのサポートが5年で切れることがあります。そのとき何をするかまで含めて設計する必要があります。
脆弱性が出たとき、どこまで絞れるか
報告義務が始まると、実務では「知ってから24時間」で動くことになります。このとき最初に必要なのが、影響範囲の把握です。
ここでSBOMが効きます。ただしSBOMだけでは足りない場面があります。ソフトウェアの構成が分かっても、それがどの個体に入っているかは別の情報だからです。
脆弱性の公表
「ライブラリXのバージョン1.2以前に問題」
**SBOMで分かること**
自社のどのファームウェアにライブラリXが入っているか
**SBOMでは分からないこと**
**そのファームウェアが、どの出荷個体に書き込まれているか**
製造記録があれば
シリアル番号とファーム版・基板ロットの対応が分かり、対象を絞れる
| 把握できていないもの | 起きること |
|---|---|
| どの個体にどのファーム版が入っているか | 出荷した全台を対象に告知することになる |
| どの個体にどの基板ロットが載っているか | ハード起因の問題で範囲を絞れない |
| 出荷先 | 該当ユーザーへ個別に連絡できない |
| 出荷時期 | 対象期間を特定できない |
産業機器では、10年、20年と使われている個体について問い合わせが来ます。当時の構成が分かる記録が残っているか——これはサイバーセキュリティの話であると同時に、記録管理の話でもあります（「電子帳簿保存法と現場記録」）。
他の規制との関係
| 規制 | CRAとの関係 |
|---|---|
| 機械規則（2023/1230） | 機械の安全に関わるサイバーセキュリティを要求。CRAとは別の法律だが方向性は同じ（「EU機械規則とは」） |
| NIS2指令 | 重要インフラ等の組織に対する要求。CRAは製品、NIS2は組織という違い |
| AI Act | AIシステムへの要求。AIを含む製品では両方が関わりうる |
| 医療機器・自動車の規制 | 同等の要求がある分野は、重複を避ける形で調整される |
整理すると、製品に対する要求（CRA）と、組織に対する要求（NIS2）は別です。自社が工場としてNIS2の対象になるかという話と、自社製品がCRAの対象になるかという話は、分けて考える必要があります（工場側の話は「工場のOTセキュリティ」）。
よくある誤解
- 「ソフトウェア会社の話」：デジタル要素を持つ製品が対象です。通信機能のある産業機器も含まれます
- 「2027年まで時間がある」：報告義務は2026年9月11日から先行して始まります
- 「インシデントは調査してから報告」：知ってから24時間以内の早期警告が求められます
- 「ソフトは外注だから関係ない」：製品としてEU市場に出す立場であれば、責任は自社にあります
- 「日本国内向けの製品なら無関係」：その製品が組み込まれた設備がEUへ出るなら、要求は遡って降りてきます
まとめ
- CRAはデジタル要素を持つ製品にサイバーセキュリティ要求を課すEUの規則
- 2026年9月11日から脆弱性・重大インシデントの報告義務が先行して始まる
- 2027年12月11日に主要義務が全面適用され、適合とCEマーキングが必要になる
- 報告は24時間・72時間・14日という段階。原因究明を待たずに一報を入れる発想が要る
- SBOMの整備とサポート期間の明示が実務上の負担になりやすい
- SBOMだけでは「どの出荷個体に入っているか」は分からない。シリアルと構成の対応がないと全台対象になりうる
この記事とQUALIKEEPの関係について
率直にお伝えします。CRAへの適合に関して、QUALIKEEP にできることはありません。製品のセキュリティ設計、脆弱性の管理、SBOMの生成、更新の配信、当局への報告——いずれも対象外です。QUALIKEEP は原材料・副資材の受入・期限・ロットを記録するサービスであり、製品のサイバーセキュリティには関与しません。
この規制への対応は、開発部門・品質保証部門・専門のベンダーの領域です。
| 領域 | 扱えるか | 補足 |
|---|---|---|
| SBOMの生成・管理 | できません | ソフトウェア構成の解析、脆弱性データベースとの照合は対象外です |
| 脆弱性の監視・報告 | できません | 当局への24時間報告を含め、報告の自動化や管理機能はありません |
| セキュリティ機能 | ありません | 攻撃の検知・防御、更新の配信を行う製品ではありません |
| CRA適合・CEマーキング | 保証しません | 適合の判定、認証機関への申請を代行・保証するものではありません |
| 部材ロットの記録 | 扱えます | 基板や部品の受入・使用の記録という、物理側の一部分に限られます |
本記事は、制度そのものを理解していただくために書いています。
ご注意
本記事は公開情報をもとにした一般的な解説です。適用日・対象範囲・報告の手順は変更されることがあります。実際の対応にあたっては、規則の原文、欧州委員会のガイダンス、およびセキュリティの専門家にご確認ください。本記事は適合を保証するものではありません。
参考・出典
※ 外部サイトの内容・URL は変更される場合があります。最新の情報は各機関の公式ページをご確認ください。