For most of the last two decades, product cybersecurity in Europe was a matter of best practice and reputation. The EU Cyber Resilience Act (CRA) ends that era. From December 2027, security stops being a differentiator a manufacturer can choose to invest in, and becomes a precondition for selling a connected product in the European Union at all. For CISOs at OEMs — and for the engineering teams that build their products, wherever those teams sit — this is the most consequential shift in product accountability since GDPR.

Here is what the CRA is, who it reaches, and what it demands of an OEM and its development organisation.

What is the EU CRA?

The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the first horizontal EU law to set mandatory cybersecurity requirements for “products with digital elements” — essentially any hardware or software product, and its remote data-processing components, that can be connected to a device or network. It entered into force on 10 December 2024 and follows a phased rollout.

Two dates matter most. From 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe security incidents to authorities. From 11 December 2027, the full regime applies: secure-by-design obligations, conformity assessment, technical documentation, and CE marking. A third, quieter milestone — 11 June 2026 — activates the framework for notifying conformity assessment bodies, the third-party labs that will certify higher-risk products.

The intent is straightforward but far-reaching: products should ship with fewer exploitable weaknesses, manufacturers should remain accountable for security across the product’s lifecycle, and the market should become more transparent about what is — and isn’t — secure.

Where does the CRA apply?

The CRA applies across all 27 EU member states, but its reach is far wider than its borders. Like GDPR, it is extraterritorial: what triggers it is not where you are headquartered but whether your product is made available on the EU market. A device manufactured in Asia, a SaaS-connected appliance, or even software downloadable from an app store accessible in the EU falls in scope regardless of the company’s location.

The scope is broad by design. It covers consumer IoT, industrial equipment, networking gear, embedded firmware, mobile and desktop applications, and the open-source and third-party components inside them. A handful of categories are carved out because they already have their own sector rules — notably medical devices, in-vitro diagnostics, type-approved motor vehicles, and certified civil aviation products. Non-commercial open source is also largely excluded. Almost everything else with a digital element is in.

How does it apply to an OEM selling into the EU?

If you are an OEM placing a product on the EU market, you are the manufacturer under the CRA — the economic operator who carries the bulk of the legal obligations. Crucially, you are responsible for the security of the entire finished product, including every third-party library, firmware blob, and open-source dependency inside it. If a vulnerability surfaces in an upstream component you didn’t write, it is still your obligation to report and remediate it. You cannot push that accountability up the supply chain.

The CRA also sorts products into risk tiers, and the tier determines how heavy the compliance path is. Roughly 90% of products fall into the default category and may use self-assessment. Important products (Class I — identity and access management, password managers, VPNs, routers, antivirus, operating systems; Class II — firewalls, IDS/IPS, hypervisors, tamper-resistant microcontrollers) face stricter routes, with Class II requiring a notified body in every case. Critical products (hardware security modules, secure elements and smart cards, smart meter gateways) demand the highest assurance, typically via European cybersecurity certification. For payments, identity, and security-hardware OEMs, this is precisely where the regulation bites hardest — many of their flagship products sit in the Important and Critical tiers.

What does the OEM need to do to be compliant?

Compliance is not a document you produce once; it is a lifecycle discipline you have to evidence. In practice, an in-scope OEM must:

• Run a cybersecurity risk assessment spanning planning, design, development, production, delivery, and maintenance — and let it actually shape architecture and engineering decisions.

• Meet the Annex I essential requirements — secure-by-default configuration, no known exploitable vulnerabilities at release, encryption of data at rest and in transit, robust access control, a secure update mechanism, minimised attack surface, and logging and monitoring.

• Operate a vulnerability-handling process with coordinated disclosure, defined remediation timelines, and free security updates for the product’s support period — guidance points to at least five years unless the product’s expected life is shorter.

• Maintain a Software Bill of Materials (SBOM) in a machine-readable format, covering at minimum top-level dependencies, and exercise supply-chain due diligence over component suppliers.

• Produce the conformity package — technical documentation (Annex VII), an EU Declaration of Conformity, the correct conformity assessment for the product’s tier, and the CE marking before the product goes to market.

• Stand up incident and vulnerability reporting to ENISA and the relevant national CSIRT, on a hard clock: an early warning within 24 hours of awareness, a follow-up within 72 hours, and a final report within 14 days (vulnerabilities) or one month (incidents), with affected users notified without undue delay.

