EU Cyber Resilience Act for IoT Firmware: What Became Mandatory on 11 September 2026 and What Indian Exporters Must Ship by December 2027

Srihari Maddula

Oct 20

17 min read

Updated: Oct 22

Macro photograph of a black circuit board with electronic components — Photo: Alexandre Debiève / Unsplash

On 11 September 2026, a clock started that most firmware teams in India have not yet noticed. From that date, any manufacturer selling a connected product into the European Union has to tell the EU about actively exploited vulnerabilities in that product within 24 hours of becoming aware of them. Not 24 hours after the patch. Not 24 hours after the post-mortem. Twenty-four hours after the first credible evidence that someone is using the flaw against real devices.

The rest of the Cyber Resilience Act, Regulation (EU) 2024/2847, does not bite until 11 December 2027. That gap has produced a comfortable misreading: that the whole regulation is a 2027 problem, and that the firmware team has fourteen months to think about it. Reporting is the first duty with operational teeth, and it is live now. A team that cannot answer "which of our shipped products contain this library, in which versions, deployed where" inside a few hours is already out of position, regardless of what the December 2027 deadline says.

Here is the rule this post is built around: treat the CRA as two clocks driven by one pipeline. The reporting clock (live since 11 September 2026) is a detection-and-response problem. The conformity clock (11 December 2027) is a design-and-evidence problem. Both are served by the same four assets: an accurate software bill of materials per firmware release, a device and version inventory, a vulnerability record that survives regulator questions, and a tested path to push a fix. Build those once, and the two clocks stop being separate projects.

The CRA does not ask whether your firmware is perfect. It asks how fast you find out when it is not, what you can prove about what is inside it, and whether you can fix it in the field.

Two Dates, Two Different Kinds of Obligation

The regulation entered into force in December 2024 and phases in on two dates that matter to a hardware company. They are easy to conflate, because most summaries lead with the later one.

Date	What applies	What it demands of a firmware team
11 September 2026	Article 14 reporting duties for manufacturers (and, later, open-source stewards)	Detect, assess, and report actively exploited vulnerabilities and severe incidents to ENISA and the relevant national CSIRT through a single reporting platform
11 December 2027	Main obligations: essential cybersecurity requirements (Annex I), conformity assessment, CE marking for cybersecurity, technical documentation	Secure-by-design evidence, vulnerability handling process, SBOM, security updates for the support period, documentation retained for ten years or the support period if longer

ENISA's Single Reporting Platform opened on the same day the reporting duty began. The agency described it as an initial operating capability, so expect the tooling to keep changing during the first months. The duty did not wait for the tooling: it applies once a manufacturer becomes aware of an actively exploited vulnerability, whether or not the manufacturer's own processes are finished.

One detail is easy to miss and worth stating plainly. ENISA's guidance indicates that exploitation you already knew about before 11 September 2026 does not have to be reported retrospectively. The obligation attaches to what you learn from that date onward.

Does This Reach an Indian Exporter at All?

Yes, and the route is not through a European subsidiary. The CRA applies to "products with digital elements" made available on the EU market: hardware with a data connection, firmware, and standalone software that is placed on the market. Where the manufacturer is established does not matter. A sensor node assembled in Vijayawada, shipped to a European distributor, and sold to a European customer is in scope. The Indian manufacturer carries the manufacturer's obligations, and the EU importer and distributor carry their own, including a duty to check the manufacturer has done the work and to pass vulnerability information back.

Three groups are easy to confuse:

Manufacturers (including contract design houses selling under their own brand) carry the full set of obligations: design requirements, vulnerability handling, reporting, documentation, conformity assessment.
Importers placing a non-EU manufacturer's product on the market must verify that the manufacturer completed conformity assessment and prepared the technical documentation. In practice they will start asking Indian suppliers for evidence, which is the first way the CRA will reach many small exporters: through a procurement questionnaire, not through a regulator.
Open-source stewards (foundations and similar bodies that systematically support projects intended for commercial use) get lighter-touch obligations, with reporting duties for them starting later. A firmware company that merely uses open-source libraries is a manufacturer, not a steward, and cannot hand the duty to the upstream project.

