From the US Cyber Trust Mark to EU Cyber Resilience Act Compliance

Julian Meroi · Published 5 October 2026 · Last reviewed 5 October 2026

Work undertaken for the US Cyber Trust Mark can produce useful evidence for a consumer IoT product’s EU Cyber Resilience Act (CRA) assessment: security test results, product-boundary documentation, vulnerability intake procedures and update commitments. Reuse depends on what was actually assessed and whether the evidence covers the product and software version offered in Europe.

This guide is for a manufacturer preparing for the FCC program or assessing evidence from participation. It does not assume that a particular product has received authorization to use the mark.

What the US program covers

The FCC established a voluntary cybersecurity labeling program for consumer wireless IoT products. Its product approach includes the device and additional components needed to use it, such as an application or backend. Read the scope and definitions in FCC 24-26, paragraphs 14–31 and 37–38. Standalone software and enterprise equipment need their own eligibility assessment; consumer-product labeling should not be assumed to cover them.

The FCC adopted the NIST IR 8425 baseline as the program’s foundation in paragraph 96. That baseline describes six technical capabilities and four supporting capabilities. A comparison against NIST IR 8425 alone does not establish that a product meets all applicable FCC testing and authorization requirements.

Program status reviewed October 1, 2026: on April 13, 2026, the FCC announced ioXt Alliance as the program’s new Lead Administrator and said it would work with ioXt to finalize implementation of the program. The FCC’s September 28 notice recognizes A2LA and ANAB as accreditation bodies for Cybersecurity Label Administrators and CyberLABs. These documents concern program administration and accreditation; neither grants authorization for an individual product to bear the mark. Check the applicable program criteria and the scope of the actual assessment when collecting evidence.

Establish the Cyber Resilience Act product boundary

For the EU assessment, apply CRA Article 2 and Article 3 to the actual offering. Article 3(1) includes a product’s remote data processing solutions. Article 3(2) defines these by reference to processing designed and developed by, or under the responsibility of, the manufacturer, whose absence would prevent the product from performing one of its functions.

For example, compare the device, firmware, companion application and required backend described in the FCC evidence with the EU offering. Identify regional differences, optional services and software changes. General cloud hosting or SaaS activity does not automatically bring an entire service into CRA scope.

Evidence that can support a Cyber Resilience Act assessment

The US capability names below refer to NIST IR 8425, sections 2.2.1 and 2.2.2. The CRA references are in Annex I. These are possible contributions, subject to the product’s risk assessment.

The update row needs particular care. CRA Part I(2)(c) addresses automatic security updates where applicable, enabled by default, an opt-out mechanism, notification of available updates and an option to postpone installation temporarily. Part II(8) requires security updates to be disseminated without delay and free of charge, with the specified exception for tailor-made products agreed with a business user. A test demonstrating that firmware signatures are verified addresses only part of this work.

For every reused test, retain the product version, tested configuration, method, result and unresolved findings. Relate it to the relevant requirement in the risk assessment and technical documentation under Article 13(3)–(4) and Annex VII(3) and (6).

Support commitments and the SBOM need separate checks

Support. FCC 24-26 paragraph 35(vii) addresses the applicant’s commitment to identify critical vulnerabilities and issue corrective updates until the disclosed support end date, unless such updates are not reasonably needed to protect against security failures. CRA vulnerability handling under Article 13(8) and Annex I Part II is not limited to critical vulnerabilities: Part II(2) requires vulnerabilities to be addressed and remediated without delay in relation to the risks they pose. Paragraphs 113(9) and 117 address disclosure of support information. The manufacturer’s chosen date does not establish the CRA support period.

Article 13(8) requires a period that reflects expected use, considering reasonable user expectations and the other specified factors. It sets a minimum of five years unless expected use is shorter. Five years is a floor, subject to that exception, and may be insufficient for a product expected to remain in use longer. Article 13(9) separately requires each security update issued during the support period to remain available for at least ten years after issue or for the remainder of the support period, whichever is longer.

SBOM. FCC 24-26 paragraphs 113(10) and 116 address disclosure of whether the manufacturer maintains an SBOM or HBOM. That disclosure does not establish the contents of an SBOM. CRA Annex I Part II(1) requires identifying and documenting product vulnerabilities and components, including an SBOM in a commonly used, machine-readable format covering at least top-level dependencies. Check the actual inventory for the EU release, including changes since testing. The CRA does not impose public SBOM publication: see Annex VII(2)(b) and (8).

Reporting and European conformity remain necessary

The CRA’s Article 14 reporting obligations apply from September 11, 2026. They cover awareness of actively exploited vulnerabilities contained in the product and severe incidents impacting its security. They use the CRA Single Reporting Platform, with notifications to the CSIRT designated as coordinator and ENISA. The early warning is due without undue delay and within 24 hours; the next notification is due without undue delay and within 72 hours, unless the relevant information has already been provided. Final-report timing differs between vulnerabilities and incidents. Use the full requirements in Article 14(1)–(8), including the Member State selection rules for manufacturers without an EU main establishment. Article 14(8) also requires the manufacturer to inform impacted users, and where appropriate all users, of the vulnerability or incident and, where necessary, of risk mitigation and corrective measures they can deploy.

Before placing products on the market under the main CRA requirements from December 11, 2027, manufacturers also need the applicable classification and conformity-assessment route, technical documentation, EU declaration of conformity and CE marking. See Articles 7, 8, 13(12) and 32. Depending on the route, a notified body may be involved. FCC labeling authorization does not perform that EU procedure.

A practical evidence review

For a connected home device, assemble the actual US assessment materials and compare the EU model and release. Check default configuration, resetting the product to its original state, account recovery, the companion application, backend dependencies, update delivery and the documented support period. Record which evidence still applies and what needs additional testing or documentation.

This is an implementation example based on NIST IR 8425 and CRA Article 13 and Annex VII. The CRA does not mandate this particular review format.