CRA初の運用期限が目前—9/11から動き出す「24/72/14」の現実対応

今日の深掘りポイント

• 9月11日から、EU域内で販売する「デジタル要素を含む製品」の製造業者に、積極的に悪用される脆弱性や重大インシデントの早期報告が事実上スタートします。24時間・72時間・14日という3本の時計が同時に回り始めます。
• これはPSIRT単体の課題ではなく、SBOM/VEX、製品在庫、脆弱性インテリジェンス、法務・広報を束ねる“統合作戦”の成熟度が問われる試金石です。
• EU規制は域外にも波及します。日本企業はEU向けSKUの棚卸し、EU域内の認定代理人（Authorized Representative）設計、供給網へのSLA逆流し（24/72/14）を今すぐ制度化すべき局面です。
• 「能動的悪用」の判断は技術×情報の競争になります。社内外のシグナル（顧客被害、TI、KEV相当リスト、ハニーポット）を自動で突合し、報告可否を分に刻む運用が勝負を分けます。
• 実務の難所は“同時多発”です。単一製品のゼロデイではなく、第三者コンポーネント由来の多SKU・多市場影響が主戦場になります。CVE付番、顧客通告、当局報告、修正リリースのワークフローを「並列・分岐」前提で設計するのが現実解です。

はじめに

EUサイバー耐性法（Cyber Resilience Act: CRA）の最初の重要マイルストーンが目前です。9月11日以降、製造業者は「デジタル要素を含む製品」で発生するセキュリティに影響する脆弱性や重大インシデントについて、早期警告（24時間）、初報（72時間）、確報（14日）のタイムボックスで所定先へ報告する体制が求められます。グローバルにEU市場へ出荷する日本企業にとっては、PSIRTやSBOMはもちろん、調達条件、販売チャネル、広報・法務までを跨いだ“運用としての規制対応”が問われる局面です。

本稿は、現場で刻むべき3つの時計の意味、脅威シナリオの実態、そして日本のCISO・SOC・TIに何ができるかを、今日時点の公開情報に基づいて分解します。緊張感のあるテーマですが、焦りは禁物です。動かすべきレバーは限られており、正しく握れば負担とリスクの双方を減らせます。

深掘り詳細

事実—いつ・誰が・何を報告するのか

• 開始日とフェーズ
  • 2026年9月11日から、製造業者は「セキュリティに影響する脆弱性」および「重大なインシデント」に関する早期報告プロセス（24時間内の警告、72時間内の初報、14日内の確報）を運用に乗せる必要があります。
  • 2027年12月11日から、より広範な義務（適合性評価、継続的なセキュリティ要件の適用など）が本格適用されます。
• 対象
  • EU市場に投入される「デジタル要素を含む製品」（Products with Digital Elements: PDE）。ハードウェア、ファームウェア、組み込みソフトウェア、汎用ソフトウェアまで広く含みます。
  • EU域外メーカーも、EUで販売するなら対象です（通常はEU域内の認定代理人を介して当局対応を行います）。
• 報告の中身（公開情報ベース）
  • 「積極的に悪用される脆弱性（exploited in the wild）」の早期警告を24時間内、重大インシデントの初報を72時間内、是正策や影響評価を含む確報を14日内に届ける三段構えが意図されています。
  • 報告先は、EU側で指定される窓口（ENISAや関係CSIRT/市場監視当局の仕組み）に集約される想定です。
• 出所
  • これらの期限設計と運用イメージは、業界解説と欧州委の公開資料で明らかにされている範囲の情報に基づきます。一次情報は欧州委の制度ページと、期限の具体像は業界の実務ガイダンスが参考になります（参考情報を末尾に記載します）。

インサイト—“24/72/14”はPSIRTの話ではなくエンタープライズ運用の話です