Some product families sit under separate EU regimes (medical devices and motor vehicles, for example) and are carved out. Pure software-as-a-service with no product element is also outside scope, though the remote data-processing parts that a product needs to function are not. If your product is an industrial IoT node, a gateway, a tracker, a smart meter peripheral, or a wearable, assume you are in scope until a lawyer or notified body tells you otherwise.

The 24-Hour Clock, Step by Step

Only two kinds of events are reportable: an actively exploited vulnerability in the product, and a severe incident that affects the security of the product. The threshold is evidence of exploitation in the wild, not severity score. A critical-rated CVE with no sign of exploitation is not reportable under Article 14. A medium-rated flaw that attackers are using against real devices is.

The sequence runs on three deadlines from the moment of awareness:

Stage	Deadline	Content
Early warning	Within 24 hours	That the event occurred; whether malicious action is suspected; which EU Member States the product is available in
Vulnerability notification (or incident notification)	Within 72 hours	General description of the product and the issue, nature of the exploit, corrective or mitigating measures taken or planned, how users can mitigate, sensitivity level
Final report	14 days after a corrective measure is available (vulnerabilities); within one month of the 72-hour notification (severe incidents)	Detailed description including severity and impact, root cause where known, the patch or mitigation issued

Reports go through the single platform and are routed to the CSIRT designated as coordinator and to ENISA at once. The manufacturer files once.

Two practical points follow from the table. The 24-hour early warning needs very little information, which is deliberate: the regulator would rather know early and incompletely than late and thoroughly. And the 72-hour notification is where an unprepared firmware team discovers it cannot say which products are affected. That is a data problem, not a legal one.

"Becoming aware" is a legal concept, and nobody will let you define it as "when our security lead read the email." An advisory sitting in a shared inbox over a weekend is a risk you should resolve with a written internal definition, an on-call route, and a named person who decides.

What a Firmware Team Must Answer in the First Hour

Take any report of exploitation against a library or protocol stack you ship. The first hour of a competent response looks the same whether or not a regulation exists. The questions are:

Do any of our shipped firmware images contain the affected component, and in which version?
Which product lines, hardware revisions, and firmware versions are affected?
How many of those devices are deployed, and in which countries? (The early warning requires the Member States concerned.)
Is the vulnerable code reachable in our configuration, or is it compiled in but never called?
Do we have evidence of exploitation against our devices, or only against the library generally?
Can we push a fix, and how long does a staged rollout take?

Questions 1, 2, and 4 are answered by a software bill of materials tied to each release. Question 3 is answered by a device registry. Question 5 is answered by telemetry and logs. Question 6 is answered by your OTA pipeline. A firmware team that has these four things can answer in minutes. A team that has none of them answers in days, by asking engineers to grep old repositories from memory.

Generating an SBOM From a Real Firmware Build

The CRA's Annex I asks manufacturers to identify and document components, including by drawing up a software bill of materials in a commonly used, machine-readable format covering at least the top-level dependencies. Two formats dominate: SPDX and CycloneDX. Both are fine; choose one and stay consistent.

If your firmware is built on Zephyr, the build system can emit SPDX directly:

# Zephyr: generate an SPDX SBOM for a specific build
west build -b <board> app/
west spdx --init -d build
west build -d build
west spdx -d build
# Output lands in build/spdx/*.spdx

For a general repository (an RTOS-agnostic firmware tree, an embedded Linux rootfs, a gateway container image), scan and emit CycloneDX:

# Scan a source tree and emit a CycloneDX JSON SBOM
syft dir:./firmware -o cyclonedx-json=sbom-fw-2.4.1.cdx.json

# Scan a built Yocto/rootfs image or container
syft ./rootfs.tar -o cyclonedx-json=sbom-gw-1.9.0.cdx.json

