EUへ販売した装置で脆弱性が悪用された。金曜の夜に海外販売会社が気付き、日本本社の製品担当へ届いたのは月曜だった。この流れでは、2026年9月11日から始まるEUサイバーレジリエンス法の24時間早期警告に間に合わない可能性があります。
先に答えると、2026年に日本企業が最優先で整えるのはCEマーキングの書類一式ではなく、「どの製品で、誰が、いつ悪用を認知し、24時間以内に早期警告、72時間以内に通知へ進めるか」という報告経路です。主要な製品要件は2027年12月11日に全面適用されますが、報告義務は15か月早く始まります。
本記事は2026年9月1日時点のRegulation (EU) 2024/2847、欧州委員会、ENISAの公式情報を基に一般的な実務整理を示します。適用範囲、役割、適合性評価、事故報告は製品と商流により変わるため、最終判断はEU法務・認証の専門家と所管当局の最新案内で確認してください。
最初の分岐は「IT企業か」ではなく、EU市場へ何を出しているか
会社単位ではなく、製品型式・版・商流で適用と役割を記録します。
CRAは、EU市場で利用可能にされる「デジタル要素を持つ製品」を横断的に扱います。ハードウェアだけでなく、ソフトウェア、遠隔データ処理を含む場合があります。工場設備、ネットワーク機器、スマート家電、業務ソフト、開発ツールなど、会社の業種名だけでは対象を切れません。
製品台帳には、製品名、型式、版、構成ソフト、接続機能、EUでの販売開始日、販売国、顧客、サポート期間、製造者表示、EUの輸入者・販売者を記録します。無償ソフトウェアでも、商業活動の文脈や提供形態で検討が必要です。対象外だと決める場合も、理由と確認日を残します。
適用判定の単位は「会社」ではなく、EU市場へ出した製品の型式・版・商流です。同じ製品名でも、EU向け機能、通信モジュール、保守契約が違えば、台帳上は分ける必要があります。
製造者、輸入者、販売者を一社名でまとめない
日本本社が設計・製造し、EU子会社が輸入し、現地代理店が販売する場合、各者の役割と義務は同じではありません。委託製造やOEMでも、自社名・商標で市場へ出す、実質的な変更を行うといった条件で役割が変わり得ます。
契約書に「CRA対応は代理店が行う」と一行書いても、法令上の役割が移るとは限りません。製造者の連絡先、EU域内の窓口、脆弱性受付、技術文書の保持、是正措置、当局対応を役割別に割り当てます。
2026年9月11日から動く24時間・72時間の時計
原因確定を待たず、認知から早期警告と通知へ進む経路を試します。
欧州委員会は、2026年9月11日から、積極的に悪用されている脆弱性と、製品のセキュリティへ影響する重大インシデントについて製造者の報告義務が始まると案内しています。認知後24時間以内に早期警告、72時間以内に完全な通知を行います。
積極的に悪用された脆弱性では、是正措置が利用可能になってから14日以内に最終報告を出す期限が示されています。重大インシデントの最終報告は、原則として1か月以内です。報告はCRA Single Reporting Platformを通じて行われます。
「脆弱性を知った時刻」は、経営会議で報告を承認した時刻ではありません。海外子会社、保守委託先、CSIRT、サポート窓口のどこで事実を把握した時に時計が動くかを、社内手順で決めます。
24時間・72時間へ対応するには、現地窓口から製品責任者までの時差・休日を含む連絡経路が必要です。
深夜・休日を含む訓練を一度行う
訓練では、EUの顧客から「攻撃に使われているらしい」という不完全な連絡が来た状況を置きます。製品型式、影響版、悪用の根拠、顧客影響、緩和策を誰が集め、誰が報告要否を判断し、誰がプラットフォームへ提出するかを時間で測ります。
24時間で原因を完全に特定することは前提にしません。早期警告に必要な最小情報と、72時間までに追加する情報を分けます。誤報の疑いがあっても、判断を保留した時刻と根拠を記録します。委託先の営業時間外に連絡できないなら、契約と当番を直します。
2027年12月までに作るのは「書類」より製品セキュリティの循環
設計、出荷、脆弱性受付、更新、終了を一つの製品運用へつなげます。
CRAの主要な義務は2027年12月11日に全面適用されます。製造者には、サイバーセキュリティリスク評価、必須要件への適合、技術文書、適合性評価、脆弱性の取扱い、セキュリティ更新などが関係します。製品を出荷した時点で終わる検査ではありません。
設計時には、攻撃面、初期設定、認証、権限、暗号、ログ、更新、安全な初期化を確認します。出荷後は、脆弱性情報の受付、再現、重要度評価、影響製品の特定、修正、顧客通知、更新配布、終了時の案内を回します。
サポート期間は営業資料の飾りではなく、脆弱性を受け付け、修正を提供する組織・予算・部品・署名鍵を何年維持するかという経営上の約束です。売上終了日とセキュリティ対応終了日を同じにしない設計が必要です。
SBOMは目的ではなく「影響製品を72時間で絞る索引」である
ソフトウェア部品表を作っていても、製品型式、出荷版、顧客、ビルド、更新履歴へつながらなければ、事故時に使えません。脆弱性が公表された時、「その部品を使う製品はある」だけでなく、「どの版を、どの顧客へ、いつ出したか」を絞れる状態にします。
外部部品の更新が止まっている、ライセンス上差し替えに制約がある、装置認証を取り直す必要がある場合、修正の期限と顧客対応へ影響します。調達契約には、脆弱性通知、修正版提供、サポート終了、SBOMまたは構成情報、再配布権を入れます。
SBOM導入の進め方では形式と運用を、IoT導入のセキュリティでは接続機器の更新・廃棄を詳しく整理しています。CRA対応では、この二つを製品型式・EU商流の台帳へ結びます。
構成情報は、製品型式・版・出荷先・更新履歴まで結び付いて初めて、事故対応の索引になります。
既にEUへ出した製品を「2027年より前だから無関係」にしない
CRAの主要要件について、適用日前に市場へ出された製品は、その後の実質的変更などで扱いが変わります。一方、2026年9月からの報告義務は、すでにEU市場へ出ている製品にも関係し得ると欧州委員会の案内は説明しています。
したがって、2027年以降の新製品だけを台帳へ載せる対応では足りません。現在サポート中の旧製品、販売終了したが更新を提供している版、顧客が長期使用する産業設備を含め、報告経路を確認します。
実質的変更か、単なる修正かは、機能、意図された目的、リスクにより検討します。大型機器のファームウェア更新、クラウド機能の追加、通信機能の有効化を「ソフトの更新だから軽微」と自動判定しません。
適合性評価は「CEを貼る作業」から逆算しない
CRAでは製品の分類と条件に応じて、自己適合宣言を含む手続や第三者が関与する適合性評価を検討します。どの手続が必要かを決める前に、製品の意図された目的、重要機能、リスク、使う整合規格、ほかのEU法令との関係を整理します。
CEマーキングは、製造者が適用されるEU法令への適合を示す枠組みの一部です。ロゴ画像を用意し、試験報告書を一冊買えば終わるものではありません。設計変更、部品変更、脆弱性修正後に、評価と技術文書の更新が必要かを判断する変更管理が続きます。
適合性評価の成果物は、発売日のための静的な書類ではなく、「どの設計・部品・ソフト版を、どの根拠で適合と判断したか」を再現できる版管理です。認証部門だけでなく、設計・調達・製造・保守が同じ製品版を参照できるようにします。
販売資料と技術文書の製品名を一致させる
営業はシリーズ名、開発は型式、保守はファームウェア版、顧客はクラウドの契約名で呼ぶことがあります。この四つが台帳でつながらないと、当局照会や脆弱性報告で対象を絞れません。
製品名、型式、ハードウェア版、ソフト版、クラウド機能、販売国、宣言書、技術文書、サポート期間を一つの識別子へ結びます。OEM供給先が別ブランドで販売する場合は、相手の製品名との対応表も維持します。
調達契約で「通知を待つ会社」をなくす
製品に組み込むOS、ライブラリ、通信モジュール、クラウドAPIの脆弱性は、供給者が先に知る場合があります。契約で通知期限、対象情報、連絡先、修正版の提供、回避策、サポート終了、再委託を定めます。
通知期限を「速やかに」とだけ書かず、CRAの24時間判断へ間に合う社内期限にします。供給者が重要度を低く評価しても、自社製品の用途では重大になる可能性があるため、判断材料となる技術情報を受け取ります。
自社の報告期限は、部品供給者や海外販売会社の回答を待って止まりません。情報が不完全でも判断・初報へ進める代替担当と、契約上の連絡期限が必要です。
OSSを使っているだけで製品全体が対象外になるわけではない
CRAには、自由・オープンソースソフトウェアの非商業的な開発・供給に関する扱いがあります。しかし、企業が有償製品へ組み込み、名称を付けてEU市場へ出す場面まで、単純に「OSSだから対象外」とは言えません。自社がどのコードを作ったかだけでなく、誰が製品を市場へ出し、保守と脆弱性対応を約束しているかを確認します。
SBOMにライブラリ名を列挙しても、保守終了版、独自パッチ、ビルド時だけ使う依存、クラウド側の機能が区別できなければ、影響製品を絞れません。上流の修正版が出ても、自社製品で回帰試験し、署名し、配布する時間が残ります。調達時には、脆弱性通知だけでなく、修正提供期間とサポート終了の予告期間を契約へ入れます。
コミュニティへ修正を還元する判断と、顧客へ安全な更新を届ける責任も分けます。公開前の脆弱性情報をどこまで共有できるか、フォークしたコードを誰が保守するか、更新不能な旧型をどう終了させるかを製品台帳へ結びます。
一つの部品を百製品へ組み込む会社では、脆弱性一件の調査件数が百になります。製品台帳に販売国、稼働版、顧客連絡先、更新可否が結ばれていれば、実際にEUで稼働する版へ絞れます。台帳は監査資料ではなく、24時間以内に担当者が対象を狭めるための運用設備です。
日本企業が90日で行う実装順序
台帳、報告経路、机上訓練の順で、実際に時間を測ります。
最初の30日で、EU売上、製品型式、版、役割、連絡先を台帳化します。対象・非対象・要確認を分け、判断根拠を残します。販売、法務、品質、開発、CSIRT、現地法人の責任者を決めます。
次の30日で、脆弱性受付と報告手順を作ります。顧客、研究者、取引先、監視から届く情報を一つの窓口へ集め、24時間・72時間の担当、代行、休日連絡、経営報告を決めます。SOCとMDRの違いを使い、監視委託先が検知後どこまで判断・連絡するかも分けます。
最後の30日で、過去の脆弱性一件を使った机上訓練を行います。型式特定、悪用確認、顧客影響、緩和策、当局報告、顧客通知まで時間を測ります。72時間で製品版を特定できないなら、製品台帳とビルド記録を直します。
2026年の合格条件は「CRA対応方針を作った」ではなく、任意の製品と脆弱性を渡された時、担当者が24時間以内に報告要否と初報情報をそろえられることです。
まとめ
EU CRA対応は、2027年の認証準備だけでは間に合いません。2026年9月11日に報告義務の時計が先に動きます。
EU向け製品を型式・版・商流で台帳化し、脆弱性の認知時刻、24時間の早期警告、72時間の通知、修正と顧客連絡を一つの運用へつなげることが最初の実装です。対象判定の議論だけで止まらず、既存製品を使った訓練で証跡を残してください。
参考情報
以下は2026年9月1日に確認した一次情報です。
よくある質問
気になる質問を開くと、本文の重要点を短く確認できます。
QCRAの主要な義務はいつ始まりますか？
A脆弱性・重大インシデントの報告義務は2026年9月11日から、主要な製品要件は2027年12月11日から適用されます。一部の適合性評価機関に関する規定はさらに早く始まります。
Q日本で製造し、EU代理店が販売する製品も対象ですか？
AEU市場で利用可能にされるデジタル要素を持つ製品は検討対象です。日本本社、EU輸入者、販売者の役割を商流ごとに確認し、契約だけで法令上の役割が移ると決めないでください。
Q2027年より前に販売した製品は何もしなくてよいですか？
A一律ではありません。主要要件の経過措置と、2026年9月からの報告義務を分けて確認します。サポート中の既存製品も脆弱性受付と影響特定の台帳へ含めます。
QSBOMを作ればCRA対応は完了しますか？
A完了しません。SBOMは構成の索引です。製品型式、出荷版、顧客、サポート期間、脆弱性判断、修正配布、技術文書、適合性評価まで運用へ接続します。
Q24時間以内に原因が分からない場合はどうしますか？
A早期警告と完全な原因分析は別です。公式ガイダンスに沿って、その時点で把握した情報を使う手順を作り、72時間通知と最終報告へ更新できる担当・証跡を用意します。
Qオープンソースソフトウェアはすべて対象外ですか？
Aすべて対象外という理解は危険です。無償・商業活動・提供者の役割などで扱いが分かれるため、製品への組込み方と提供形態を一次情報と専門家で確認します。