• 「能動的悪用」の有無は技術判定だけでは足りないです。自社テレメトリ、顧客インシデント、外部TI、既知の悪用リスト、ハニーポット観測、ベンダー間情報共有（ISAC等）を“自動で突合”し、しきい値を超えたら即座に「早期警告」を打てる体制が鍵です。
• SBOM/VEXはレポートの“言語”です。CVSSだけでなく、影響するSKU・バージョン・構成差分をVEXで機械可読に示せると、規制対応（当局・顧客・販売網）とCSIRT運用の両方が劇的に軽くなります。
• 72時間での初報は法務・広報の同時稼働が前提です。技術的事実、顧客影響、修正ETA、迂回策（mitigation）、市場監視当局への必要情報を“矛盾なく”整えるRACIとテンプレを常設しておくべきです。
• 多SKU・多市場に波及する「サプライヤー由来の欠陥」が主戦場です。調達契約に「24/72/14」を逆流し、上流サプライヤーにSBOM/VEX、CVE付番、PoC/KEV検知の共有SLAを課すと、下流での混乱を抑制できます。
• 規制の波及は地政学的です。EU準拠の報告様式とプロセスは、英国・豪州・一部アジアでの参照基準化が濃厚です。最初から“マルチ法域”テンプレ（EU/UK/他）で設計しておくと、再設計コストを抑えられます（ここは筆者の推測ですが、過去のGDPR/NIS2/DORAの波及から高確度のシナリオです）。

運用設計の勘所—“三つの時計”と“二つの地図”

• 三つの時計
  • 24h: 事実の有無（能動的悪用/重大性）と影響範囲の仮説を掲げ、当局へ「早期警告」。不確実性はそのまま明示する設計でよいです。
  • 72h: 初報で技術的根拠、影響評価（製品/顧客/地域）、迂回策、修正ロードマップ、連絡先を整備。
  • 14d: 確報でCVE、パッチ/設定回避、展開状況、残余リスク、追加モニタリング計画を確定。
• 二つの地図
  • 製品地図（SKU/地域/版/構成/ライフサイクル段階）。PLM/CMDB、販売台帳とSBOMを接続。
  • 依存地図（サプライヤー/OSS/第三者サービス）。VEXと契約SLAで“動く地図”にする。

脅威シナリオと影響

以下は、CRAの報告要件下で実際に想定すべき脅威シナリオです。MITRE ATT&CKの戦術・技法に沿って、運用・規制対応の両面から整理します（技法名は代表例。個別IDはバージョン差を避けるため明示しません）。

1. 量産IoTに対するRCEのワーム的悪用

• シナリオ
  • インターネット露出デバイスの未修正RCEが野外で連鎖悪用。Bot化→DDoS/プロキシ化/マイニングへ。
• ATT&CK対応
  • 初期アクセス: Exploit Public-Facing Application
  • 実行: Command and Scripting Interpreter
  • 永続化: Modify Firmware/Valid Accounts
  • 横展開: Remote Services
  • 影響: Inhibit System Recovery/Data Encrypted for Impact
• CRA的影響
  • 能動的悪用の閾値を即時充足。24h早期警告が必須。
  • SKUとファーム版差、ISP配布機種の分布推定、暫定Mitigation（デフォルト無効化/ACL/WAF署名）を72hで提示。

2. サプライチェーン由来の暗号ライブラリ欠陥（広範な製品に潜在）

• シナリオ
  • 一般的な暗号/圧縮ライブラリに重大バグ。攻撃者はVPN/ゲートウェイ/産業機器まで横並びに狙う。
• ATT&CK対応
  • 初期アクセス: Supply Chain Compromise
  • 防御回避: Obfuscated/Compressed Files and Information
  • 資格情報アクセス: Credential Access via Cryptographic Weakness
  • 影響: Exfiltration over C2 Channel
• CRA的影響
  • 多SKU・多顧客で同時多発。SBOMベースの影響特定とVEXで「影響あり/なし」を機械可読に提示しないと、72hで破綻します。
  • 上流ベンダーからの修正ETAに依存するため、契約SLAと代替実装の設計力が問われます。

3. 更新機構の悪用（署名検証欠陥/アップデートサーバ侵害）

• シナリオ
  • アップデート経路を乗っ取り、正規更新に見せかけた悪性イメージを配布。
• ATT&CK対応
  • 初期アクセス: Compromise Software Update
  • 指揮統制: Application Layer Protocol
  • 影響: Firmware Corruption/Service Stop