# Check the SBOM against known-vulnerability data
grype sbom:./sbom-gw-1.9.0.cdx.json --fail-on high

Two rules keep this honest. Generate the SBOM in CI from the exact build that was released, and store it next to the signed binary, keyed by firmware version and hash. An SBOM written by hand during a documentation sprint is out of date the week after it is written. And remember that scanners see packages, not vendored copies: a C library dropped into the source tree as copied files is invisible to most tools unless you record it manually. Keep a short third_party.yaml for those cases.

Recording Whether a Vulnerability Actually Matters

Most CVEs that match a component in your SBOM do not affect your product, because you compile only part of the library, a feature is disabled, or the vulnerable path is not reachable. Record that decision in a machine-readable form so you do not re-argue it every time a scanner fires. CycloneDX supports this through VEX (Vulnerability Exploitability eXchange) statements:

{
  "vulnerabilities": [
    {
      "id": "CVE-2026-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "Affected parser is compiled out (CONFIG_PARSER_X=n) in all shipping builds of gateway firmware 1.9.x."
      },
      "affects": [ { "ref": "pkg:generic/vendor-lib@3.2.1" } ]
    }
  ]
}

The not_affected state with a documented justification is also what you hand to a customer's procurement team when they ask the question that will come up within months of the CRA taking effect: "your scanner says you ship the vulnerable library, so are we at risk?"

A Vulnerability Record That Survives Regulator Questions

When an incident is real, you will be asked for specifics under time pressure. The cheapest preparation is a fixed record format that engineering fills in as the investigation proceeds, so the 24, 72-hour, and final reports are copies of data you already hold:

# vuln-record.yaml
id: VR-2026-014
opened_utc: 2026-11-03T06:41:00Z
aware_utc:  2026-11-03T06:41:00Z        # when the decision-maker concluded exploitation is credible
source: customer report + honeypot telemetry
component: vendor-lib 3.2.1
affected_products:
  - name: GW-200 gateway
    versions: ["1.7.0", "1.9.0"]
    deployed_units_est: 3200
    eu_member_states: [DE, NL, PL, IT]
exploitation_evidence: "Anomalous config writes from 4 external IPs; matches public PoC"
mitigation_available: false
reports:
  early_warning_due_utc: 2026-11-04T06:41:00Z
  notification_due_utc:  2026-11-06T06:41:00Z
  final_report_rule: "14 days after corrective measure available"
owner: security-lead
decision_log:
  - 2026-11-03T07:10Z: "Treat as actively exploited; start clock"

The aware_utc line deserves attention. It records a decision, made by a named person, with a timestamp. Defining it in advance protects the team from both failure modes: filing too late because nobody wanted to call it, and filing noise because every scanner hit looked urgent.

If you cannot name the person who decides "we are aware," you do not yet have a reporting process.

Support Periods, Security Updates, and the OTA Question

The December 2027 obligations include several that turn a firmware roadmap into a legal commitment. Manufacturers must address vulnerabilities without delay, provide security updates free of charge during the support period, and generally make those updates available separately from feature updates. The support period must reflect the expected use time of the product and, as a baseline, last at least five years unless the product is expected to be used for a shorter time. Updates are meant to be applied automatically by default where appropriate, with the ability to opt out.

That last point turns OTA from a convenience into a conformity question. A fielded device that cannot be updated cannot meet a five-year support promise. Hardware teams who sold a sealed, flash-once product line in 2023 are exposed in a way that no process document can fix. This is why an update path needs to be treated as an architectural requirement from the first schematic review. We cover the patterns in detail in our post on OTA architecture patterns that scale; the short version for CRA purposes is: signed images, rollback protection, a staged rollout mechanism, and a way to learn which devices actually received the fix.

Alongside updates, expect a handful of design requirements that your firmware reviews should already check:

