EU Cyber Resilience Act Vulnerability Reporting Went Live September 11

EU reporting obligations are operational, not pending

The EU Cyber Resilience Act's vulnerability-reporting regime took effect on September 11, 2026. Manufacturers of connected products sold in the EU must now report active vulnerabilities and severe incidents as an operational requirement, not a future compliance exercise. The broader CRA becomes fully applicable on December 11, 2027.

The reporting duties apply to products already available in the EU market, not only newly launched devices. Vendors must maintain vulnerability processes, security updates, coordinated disclosure, software bills of materials, and lifecycle security for products with digital elements—including connected hardware, software, companion applications, and cloud-linked device ecosystems.

Enterprise buyers should treat September 11 as the start of a live obligation. Procurement teams must add contractual requirements for vulnerability notification, incident escalation, SBOM availability, patch-service-level commitments, supported-device lifetimes, and evidence of coordinated vulnerability disclosure. Buyers also need to determine which supplier bears CRA responsibility when a device is private-labeled, substantially modified, or bundled into a managed service.

Mature security operations become a competitive advantage

Vendors with established product-security operations—including IoT platforms, device-management providers, and security vendors offering asset inventory, vulnerability management, SBOM, and over-the-air updates—gain an advantage over hardware suppliers that treat security as a release-time certification exercise. The CRA broadens competitive pressure from standalone IoT security tools to suppliers that can provide evidence across the full device lifecycle.

IT and security teams should test whether the device-management platform can inventory firmware versions, detect unsupported devices, and execute staged over-the-air updates. Replacing unmanaged device fleets is slower and more expensive than updating contract language, so buyers should add CRA-aligned lifecycle requirements to 2027 purchasing cycles now.

NIST revision could reshape federal procurement requirements

NIST opened a pre-draft call for comments on SP 800-213A, the IoT Device Cybersecurity Requirement Catalog, with public comments due October 15, 2026. The catalog shapes cybersecurity requirements for IoT devices purchased by U.S. federal agencies. A revision could influence request-for-proposal language, security attestations, device documentation, vulnerability handling, and lifecycle-support requirements across federal procurement.

Vendors that already document device identity, secure update mechanisms, vulnerability disclosure, logging, configuration controls, and end-of-support policies will be better positioned for federal bids. Suppliers unable to provide those artifacts may face higher compliance costs or exclusion from security-sensitive procurements.

Enterprises selling to or supplying government customers should monitor the revision and map current device-management controls to the catalog. Commercial buyers can also use the emerging federal requirements as a benchmark when comparing platforms from Microsoft, AWS, Google, Siemens, Cisco, and specialist IoT-security vendors.

Tenda firmware backdoors underscore device-management risks

CERT/CC warned that several firmware versions from Chinese networking-equipment maker Tenda contain an undocumented authentication backdoor that can enable administrative access to web-management interfaces. The firmware reportedly embeds an authentication mechanism that bypasses normal administrative access controls.

The incident increases the value of device-management platforms that can identify exact hardware and firmware versions, enforce configuration baselines, isolate devices, and coordinate firmware replacement. It also strengthens the position of enterprise networking vendors with stronger software-supply-chain controls and formal vulnerability-response programs.

IT and security teams should audit Tenda deployments, verify firmware inventories rather than relying on model-level asset lists, restrict management interfaces, and require suppliers to disclose firmware provenance and privileged-access mechanisms. For new purchases, the incident supports weighting centralized firmware management and vendor response history alongside unit price and network performance.

What to do now

Require IoT suppliers to provide SBOMs, vulnerability-notification procedures, update support periods, and named incident contacts. Review network equipment—including Tenda devices—for undocumented administrative access and maintain an auditable firmware baseline. Add CRA and NIST-aligned lifecycle requirements to 2027 purchasing cycles before device fleets require expensive replacement.