Cyber Resilience Act (CRA): New security requirements for all software in EU/EEA
The Cyber Resilience Act introduces mandatory cybersecurity requirements for all products with digital elements sold in the EU/EEA. Here is how Norwegian developers, manufacturers, and distributors are affected — and how to prepare.
The Cyber Resilience Act (CRA) is the EU's new regulation introducing mandatory cybersecurity requirements for all products with digital elements sold in the EU/EEA — including software and IoT devices. The requirements cover SBOM, CE marking, and secure by design. The vulnerability reporting obligation starts on 11 September 2026, and full compliance is required from 11 December 2027.
CRA represents a paradigm shift for the software industry. For the first time, cybersecurity becomes a legally mandated product requirement — on par with physical safety and electromagnetic compatibility. For Norwegian software developers, manufacturers, and distributors, this means new obligations that require preparation starting now.
In this article, we provide a complete overview of what CRA entails, who is affected, what requirements are imposed, and concrete steps you should take.
What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation adopted in October 2024 that sets horizontal cybersecurity requirements for all products with digital elements made available on the internal market. "Products with digital elements" means any software or hardware product and associated remote data processing solutions, including software components made available separately.
This means CRA covers an enormous range — from IoT devices such as smart light bulbs and industrial sensors, through operating systems and browsers, to specialised enterprise solutions and cloud-based services with associated client software. The regulation applies directly throughout the EU and will be implemented in Norwegian law through the EEA Agreement.
CRA differs from directives such as NIS2 in that it targets the products themselves, not the organisations that use them. The objective is to ensure that all digital products on the market meet a minimum level of cybersecurity throughout their entire lifecycle.
Background: Why CRA?
In recent years, cyberattacks targeting software supply chains have exploded in scale and severity. Incidents such as the SolarWinds attack in 2020, the Log4Shell vulnerability in 2021, and the MOVEit attack in 2023 demonstrated how a single vulnerability in a software component can impact thousands of organisations globally.
The European Commission identified three fundamental problems that CRA is designed to address:
Low cybersecurity levels in products. Many digital products are launched with known vulnerabilities and without any commitment to deliver security updates. Manufacturers have had few incentives to invest in security after launch.
Lack of information for users. Consumers and businesses have had little ability to assess the cybersecurity of the products they purchase. No common framework has existed for comparing security levels.
Fragmented regulation. Different sectors have had different requirements, and many product categories have lacked cybersecurity requirements entirely. CRA establishes a unified, horizontal framework covering all digital products.
Estimates from the European Commission indicate that cyberattacks cost the global economy over EUR 5.5 trillion in 2023. CRA is the EU's response to breaking the vicious cycle in which insecure products are released on the market without consequences for the manufacturer.
Timeline: Key dates
CRA takes effect gradually with three key milestones:
- October 2024: CRA is formally adopted by the EU and published in the Official Journal
- 11 June 2026: Rules for conformity assessment bodies (notified bodies) take effect
- 11 September 2026: Vulnerability reporting obligation takes effect — manufacturers must notify ENISA/national authorities within 24 hours
- 11 December 2027: Full application — all requirements for products with digital elements apply in full, including CE marking, SBOM, and secure by design
- 2027–2028: Expected incorporation into the EEA Agreement and implementation in Norwegian law
For Norwegian businesses, it is critical to note that the vulnerability reporting obligation starts as early as September 2026. Even though full compliance is not required until December 2027, preparations should begin immediately.
Who is affected by CRA?
CRA imposes obligations on all economic operators in the value chain for digital products. The regulation distinguishes between three roles with different responsibilities:
| Role | Who does this cover? | Key obligations |
|---|---|---|
| Manufacturer | The entity that develops or produces the product with digital elements and markets it under its own name | Conduct risk assessment, ensure the product meets security requirements, provide SBOM, perform conformity assessment, CE-mark the product, deliver security updates throughout the product's lifetime, report actively exploited vulnerabilities within 24 hours |
| Importer | The entity that brings a product from a non-EU manufacturer onto the EU/EEA market | Verify that the manufacturer has performed conformity assessment and CE marking, ensure the manufacturer's documentation is available, not place non-compliant products on the market |
| Distributor | The entity that makes the product available on the market without modifying it | Verify CE marking and declaration of conformity, ensure the product has no known unaddressed vulnerabilities, notify supervisory authorities about non-compliant products |
Who is a "manufacturer" in practice?
The definition of manufacturer is broad and captures most Norwegian software companies. If you develop software — whether a mobile app, a SaaS platform, a desktop application, or a firmware update — and make it available on the EU/EEA market (including free of charge), you are most likely a manufacturer under CRA.
What about open source?
CRA contains an important exemption for open-source software developed and shared without commercial activity. However, be aware: if you use open source in a commercial product, you as the manufacturer are responsible for ensuring that these components meet CRA requirements. And if an open-source project is run by a commercial entity — for example with paid support, hosting, or premium features — the project itself may fall within the scope of CRA.
CRA also introduces the concept of an "open-source software steward" for organisations that systematically support the development of open-source software intended for commercial use. These have lighter obligations but must still maintain security policies and cooperate with authorities on vulnerability reporting.
What is required? Key obligations
CRA sets comprehensive requirements for products with digital elements. Here are the most important:
| Requirement | Description | Deadline |
|---|---|---|
| Risk assessment | Documented cybersecurity risk assessment throughout the product's lifecycle | Dec. 2027 |
| Secure by design | Products must be designed, developed, and produced with security built in from the start | Dec. 2027 |
| Attack surface minimisation | Products must be delivered with a secure default configuration and minimal attack surface | Dec. 2027 |
| Vulnerability management | Manufacturers must identify, document, and remediate vulnerabilities throughout the product's lifetime | Dec. 2027 |
| Security updates | Free security updates for a minimum of 5 years or the product's expected lifetime | Dec. 2027 |
| SBOM | Software Bill of Materials — machine-readable inventory of all components and dependencies | Dec. 2027 |
| Conformity assessment | The manufacturer must perform a conformity assessment (self-assessment or third-party assessment) | Dec. 2027 |
| CE marking | The product must be CE-marked to demonstrate compliance with CRA requirements | Dec. 2027 |
| Technical documentation | Complete technical documentation covering design, development, and conformity assessment | Dec. 2027 |
| Vulnerability reporting | Actively exploited vulnerabilities must be reported to ENISA/national authority within 24 hours | Sep. 2026 |
Product categories and conformity assessment
CRA divides products into three categories based on criticality:
- Standard (default): Most products. The manufacturer can perform self-assessment of conformity (Module A)
- Important products, Class I: Identity management, browsers, password managers, VPNs, network management, SIEM systems, and more. May use harmonised standards for self-assessment; otherwise, third-party assessment is required
- Important products, Class II: Operating systems, hypervisors, microcontrollers, industrial control systems, firewalls, and more. Mandatory third-party assessment required
- Critical products: Smart cards, HSMs, smart meters, and similar. Requires European cybersecurity certification
SBOM: Software Bill of Materials
One of the most concrete and transformative requirements in CRA is the mandate for a Software Bill of Materials (SBOM). But what exactly is an SBOM, and why is it so important?
What is an SBOM?
An SBOM is a formal, machine-readable inventory of all software components and dependencies included in a product. Think of it as an ingredient list for software. Just as a food producer must list all ingredients on the packaging, a software manufacturer under CRA must document all libraries, frameworks, and third-party components contained in the product.
Why does CRA require an SBOM?
The Log4Shell vulnerability in December 2021 illustrates the need perfectly. Log4j was a widely used Java component embedded in thousands of products. When the critical vulnerability was discovered, most organisations had no overview of where Log4j was in use. It took weeks — in some cases months — just to map the extent. With an SBOM in place, you can immediately identify whether a vulnerable component exists in your products.
What must an SBOM contain?
CRA requires that the SBOM at minimum covers the top-level dependencies in the product. In practice, a robust SBOM should include:
- Name and version of all software components
- Licence terms for each component
- Supplier or origin of the component
- Unique identifiers (e.g. CPE or Package URL)
- The dependency tree showing relationships between components
Common formats are CycloneDX and SPDX, both supported by a wide range of tools in the developer ecosystem.
How do you get started with SBOM?
For most modern development projects, SBOM generation can be automated directly in the CI/CD pipeline. Tools such as Syft, Trivy, and CycloneDX CLI can generate SBOMs from existing projects. The most important thing is to start early — retroactive SBOM generation for complex systems is significantly more demanding.
Secure by design: Security from the first line of code
CRA formalises the "secure by design" principle as a legal requirement. This means security cannot be treated as an afterthought or an add-on — it must be an integral part of product development from architecture to delivery.
What does secure by design mean in practice?
CRA sets concrete requirements for how products must be designed and delivered:
- Secure default configuration: Products must be delivered with secure default settings. The user should not have to enable security — it must be on by default
- Attack surface minimisation: Unnecessary ports, services, and interfaces must be disabled by default
- Proper authentication: Default passwords and predictable credentials are not permitted. Unique, strong initial credentials are required
- Cryptographic protection: Data in transit and data at rest must be protected using up-to-date cryptographic mechanisms
- Integrity protection: Mechanisms to ensure that the product's software and configuration data have not been tampered with
- Availability protection: Products must be resilient against denial-of-service attacks and excessive resource consumption
For development teams, this means security reviews, threat modelling, and secure coding must become a natural part of the development process — not something done after the fact following a penetration test.
CE marking of software
For the first time in history, software will require CE marking for cybersecurity. The CE mark — which most people know from physical products such as electronics and toys — will now also indicate that a digital product meets the EU's cybersecurity requirements.
What does CE marking mean for software?
CE marking under CRA means that the manufacturer declares the product meets the essential cybersecurity requirements of the regulation. To CE-mark the product, the manufacturer must:
- Conduct a documented risk assessment
- Ensure the product meets all relevant security requirements
- Prepare technical documentation
- Perform a conformity assessment (self-assessment or third-party assessment, depending on the product category)
- Issue an EU declaration of conformity
- Affix the CE mark to the product or its documentation
For software without physical packaging, the CE mark can be displayed in the product's digital documentation, user interface, or download page.
Consequences for market access
After 11 December 2027, products with digital elements without CE marking will not be legally sellable on the EU/EEA market. This means CRA compliance is not optional — it is a prerequisite for market access.
Penalties and fines
CRA introduces a significant penalty regime that gives supervisory authorities strong tools for enforcement:
| Type of breach | Maximum fine | Alternative calculation |
|---|---|---|
| Breach of essential security requirements and vulnerability management | EUR 15 million | 2.5% of global turnover (whichever is higher) |
| Breach of other obligations | EUR 10 million | 2% of global turnover (whichever is higher) |
| Providing false information to supervisory authorities | EUR 5 million | 1% of global turnover (whichever is higher) |
In addition to fines, supervisory authorities can:
- Order product withdrawal from the market
- Require corrective measures with binding deadlines
- Prohibit or restrict the making available of products
- Impose periodic penalty payments for non-compliance
In Norway, the Norwegian Communications Authority (Nkom) will have supervisory responsibility for CRA. Nkom already has experience with market surveillance for electronic products and will expand this to cover the cybersecurity requirements in CRA.
For SMEs, proportionally lower fines apply, but they are still significant enough to threaten a business's existence. It is important to note that fines can be imposed not only for insecure products, but also for missing documentation, failure to report vulnerabilities, or inadequate conformity assessment.
Practical steps: How your business can prepare
Whether you develop software, import digital products, or distribute technology solutions, you should start preparing now. Here is a phased approach:
Phase 1: Mapping and analysis (now – September 2026)
- Map all products with digital elements you produce, import, or distribute
- Classify each product by CRA category (standard, important Class I/II, critical)
- Identify your role in the value chain for each product (manufacturer, importer, distributor)
- Conduct a gap analysis against CRA requirements for each product
- Map all third-party components and dependencies in your products
- Assess whether open-source components you use may trigger CRA obligations
- Establish procedures for vulnerability reporting (required from September 2026)
Phase 2: Implementation (September 2026 – December 2027)
- Implement SBOM generation in the CI/CD pipeline for all products
- Integrate automated vulnerability scanning into the development workflow
- Establish processes for secure by design — threat modelling, secure coding, security reviews
- Prepare technical documentation that meets CRA requirements
- Conduct risk assessments for each product
- Establish routines for delivering security updates throughout the product's lifetime
- Prepare conformity assessment (self-assessment or plan for third-party assessment)
- Update supplier contracts to ensure CRA compliance throughout the value chain
Phase 3: Compliance and maintenance (December 2027 and ongoing)
- Perform conformity assessment and CE-mark all products
- Issue an EU declaration of conformity for each product
- Establish continuous vulnerability management and update programme
- Conduct regular reviews of SBOM and dependencies
- Keep technical documentation up to date with all product changes
- Monitor regulatory updates and harmonised standards
- Conduct periodic security audits and penetration tests
How does CRA relate to NIS2 and the AI Act?
CRA is part of a broader regulatory wave from the EU. Together with the NIS2 Directive and the AI Act (EU AI Act), CRA forms a comprehensive framework for digital security and trust:
- CRA regulates the products — ensures that digital products are secure from design to end of life
- NIS2 regulates the organisations — ensures that critical organisations have adequate cybersecurity
- The AI Act regulates AI systems — ensures that artificial intelligence is used safely and responsibly
For IT suppliers in the financial sector, you should also familiarise yourself with DORA, which sets its own requirements for digital operational resilience. And with the EU Data Act, additional rules for data sharing and cloud portability are on the way.
For businesses subject to several of these regulations, it is wise to take a holistic approach to compliance. Many of the measures — such as risk assessment, documentation, incident handling, and supply chain security — overlap.
How we can help
At UNOS SOFTWARE AS, we build software with security as a core value, and we help Norwegian businesses navigate the increasingly complex regulatory landscape. Together with our partner Unos IT AS, we offer a complete range of services from development to operations. We offer:
- Secure software development with built-in CRA compliance — through our software development service, we build solutions with secure by design principles, automated SBOM generation, and vulnerability management integrated into the development workflow
- Technical consulting on CRA preparation — our consulting service helps you with gap analyses, product classification, SBOM strategy, and preparation for conformity assessment
- System integration and modernisation — through our integration service, we help you integrate security tools, automate SBOM generation, and build robust CI/CD pipelines that support CRA compliance
- Secure cloud infrastructure — our cloud and infrastructure service ensures your infrastructure is built to deliver security updates efficiently and meet CRA requirements for continuous vulnerability management
CRA is not just a regulatory requirement — it is an opportunity to raise the quality of your software, reduce security risk, and build lasting trust with your customers.
Are you unsure how CRA affects your products? Get in touch for an informal conversation about your CRA preparations and compliance needs.
Frequently asked questions about the Cyber Resilience Act
Does CRA apply to SaaS software?
Yes, in most cases. Software made available on the EU/EEA market — including SaaS solutions with associated client software — is covered by CRA. Pure cloud-based services without a local software component may fall outside the scope, but the boundaries are still being clarified.
When does the vulnerability reporting obligation start?
The reporting obligation for actively exploited vulnerabilities starts on 11 September 2026. Manufacturers must notify ENISA and national authorities within 24 hours of becoming aware that a vulnerability is being actively exploited.
What is the difference between CRA and NIS2?
CRA regulates the products — it sets security requirements for digital products sold on the market. NIS2 regulates the organisations — it sets security requirements for organisations in critical sectors. A business can be subject to both regulations.
Do I need an SBOM for existing products?
Yes, from 11 December 2027, all products with digital elements on the market must have an up-to-date SBOM. Retroactive SBOM generation can be demanding for legacy systems, so it is important to start early.
What happens if I do not comply with CRA by the deadline?
Fines can be up to EUR 15 million or 2.5 per cent of global turnover. In addition, supervisory authorities can require product withdrawal from the market or prohibit sales until the requirements are met.
Sources and further reading
- European Parliament (2024). "Regulation (EU) 2024/2847 — Cyber Resilience Act." eur-lex.europa.eu
- European Commission (2025). "Cyber Resilience Act — Factsheet and Implementation Guidance." digital-strategy.ec.europa.eu
- Norwegian Communications Authority (2025). "CRA and supervision of cybersecurity in digital products." nkom.no
- ENISA (2025). "Cyber Resilience Act — Guidelines for Manufacturers." enisa.europa.eu
- Norwegian Government (2025). "EEA implementation of the Cyber Resilience Act." regjeringen.no
- NSM (2025). "Security in the software supply chain — recommendations for Norwegian businesses." nsm.no
- NTIA (2025). "Software Bill of Materials — Minimum Elements and Guidance." ntia.gov
Get in touch
Need help with CRA preparation, SBOM strategy, or secure software development? UNOS SOFTWARE AS — in partnership with Unos IT AS — helps Norwegian businesses navigate the new requirements. Send us an enquiry through the contact form — we will have an informal conversation about how we can help your business with CRA compliance.