2026年9月11日、EUサイバーレジリエンス法（CRA）の報告義務が適用開始となりました。タイやASEANでIoT製品を設計・製造し、EU、英国、シンガポール、日本へ展開する企業にとって、ETSI EN 303 645は市場ごとに資料を作り直す前の「共通証跡マトリクス」として役立ちます。ただし、ETSIへの対応は法律への適合、認証、ラベル取得を自動的に保証するものではありません。本稿では、製品・ファームウェア・更新・ログの証跡を一度整え、各制度へ正しく差分展開する実務を解説します。
いまETSI EN 303 645を見直す理由
ETSIが2024年10月に公表した案内によれば、現行版は ETSI EN 303 645 V3.1.3（2024-09）です。対象はコンシューマーIoTのサイバーセキュリティ基準であり、実装方法を一つに固定するのではなく、達成すべき結果を中心にしたベースラインです。Singapore Cyber Security Agency（CSA）の説明では、標準は14の幅広い規定で構成されます。
この標準がタイの製造現場にとって重要なのは、単に欧州向け文書だからではありません。ネットワークカメラ、環境センサー、ゲートウェイ、スマートコントローラー、保守用モバイル端末などは、同じハードウェアやファームウェアを地域別SKUとして出荷することがあります。一方、発売先ではEU CRA、英国PSTI、シンガポールCLS、日本JC-STARと制度の名称、対象範囲、申請方法、責任主体が異なります。市場ごとにゼロから質問票へ回答すると、同じパスワード制御や更新機能について表現が揺れ、証跡が分散し、重大事象の発生時に必要な情報が集まりません。
そこで、ETSI EN 303 645を製品セキュリティの「共通言語」として使います。要求事項を社内コントロールに翻訳し、設計仕様、設定値、試験結果、運用記録、公開ページをひも付けます。その後、販売市場ごとの法令・認証・ラベルの要求へ差分マッピングします。ここで大切なのは、共通化するのが証拠の材料と管理方法であり、各制度の判定そのものではないことです。
2026年9月11日のCRA報告義務は何を変えたか
欧州委員会の公式情報では、2026年9月11日から、デジタル要素を持つ製品のメーカーには、積極的に悪用されている脆弱性と、製品セキュリティに影響する重大インシデントの報告義務が生じます。対象となる事象を認識してから、原則として24時間以内に早期警告、72時間以内に通知を行う枠組みです。すべての脆弱性や停止が一律に報告対象という意味ではなく、定義への該当性は事実関係と公式ガイダンスに基づき判断する必要があります。
この時間軸は、製品セキュリティを「発売前の試験」に閉じ込められないことを示します。24時間で初報を組み立てるには、影響製品、バージョン、販売地域、悪用状況、緩和策、連絡責任者を平時から追跡できなければなりません。ETSIベースの証跡マトリクスに製品識別、ファームウェア構成、脆弱性受付、更新、ログを統合しておけば、CRAの報告判断に必要な事実を探す時間を短縮できます。CRAの他の主要義務は2027年12月11日に全面適用予定であり、2026年の報告開始を「運用能力を先に試される節目」と捉えるのが実務的です。
ETSI EN 303 645は法律でも認証でもない
最初に誤解を外します。ETSI EN 303 645は、コンシューマーIoTの基礎的なセキュリティ成果を整理した標準です。EU CRAという法律そのものではなく、英国PSTIの適合宣言でも、シンガポールCLSや日本JC-STARのラベルでもありません。標準に沿った設計や評価を行っていても、対象製品、事業者の役割、必須文書、試験レベル、申請手続、表示方法を各制度で確認しなければなりません。
また、名称にIoTが含まれていても、工場で使うすべてのOT機器へ同じ制度が適用されるわけではありません。消費者向け製品、産業専用製品、組込みコンポーネント、医療・車載などの分野別規制対象では、スコープが異なります。タイで製造していること、EUの企業へ納品すること、最終消費者が使用することのどれが適用判断に効くかも制度ごとに違います。営業資料だけで対象を決めず、製品の意図された用途、流通形態、ブランド表示、メーカー・輸入者・販売者の役割を整理し、必要に応じて法務・認証専門家へ確認してください。
一方で、標準を使う価値は大きいです。パスワード、脆弱性報告、更新、機密情報の保護、通信、攻撃面、ソフトウェア完全性、個人データ、レジリエンス、テレメトリー、削除、設置・保守、入力検証という論点は複数制度で重なります。製品チームがこれらを一つのコントロール台帳で管理すれば、追加要求の識別、試験の再利用、翻訳、顧客回答の一貫性が高まります。
「準拠」「試験済み」「認証済み」を分ける
社内外の文書では、少なくとも次の表現を区別します。
| 表現 | 実務上の意味 | 確認すべき証跡 |
|---|---|---|
| 設計ベースラインとして採用 | ETSIの論点を設計・運用要件へ反映 | 要求仕様、適用宣言、責任者 |
| 自己評価を実施 | 自社の手順で適合状況を確認 | チェックリスト、試験結果、未解決差分 |
| 第三者試験を実施 | 指定範囲を外部ラボが評価 | 試験範囲、版、報告書、除外事項 |
| 制度へ申請・ラベル取得 | 各制度の正式手順を完了 | 登録番号、対象SKU、有効条件、公開情報 |
| 法令への適合を宣言 | 適用法令と責任主体に基づく表明 | 法的スコープ、技術文書、宣言書 |
「ETSI対応だからCRA対応済み」と短縮すると、経営判断、顧客説明、監査のすべてで誤解が残ります。正しくは「ETSI EN 303 645を共通ベースラインにし、CRAについては別途スコープ・要求・報告体制・技術文書の差分を管理している」と表現します。
connected deviceを4つの証跡面で捉える
証跡マトリクスを機能一覧から始めると、アプリ画面に見える設定だけが中心になりがちです。実務では、製品を DEVICE、FIRMWARE、UPDATE、LOG の4面に分けると、設計から市場運用まで追跡しやすくなります。
DEVICE：製品と責任範囲を一意にする
DEVICE面では、製品名、型式、ハードウェアリビジョン、SKU、販売国、ネットワーク機能、初期設定、管理インターフェース、依存クラウド、モバイルアプリ、外部ライブラリを記録します。箱に印刷された型式とSBOM上の製品識別、サポートサイトの表記が一致していることが重要です。OEM/ODM案件では、設計者、製造者、ブランド所有者、アップデート配布者、脆弱性窓口の役割をRACIで明確にします。
パスワードについては「デフォルトパスワードなし」と一行書くだけでは不十分です。工場書込み時の資格情報生成、個体固有性、初回設定、リセット後の状態、サービス用アカウント、ロックアウト、秘密情報の保管場所まで証明します。量産テスト用アカウントが製品版に残らないことも、ビルド設定と出荷検査の両方で確認します。
FIRMWARE：何が動いているかを再現できるようにする
FIRMWARE面では、ソースの版、ビルドID、署名、ブートチェーン、SBOM、コンパイラやCI/CDの記録、設定差分、脆弱性評価を結び付けます。ある脆弱性が報告されたとき、「どの販売済みSKUのどの版に含まれるか」を数時間で答えられる構成が目標です。
完全性の証跡には、セキュアブートの有無だけでなく、署名検証に失敗した場合の動作、ロールバック制御、リカバリーイメージ、鍵の保管とローテーション、製造工程での鍵注入を含めます。タイの工場で量産する場合、開発拠点が発行した署名済み成果物を、どの端末が受け取り、誰が設備へ配布し、どのログで照合するかまで工程化します。
UPDATE：最低サポート期間と実際の配布能力を示す
UPDATE面では、更新方針、最低サポート期間、脆弱性の優先度、修正目標時間、署名、段階配信、失敗時の復旧、顧客通知、保守終了を管理します。英国PSTIでは、メーカーが最低セキュリティ更新期間を公開することが基礎要件の一つです。公開期間と社内の部品調達、クラウド維持、エンジニア配置が矛盾していないかを確認します。
EU CRAへの備えでは、更新を作れることに加え、影響範囲の判定、配布状況、顧客への緩和策、是正措置が利用可能になった日を記録します。サポート終了した製品の扱いも曖昧にしません。更新サーバーが地域別の場合は、同じ修正版が各市場へいつ届いたかを追跡できる配布台帳を作ります。
LOG：通知判断に使える事実を残す
LOG面は「何でも保存する」ことが目的ではありません。認証失敗、設定変更、更新結果、完全性エラー、異常通信、クラッシュ、時刻同期、管理操作など、検知・調査・復旧に必要な事象を定義します。ログの時刻、端末ID、ファームウェア版、収集経路、保持期間、アクセス制御、個人データの扱いを合わせて決めます。
クラウドへ常時接続しない製品なら、ローカルでの取得方法、販売代理店や顧客から安全に回収する方法、サポート部門が開発へ引き渡す方法を試します。24時間の初報に必要な情報が装置内にしかなく、現場から取り出す手順が未検証では、制度対応は紙の上だけです。
共通証跡マトリクスの作り方
マトリクスは「ETSI条項対制度条項」の対応表だけでは機能しません。各行に、コントロール、対象製品、責任者、証跡、保存場所、更新頻度、試験方法、未解決差分を持たせます。販売先の列には合否ではなく、直接再利用、調整して再利用、別評価が必要、非該当候補の状態を記録します。法令・制度の最終判断を設計担当者のセルフチェックだけで確定しないためです。
| 共通コントロール | 最低限の証跡例 | 製品オーナーへの確認 |
|---|---|---|
| 個体固有の認証 | 資格情報生成仕様、リセット試験、量産検査 | 保守アカウントも対象か |
| 脆弱性報告窓口 | 公開URL、受付SLA、PGP鍵、受付記録 | 多言語・休日に誰が受けるか |
| セキュリティ更新 | 公開サポート期間、署名試験、配布ログ | 地域別SKUへ同時配布できるか |
| 秘密情報の保護 | 鍵管理設計、保存領域試験、製造鍵注入記録 | ODMと鍵責任を分離したか |
| 安全な通信 | プロトコル一覧、証明書検証、失敗時動作 | 工場プロキシ環境でも成立するか |
| 攻撃面の縮小 | ポート一覧、サービス無効化、デバッグ封止 | 量産モードに試験機能が残らないか |
| 完全性・復旧 | ブート検証、ロールバック、復旧試験 | 失敗時に安全な状態へ戻るか |
| テレメトリーとログ | イベント定義、保持、取得、アクセス記録 | 報告判断へ24時間以内に使えるか |
証跡の名前を市場別に増やしすぎない
例えば、パスワード試験結果を UK_PSTI_password_test.xlsx として作ると、日本向け、シンガポール向け、EU向けに複製が増えます。代わりに、製品ID、コントロールID、証跡ID、版、試験日、試験環境を共通キーにします。各市場の提出物は、この正本から必要範囲を参照・翻訳して生成します。元資料を修正したら、どの市場文書が影響を受けるかを追跡できます。
証跡は長い報告書だけではありません。Gitのタグ、CIの署名検証ログ、チケット、公開Webページ、脆弱性受付記録、更新サーバーの配布結果、工場検査ログも含まれます。ただし、リンク切れやアクセス権不足は「証跡がない」のと同じです。監査用エクスポートを定期的に作り、個人アカウントに依存しない保管先へ置きます。
4市場へどう差分展開するか
EU CRA：製品ライフサイクルと報告運用を追加する
CRAでは、デジタル要素を持つ製品について、設計・開発・製造だけでなく、市場投入後の脆弱性取扱い、更新、技術文書、適合評価、報告などを見ます。ETSIのコントロールは基礎資料になり得ますが、CRAの適用範囲、製品分類、事業者の役割、必須手続を別途確認します。ETSIの自己評価票を埋めただけでCRA適合とは言えません。
2026年9月11日から始まった報告義務への実務対応では、脆弱性受付から法的トリアージまでの引継ぎが重要です。PSIRT、開発、クラウド運用、工場品質、地域販売会社、法務の連絡網を作り、「認識時刻」を誰が記録するか、積極的悪用や重大性をどの情報で判断するか、Single Reporting Platformへ誰が入力するかを決めます。初報は最終原因分析ではありません。限られた時間で既知の事実、不確実性、暫定措置を整理し、その後の72時間通知と最終報告へ一貫して更新できるケース番号が必要です。
UK PSTI：三つの基礎要件と流通責任を明示する
英国の消費者向け接続製品セキュリティ制度は2024年4月29日に発効しました。政府ガイダンスが示す基礎要求は、普遍的または容易に推測できるデフォルトパスワードの禁止、セキュリティ問題を報告する方法の公開、最低セキュリティ更新期間の公開です。ETSI EN 303 645の主要論点と整合しますが、PSTI法・規則に基づく義務やStatement of Complianceは別に扱います。
タイのOEM/ODMが英国ブランドへ供給する場合、自社がどの情報を提供し、ブランド所有者や輸入者が何を宣言するかを契約へ落とします。更新期間をブランド側のWebだけで公開しても、タイ側が修正とビルドを支えられなければ実効性がありません。部品のEOL通知、OSSの脆弱性監視、鍵管理、更新サーバー費用を含めて、販売終了後の責任を見積もります。
Singapore CLS：ETSIベースでも申請階層を混同しない
Singapore CSAのメーカー向け情報では、CLSはラベルの星数を示すCybersecurity Levelと、順に完了するAssessment Tierを区別しています。Assessment Tier 1とTier 2はETSI EN 303 645を基礎とし、取得するCLS Levelは完了した最高Tierに対応します。CSAはETSI標準を14の幅広い規定として説明しています。このため、ETSIベースの自己評価や証跡台帳は申請準備に使いやすい一方、希望Level、必要Tier、対象製品、試験、申請書、ラベル利用条件はCLSの現行手順に従います。
ASEAN本社で共通証跡を英語化し、シンガポールの申請資料へ必要な範囲を抽出すると効率的です。ただし、相互承認が明示されていない制度間で「一つの試験報告書ですべて取得できる」と約束しないでください。試験所へ事前に版、範囲、サンプル、ファームウェア、再試験条件を確認します。
日本JC-STAR：調和は同一性ではない
IPAのJC-STAR詳細情報では、評価基準はETSIやNISTなどの国際的な標準・ガイダンスとの整合を意識して策定されています。しかし、JC-STARは日本の独自制度であり、申請区分、適合基準、証跡、手続を満たして初めてラベルを扱えます。ETSIの評価結果は有用な入力ですが、自動的なラベル付与や代替認証ではありません。
制度の全体像はJC-STAR IoTセキュリティラベリング解説を参照してください。タイ拠点からの準備はタイ拠点向けJC-STAR対応で整理しています。本稿の共通証跡マトリクスと組み合わせる場合、JC-STAR固有列に申請レベル、評価方法、提出形式、表示要件を追加します。
| 行き先 | ETSI証跡の使い方 | 必ず別確認する事項 |
|---|---|---|
| EU CRA | ベースライン設計、更新、脆弱性処理の入力 | 適用範囲、分類、適合評価、技術文書、報告 |
| UK PSTI | パスワード、報告窓口、更新期間の裏付け | 対象製品、事業者義務、適合声明、記録 |
| Singapore CLS | Assessment Tier 1/2準備の基礎資料 | 希望Level、必要Tier、試験・申請、ラベル条件 |
| Japan JC-STAR | 国際標準と調和した証跡の再利用 | レベル別基準、申請、評価、表示 |
タイ工場で証跡を生む工程設計
証跡は開発部門だけでは完成しません。量産工程で設定、鍵、版、検査が変わるため、タイ工場のMES、治具、書込み装置、検査端末から得られる記録を製品台帳へつなぎます。産業ネットワーク構築の実務で解説するように、OT側の可用性と分離を保ちながら、必要なログだけを安全に収集する設計が必要です。
製造指図には、承認済みハードウェア版、ファームウェアのハッシュ、設定プロファイル、鍵注入手順、検査仕様を固定します。書込み後に端末IDとビルドIDを読み返し、署名状態、不要ポート、初期認証、更新機能を抜取または全数で検査します。不合格品の隔離と再作業では、古いファームウェアへの戻しが許可される条件を決めます。検査結果はシリアル番号にひも付け、販売地域まで追える状態にします。
サプライヤーには、OSS/SBOM、脆弱性通知、修正版提供、サポート終了、秘密情報、インシデント協力を契約要求として渡します。「ETSI準拠部品」という表現だけで受入れず、対象版と証跡を確認します。モジュールの証跡があっても、完成品での設定、クラウド連携、モバイルアプリ、利用者操作により攻撃面は変わります。完成品としての再評価を計画します。
IoT機器セキュリティ調達基準の書き方
調達仕様には「ETSI EN 303 645に準拠すること」だけを書かず、回答可能な成果物を定義します。
| 調達項目 | 要求例 | 受入れ方法 |
|---|---|---|
| 適用範囲 | 対象モデル・版・除外条項を提示 | 適用宣言レビュー |
| 脆弱性管理 | 公開窓口、受付SLA、通知方法を提示 | URL確認、机上訓練 |
| 更新 | 最低期間、署名、失敗復旧、EOLを提示 | 更新・ロールバック試験 |
| SBOM | 形式、版、更新頻度、脆弱性連絡を合意 | サンプル照合 |
| 製造 | 鍵注入、デバッグ封止、版照合を記録 | 工場監査、ログ抜取 |
| インシデント | 24/72時間判断に必要な情報提供を合意 | 連絡訓練、SLA測定 |
この粒度なら、候補ベンダーを比較でき、契約後の受入試験にもつながります。規格番号だけの要求は、価格見積には載っても責任分界を作りません。
90日で作るSCOPE・EVIDENCE・DRILL
1〜30日：SCOPEを固定する
最初の30日では、対象製品ファミリーを一つ選びます。全製品を同時に始めると、例外の議論に時間を使い、正本ができません。型式、版、用途、ユーザー、販売国、ブランド、クラウド、アプリ、OEM/ODM関係、更新責任を1ページにまとめます。各市場の法的対象性は仮説と確定を分け、根拠URL、確認者、確認日を記録します。
次に、ETSIの14の幅広い規定を自社コントロールへ展開し、DEVICE、FIRMWARE、UPDATE、LOGへ割り当てます。既存のISO 27001、IEC 62443、Secure SDLC、品質保証の記録が使える場合は参照し、重複手順を作りません。ただし組織の情報セキュリティ手順が、そのまま製品機能の証拠になるとは限らないため、製品単位の裏付けを残します。
31〜60日：EVIDENCEを集めて穴を試す
次の30日で、各コントロールに証跡IDを付けます。文書が存在するかだけでなく、現行版か、対象SKUを含むか、第三者が再現できるかを確認します。代表的な試験として、工場出荷状態からの初回設定、パスワードリセット、証明書エラー、更新中断、署名不正、ロールバック、ネットワーク断、ログ回収、データ削除を実施します。
差分は重大度、所有者、期限、出荷可否へ変換します。「対応中」という状態を長期間残さず、暫定緩和、顧客通知、次回版、受入れたリスクの承認者を記録します。各市場列では、証跡が直接使えるか、翻訳・形式変更が必要か、追加試験が必要かを判定します。
61〜90日：DRILLで運用可能性を確認する
最後の30日では、仮想の積極的悪用脆弱性を使って机上訓練します。サポート窓口が報告を受けた時刻を起点に、影響版の特定、SBOM照合、販売地域の抽出、悪用情報の確認、暫定緩和、経営・法務へのエスカレーション、初報案、72時間通知案までを通します。実際に規制当局へ架空報告を送るのではなく、社内テンプレートと承認経路を検証します。
訓練後は、情報の欠落と待ち時間を測ります。例えば、販売済みシリアルの地域抽出に8時間、外部モジュールの版確認に12時間かかるなら、24時間初報の余裕はほとんどありません。API連携や台帳統合が必要な箇所を改善バックログへ入れます。二回目の訓練で、担当者不在や休日も想定します。
成果を測るKPI
認証の数だけをKPIにすると、運用能力が見えません。次の指標を製品ファミリーごとに測ります。
- 販売済みSKUからファームウェア版とSBOMへ到達する時間
- 脆弱性受付から製品責任者へ通知する時間
- 影響地域・台数を暫定算出する時間
- セキュリティ更新の作成、承認、段階配信に要する時間
- 更新成功率と失敗時復旧率
- 共通証跡を市場別提出物へ再利用できた割合
- 期限切れ・リンク切れ・所有者不明の証跡数
- 24時間早期警告案と72時間通知案を承認できる訓練時間
KPIは規制適合を保証するものではありませんが、紙のチェックリストを実行能力へ変える助けになります。経営層には、未対応条項の数だけでなく、出荷計画、サポート費用、インシデント時の時間リスクとして報告します。
よくある失敗と回避策
第一の失敗は、ETSIのチェックリストを品質部門だけが保有することです。実装責任者、工場、クラウド、サポートが証跡を更新しなければ、発売時点で陳腐化します。各行に所有者と更新イベントを指定してください。
第二は、認証用サンプルと量産品が異なることです。評価後の部品代替、設定変更、クラウドAPI変更、証明書更新が適用範囲へ与える影響を変更管理に組み込みます。変更票には「セキュリティ証跡・市場別提出物の更新要否」を必須項目として置きます。
第三は、更新期間をマーケティングが単独で決めることです。最低更新期間の公開は、部品、開発、署名鍵、配布基盤、サポート窓口の費用を伴います。製品原価とライフサイクル予算へ含めます。
第四は、脆弱性窓口を作って終わることです。自動返信が届くか、添付を安全に受け取れるか、休日も確認されるか、サプライヤーへ展開できるか、報告者へ進捗を返せるかを定期的にテストします。
第五は、各国制度の名称を同じ「認証」と呼ぶことです。法律上の義務、自己適合、第三者評価、任意ラベル、相互承認を区別し、営業資料の表現を法務・品質・技術で共同レビューします。
FAQ
ETSI EN 303 645とは何ですか？
コンシューマーIoT製品のサイバーセキュリティについて、結果重視の基礎的な規定と実装ガイダンスを示す欧州標準です。現行版はV3.1.3（2024-09）です。複数市場の製品セキュリティ証跡を整理する共通ベースラインとして有用ですが、法律や全市場共通の認証ではありません。
ETSI EN 303 645に対応すればEU CRAへ自動適合しますか？
いいえ。ETSI対応の設計・試験・運用証跡はCRA準備の入力になりますが、CRAの対象範囲、製品分類、適合評価、技術文書、脆弱性対応、報告義務などを別途評価する必要があります。対象判断や法的解釈は公式文書を確認し、必要に応じて専門家へ相談してください。
EU CRAの24時間・72時間報告は何を指しますか？
欧州委員会の説明では、積極的に悪用されている脆弱性または製品セキュリティへ影響する重大インシデントについて、認識後24時間以内に早期警告、72時間以内に通知する枠組みです。すべての不具合が対象ではありません。事象の分類、認識時刻、既知の事実、影響製品、緩和策を追跡できる運用が必要です。
IoT製品セキュリティ認証は一つ取れば多国で使えますか？
一般には自動的に使えるとは限りません。共通試験や証跡を再利用できる場合はありますが、制度ごとに対象、レベル、申請、責任主体、表示条件が異なります。相互承認は主管当局が明示する範囲に限って確認し、それ以外は「準備効率化」と「正式な承認」を分けて説明します。
JC-STARとETSI EN 303 645の関係は？
IPAはJC-STARの基準がETSIやNISTなど国際的な標準・ガイダンスとの調和を意識していると説明しています。そのため証跡の多くを整理して再利用できますが、JC-STARは独自制度です。ETSIの自己評価や第三者試験だけでJC-STARラベルを取得したことにはなりません。
IoT機器セキュリティ調達基準には何を書けばよいですか？
規格名だけでなく、対象型式・版、適用宣言、パスワード設計、脆弱性窓口、最低更新期間、署名更新、SBOM、製造時の鍵管理、ログ、インシデント協力、受入試験、証跡の提出形式を記載します。要件ごとに責任者、期限、受入れ条件を付けると、比較と契約管理に使えます。
タイ工場は最初に何から始めるべきですか？
一つの代表製品を選び、DEVICE、FIRMWARE、UPDATE、LOGの4面で現状証跡を集めてください。30日で範囲、60日で証跡、90日でインシデント訓練まで行うと、文書不足だけでなく実際の待ち時間も見えます。全製品展開は、そのテンプレートを改善してから進める方が現実的です。
まとめ
ETSI EN 303 645は、タイ・ASEANのIoTメーカーが多国展開を準備する際の強力な共通ベースラインです。DEVICE、FIRMWARE、UPDATE、LOGの証跡を一つのマトリクスへ集約すれば、EU CRA、英国PSTI、シンガポールCLS、日本JC-STARに必要な差分を見つけやすくなります。ただし、標準は法律でも認証でもなく、各市場の適用判断、手続、評価、表示を置き換えません。2026年9月11日に始まったCRA報告義務を契機に、24時間・72時間で事実を動かせる運用まで検証することが重要です。
TOMAS TECHでは、タイ工場の製品・ファームウェア・更新・ログの現状整理から、共通証跡マトリクス、調達要件、90日ドリルの設計まで、検討初期でもご相談いただけます。お問い合わせはこちらから、対象製品と展開予定国をお知らせください。
参考情報
- ETSI, ETSI EN 303 645 V3.1.3 release: https://www.etsi.org/newsroom/press-releases/2457-etsi-releases-new-guidelines-to-enhance-cyber-security-for-consumer-iot-devices/
- IPA, JC-STAR制度詳細: https://www.ipa.go.jp/security/jc-star/detail.html
- European Commission, CRA implementation: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
- European Commission, CRA reporting obligations: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- European Commission, CRA legal summary: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
- UK Government, Consumer connectable product security regulations: https://www.gov.uk/guidance/regulations-consumer-connectable-product-security
- Cyber Security Agency of Singapore, CLS for manufacturers: https://www.csa.gov.sg/our-programmes/certification-and-labelling-schemes/cybersecurity-labelling-scheme/for-manufacturers/
- EUR-Lex, Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/2024-11-20/eng
注：本稿は製品セキュリティ実務の一般情報であり、法的助言や認証結果を示すものではありません。対象範囲と適合方法は、製品、用途、流通、事業者の役割、最新版の公式文書に基づいて個別に確認してください。
