US Cyber Trust Mark Guide: The Labelling Programme for Smart Devices

Buyers of smart home devices have had no simple way to tell a product built with basic security from one shipped with a shared default password and no update plan, and the US Cyber Trust Mark is the Federal Communications Commission's attempt to fix that with a voluntary label. The programme was created by the FCC's IoT Labeling Order in March 2024 and is codified in 47 CFR Part 8, Subpart B. Its rollout has been slower and bumpier than planned: the first Lead Administrator withdrew in December 2025 and a replacement was selected in April 2026. This guide explains who the programme applies to, what the rules require of manufacturers, labs and administrators, how a product is tested and authorised, and how the label relates to NIST, ETSI and EU requirements. It is written for product security leads, compliance managers and security teams who buy or build consumer connected devices. Status is stated as of the FCC public notices available in October 2026.

Key takeaways

• Voluntary, but with real legal teeth once you opt in. No manufacturer has to use the label, but a grantee that does takes on continuing obligations under 47 CFR Part 8, including a declared support period, record keeping and termination for nonconformance.
• The technical baseline is NISTIR 8425. The Order requires the Lead Administrator to base its recommended standards and test procedures on NIST's consumer IoT profile: six product capabilities and four developer activities.
• Third parties run the scheme. Accredited CyberLABs test, Cybersecurity Label Administrators (CLAs) review and authorise, and a Lead Administrator coordinates standards and outreach. The FCC keeps oversight and enforcement.
• The QR code matters as much as the logo. The label links to a public IoT Registry entry that discloses the support period end date, update method, default password instructions and whether an SBOM is kept.
• Status is still settling. UL Solutions withdrew as Lead Administrator effective 19 December 2025, ioXt Alliance was selected in April 2026, and as of the FCC's August 2026 notice the labelling standards and test procedures had not yet taken effect, so check the docket before planning a launch.

What it is and who it applies to

The Commission adopted the Report and Order (FCC 24-26) on 14 March 2024 and released it the next day; the rules took effect on 29 August 2024, with compliance dates to follow Paperwork Reduction Act review. The work sits in PS Docket No. 23-239 and is run by the Public Safety and Homeland Security Bureau. Products that pass get the FCC IoT Label: the US Cyber Trust Mark logo plus a scannable QR code.

Scope

• In scope: wireless consumer IoT products. Under 47 CFR 8.203 an IoT device is internet connected, intentionally emits radiofrequency energy, has at least one sensor or actuator and a network interface, and is intended primarily for consumer rather than enterprise or industrial use. A "product" includes the device plus the components it needs, such as backend services, gateways and mobile apps.
• Out of scope for now: FDA-regulated medical devices, NHTSA-regulated motor vehicles and their equipment, enterprise and industrial products, and wired-only devices.
• Excluded sources: products from entities on the FCC Covered List, the Commerce Entity List, the Department of Defense Section 1260H list of Chinese military companies, or entities debarred from federal awards cannot carry the label (47 CFR 8.204). Applicants declare this under penalty of perjury.

Who does what

Programme status as of October 2026

The August 2026 notice ties CLA accreditation to "the effective date of the adopted IoT labeling standards and testing procedures" and states that conditionally approved CLAs cannot yet approve use of the label. Treat the programme as legally established but not yet operational for most product classes, and watch PS Docket 23-239 for the standards order.

Structure and key requirements

The FCC has not yet adopted product-class standards, so the best guide to what testing will cover is the baseline the Order points to: NISTIR 8425, Profile of the IoT Core Baseline for Consumer IoT Products (September 2022). For routers NIST published a separate profile, NIST IR 8425A (September 2024).

Obligations written into the rules

• Support period: the applicant commits to identify critical vulnerabilities and issue updates promptly until a disclosed support period end date (47 CFR 8.208). That date appears in the registry.
• IoT Registry disclosures (8.222): product name, manufacturer, authorisation date and status, CLA and lab, how to change the default password, secure configuration information, how updates are delivered, the minimum support period end date and whether a software or hardware bill of materials is maintained.
• Defects and design changes (8.214): the grantee must investigate complaints and report to the FCC within 20 days when asked.
• Records (8.215): kept for two years after the product stops being marketed, longer if a proceeding is pending.
• Advertising (8.213): the mark cannot be used deceptively, for example on a variant that was not authorised.
• Termination (8.216): authority to use the label ends on false statements, nonconformance or the grantee becoming a listed source.
• Renewal: the Lead Administrator recommends renewal intervals per product class; Part 8 does not set a fixed period.

Identity and NHI requirements

Several criteria are identity controls in all but name, and the device itself is a non-human identity that talks to a cloud backend with its own credentials.

• Device identity: Asset Identification needs a unique, durable product identifier. In practice that means a per-device certificate or key provisioned at manufacture, not a serial number in plain text. See the Device and IoT Identity Guide.
• Default credentials: the registry must say how to change the default password, and testing is expected to reject shared defaults that attackers use as Default Accounts (MITRE ATT&CK T1078.001) or guess with Brute Force (T1110).
• Interface access control: local web interfaces, debug ports, Telnet or SSH services and pairing protocols each need an authentication decision.
• Backend and app credentials: because the "product" includes backends and apps, API keys embedded in a mobile app or firmware are in scope. Hard-coded keys found in a binary (Credentials In Files, T1552.001) undermine the whole label. The Verkada camera breach shows how admin credentials in a vendor's support tooling can expose customer devices at scale, even when device firmware is sound.
• Update signing keys: Software Update relies on a signing key that is the most privileged NHI the manufacturer owns. Store it in an HSM, limit who can sign, and log every signing event.