No known exploitable vulnerabilities in the product at the time it is placed on the market.
Secure-by-default configuration, with the ability to reset to the original state.
Protection against unauthorised access through authentication and identity management, with no shared default passwords baked into every unit.
Confidentiality and integrity of stored, transmitted, and processed data using state-of-the-art mechanisms.
Minimised attack surface, including unneeded interfaces such as debug ports left open.
Logging and monitoring of security-relevant events, with the user able to opt out.

The Product Class Decides Who Audits You

Not every product faces the same conformity route. The CRA sorts products into tiers, and the tier decides whether you can self-assess or need a third party.

Tier	Typical examples	Conformity route
Default (the large majority)	Most sensors, trackers, consumer and light-industrial devices	Self-assessment by the manufacturer, with technical documentation and an EU declaration of conformity
Important, Class I	Items such as identity-management software, standalone browsers, password managers	Harmonised standard or third-party assessment
Important, Class II	Items such as hypervisors, firewalls, tamper-resistant microcontrollers and secure elements	Third-party assessment by a notified body
Critical	Items such as hardware security modules and smart meter gateways	Mandatory European cybersecurity certification, where schemes exist

The lists of qualifying product categories come from the regulation's annexes and implementing acts, and the harmonised standards that will let manufacturers claim conformity are still being developed in European standards bodies. Wireless products already face a related regime: the cybersecurity requirements under the Radio Equipment Directive have applied to radio equipment since 1 August 2025, with harmonised standards in the EN 18031 series. How the two regimes interact for a given product in late 2027 is a question to settle with a notified body well before a design is frozen, not after.

The Library Advisory That Arrived on a Friday

A representative scenario, composited from field-gateway work and genericised, shows what the pipeline buys you. A manufacturer ships three product lines into Europe: a LoRaWAN-to-Ethernet gateway running embedded Linux, a battery-powered sensor node on an RTOS, and an industrial display module. A public advisory describes active exploitation of an HTTP client library, and a customer forwards it with a one-line question: "Are we affected?"

The team without a pipeline starts at 17:30 on a Friday. Someone remembers the gateway uses that library but cannot recall which version shipped to which customers. Firmware repositories are searched by hand. Two hardware revisions turn out to use different forks. By Monday a spreadsheet exists. The 72-hour notification window has already closed before anyone is certain which products are in scope.

The team with the pipeline queries its SBOM store for the component name. The result, in about ten minutes, is that gateway firmware 1.7.x and 1.9.x contain the vulnerable version; the sensor node and the display module do not contain the library at all. A device registry query returns around 3,200 deployed gateways, with an EU country breakdown. A look at the build configuration shows the vulnerable client path is reachable only when a cloud-sync feature is enabled, which is on by default. Gateway telemetry shows no sign of exploitation in its own fleet yet, so the team decides the condition for "actively exploited in our product" is not met, writes that decision down with a timestamp, and starts the patch. When a second customer report arrives two days later with logs showing exploitation against a fielded unit, the 24-hour clock starts from that documented moment, and the early warning is filed with three fields already known.

The difference is not legal sophistication. Both teams read the same regulation. One of them could answer six questions in an hour.

Due Diligence on Every Component You Did Not Write

The CRA makes the manufacturer responsible for the whole product, including parts bought in. A manufacturer integrating a third-party component must exercise due diligence so that it does not compromise the cybersecurity of the product, and must report a vulnerability found in a component to whoever maintains it. For a firmware company, that sentence covers a surprising amount of silicon vendor code. The table below lists the usual layers and the question to put to each supplier.

Layer	Typical source	What to ask before you rely on it
SoC or MCU vendor SDK and HAL	Silicon vendor	Do they publish security advisories and a support lifetime? Is there a named PSIRT contact?
RTOS or embedded Linux distribution	Open-source project or vendor	Which release branch is supported, for how long, and how are CVE fixes back-ported?
Radio module with its own firmware	Module maker	Can you update module firmware in the field? Who owns that update and its signing keys?
TLS, crypto, and protocol stacks	Open-source or commercial	Which version is pinned, and what is the process when a CVE lands upstream?
Bootloader and secure-element firmware	Silicon vendor or in-house	Is secure boot enforced, are keys per-device or per-product, and what is the key-rotation story?
Cloud backend and device management	In-house or SaaS	Does the backend count as a remote data-processing element of the product? Who patches it?

