The European Union Cyber Resilience Act (CRA) is best understood as a product-safety regime for cybersecurity. It makes cybersecurity a legally required property of many software and hardware products sold or otherwise commercially supplied in the European Union, in much the same way that European product law already regulates electrical, mechanical, radio or medical safety.
Formally, it is Regulation (EU) 2024/2847 on horizontal cybersecurity requirements for products with digital elements. Because it is a regulation rather than a directive, it applies directly throughout the European Union; it does not need to be transposed into Polish law to create the substantive product obligations.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02024R2847-20241120
A useful simplification is:
NIS2 asks whether your organisation operates securely.
CRA asks whether the digital product you put on the market is secure.
That distinction is fundamental.
1. What does CRA cover?
The central concept is a “product with digital elements.” This includes software, hardware and relevant remote data-processing functionality where the product is made available on the European Union market and its intended or reasonably foreseeable use involves a direct or indirect connection to another device or network. Components sold separately can themselves be products under CRA.
Source: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
So potentially covered products include desktop software, mobile applications, operating systems, commercial software libraries, network equipment, routers, smart devices, Internet of Things equipment, security software, firmware, industrial control products and many other types of connected software and hardware.
For example, if you develop an on-premises API gateway that customers install in their infrastructure, that is very likely the type of software product CRA is intended to regulate.
An Internet of Things device plus the manufacturer's cloud backend can also fall within CRA where that remote backend is necessary for the device to perform one of its functions. CRA calls this a remote data processing solution.
There is, however, an important distinction around Software as a Service.
A pure cloud Software as a Service product is not automatically a CRA product. The regulation specifically distinguishes normal cloud services from remote processing that forms part of another digital product. Standalone Software as a Service, Platform as a Service and Infrastructure as a Service are generally regulated from the organisational cybersecurity side through the Network and Information Security Directive 2 rather than automatically through CRA.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1732091856979&uri=CELEX%3A32024R2847
Approximately:
| Product | CRA position |
|---|---|
| Commercial desktop application | Usually in scope |
| Commercial mobile application | Usually in scope |
| On-premises server application | Usually in scope |
| Commercial software component/library | Potentially in scope |
| Router or Internet of Things device | In scope |
| Device + essential manufacturer-operated cloud backend | Backend may be part of CRA product |
| Pure hosted Software as a Service | Generally not CRA merely because it is Software as a Service |
| Internal application never placed on the market | Generally outside CRA |
| Non-commercial open-source project | Special exemption/regime |
The exact boundary can become legally subtle, particularly for cloud-connected products.
2. CRA changes cybersecurity from “best practice” into a product requirement
The major conceptual change is that a manufacturer cannot simply release software and deal with security opportunistically.
Before placing a product on the market, the manufacturer must conduct a cybersecurity risk assessment and use that assessment throughout planning, architecture, development, production, delivery and maintenance. Third-party components must also be considered.
Annex I establishes essential cybersecurity requirements. Among other things, products must be designed and produced according to their cybersecurity risks, should not be released with known exploitable vulnerabilities, must be securely configured by default, must support vulnerability remediation and security updates, should restrict attack surfaces and should reduce the potential impact of successful exploitation.
The regulation also addresses access control, confidentiality, integrity, availability, resilience, logging and secure deletion of data.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202402847
This has significant architectural consequences. CRA effectively creates a legal basis for practices such as:
- secure-by-default configuration;
- least privilege;
- strong authentication and authorization;
- secure secret handling;
- encryption where appropriate;
- minimised network exposure;
- security event logging;
- secure update mechanisms;
- dependency management;
- security testing;
- vulnerability monitoring;
- secure lifecycle management.
In other words, “we follow secure coding guidelines” is not sufficient. The manufacturer needs evidence that its product and development processes meet the applicable requirements.
3. Software supply-chain management becomes particularly important
One of the most important CRA requirements for software companies is the explicit requirement to identify and document software components and vulnerabilities.
Manufacturers must create a Software Bill of Materials (SBOM) in a commonly used, machine-readable format, covering at least the product's top-level dependencies.
Source: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
For example:
Your application
├── ASP.NET Core
├── OpenSSL
├── PostgreSQL client
├── Redis client
├── Newtonsoft.Json
├── React
└── 187 transitive packages
You cannot treat those dependencies simply as implementation details anymore.
You need a process roughly resembling:
source repository
↓
dependency inventory
↓
Software Bill of Materials
↓
vulnerability intelligence
↓
risk assessment
↓
patch / mitigate / accept
↓
security release
↓
customer notification
CRA therefore strongly reinforces Software Composition Analysis, dependency scanning and supply-chain security as product-governance functions rather than merely developer tooling.
4. Vulnerability management becomes a legal lifecycle obligation
Manufacturers must have a functioning vulnerability-management process.
Among other things they must regularly test and review product security, remediate vulnerabilities without undue delay, maintain a coordinated vulnerability disclosure policy, provide a contact mechanism for vulnerability reports, securely distribute updates and disclose information concerning vulnerabilities after fixes become available.
Security updates generally need to be supplied free of charge, unless a specific exception applies for a tailor-made business product.
The manufacturer must also define a support period.
The general rule is at least five years, unless the product's reasonably expected lifetime is shorter. Conversely, a product expected to remain in use longer may require longer support.
Another easily overlooked requirement is that a security update released during the support period must remain available for at least 10 years after its release or for the remaining support period, whichever is longer.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R2847
This changes product lifecycle economics considerably. Selling a software product creates a long-lived cybersecurity obligation.
5. Incident and vulnerability reporting is already active
CRA entered into force on 10 December 2024. Most product requirements apply from 11 December 2027, but Article 14 reporting requirements became applicable on 11 September 2026.
Source: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Manufacturers must report two particularly important situations:
- actively exploited vulnerabilities;
- severe incidents affecting the security of a product.
The reporting sequence is generally:
| Stage | Deadline |
|---|---|
| Early warning | within 24 hours |
| Main notification | within 72 hours |
| Final report — exploited vulnerability | no later than 14 days after a corrective/mitigating measure becomes available |
| Final report — severe incident | within one month after the 72-hour notification |
Source: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
These reports go through the Cyber Resilience Act Single Reporting Platform, operated by the European Union Agency for Cybersecurity (ENISA). The platform went operational on 11 September 2026.
Companies selling affected products should therefore have an incident escalation mechanism capable of answering:
Is this vulnerability actively exploited?
↓
When did we become aware?
↓
Does Article 14 apply?
↓
Who owns the CRA notification?
↓
24-hour early warning
↓
72-hour report
↓
remediation + final report
A normal security ticketing process without explicit regulatory escalation may therefore be insufficient.
6. CRA requires conformity assessment and CE marking
CRA is not merely an incident-reporting regulation.
Before putting a covered product on the market, the manufacturer must demonstrate conformity, prepare technical documentation, issue an European Union Declaration of Conformity and apply the CE marking where required under the CRA framework.
Products are broadly divided into three risk groups.
For the default category, which includes many ordinary applications, mobile applications, games and consumer products, manufacturer self-assessment is generally possible.
For important products — Class I, self-assessment can remain possible where the appropriate harmonised standards, common specifications or recognised certification schemes have been applied. Otherwise, a notified conformity-assessment body may be necessary.
For important products — Class II, third-party conformity assessment is generally required.
There is then a category of critical products, for which stricter conformity-assessment/certification arrangements apply.
Source: https://digital-strategy.ec.europa.eu/en/policies/cra-summary
Examples of important Class I products include operating systems, password managers, Virtual Private Network products, antivirus software, identity-management systems, Security Information and Event Management systems, routers and network-management software.
Class II includes products such as hypervisors, container runtime systems, firewalls and intrusion detection/prevention systems.
Source: https://eur-lex.europa.eu/legal-content/pl/ALL/?uri=CELEX%3A32024R2847
So CRA's compliance burden is intentionally risk-based.
7. Open-source software is treated differently
CRA distinguishes normal open-source development from commercial product manufacturing.
A developer contributing code to a genuinely non-commercial open-source project does not suddenly become legally responsible as a CRA manufacturer merely because a commercial product later consumes the library.
Free and open-source software becomes relevant where it is supplied as part of a commercial activity. CRA also creates a special category called an open-source software steward for organisations systematically supporting open-source projects intended for commercial use. Those stewards have a lighter regulatory regime.
Source: https://digital-strategy.ec.europa.eu/en/policies/cra-open-source
The company integrating an open-source component into its commercial product nevertheless retains due-diligence obligations concerning that component.
OSS author → not necessarily CRA manufacturer
↓ dependency
commercial product vendor
↓
responsible for cybersecurity of resulting product
8. CRA versus NIS2
The two regimes overlap conceptually but regulate different objects.
CRA — Cyber Resilience Act
Regulates products.
The central question is:
Is the software/hardware product being placed on the European Union market cybersecure?
Responsibility primarily falls on manufacturers, importers and distributors.
NIS2 — Network and Information Security Directive 2
Regulates organisations providing certain important or essential services.
The central question is:
Does the organisation adequately manage cybersecurity risks to its network and information systems?
A company can therefore be covered by both.
Cybersecurity company
│
├── internal corporate infrastructure
│ └── NIS2 may apply
│
└── commercial firewall appliance
└── CRA applies to product
The CRA was explicitly designed to complement NIS2 and other European cybersecurity legislation.
9. The penalties are substantial
Failure to comply with Annex I cybersecurity requirements or major manufacturer/reporting obligations can lead to administrative fines of up to:
€15 million or 2.5% of total worldwide annual turnover, whichever is higher.
Other categories of violations can reach €10 million or 2%, while providing incorrect, incomplete or misleading information to authorities may reach €5 million or 1% of worldwide annual turnover.
Source: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ%3AL_202402847
Authorities can also impose market-surveillance measures, including restrictions, withdrawal or recall of products.
So CRA should not be treated as another ISO-style certification exercise. It is enforceable product legislation.
10. What CRA means for a software engineering organisation
From an architecture and engineering perspective, CRA can be translated into:
PRODUCT GOVERNANCE
│
├── CRA scope determination
├── product classification
├── support-period definition
└── responsible manufacturer identification
│
▼
SECURITY ENGINEERING
│
├── threat modelling
├── cybersecurity risk assessment
├── secure architecture
├── secure-by-default configuration
├── authentication / authorization
├── cryptography
└── attack-surface management
│
▼
SECURE SDLC
│
├── code review
├── Static Application Security Testing
├── Dynamic Application Security Testing
├── Software Composition Analysis
├── dependency scanning
├── Software Bill of Materials generation
└── security testing
│
▼
RELEASE GOVERNANCE
│
├── evidence
├── technical documentation
├── conformity assessment
├── European Union Declaration of Conformity
└── CE marking
│
▼
POST-MARKET SECURITY
│
├── vulnerability monitoring
├── Coordinated Vulnerability Disclosure
├── vulnerability intake
├── patch production
├── secure update distribution
├── customer advisories
└── lifecycle/support management
│
▼
REGULATORY INCIDENT MANAGEMENT
│
├── detect active exploitation
├── 24-hour notification
├── 72-hour notification
└── final reporting
The most important consequence of CRA for software companies is not the CE label.
It is that the Secure Software Development Lifecycle becomes part of legally demonstrable product compliance.
A company should be able to reconstruct the argument:
threat → risk → security requirement → architecture control → implementation → test → evidence → release → monitoring → remediation.
That traceability will become much more important than simply having penetration-test reports.
Key dates
- 10 December 2024 — CRA entered into force.
- 11 September 2026 — Article 14 reporting obligations apply.
- 11 December 2027 — the main CRA compliance regime becomes fully applicable.
For a non-trivial software portfolio, December 2027 is therefore not the sensible date to start a CRA programme. The architecture, Software Bill of Materials generation, vulnerability-management processes, evidence collection, support policy and conformity-assessment strategy need to be designed into the development lifecycle beforehand.
- Author
Patryk Nowak
Backend developer
- Comments
- Leave a Comment