Implementation steps

1. Decide whether the label is worth it per product line. Consider US retail channel demand, procurement requirements from customers, and the cost of a public support period commitment you must then honour.
2. Confirm eligibility. Check the product is wireless, consumer-focused and not a medical device or vehicle; screen every component supplier against the Covered List, Entity List and 1260H list, because the perjury declaration covers the whole product.
3. Gap assess against NISTIR 8425 now. Score each of the ten criteria for the device, app and backend. If you already target ETSI EN 303 645, map existing evidence across; the overlap is large.
4. Fix the high-impact gaps first: unique per-device credentials, signed and authenticated updates, a published vulnerability disclosure policy, disabled debug interfaces and removed hard-coded secrets.
5. Set and document the support period. Agree it with engineering and finance, since it becomes a public commitment in the registry.
6. Prepare registry content and an SBOM. Write clear, plain language instructions for changing passwords and secure configuration. See the SBOM Guide.
7. Pick a CyberLAB and CLA once they are authorised. Confirm the lab's ISO/IEC 17025 scope covers the FCC programme and the CLA has full, not conditional, approval.
8. Pilot with one product. Run a dry test with the lab before committing a whole range; use the findings to fix shared platform components.
9. Plan for change and rollback. Define which firmware or hardware changes trigger a reassessment under 8.214, and how you will pull the label from packaging and listings if authorisation is terminated or the product reaches its support end date.

Evidence and assessment

Metrics that show the programme is working

• Patch latency: median days from confirmed critical vulnerability to shipped fix, per product.
• Update uptake: share of active devices on the latest security release 30 days after release.
• Registry accuracy: registry entries checked against current firmware and support dates each quarter, target 100 percent.
• Disclosure responsiveness: percentage of researcher reports acknowledged within the published timescale.
• Secret hygiene: count of hard-coded credentials found by binary scanning of release images, target zero.

Monitor backend authentication logs for spikes of failed device logins, devices reporting old firmware long after release, and certificate failures, which often signal cloning or tampering.

Mapping to other frameworks

• ETSI EN 303 645: the European baseline covers much of the same ground with more prescriptive provisions. Evidence built for it reuses well here. See the ETSI EN 303 645 Consumer IoT Guide.
• UK PSTI: mandatory in the UK for three requirements (passwords, vulnerability reporting, support period), all of which the Trust Mark registry also discloses.
• EU rules: the Radio Equipment Directive delegated act and the Cyber Resilience Act are mandatory for the EU market; a Trust Mark does not satisfy them, but the same engineering work feeds both. See the EU Cyber Resilience Act Guide.

Small vs large manufacturers

A small vendor with one or two products may get more value from building to EN 303 645 and NISTIR 8425 now and deciding on the label once a CLA is fully authorised. A large vendor selling through US retail should run a pilot as soon as standards are adopted, because shared platforms mean one assessment programme can cover many SKUs, and the registry obligations are cheaper to automate than to maintain by hand.

Common pitfalls

• Treating the label as a one-off test. The grant carries continuing duties, and a missed support commitment is a nonconformance that can end authority to use the mark.
• Testing the device and forgetting the cloud. The product definition includes backends and apps. A secure device with a weak API or leaked keys fails the intent of the programme.
• Shared or derivable default credentials. Credentials baked into firmware are discovered and published quickly, as the HPE Aruba Instant On hard-coded credentials case shows: every device shared the same admin login.
• Supplier screening done once. Covered List and Entity List entries change; a component vendor added later can put your grant at risk.
• Registry drift. Firmware updates change update methods and configuration guidance, and the registry entry is left stale.
• Planning launches around old timelines. Early 2024 and 2025 announcements assumed labelled products soon after; the Lead Administrator change reset that. Build plans from the latest public notice.

Practitioner checklist

• Track PS Docket No. 23-239 and record the date the standards and test procedures take effect.
• Confirm each candidate product meets the 47 CFR 8.203 definition and is not excluded.
• Screen all component suppliers against the Covered List, Entity List and 1260H list, and repeat on a schedule.
• Run a NISTIR 8425 gap assessment across device, app and backend.
• Remove shared defaults and hard-coded secrets; provision unique per-device identity.
• Sign updates with keys held in an HSM and verify signatures on the device.
• Publish a vulnerability disclosure policy with acknowledgement timescales.
• Agree and publish a support period end date that finance and engineering will honour.
• Check that your CyberLAB and CLA have full, not conditional, FCC approval.
• Automate registry updates from your release process.

Standards and references

• eCFR: 47 CFR Part 8 Subpart B, Cybersecurity Labeling Program for IoT Products
• Federal Register: Cybersecurity Labeling for Internet of Things (FCC 24-26)
• FCC: PSHSB Selects ioXt Alliance as New Lead Administrator (DA 26-354)
• FCC: Filing Window for Lead Administrator Applications (DA 26-18)
• FCC: Conditionally Approved Cybersecurity Label Administrators (DA 26-834)
• NIST: IR 8425, Profile of the IoT Core Baseline for Consumer IoT Products
• NIST: IR 8425A, Recommended Cybersecurity Requirements for Consumer-Grade Router Products
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: IoT Security Guide · Device and IoT Identity Guide · ETSI EN 303 645 Consumer IoT Guide · EU Cyber Resilience Act Guide. This guide summarises the US Cyber Trust Mark programme and FCC rules as of October 2026 and is not legal advice.