Security

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) sets cybersecurity requirements for products with digital elements placed on the EU market. Reporting obligations for actively exploited vulnerabilities and severe incidents apply from 11 September 2026. The essential requirements, conformity assessment and CE marking apply in full from 11 December 2027.

The Cyber Resilience Act represents a fundamental change in how cybersecurity is integrated into the design, development and lifecycle management of products with digital elements. Cybersecurity can't be treated as an afterthought; to conform with CRA, products must be secure by design, and security vulnerabilities must be managed rigorously throughout the product's lifecycle.

Nordic provides the complete chip-to-cloud security solution to support compliance readiness, powered by nRF Cloud. Nordic supplies the component-level evidence your conformity work draws on: security advisories and a coordinated vulnerability disclosure process, SBOMs for Nordic software, component-level Declarations of Conformity and supporting technical documentation. The product-level risk assessment, Declaration of Conformity, CE marking and reporting obligations remain yours. This page sets out what Nordic provides and when. For the regulation itself and your own obligations, start with the European Commission and ENISA.

Your obligations under the CRA are yours. What follows is what Nordic provides for each one: the evidence, tooling and commitments that you can draw on. The first row started applying from September 11th, 2026, and the rows below that apply from December 11th, 2027.

Reporting obligations started applying from 11 September 2026, which makes this the part that changes something first. Nordic's vulnerability reporting and coordinated disclosure process is in place and can be found here.

• Report a vulnerability in Nordic silicon or Nordic software. Nordic acknowledges receipt, triages, and issues an advisory with mitigation guidance where on is warranted.
• Subscribe to security notifications in myNordic to be told when Nordic publishes a security advisory, rather than having to check for one. Significant items are also carried in Product Update Notifications.

Nordic reports for the products Nordic places on the market. You report for the product you place on the market, including when the root cause sits in a Nordic component. Telling Nordic does not discharge your own reporting obligations.

Nordic notifies actively exploited vulnerabilities and severe security incidents affecting its products to the CSIRT designated as coordinator and to ENISA simultaneously, through ENISA's Single Reporting Platform (SRP), following the regulation's 24-hour, 72-hour and final-report timelines. In parallel, Nordic informs affected customers through myNordic, together with available corrective or mitigating measures.

As our customer, you should create a myNordic account and subscribe to relevant product notifications to start receiving security advisories via email and the myNordic portal.

The CRA process starts by classifying your product. Determining your class is your responsibility, and it should be one of the first steps on your path to CRA compliance to determine whether a third-party assessment is required.

There are four classes in CRA, with increasing implications to both security and conformity assessment routes: Default, Important Class I, Important Class II and Critical. The same essential cybersecurity requirements apply for each class, but the Default class is subject to self-assessment only, meaning that a notified body does not need to be involved in the assessment. Class I products may also be subject to self-assessment, if applying a harmonized standard, but otherwise they require a third-party assessment. Products that fall under Class II and Critical are always subject to a third-party assessment or a cybersecure certification.

The recommended way to walk through the classification procedure goes as follows. First determine whether your product is in scope of CRA. If yes, determine whether it is a Critical class product as defined in CRA Annex IV. If not, go through the lists of products in CRA Annex III to determine whether your product falls under Class II. If it does not, then determine whether it falls under Class I. If it does not, it falls under the Default class.

The class of a Nordic part does not transfer to your product. A Class I microcontroller inside a smart thermostat does not make the thermostat Class I. Your product is classified on what your product is and does, against the Annex III and Annex IV lists, judged on intended purpose and core functionality rather than on components. Determining your class is yours to do as manufacturer; Nordic will not make the determination for you. The classification reference sets out the decision procedure and the full category list.

In many cases, an IoT end product will fall under the Default class, which means it will be subject to self-assessment instead of assessment by a third party – even if the integrated Nordic part were Class I or Class II. Read through the Annexes III and IV to determine the correct class for your product.

CRA readiness assessment.  Evaluate your connected product against key CRA requirements and cybersecurity best practices. Get a clear readiness score and actionable recommendations. The assessment can be taken here.

Continuous vulnerability monitoring. Monitor CVEs affecting the software running on your products. Go beyond SBOM matching with fleet exposure analysis that identifies which deployed devices are actually affected. Get started with continuous vulnerability monitoring.

Lifetime FOTA. Securely deliver firmware updates throughout the device lifecycle. Track deployment history and verify remediation across affected devices, providing valuable evidence for your technical documentation. Learn more about Lifetime FOTA with nRF Cloud here.

nRF Connect SDK LTS is the SDK version Nordic cites in conformity documentation, and the version to build on if you intend to rely on a Nordic conformity package as evidence. Current product series are covered by nRF Connect SDK 3.4 LTS. If you are using nRF5 SDK, please wait for further information to be published on which version to use and how to proceed.

The Nordic product placed on the market with regards to CRA is the combination of hardware and software; a Nordic SoC and a named SDK version. An example of such a combination could be the nRF52840 with nRF Connect SDK v3.4.0 LTS. This product, when combining hardware with an SDK LTS version, will have a 5-year minimum support period. The support periods for each software and hardware combination will be published separately. For open-source components that Nordic does not own, Nordic tracks them, applies fixes in the SDK, and reports and shares fixes upstream.

Nordic's support period covers vulnerability handling and security updates for the Nordic product. It is not a commitment to functional maintenance, new features, or silicon supply. Nordic's published lifecycle policy and the applicable Nordic terms, conditions and license terms govern; where this page and those documents differ, those documents prevail.

