US Federal Software and IoT Procurement Evidence for the EU Cyber Resilience Act

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

Federal contracts can leave a software or IoT supplier with useful security evidence: development records, inventories, customer security requirements, test results and vulnerability-response commitments. For EU Cyber Resilience Act (CRA) preparation, identify which of those records demonstrate the security of the product you will place on the EU market.

This guide covers the procurement context and how to assess the resulting evidence. The detailed development-practice mapping is in our NIST SSDF to CRA guide. The SBOM discussion here concerns federal procurement evidence; SBOM work is relevant to manufacturers worldwide.

Federal software-assurance policy changed in 2026

OMB M-26-05, page 1, dated January 23, 2026, rescinded M-22-18 and M-23-16. It directs agencies to develop software and hardware assurance policies suited to their risk determinations and mission needs.

Agencies may continue to use the Secure Software Development Attestation Form. They may also adopt contract terms requiring a current SBOM on request. For cloud platforms, the memorandum’s footnote says such terms should specify the runtime production environment. These are agency choices described by the memo, so a current supplier assessment must start with the applicable contract and agency requirements. Do not assume that every federal supplier has the same current attestation or SBOM duty, or that the memo automatically removed a term from an existing contract.

An attestation can help identify the practices and products covered by a supplier’s declaration. For a CRA assessment, collect the underlying evidence: what ran, for which releases, with which findings and corrective actions. Article 31(1) requires technical documentation containing the relevant data or details of the means used to ensure that the product and manufacturer processes meet Annex I.

Federal IoT procurement has an additional statutory basis

The IoT Cybersecurity Improvement Act of 2020 addresses federal agency use of IoT devices. Sections 4 and 5 concern NIST security standards and guidelines and vulnerability disclosure guidance. Section 7 prohibits agency procurement, obtaining, renewal or use where the agency CIO determines that use prevents compliance with the relevant standards and guidelines, subject to its waiver provisions.

This is a federal acquisition framework. It does not impose a general security certification on every consumer device sold in the US. The Act’s device definition and the agency’s requirements need to be checked for the particular procurement.

NIST SP 800-213, sections 3 and 4 helps agencies identify device requirements and manage gaps in the context of their systems. A customer’s approved deployment can depend on network controls, physical protection or operating procedures around the device. Record these assumptions when considering reuse for an EU product assessment.

Turn procurement evidence into product evidence

The table gives Meroi Security’s analytical mapping. NIST guidance is a useful technical reference; its use does not itself establish a CRA presumption of conformity under Article 27.

Activity numbers refer to NIST IR 8259 Revision 1, April 2026, sections 3.2–3.6 and 4.1–4.3. Use that edition when reading this table. The 2020 edition uses a different activity structure.

An agency’s compensating controls need examination

Suppose a federal deployment accepts an IoT sensor because it runs on an isolated network and administrators restrict its management interface. Those deployment conditions are relevant evidence about the expected environment. Assess whether the same assumptions hold for the EU product’s intended and reasonably foreseeable use.

Article 13(3) expressly includes conditions of use, such as the operational environment and assets to protect. It also requires an explanation of which Annex I Part I(2) requirements apply and how they are implemented. An agency’s risk acceptance does not determine the manufacturer’s CRA conclusion. Check the product design, defaults and instructions against the assessment, including whether the product may be deployed without the federal customer’s surrounding controls.

This sensor review is an implementation example based on SP 800-213 and CRA Article 13. The CRA does not mandate this particular scenario or review format.

How to assess an existing federal SBOM

The CISA 2026 Minimum Elements replaces the 2021 NTIA minimum elements. Its scope section expressly says the document creates no new requirements. Contractual incorporation and the actual delivery specification still matter.

For the CRA, Annex I Part II(1) requires a commonly used, machine-readable format covering at least top-level dependencies. The practical checks are:

1. Match the inventory to the product release and included software components.
2. Identify whether the federal inventory covers a development environment, deployed service, firmware image or shipped package. Compare that scope with the EU product, including qualifying remote data processing under Article 3(2).
3. Check machine readability and dependency coverage against the CRA provision.
4. Connect identified components to the vulnerability-handling work and integrated-component due diligence required by Article 13(5)–(6).

These checks illustrate an implementation based on the cited sources. CISA’s individual data fields and this four-step review format are not prescribed by the CRA. A detailed federal SBOM can provide useful input without creating an automatic finding of EU compliance.

Establish reporting separately from contract notifications

The manufacturer’s Article 14 obligations apply from September 11, 2026. Awareness of an actively exploited vulnerability contained in the product or a severe incident impacting its security triggers the applicable notification process through the CRA Single Reporting Platform to the CSIRT designated as coordinator and ENISA. 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.

Both processes include an early warning without undue delay and within 24 hours of awareness, followed by a notification without undue delay and within 72 hours unless the relevant information has already been provided. Vulnerability final reports are due no later than 14 days after a corrective or mitigating measure is available; severe-incident final reports are due within one month after the incident notification. The already-provided-information qualification also applies to the final reports. See Article 14(2) and (4).

Build these obligations into the existing response arrangements alongside customer-contract notifications. A federal customer’s ticket, supplier attestation or US incident report does not submit the CRA notification.

What to prepare for an EU product review

Assemble the applicable federal contract requirements, product and version scope, development evidence, test reports, SBOM and support commitments. For each record, identify the CRA requirement it helps demonstrate and the remaining evidence needed. This suggested organization follows Article 31 and Annex VII; the CRA does not prescribe that record format.

Then determine the EU product’s classification, conformity-assessment route, documentation, declaration and CE-marking work under Article 13(12) and Article 32. Main application starts December 11, 2027; reporting follows the earlier date set in Article 71.