The U.S. Cyber Trust Mark: the FCC's IoT labeling program and what it means for device makers

The FCC describes its own goal plainly: the IoT Labeling Program gives consumers "an easy-to-understand and quickly recognizable FCC IoT Label that includes the U.S. government certification mark... that provides assurances regarding the baseline cybersecurity of an IoT product," administered under the FCC's Public Safety and Homeland Security Bureau (PSHSB). Unlike the UK's PSTI regime, which has been mandatory law since 29 April 2024, the FCC chose a voluntary structure on the reasoning that broad industry buy-in was more valuable early on than a compliance mandate — but once a manufacturer applies to use the mark, the program's requirements, testing and registry disclosures are not optional for that product.

The Order applies to IoT products, not just IoT devices — a deliberately broader unit of analysis than many existing device-level standards use. Following NIST IR 8425's scoping definition, an in-scope "product" is the IoT device plus whatever else is needed to use it beyond basic operation: a companion mobile app, a backend or cloud service, and any specialty networking or gateway hardware in between. The FCC adopted this product-level scope over objections from commenters who wanted a narrower device-only program, agreeing with NIST that "the cybersecurity technical and non-technical outcomes defined in the NISTIR 8425 consumer profile apply to IoT products and not just IoT devices."

Some categories sit outside the program entirely. The FCC's product definition explicitly carries over NIST's exclusion of "common general purpose computing equipment (e.g., personal computers, smartphones) as well as routers" — router-specific requirements are being developed separately rather than folded into this baseline. Motor vehicles and motor vehicle equipment are excluded by a separate statutory definition in the Order, and medical devices fall outside this program's current scope as well. For the comparable but distinct European consumer-IoT baseline, see ETSI EN 303 645; for the separate US federal-procurement baseline that also builds on the NISTIR 8259 series, see NIST IoT device cybersecurity requirements.

The FCC built its technical baseline directly on NIST IR 8425, Profile of the IoT Core Baseline for Consumer Products, rather than writing new criteria from scratch. The Order lists ten outcomes, split between what the product must do on its own and what the product's developer must do around it:

NIST frames the first six as outcomes "expected to be satisfied by software and/or hardware implemented in the IoT product," and the last four as activities performed by the product's developer rather than the product itself — the FCC's Order adopts both halves as its testing baseline.

Every product approved to use the FCC IoT Label must display the Cyber Trust Mark together with a QR code; the FCC made the QR code mandatory precisely so the label stays current even after a product ships. Scanning it opens a decentralized, API-driven registry rather than a single static database — manufacturers supply information through a common API, and the registry surfaces it to consumers in a uniform format. The Order pared this down from an earlier, more expansive proposal to eleven required elements:

• Product name and manufacturer name
• Date the product's authorization (cybersecurity certification) was granted, and the authorization's current status
• Name and contact information of the authorizing Cybersecurity Label Administrator
• Name of the lab that conducted the conformity testing
• Instructions for changing the default password (or a statement that it cannot be changed)
• Information or a link on how to configure the product securely
• Whether software updates are automatic, and how to get them if not
• The minimum support end date through which the manufacturer commits to identifying and patching critical vulnerabilities — or a statement that the product is unsupported
• Disclosure of whether the manufacturer maintains a Hardware Bill of Materials (HBOM) and/or Software Bill of Materials (SBOM)
• Additional elements the FCC's Bureau may later require

The FCC deliberately limited the registry to this list after commenters warned that a fuller catalogue — including published vulnerability details — would be too complex to maintain and could tip off attackers; the SBOM/HBOM item discloses only that a bill of materials exists, not its contents.

Running the registry and reviewing applications is delegated below the FCC itself. A single Lead Administrator coordinates a network of Cybersecurity Label Administrators (CLAs), who review individual applications and authorize (or deny) a product's use of the label; CLAs must be accredited to ISO/IEC 17065, the standard for product certification bodies. Actual conformity testing against the NIST IR 8425 criteria is performed by an accredited and Lead Administrator-recognized lab — the Order's term for this is a CyberLAB — or alternatively by a CLA's own in-house testing lab or by the applicant's own in-house lab, each accredited to ISO/IEC 17025, the general lab-competence standard.

The Lead Administrator role has already changed hands once during rollout: the FCC named UL Solutions Lead Administrator in December 2024, UL Solutions filed a notice of withdrawal in December 2025, and the FCC named the ioXt Alliance as the new Lead Administrator on 13 April 2026, with FCC Chairman Brendan Carr framing the change around "advancing national and cyber security" alongside the program's original consumer-information goal. A device maker planning a launch date around certification should check the FCC's Cyber Trust Mark program page directly for the current list of recognized CLAs and CyberLABs before committing to a timeline.

Two parts of the Order connect directly to the kind of firmware and software supply-chain evidence a device maker already needs for other regimes. First, the registry's SBOM/HBOM disclosure item means a manufacturer has to state, in a public and dynamic record, whether it maintains that inventory at all — a yes/no disclosure, not a published parts list. Second, every applicant signs a declaration under penalty of perjury that it "will, until the support period end date disclosed in the registry, diligently identify critical vulnerabilities" in the product and issue corrective updates. Meeting that commitment in practice, across a product's declared support period, depends on actually knowing what firmware components are present and which of them carry known exploitable vulnerabilities — the same underlying work covered in firmware SBOM without source code.

This is one of the places where AI-assisted analysis adds real, bounded value rather than a marketing claim: engineer-reviewed, automated component identification and known-vulnerability matching across a firmware image can build and keep current the SBOM and vulnerability-handling record an applicant needs to honor that perjury declaration, faster than purely manual research. It does not do more than that. It cannot stand in for a CyberLAB's accredited conformity test against the ten NIST IR 8425 outcomes, it does not decide whether a CLA authorizes the label, and no part of the FCC's program recognizes an "AI-certified" shortcut around accredited testing.

The Cyber Trust Mark sits alongside, not instead of, other regimes a device maker selling internationally may already be tracking. It is voluntary where the UK's PSTI regime and the EU's Cyber Resilience Act are mandatory; its NIST IR 8425 technical baseline overlaps substantially with — but is not identical to — the device-level outcomes in ETSI EN 303 645 and the federal-procurement-focused NISTIR 8259 series and SP 800-213. None of these frameworks formally defer to another, so a product sold into multiple markets typically needs a shared evidence base — firmware component inventory, update mechanism, and vulnerability-handling process — mapped separately against each one's specific criteria rather than a single certification covering all of them.