Radio modules deserve special attention because they are the component teams most often forget. A cellular or Wi-Fi module typically runs its own firmware stack from the module maker. If a vulnerability lands in that stack and the module cannot be updated in the field, the product inherits a flaw it cannot fix. Procurement should ask for update support in writing before the module is designed in, not after the first advisory.

A component you cannot update is a liability you have chosen to carry for the whole support period. Put the update question in the component selection checklist, next to price and availability.

The Technical File You Will Be Asked For

For default-class products the manufacturer self-assesses, which means the evidence is yours to assemble and yours to defend. The technical documentation must be available for inspection by market surveillance authorities, and the manufacturer keeps it for ten years after the product is placed on the market or for the support period, whichever is longer. A workable file for a firmware product contains:

A description of the product, its intended purpose, and the versions of software affecting compliance.
The cybersecurity risk assessment, showing how each Annex I requirement applies and how it was addressed.
The list of components, including the SBOM for each released firmware version.
The vulnerability handling process: intake channel, triage rule, the awareness definition, reporting procedure, and the update procedure.
Test and verification evidence: results of security testing, fuzzing of parsers, penetration testing of exposed interfaces, and the secure-boot and update test records.
The EU declaration of conformity and the user information and instructions that accompany the product.

Most of this exists in some form inside a competent engineering team. The work is collecting it per release rather than reconstructing it in a rush. A practical habit: treat each firmware release as producing a release bundle (signed binary, SBOM, test report, change log, risk-assessment delta) and archive the bundle in write-once storage.

What to Log So the 24-Hour Clock Is Answerable

Questions 5 and 6 from the first-hour list depend on telemetry that most devices do not send. Exploitation evidence in the field rarely arrives as a polite customer email. It arrives as patterns: configuration writes from unexpected sources, repeated authentication failures followed by one success, an unscheduled reboot count that jumps across a fleet, firmware hashes that do not match what was shipped.

Decide in advance which security-relevant events a device reports, keep them small, and make them cheap to send. A compact event record from a gateway might look like this:

// Security event record, sent on state change or threshold, not continuously
typedef struct __attribute__((packed)) {
    uint32_t ts_unix;        // device clock; server stamps its own time on receipt
    uint8_t  event_id;       // 1=auth_fail_burst, 2=cfg_write_remote, 3=fw_hash_mismatch,
                             // 4=unexpected_reboot, 5=debug_port_active, 6=update_rejected
    uint8_t  severity;       // 0..3
    uint16_t count;          // occurrences since last report
    uint8_t  src_class;      // 0=local, 1=LAN, 2=WAN, 3=unknown
    uint8_t  fw_hash8[8];    // first 8 bytes of running image hash
} sec_event_t;               // 17 bytes

On a LoRaWAN or satellite link, 17 bytes per event is affordable; on Ethernet it is trivial. The server side then needs two rules at minimum: alert on fw_hash_mismatch from any unit (someone has altered an image), and alert on a sudden fleet-wide rise of any single event class. Neither rule proves exploitation, but both give the awareness decision something factual to rest on.

Privacy deserves a sentence. Security logs that identify individuals fall under data protection law, so keep event records technical and avoid payloads that carry personal data.

What the Five-Year Support Promise Costs

A support period is a recurring cost, and it is better priced before the product is sold than after. Consider a fleet of 3,200 gateways on Ethernet with a 400 KB signed delta image per update. One staged rollout moves roughly 1.3 GB of image data, which is negligible. Now consider 3,200 battery-powered nodes on a LoRaWAN link, where a full image of 128 KB must travel over a link whose practical throughput is measured in hundreds of bits per second after duty-cycle limits and fragmentation overhead. Multicast firmware-update-over-the-air schemes exist for this case, but a full image can take hours to days to complete across a fleet, and every missed fragment must be recovered. The same security promise has a different price on each link.