• CRA的影響
  • 重大インシデント判定。24hで早期警告、72hで鍵ローテーション/配信停止/復旧パスを示す必要。
  • 署名鍵管理・更新ロールバック手順の有無が生死を分けます。

4. エンタープライズ製品の脆弱性を足掛かりにしたランサムウェア侵入

• シナリオ
  • アプライアンス/ミドルウェアの外部公開面から侵入→AD横展開→暗号化・二重恐喝。
• ATT&CK対応
  • 初期アクセス: Exploit Public-Facing Application
  • 発見/横展開: Discovery/Pass-the-Hash/Remote Services
  • 影響: Data Encrypted for Impact/Exfiltration to Cloud Storage
• CRA的影響
  • 顧客側インシデントと製品脆弱性が絡むため、報告の境界設定（自社責任範囲）と顧客通知の整合が肝です。

総じて、これらは“技術対応”と“規制報告”が同時進行で走るシナリオです。メトリクス的にも緊急性・実行性・発生確度が高い案件群で、準備の有無が被害抑止だけでなく規制リスク（是正要求、罰則、販売停止）にも直結します。

セキュリティ担当者のアクション

• 24/72/14「時計訓練」を全社で
  • 24h: 早期警告ドラフトを60分で作る演習。テンプレ＋法務チェックの最短経路を固定します。
  • 72h: 顧客通告、当局初報、社内経営報告を“矛盾なく”出すテーブルトップ演習。
  • 14d: 確報とパッチ展開状況の整合性監査（VEX発行含む）。
• SBOM/VEXの“運用レベル”実装
  • EU向けSKUのSBOMカバレッジをKPI化（例：最新出荷版のSBOM整備率100%を必達）。
  • 影響評価の高速化にVEXを採用し、顧客・販売網・当局への一貫提供を自動化します。
• 「能動的悪用」を機械で検知・補強
  • 外部TI、既知悪用リスト、ハニーポット、顧客被害通報をSIEM/Case管理で自動突合。しきい値超過→即エスカレーション。
  • CVE公開前の観測（例：流出PoC、リコンバイト、スキャン急増）を指標化し、報告判断に活かします。
• 供給網へのSLA逆流し
  • 調達契約に「24/72/14」「SBOM/VEX」「CVE付番」「顧客通告支援」「PoC取扱い」を条項化。部品ベンダーにもPSIRT連絡経路を固定します。
• 報告テンプレ・権限委任・時間外体制
  • 当局・顧客・販売網それぞれの定型テンプレを整備。代理提出権限と連絡先（EU代理人含む）を文書化。
  • 週末・祝日のオンコール体制をPSIRT/法務/広報/IT運用でクロスに組みます。
• CVE/CNAポリシー整備
  • 自社CVE付番の基準とタイミング、第三者コンポーネントの扱い、協調開示のルールを明文化。可能であればCNA参加でレイテンシを短縮します。
• 顧客通告と当局報告の“二層運用”
  • 顧客向けアドバイザリは導入シナリオ別（オンプレ/マネージド/閉域）で書き分け。当局向けは法的要件優先で最小漏洩・最大実用のバランス設計。
• マルチ法域の統合レジスター
  • EU（CRA）、米（CIRCIA相当/SECディスクロージャ）、業界規制（医療/自動車/産業）を一枚のイベント・レジスターに統合。期限と提出先の自動リマインドを実装します。
• 例外処理と安全計装
  • 更新機構のロールバック、鍵ローテーション、ブートローダ保護、セーフモード運転など“安全に壊れる”設計をあらかじめ仕込むことが、規制も運用も救います。

—— 編集後記として一言。規制は重く見えますが、ひとつずつ分解すれば多くは既存の良い実務（PSIRT、SBOM、協調開示）を“時間で束ね直す”作業です。今日つくる運用は明日の競争力になります。焦らず、しかし時計は回り始めています。動きましょう。

参考情報

• 欧州委員会 Cyber Resilience Act（制度概要と適用対象の一次情報）: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• Sonatype: The CRA reporting deadline is almost here（報告期限と「24/72/14」運用の実務解説）: https://www.sonatype.com/blog/the-cra-reporting-deadline-is-almost-here