The penalties give this teeth. Breach of the essential requirements can draw fines of up to €15 million or 2.5% of global annual turnover, whichever is higher — alongside the more existential risk of being barred from the EU market.

How the CRA reaches the India GCC building the product

Here is the part many leadership teams underestimate. The CRA’s legal obligations sit with the manufacturer — but the work of compliance happens wherever the product is actually engineered. For a large share of global OEMs, that is an India-based Global Capability Centre.

The essential requirements translate directly into engineering practice: secure-by-design coding standards, threat modelling, eliminating known exploitable vulnerabilities before release, building and validating secure update mechanisms, generating and maintaining the SBOM, and running coordinated vulnerability disclosure. Every one of those is executed by the development team — and increasingly, that team is in Bengaluru, Hyderabad, or Pune, not Munich or Stockholm.

The 24-hour reporting clock makes the dependency even sharper. When an exploited vulnerability is detected, the GCC’s security engineering and on-call functions are the ones who must triage it fast enough for the manufacturer to notify ENISA in time. In effect, the CRA exports EU product-security obligations into Indian development organisations. The GCC may not be the “manufacturer” on the declaration of conformity, but it is where compliance is won or lost. For GCC leaders, the message is concrete: secure development lifecycle maturity, SBOM tooling, and product incident response are now market-access requirements for their parent company — not internal nice-to-haves.

Typical pain points organisations face

Across early CRA programmes, the same friction points recur:

• Scoping and classification ambiguity — deciding which products are in scope and which tier they fall into, especially for hybrid hardware-software and SaaS-connected products.

• Supply-chain and SBOM blind spots — many teams cannot yet produce a complete, machine-readable SBOM, let alone monitor upstream and open-source dependencies continuously.

• Secure-development-lifecycle gaps — ad-hoc security practices that don’t yet meet “no known exploitable vulnerabilities at release,” and that lack the audit trail to prove it.

• The 24-hour clock — most product organisations have no reporting workflow that can detect, classify, and escalate a reportable event fast enough.

• Conformity assessment readiness — for Important and Critical products, the technical documentation and third-party testing burden is heavy, and notified-body capacity is still ramping up.

• Cross-border ownership — confusion over who owns CRA compliance between EU entities, importers, and offshore development centres.

How PrismDiscover keeps your SBOM live — and your CRA reporting on time

The CRA turns the Software Bill of Materials from a one-time deliverable into a living obligation, and it makes the manufacturer answerable for vulnerabilities in every upstream and open-source component — even the ones you never wrote. That combination is exactly what PrismDiscover is built to address.

• A live SBOM, not a snapshot. PrismDiscover continuously discovers and inventories the components inside your products, keeping the SBOM current as code, dependencies, and releases change. Instead of a machine-readable SBOM that is accurate the day you generate it and stale the day after, you maintain the always-current inventory the CRA expects under Annex V.

• Daily scanning for upstream vulnerabilities. Every day, PrismDiscover checks your live component inventory against the latest vulnerability intelligence, flagging newly disclosed and actively exploited vulnerabilities in third-party and open-source dependencies. These are precisely the components the CRA makes you, the manufacturer, responsible for — and a daily cadence is what turns the manufacturer’s lifecycle duty into something operational rather than aspirational.

• Faster, evidenced reporting to the authorities. When an actively exploited vulnerability surfaces in a component you ship, the 24-hour clock to notify ENISA and the relevant national CSIRT starts immediately. PrismDiscover gives you early detection plus the component-level evidence — which product, which version, which dependency is affected — needed to triage, confirm reportability, and file within the window. The result is a repeatable reporting workflow instead of a last-minute scramble against the deadline.

The CRA’s deadlines are no longer distant. Reporting obligations are already live, and full compliance lands in December 2027 — well inside the design cycle of products being scoped today. Keeping a live SBOM and a daily eye on upstream risk is no longer good hygiene; under the CRA it is the difference between staying in the European market and being shut out of it. PrismDiscover is built to make that continuous, evidenced, and audit-ready.

To see how PrismDiscover can keep your SBOM live and your CRA reporting on time, talk to the Prism team.