Access to the EU market
Products that cannot show they meet the Act cannot be placed on the EU market after the main obligations apply. Distributors and large buyers will ask for evidence in contracts before then.
Board and leadership view
Why the Cyber Resilience Act matters to your board
The work is technical. The consequences of getting EU Cyber Resilience Act wrong show up in revenue, liability and reputation, which is why we report on it in the language of the boardroom first.
Fines and personal exposure
Penalties reach €15M or 2.5% of worldwide turnover, and authorities can order recalls or withdrawal. Missed reporting is a breach in its own right.
Reputation with customers
A product exploited in the field and reported late damages trust fast. Showing a tested, supported product helps in sales and tenders.
Deadlines and ownership
Reporting starts 11 September 2026 and the main rules follow on 11 December 2027. Someone at executive level needs to own product security for the full support period.
Fit
Who the Act affects
Software and app makers
Operating systems, mobile apps, desktop software and firmware sold in the EU fall in scope.
Connected device manufacturers
Routers, cameras, wearables, industrial controllers and smart home products carry the heaviest load.
Importers and distributors
They must check that manufacturers have done the work before placing products on the EU market.
Open source stewards
Commercial use of open source brings duties for those who monetise it, with lighter rules for stewards.
Scope of work
What Summit delivers for EU Cyber Resilience Act
One accountable team takes you from scoping to retest. The people who test your systems are the people who explain the findings to your leadership.
Gap analysis
We map each in-scope product to the Annex I essential requirements and your vulnerability handling, and rank the gaps by risk.
Penetration testing
Human-led testing of firmware, mobile and web apps, APIs, cloud back ends and update mechanisms, with proof of impact.
Control validation
We check that secure defaults, access control, encryption and update controls work as described, not only that they exist.
Evidence pack
Scope, method, findings and results organised so they can sit in your technical file and answer customer questions.
Remediation support and retest
Clear fix guidance for your engineers, then a retest that confirms each issue is closed.
Board-ready report
A plain-language summary of exposure, progress and decisions needed, for executives and non-technical readers.
Fixed scope, one team, no hand-offsYou get a named lead, a clear scope document before work starts and a report your leadership, customers and reviewers can read without a translator. We stay with you through your review to answer questions about what we tested and found.
How it works
A practical CRA readiness path
Timelines are typical ranges, not promises. Yours depends on scope, team size and how much is already in place.
- 1
Scope your portfolio
Weeks 1 to 3List every product and service, decide which are in scope and identify the likely product class for each.
- 2
Assess gaps
Weeks 3 to 8Compare each product against the Annex I essential requirements and your current vulnerability handling.
- 3
Stand up reporting
Months 2 to 4Build the 24 hour, 72 hour and final report process, ahead of or in line with the September 2026 date.
- 4
Test, fix and retest
Months 3 to 8Run penetration testing and review of firmware, apps and update channels, then fix and retest.
- 5
Build the technical file
Months 6 to 12Assemble the risk assessment, SBOM and test evidence for the conformity route, and keep testing each release.
Deliverables
What your leadership team receives
Every engagement ends with material written for two audiences: a plain-language view for executives and the board, and full technical detail for the engineers who fix things.
Which of our products are in scope?
Ask for a product list with the likely class for each. Scope drives cost, route and timing.
Who owns the 24 hour reporting duty?
Name one accountable executive and a deputy, and check the route works out of hours.
Do we know what is inside our products?
Ask for the SBOM status. Unknown components are unknown risk.
How long will we support each product?
Confirm the support period is set, shown to buyers and funded.
What evidence would we show a regulator tomorrow?
Ask to see tested, dated proof, not only policies.
The detail
What the Cyber Resilience Act actually is
The Cyber Resilience Act (CRA), Regulation (EU) 2024/2847, sets mandatory cybersecurity rules for products with digital elements: hardware and software that connect, directly or indirectly, to a device or network. That covers smart devices, routers, operating systems, mobile apps, firmware, and software sold on its own. It entered into force in December 2024.
Obligations fall mainly on manufacturers, who must build security in, handle vulnerabilities for the whole support period and prepare technical documentation. Importers and distributors have duties too. Some products are outside scope because other EU law already covers them, such as certain medical devices and vehicles, and pure software-as-a-service is generally out unless it is a remote data processing solution that a product needs to function.
The rules arrive in stages: conformity assessment body provisions from June 2026, reporting obligations from 11 September 2026 and the main obligations from 11 December 2027. If you sell connected products into the EU, buyers and distributors will start asking for evidence well before the last date.
Key terms in plain English
- Product with digital elements
- Any software or hardware product, and its remote data processing solutions, that connects to a device or network.
- Essential requirements
- The security-by-design and vulnerability handling rules in Annex I that every in-scope product must meet.
- Important and critical products
- Higher-risk classes (Annex III, Class I and II, and Annex IV) that face stricter conformity routes.
- SBOM
- Software bill of materials: a machine-readable list of the components in your product, which manufacturers must produce.
Requirements
What the Act asks of manufacturers
The core of the Act is a set of essential requirements, a vulnerability handling process, reporting duties and proof that you did the work. Here is what each means in practice.
1
Security by design and by default
Products must be designed, developed and produced to an appropriate level of cybersecurity based on risk. That means no known exploitable vulnerabilities at release, secure default settings, protection from unauthorised access, encryption of data and minimal attack surface.
What it looks like in practice
- A documented cybersecurity risk assessment per product
- Secure default configuration and no shared default passwords
- Access control and encryption for stored and transmitted data
2
Vulnerability handling for the whole support period
Manufacturers must find, document and fix vulnerabilities, ship security updates free of charge and promptly, run regular tests and reviews, publish a coordinated vulnerability disclosure policy and provide a contact point for reports.
What it looks like in practice
- An SBOM covering at least top-level dependencies
- A public disclosure policy and reporting channel
- Regular security testing with tracked remediation
3
Reporting exploited vulnerabilities and severe incidents
From 11 September 2026, manufacturers must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, a fuller notification within 72 hours and a final report later. Reports go to the designated national CSIRT and ENISA.
What it looks like in practice
- A named owner and 24 hour on-call route
- Templates and a decision tree for what counts as reportable
- Rehearsed handoff between product, security and legal
4
Conformity assessment and technical documentation
Most products can follow a self-assessment route. Important products (Class I and II) and critical products face stricter routes, and some need an external body. Either way you must keep technical documentation and a declaration of conformity for ten years.
What it looks like in practice
- A technical file with design, risk and test evidence
- Correct product class identified early
- A documented route to the declaration of conformity
5
Support period and user information
You must set a support period of at least five years, unless the product is expected to be used for less, and tell users what it is. Instructions must explain secure use, where to report problems and how updates are delivered.
What it looks like in practice
- A support end date shown at purchase
- Security updates separated from feature updates where possible
- Clear user guidance on secure setup
Where testing fits
How penetration testing supports EU Cyber Resilience Act
The Act expects manufacturers to test their products and to show that vulnerabilities are found and fixed. Penetration testing gives technical evidence for the file and a record that you acted on findings.
Annex I, Part I
Products free of known exploitable vulnerabilities
Penetration testing of firmware, apps, APIs and update mechanisms before release shows you looked for them.
Annex I, Part II
Regular testing and review
The Act requires effective and regular tests of product security. Retests after fixes show the loop is closed.
Technical file
Evidence of conformity
Test scope, methods, findings and retest results sit naturally in the documentation you must keep for ten years.
Reporting readiness
Knowing your exposure
Testing helps you understand which weaknesses could become reportable if exploited.
Avoid these
Common EU Cyber Resilience Act mistakes, and how to avoid them
!
Assuming SaaS is automatically out
Remote data processing that a product needs to work can be in scope. Check each product, not just the company.
!
Waiting for 2027
Reporting duties start in September 2026. The reporting process cannot be built in a week.
!
No SBOM or component tracking
You cannot fix or report what you cannot see. Build the component list now.
!
Treating it as a paperwork task
Authorities and customers will expect real testing and fixes, not only documents.
FAQ
EU Cyber Resilience Act questions, answered
When does the Cyber Resilience Act apply?
In stages. Reporting obligations apply from 11 September 2026 and most other obligations, including the essential requirements, from 11 December 2027. Provisions on conformity assessment bodies started earlier, in June 2026.
Does it apply to software and apps?
Yes, software sold or distributed as a product with digital elements is in scope. Pure SaaS is generally outside unless it is a remote data processing solution a product needs in order to function.
What must be reported and how fast?
Actively exploited vulnerabilities and severe incidents. Send an early warning within 24 hours, a notification within 72 hours and a final report afterwards, to the national CSIRT designated under the Act.
What are the fines?
Up to €15M or 2.5% of worldwide annual turnover for breaching the essential requirements, up to €10M or 2% for other obligations, and up to €5M or 1% for incorrect information. Market surveillance authorities can also order recalls.
Do I need an external conformity assessment?
Many products can follow self-assessment. Important products in Class I and II, and critical products, face stricter routes, and some require an external body. Confirm your class early.
How does penetration testing fit?
The Act requires regular testing of product security. A documented test, remediation and retest cycle gives you evidence for the technical file and for customers who ask.
Is this legal advice?
No. It is general education about the regulation. Confirm your product class and obligations with qualified counsel.
Related frameworks
Often assessed alongside EU Cyber Resilience Act
EU regulationDORA & NIS2EU resilience rules for financial entities (DORA) and essential and important entities (NIS2): reporting clocks, TLPT and supplier risk.Privacy lawGDPRSeven principles, six lawful bases and the 72-hour breach clock. See how Article 32 security testing fits your obligations.Security assuranceISO 27001The international standard for an information security management system. Clauses, the 93 Annex A controls, and how certification works.
Browse all 23 security and compliance frameworks or see our penetration testing services.
Helpful resources
ChecklistPre-launch security checklistKeep reading on the Summit resources hub.GuideAPI security guideKeep reading on the Summit resources hub.ReportSample VAPT reportKeep reading on the Summit resources hub.
Last reviewed October 2026. Requirements change; confirm current texts and dates before you commit to a plan.