Where the conformity boundary falls. Nordic declares conformity for the silicon and the named SDK configuration. You declare for the product and place on the market. Nordic's declaration and technical evidence are inputs to your technical file; they do not replace it, and there is no mechanism in the CRA by which a supplier's declaration discharges yours. Your own assessment covers what Nordic's cannot: your application software, your integration and configuration choices, your interfaces and exposed services, and your product's operating environment.

Disclaimer: These answers are provided for general orientation only. They reflect Nordic's understanding of the Cyber Resilience Act at the date of publication, they are not legal advice, and they are not a complete statement of the law or of your obligations. The Regulation itself, and guidance issued by the European Commission and ENISA, are the authoritative sources, and the position may develop through implementing and delegated acts, harmonized standards and ADCO guidance. Nordic does not undertake to keep these answers current and accepts no responsibility for decisions taken in reliance on them. Please take your own legal advice on how the CRA applies to your product. The CRA Regulation and the FAQs on the CRA implementation can be found in the links given here.

If you have further questions after reading through the FAQ, please open a DevZone ticket or talk to your local sales representative.

What is considered a product with digital elements?
A product with digital elements is defined as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately”. Note that it can be either software, hardware, or a combination of both, last of which is the case for the Nordic silicon + SDK combination.

What are the deadlines for CRA?
Mandatory reporting deadline is on September 11th, 2026, and the full compliance deadline is on December 11th, 2027. For further information on the mandatory reporting responsibilities, please refer to the Vulnerability handling and disclosure section at the top of this page.

When does CRA start applying for a product?
CRA starts applying when a product with digital elements is placed on the EU market after December 11th, 2027, and continues to apply throughout its lifetime. For products placed on the market before December 11th, 2027, the CRA applies only if those products are substantially modified after that date.

This means, a product placed on the market before December 11th, 2027, is not required to be brought into CRA compliance unless it is substantially modified. However, new copies of that product may not be placed on the market after December 11th, 2027, without bringing them to compliance.

Note also that the reporting obligations that came into force on September 11th, 2026, apply also for products placed on the market before that date. For more information, please see the FAQs on the CRA implementation PDF.

How do I receive security advisories for CVEs concerning Nordic products?
Create a myNordic account and subscribe to notifications here. You will then receive security advisories in the email address configured in your myNordic account. You may also additionally subscribe to CVE databases such as NIST's National Vulnerability Database to receive security advisories through those channels as well.

How can I monitor for security vulnerabilities in my firmware?
Set up continuous CVE monitoring using nRF Cloud. Using nRF Cloud allows you to scan your SBOM for known vulnerabilities and monitor risk and resolutions real-time. nRF Cloud's continuous CVE monitoring surfaces new vulnerabilities as they are identified, and existing vulnerability remediations can be triaged and tracked as they roll out. Get fleet-wide visibility into your security and see which devices are exposed or running unpatched firmware across your entire fleet.

How can I provide security updates for my devices in the field?
CRA mandates that you need to be able to provide security updates to your devices in order to patch security vulnerabilities in affected devices. It does not take stance on the exact mechanism – as long as it is secure. The best way to update a wireless device in the field is a firmware over-the-air update, which you can easily set up for a fleet of devices using nRF Cloud. nRF Cloud offers lifetime FOTA, which helps manufacturers deliver security updates over the full lifetime of their devices with predictable commercial terms and a ready-to-use cloud service.

Which SDK version should I use to guarantee I get the latest security updates for my device?
Using the latest nRF Connect SDK LTS version available is recommended for getting the latest security updates. If you are using nRF5 SDK, please wait for further information from us on which version to use.

Does Nordic provide a software bill-of-materials (SBOM) for my application?
Nordic provides a mechanism for you to generate an SBOM for the exact software composition for your application created with nRF Connect SDK. Nordic cannot pre-generate an accurate SBOM for your application, as the components you include in your application dictate what software and versions are found inside. For information on SBOM generation, please refer to the SBOM documentation.

Does the conformance of a Nordic product carry over to my product when it is integrated as a component?
No, the conformance of an integrated component, such as that of a Nordic wireless SoC, does not automatically carry over to the final product. Each manufacturer of a product with digital elements must go through the conformance assessment for their own product.

What does transfer is evidence: A CRA-conformant component can be used as supporting evidence in the integrator's risk assessment and conformity assessment. Conformity (or presumed conformity) of a component may help show that certain requirements are satisfied for that component. However, once components are integrated, new risks can emerge and those risks must be assessed for the finished product.

What is a conformity package?
A conformity package, or the technical documentation or conformity assessment file, under the CRA is the collection of mandatory documents and evidence a manufacturer must compile to prove a hardware, or software product meets the law's essential cybersecurity requirements before it can be sold in the European Union. Nordic will provide conformity packages for Nordic products, which are a combination of software and hardware.

Do Nordic's conformity packages cover my product for CRA?
Nordic's conformity packages fully cover only Nordic products, but they can be used as input and evidence in your technical file for declaring conformity for your products. It is your obligation to ensure CRA conformity for your products.

When will Nordic conformity packages be available?
Nordic's conformity packages will be available in early 2027 as draft versions. The packages will be finalized before December 11th, 2027, but you may already start using the draft versions as soon as they are available. The aim is that the differences between the draft versions and the final versions stay minimal.