Plan the support period around the most expensive link in the line-up. Where the physical layer cannot carry a full image economically, the design response is to isolate the small, security-critical parts (bootloader, crypto, network handling) so that they can be updated cheaply and the large application image changes rarely. That architectural split is a decision for the first design review, not the third year in the field.

Add the people cost. A five-year promise implies someone monitors upstream advisories for every component for five years, rebuilds, regression-tests, and ships. Teams that sell a product line and disband its engineers will find the promise expensive to keep. A simple rule: budget the support period as an annual line item, per product line, starting the year of launch.

The SBOM paid for itself in one ten-minute query. Generate it in CI for every release and store it next to the signed binary.

When This Framework Is Overkill

Not every company needs this level of machinery on day one. A manufacturer that sells only in India, with no plans to export to Europe, is not subject to the CRA, though the same hygiene is increasingly requested by large Indian enterprise and defence customers, and building it once for both markets is cheaper than building it twice. A prototype-stage product with a single pilot deployment does not need a full registry. A design house that delivers firmware to a client who then brands and sells the product may not be the CRA manufacturer at all, and the contract should say who is.

Two ways to over-engineer are worth avoiding. Do not report every scanner hit: the threshold is active exploitation, and flooding the platform with unexploited CVEs would be both wrong and counterproductive. And do not buy a platform before you have a process. A shared spreadsheet fed from CI-generated SBOMs and a written on-call rule will carry a small team a long way.

Starting on Monday Morning

A sequence that fits a team of ten to fifteen engineers, ordered so each step makes the next cheaper:

Week 1, inventory. List every product line, hardware revision, and firmware branch still supported in the field. Record where each ships. This list alone will expose forgotten products.
Week 2, SBOM in CI. Add SBOM generation to the release pipeline for every product, store it with the signed binary, and name artifacts by version and hash.
Week 3, intake. Publish a security contact and a vulnerability disclosure policy. A security.txt file at /.well-known/security.txt on your website is a small, standard start, and an alias that reaches a human on weekends is the part that matters.

# /.well-known/security.txt (RFC 9116)
Contact: mailto:security@example.com
Expires: 2027-10-20T00:00:00.000Z
Policy: https://example.com/security-policy
Preferred-Languages: en

Week 4, the awareness rule. Write down who decides that exploitation is credible, how they can be reached out of hours, and how the decision is recorded. Rehearse once with a fictional advisory.
Week 5 to 6, device registry. Make sure you can enumerate deployed units by product, firmware version, and country, even if the first version is a query over your cloud backend.
Week 7 to 8, update path audit. For each product, answer: can we push a signed update, can the device roll back, and can we tell who has the fix? Anything with a "no" goes on the roadmap with a date.
Quarter 2, design reviews against Annex I. Add the secure-by-default and attack-surface checks to every schematic and firmware review so the evidence accumulates as a by-product of normal work.

Where to Verify Every Date in This Post

Regulations move through delegated acts, implementing acts, and guidance, and this post will age. The primary sources are the text of Regulation (EU) 2024/2847 (Articles 13, 14, 16 and 64, and Annex I in particular), ENISA's pages and FAQ for the Single Reporting Platform, and the European Commission's CRA reporting page. Penalties for breaching the core obligations are severe: for the most serious categories, administrative fines scale up to €15 million or 2.5 percent of worldwide annual turnover. Treat those figures as upper bounds to confirm in the regulation, and take legal advice for your specific product and contract structure. Nothing here is legal advice.

The Friday Question

The point of the story above is the Friday afternoon, not the regulation. Every connected product eventually meets a day when someone outside the company says "this is being exploited," and the quality of what happens next was decided months earlier, by whether the firmware team could say what was inside its own releases. The CRA now puts a 24-hour deadline on that moment, and the preparation costs far less than a single late report. Start with the SBOM, because everything else is easier once you know what you shipped.