スマートカメラの通信を暗号化し、初期パスワードも廃止した。それでもU.S. Cyber Trust Markの準備は半分です。カメラを操作するアプリに古いライブラリが残り、クラウドの認証が突破され、サポート終了日を過ぎても店頭在庫が売られるなら、筐体の試験だけでは利用者を守れません。
Cyber Trust Markで評価する単位はIoT機器一台ではなく、機器、アプリ、ハブ、バックエンド、更新サービスを含めて消費者へ機能を届けるIoT productです。
本記事は2026年9月2日時点のFCC 24-26、47 CFR Part 8、NIST IR 8425、2025年6月の米国大統領令を確認して構成しています。制度は任意ラベルですが、連邦調達では2027年1月4日までに対象consumer IoTへラベルを求める方向の規則改正が指示されています。民間小売と連邦調達を同じ開始日と断定しません。
最初に「製品の外」を製品へ戻す
機器だけでなく、アプリ、cloud、hub、更新基盤を評価境界へ入れます。
NIST IR 8425はIoT productを、一つ以上のIoT deviceと、必要に応じて専用gateway、companion application、backendなどの関連componentから成るものとして扱います。日本メーカーが機器を設計し、別会社のアプリとクラウドを組み合わせる場合も、消費者が使う機能は一つです。
製品境界表にはdevice model、firmware、radio module、mobile appのOS・版、cloud service、認証基盤、update server、第三者SDKを置きます。誰が開発したかではなく、どれがなければ製品の目的を果たせないかで入れます。
同じ筐体でも、北米版だけ別クラウド、量販店向けだけ別アプリ、OEM先ごとにサポート期間が違う場合は同一評価で扱えるかを確認します。製品名が同じでもセキュリティ境界が違えば、証拠とレジストリ情報も分けます。
試験範囲から委託クラウドを外しても、攻撃面からは消えません。契約上の委託先と、ラベル上のIoT product boundaryを一致させます。
六つの製品能力と四つの運用を証拠へ変える
NISTのoutcomeを、仕様、実機試験、ログ、利用者説明へ落とします。
NIST IR 8425のconsumer profileは、asset identification、interface access control、product configuration、data protection、software update、cybersecurity state awarenessという製品能力を示します。これにdocumentation、問い合わせ受付、情報発信、教育・周知という開発者活動が加わります。
要件一覧へYを付けるだけでなく、脅威、実装、試験、利用者表示、運用担当を一つのevidence setへまとめます。例えばsoftware updateなら、署名検証、失敗時の安全性、配信権限、更新通知、サポート終了後の挙動まで確認します。
interface access controlでは、初期資格情報、不要インターフェース、認証失敗、権限分離、工場用デバッグポートを見ます。スマートフォンからログインできるだけでなく、所有者変更、譲渡、退去、紛失時に以前の利用者を外せることも重要です。
実機の通信だけでなく、所有者変更、アプリ認証、更新失敗、クラウド停止まで製品として試験します。
Cyber Trust Markの合格証拠は、仕様、実機結果、運用ログ、利用者説明の四つが同じ製品版を指す一式です。
IoT導入のROIとセキュリティ で企業が調達する場合も、ラベルの有無だけでなく、設置環境とネットワーク分離を別に評価します。
QRコードはロゴの飾りではなく更新される約束
公開レジストリを製品台帳と同期し、失効やサポート終了も伝えます。
FCCの設計では、Cyber Trust MarkにQRコードを伴わせ、消費者向けの公開レジストリへ接続します。レジストリは製品のセキュリティ情報を示し、認可が失われた場合や、メーカーが更新提供を終えた場合も利用者が分かる動的な仕組みです。
製品ページ、箱、取扱説明、EC画像で、マークとQRコードの意味を誇張しません。「安全を保証」「ハッキングされない」と表示せず、制度の適合範囲、モデル、サポート期間、更新方法、脆弱性窓口へ案内します。
レジストリのproduct name、model、manufacturer、support period、申請情報と、社内PLM・EOL台帳を同期します。社内で延長を決めても公開情報が古い、または公開だけ延長して更新要員がいない状態を防ぎます。
QRコードの価値は取得日の合格証ではなく、購入後もモデル固有のサポート期限、更新方法、脆弱性情報を確認できることです。
サポート終了日を営業ではなく原価へ入れる
更新、cloud、PSIRT、署名鍵を維持する将来費用を発売前に確保します。
FCCのルールでは、申請者はレジストリへ開示したsupport period end dateまでcritical vulnerabilityを継続的に特定し、セキュリティ障害を防ぐため合理的に必要な更新を速やかに提供する旨を宣言します。発売時に曖昧な「長期サポート」と書くのではなく、日付と能力を結びます。
販売終了からサポート終了までの台数、クラウド維持、PSIRT、人員、署名鍵、ビルド環境、第三者ライブラリ、モバイルOS追随を原価へ入れます。量販店在庫が販売終了後も残るなら、最終出荷日だけで期間を切ると購入者の実利用期間が短くなります。
脆弱性受付では、研究者が安全に報告できる窓口、応答目標、CVE調整、顧客通知、修正版、回避策を定めます。重大度だけでなく、実際の悪用、ネットワーク露出、安全への影響、更新率で優先します。
ラベル取得費より大きいのは、公開した終了日までアプリ、クラウド、署名鍵、PSIRTを維持する将来原価です。発売承認時に引当と責任者を決めます。
EUサイバーレジリエンス法 も脆弱性対応と更新期間を扱いますが、対象、法的性格、報告先、適用時期は別です。一つのPSIRTで証拠を共通化し、法令判断は分けます。
試験所、CLA、FCCの役割を混ぜない
試験、申請審査、制度監督の責任を分け、量産版の証拠を固定します。
制度では、認められた試験所が製品を試験し、Cybersecurity Label Administratorが申請を審査してマーク利用を認め、FCCが制度と商標を監督する構造です。試験所へ製品を送れば自動的にマークが付くわけではありません。
申請前に、申請主体、製造者、ブランド所有者、米国販売者、OEM先を整理します。禁止対象企業等に関する宣言もあり、部品調達・支配関係を法務と確認します。試験サンプルが量産版と同じfirmware、鍵、クラウド環境かを固定します。
不適合が出た場合、試験用設定だけ直さず、製品要求、コード、製造初期設定、サポート文書へ戻します。再試験の証拠と出荷済み製品への適用範囲を残します。
変更がラベルを古くする瞬間を決める
評価境界を変える更新を検知し、再試験と公開情報更新へ戻します。
アプリの認証方式、クラウド基盤、無線module、暗号ライブラリ、update mechanism、support periodが変われば、元の評価との関係を判断します。軽微な画面修正と、セキュリティ境界を変える変更を同じ承認フローにしません。
変更審査にはproduct ID、変更component、脅威、既存試験への影響、追加試験、レジストリ更新、在庫、顧客通知を含めます。OEMモデルでは一社のクラウド変更が複数ブランドへ波及します。
ラベルの認可状態が変わった場合、製造、梱包、EC画像、販売店素材、QRコード、在庫を止める必要があります。印刷物だけ差し替えてレジストリが別モデルを指す事故を演習します。
Cyber Trust Markの変更管理単位は筐体の型番ではなく、評価したIoT product boundaryとセキュリティ能力を変える構成・運用です。
店頭とECに残る古い表示を止める
マーク利用の認可状態やsupport情報が変わっても、印刷済み箱、量販店の商品画像、流通在庫、取扱説明PDFは自動では更新されません。security teamがregistryを直しても、販売現場が古い表示を続ければ消費者は誤った約束を見ます。
product modelとlabel artwork、QR destination、registry record、販売国、lot、retailer asset IDを結びます。失効・取下げ・support変更のeventから、製造停止、素材差替え、在庫確認、販売店通知を起動します。返却や廃棄が必要か、表示訂正で足りるかはFCC・CLAの指示と契約で判断します。
公開情報の変更を、工場の箱から小売EC画像と流通在庫まで同じmodel IDで反映します。
ラベルの信頼を壊すのは試験不合格だけではありません。公開registryと店頭の箱が違う状態を残さない流通管理が必要です。
返品・整備品・交換品では、外箱と本体modelが入れ替わることがあります。QRコードを箱だけに依存させず、本体identifierとregistry情報をservice工程でも照合します。
日本のJC-STARと同じ星だと思わない
共通証拠を再利用しつつ、制度ごとの対象と申請差分を管理します。
各国のラベル制度は相互運用を目指していますが、制度名、対象、評価方式、表示、調達効果は同じではありません。日本のJC-STARを取れば米国マークが自動付与される、またはその逆と仮定しません。
JC-STARのレベル選定 で国内調達を考える製品も、共通するNIST・ETSIの証拠、SBOM、PSIRT、更新試験を再利用しながら、申請手続と追加要件をcrosswalkします。
海外展開ロードマップでは、製品共通のsecurity caseを中央に置き、米国、EU、日本、英国、シンガポールの制度差分を添えます。国ごとに別チームが同じ製品へ矛盾するサポート期間を宣言しないようにします。
120日で一モデルを申請可能にする
製品境界、試験、運用、公開、変更を一モデルで通します。
最初の30日で一つの米国向けモデルを選び、device、app、cloud、update、supportの製品境界と責任者を確定します。
31日目から60日目はNIST IR 8425の能力を仕様・試験・運用へ対応させ、証拠不足と第三者componentを洗います。
61日目から90日目は量産firmwareと本番同等cloudで試験し、脆弱性受付、更新配信、所有者変更、初期化、サービス終了を演習します。
91日目から120日目は申請情報、レジストリ、QRコード、販売素材、変更管理を突き合わせます。KPIは未評価component、試験再現率、critical修正時間、更新到達率、レジストリ差異、EOL原価です。
申請前の合格条件は試験に一度通ることではなく、公開サポート終了日まで、同じ製品境界で脆弱性を受け、直し、届け、説明できることです。
取引先サイバーリスク管理 を使い、クラウド・SDK・製造委託先の変更通知と脆弱性協力を契約へ入れます。
まとめ
取得時点のマークを、販売後の更新責任まで含む製品運用へ変えます。
U.S. Cyber Trust Markは、箱へ貼る信頼マークを買う制度ではありません。機器とデジタルサービスを一つの製品として定義し、試験、公開情報、脆弱性受付、更新、サポート終了を継続できるメーカーへマークの使用を認める仕組みです。
取得判断の最終質問は「試験費を払えるか」ではなく、「販売後の全台へ、約束した日まで安全な更新と正確な公開情報を届け続けられるか」です。
参考情報
以下は2026年9月2日に確認した一次情報です。
よくある質問 気になる質問を開くと、本文の重要点を短く確認できます。
Q U.S. Cyber Trust Markは米国で必須ですか？ A 民間市場向けにはFCCが設けた任意制度です。ただし2025年6月の大統領令は、2027年1月4日までに連邦政府が調達する対象consumer IoTへラベルを求める方向のFAR改正を指示しています。
Q Wi-FiやBluetoothを使う製品は全て対象ですか？ A 制度はconsumer IoT productを対象としますが、医療機器など他の制度で扱われる対象外カテゴリーがあります。製品用途、無線機能、適用除外を47 CFR Part 8で確認します。
Q 機器のpenetration testだけで取得できますか？ A 機器だけでなく、必要なアプリ、gateway、backendを含むIoT product全体の能力と、文書、脆弱性受付、情報発信、教育などの開発者活動を証拠化します。
Q サポート期間は何年でなければなりませんか？ A 一律の年数を答える制度ではなく、申請者が製品のsupport period end dateを公開し、その日まで必要な脆弱性対応と更新を行う約束を管理します。販売在庫と利用期間を踏まえて設定します。
Q JC-STARを取得すれば米国マークも使えますか？ A 制度間で共通証拠や相互承認の検討はあり得ますが、JC-STAR取得だけでFCCのCyber Trust Markが自動付与されるとは限りません。最新の承認範囲と申請手続を個別に確認します。
Q ラベル取得後にアプリを大幅更新しても同じマークを使えますか？ A 認証、データ保護、更新、製品境界へ影響する変更は、元の評価と認可への影響を審査します。必要な再試験、申請・registry更新を完了する前に同一扱いしません。
