The EU Cyber Resilience Act reaches down to integrated circuits. Article 3 covers hardware and software components placed on the market separately, and the Commission's July 2026 guidance names integrated circuits as an example. For chip suppliers this is a product law with CE marking, not a matter for the security team alone, and one part of it has been live since 11 September 2026.
IP suppliers have a harder question, because neither the regulation nor the guidance mentions IP cores. This post sets out what the text says, how it might apply by role, and where the answer is still open, with each date checked against the regulation. It is general information, not legal advice. Take your own facts to a qualified adviser.
Key takeaways
- Reporting is already in force. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, including for products placed on the market before the main rules apply.
- The main obligations apply from 11 December 2027, and they attach to individual units rather than product types. A design already shipping is not exempt for units placed on the market after that date.
- Existing silicon does not automatically need a respin. The guidance accepts an older design if a current risk assessment and the technical file show it is adequately secure.
- Chips with security functions may fall in stricter classes. Class I covers microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities, and the classes above it are set by AVA_VAN level.
- Licensed IP is the grey area. Firmware and source code have the clearest guidance. RTL and layout files do not, but your licensees still have due diligence duties and will ask you for evidence.
The dates, as the text sets them
| Date | What happens | Where it comes from |
|---|---|---|
| 11 June 2026 | Rules on notifying conformity assessment bodies apply | Article 71(2), covering Articles 35 to 51 |
| 11 September 2026 | Manufacturer reporting applies | Article 71(2), covering Article 14, and Article 69(3) |
| 11 December 2027 | Everything else applies, including the essential requirements, CE marking and market surveillance | Article 71(2) |
| 11 June 2028 | Existing EU type-examination certificates on cybersecurity lapse, unless they end sooner | Article 69(1) |
Some planning dates sit outside the regulation. The Commission's implementation page targets 11 December 2026 for enough notified conformity assessment bodies. Standards are less settled. The Commission's FAQ gives 30 August 2026 for the first horizontal standards and 30 October 2026 for vertical ones. An independent tracker reports a draft amendment moving these to 31 October and 31 December 2026, which we could not confirm on a Commission page.
What the text says, and what it leaves open
| Question | What the sources say | Status for chips and IP |
|---|---|---|
| Is a packaged chip in scope? | A product with digital elements includes hardware components placed on the market separately (Article 3(1)). The guidance lists integrated circuits as standalone hardware. | Clear, if the chip has a data connection and is placed on the EU market. |
| Does an analogue or power part count? | Signals that only trigger or power a function, with no digitally encoded information, are not a data connection (guidance, paragraph 28). | Helpful, but mixed-signal parts with digital interfaces need their own analysis. |
| Is licensed source code a product? | Software includes source code. Code supplied commercially as a product is placed on the market, and the supplier is not responsible for the customer's later adaptations (guidance, paragraphs 22 to 24 and Example 7). | Clear for firmware, drivers and libraries. |
| Is RTL or a GDSII macro a product? | Not addressed. Hardware is defined as a physical system or parts of one (Article 3(5)). The guidance describes source code as something compiled or interpreted for execution by a computer. | Uncertain. RTL is synthesised rather than executed, and a layout file is not physical. Do not assume either answer. |
| Does a licence to a customer outside the EU count? | Making available means supply for distribution or use on the Union market in the course of a commercial activity (Article 3(22)). | Depends on facts. Silicon reaching the EU does not settle whether the IP itself was supplied to that market. |
| Is an SoC a Class I product? | The Annex III entries depend on core functionality, and the descriptions name secure boot, trusted execution and key storage as examples of security functions. | Uncertain for general-purpose SoCs, which the technical descriptions do not name as a category. |
The three classes that matter for silicon
Implementing Regulation (EU) 2025/2392 gives the technical descriptions:
- Class I: microprocessors, microcontrollers, ASICs and FPGAs with security-related functionalities that aim to secure something beyond the chip itself. Self-assessment is possible only with harmonised standards, common specifications or a suitable certification scheme applied in full. Otherwise a notified body is involved (Article 32(2)).
- Class II: tamper-resistant microprocessors and microcontrollers designed for AVA_VAN level 2 or 3. These go to third-party assessment or a certification scheme (Article 32(3)).
- Critical (Annex IV): secure elements designed for at least AVA_VAN.4, including TPMs and embedded UICCs. The description says they can be discrete or integrated into an SoC. Without a delegated act requiring certification, Article 32(3) applies (Article 8(1)).
Integration alone does not move the host up a class. Article 7(1) says so, and the FAQ's example is a laptop with a secure element. How this works when the secure element is a licensed block inside a chip sold as one product is not spelled out, so an SoC with such a block should get a specific legal view.
The action list by role
One company can hold several roles. The legal duties come from the text. The suggested actions are our reading of how to meet them.
Chip or SoC supplier selling under its own name
A fabless company is likely to be the manufacturer, since Article 3(13) covers those who have products designed or made for them and market them under their own name.
- Now: confirm you can report within 24 hours through ENISA's Single Reporting Platform. Agree who decides the clock has started, which the guidance ties to reasonable certainty after initial assessment.
- Now: sort the portfolio by class, and write down the core functionality reasoning for each family.
- 2026 to 2027: run Article 13(2) risk assessments that cover integration as a foreseeable use. The guidance's Example 12 is a microcontroller designed before the Act that needs no redesign if the assessment and technical file support it.
- 2026 to 2027: set support periods from expected use. The five-year figure is a floor, and the FAQ names microprocessors among hardware often in use for longer.
- 2027: check secure defaults against what you ship. The FAQ's example is a microcontroller delivered with network interfaces off, and the supplier answers only for the delivered configuration.
- 2027: build the Annex I Part II processes: a software bill of materials for firmware, a coordinated disclosure policy, a reporting contact, and free security updates with advisories.
- Before 11 December 2027: have the conformity route, technical file, EU declaration and CE marking ready for every unit placed on the market from that date. Book a notified body early if you are in Class I without standards, or above it.
IP licensor
- Split the deliverables. List what you ship: RTL, netlists, GDSII, boot ROM code, drivers, crypto libraries, verification tools. Code that runs on a processor sits closest to the guidance on software. Get advice on the rest.
- Record the market facts. Note where each licensee is, and whether the supply is finished or still shared for development. Unfinished code shared during development is not treated as placed on the market.
- Prepare a security package either way. Licensees will want integration assumptions, known vulnerabilities, a software bill of materials for any code, and your support commitment.
- Open a vulnerability intake. Licensees must report component flaws to whoever makes or maintains the component (Article 13(6)).
- Review licences for notification timing, fix delivery, end of support and sharing evidence with authorities.
- Do not lean on "tailor-made". That deviation covers only secure defaults and free updates, and needs a particular business user, explicit agreement and evidence in the file.
IP licensee or integrator
- Do due diligence for every third-party block (Article 13(5)). Start from what your product needs from the block, then verify it proportionately to risk using supplier documents or your own tests.
- Do not wait for CE marks. The FAQ confirms you may integrate unmarked components, as long as you diligence them by other means.
- Plan for unsupported blocks. You remain responsible for vulnerability handling across the whole product. If a supplier stops helping, you are expected to find another way, such as disabling a function or replacing the component.
- Align support periods. A supplier window shorter than yours becomes your gap to close.
Importer, distributor and manufacturing partners
- Importers and distributors check CE marking and manufacturer documents, and hold back non-compliant products. Those who rebrand or substantially modify take on manufacturer duties (Article 21). Distributors need not bring units placed on the market before 11 December 2027 into compliance, unless they substantially modify them.
- Foundries and assembly houses are not named. If they only build to order for a product sold under the customer's name, the definition points to the customer as manufacturer. That is our reading, not a stated rule, and it may differ for foundry-supplied code or libraries.
A worked example: one SoC, one IP licence
This scenario is invented for illustration. All details are assumptions, and the conclusions are one reasonable reading. A fabless supplier sells an industrial gateway SoC to module makers in the EU under its own name. It licenses a hardware root of trust block with boot ROM code from an IP supplier outside the EU. Revision A has shipped since 2025. Revision B follows in January 2028.
| Point in time | SoC supplier | IP supplier |
|---|---|---|
| Today | Article 14 reporting already applies to revision A units in scope | Applies only to anything it has placed on the EU market, so it needs a scope answer for the boot code first |
| Before 11 December 2027 | Revision A units placed before this date need no CRA conformity, unless substantially modified later | Delivers a security package and agrees vulnerability channels |
| From 11 December 2027 | New revision A units need full conformity. A redesign is only needed if the risk assessment shows one | Depends on the scope answer, though the licensee's due diligence applies regardless |
| January 2028 | Revision B is placed on the market. Assumed expected use of ten years gives support to January 2038, stated at purchase by month and year | Its support commitment feeds the SoC supplier's choice |
| Class decision | Secure boot and a trusted execution environment point towards Class I, pending a core functionality analysis. Without an applied harmonised standard, a notified body is involved | If the block were designed for AVA_VAN.4 as a secure element, the question becomes harder and needs advice |
Now suppose that in 2028 attackers exploit a flaw in the boot ROM on revision B units. The clock runs from awareness, and it also applies to the module makers if the flaw is actively exploited in their products.
| Step | Deadline | Note |
|---|---|---|
| Early warning | 24 hours from awareness | Limited information, including where the product is known to be available |
| Notification | 72 hours from awareness | Product details, exploit nature, available mitigations |
| Upstream report | No hour limit set in Article 13(6) | To the IP supplier, unless it is confirmed to know already |
| Final report | 14 days after a corrective or mitigating measure is available | If a mitigation ships on day 20, the report is due by day 34 |
Mask ROM cannot be patched, so the available measure may be a later boot stage check, a disabled feature or a new revision. So the risk assessment should state early what is field-updatable, because the design decides how many options you have.
Where do you stand? A short decision guide
- Do you supply a finished chip under your name? If it has a data connection and reaches the EU market, plan as a manufacturer.
- Does it provide security functions for things beyond itself? If so, test it against the Class I descriptions. If it is designed for an AVA_VAN level, check Class II and Annex IV.
- Do you supply code that runs on the customer's system? Treat it as probably in scope once it is finished and supplied commercially.
- Do you supply only RTL or layout? Get a written legal view, and prepare the security package whatever it says, because your customers need it.
- Is your market excluded? The Act excludes products under the medical device, vehicle type-approval and marine equipment rules, and certified aviation products. The FAQ warns that uncertified aviation and marine components may still be covered, so check your parts.
Our SoC lifecycle on The Semiconductor Hub shows where these decisions fall in a programme.
FAQ
What are the penalties?
Member States set them, within limits. Breaches of the essential requirements or Articles 13 and 14 can reach €15 million or 2.5% of worldwide annual turnover, whichever is higher (Article 64(2)). Microenterprises and small enterprises may not be fined for missing the 24-hour deadline.
Does a vulnerability in a third-party block always have to be reported?
No. If it cannot be exploited in your product, or has not been, it is not an actively exploited vulnerability in your product. You still handle it and report it upstream. Exploitation found before 11 September 2026 need not be reported retroactively.
Must security updates stay available?
Yes. Each update during the support period stays available for at least ten years or the rest of the support period, whichever is longer (Article 13(9)).
How much weight does the guidance carry?
Treat it as the Commission's interpretation. The copy we read is headed as approval of the content of a draft communication, and the FAQ states that it does not represent an official position. The Court of Justice has the final say on EU law.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20 November 2024. Articles 3, 7, 8, 13, 14, 21, 32, 64, 69 and 71 and Annexes I, III and IV, read in a reproduction of the Official Journal text and as quoted in the Commission FAQ. Check the authentic text on EUR-Lex.
- Commission Implementing Regulation (EU) 2025/2392 on the technical description of important and critical products, OJ L, 1 December 2025.
- European Commission, "Commission guidance on the application of Regulation (EU) 2024/2847", C(2026) 5252 final, Annex, 27 July 2026.
- European Commission services, "FAQs on the Cyber Resilience Act", version 1.4, 4 September 2026.
- European Commission, "Cyber Resilience Act: reporting obligations" page, updated 11 September 2026, and "Cyber Resilience Act" policy page, updated 7 September 2026.
- European Commission, "Cyber Resilience Act implementation" factpage, updated 27 July 2026, and CRA summary page, updated 3 December 2025.
- cyberresilienceact.eu (independent), "CRA standardisation deadlines pushed back two months", 30 July 2026, updated 11 September 2026.
This post is general information, not legal advice, and reflects sources available to 11 September 2026. The worked example is illustrative. Views on how the regulation applies to silicon and IP are our reading and may change with further guidance or case law.
Your comments will be moderated before it appears here.