The Cyber Resilience Act (CRA) moves the security of digital products from the “nice-to-have” category to one of the conditions for selling them in the European Union. Manufacturers must be able to demonstrate how they assessed risks, set up secure default configurations, reviewed the source code to ensure it contains no known vulnerabilities, and support the product throughout its lifecycle. In practice, the CRA is steering companies towards a secure software development lifecycle.
Manufacturers see security as an extra hassle
Our experience shows that in software development, tight delivery deadlines, attractive design and new, appealing features often take priority. Simply considering whether a product is secure tends to rank low on the list. Cybersecurity is usually not addressed during the product design stage, but only later — if there is still enough time and budget left.
The CRA now explicitly tells companies placing products with digital elements on the market that it is not enough for a feature in a device to simply work. It must be designed to work securely.
The CRA mandates what we have long regarded as good practice
Most of the CRA’s technical principles have long been part of recommended secure development practices. Risk analysis, secure default settings, checks of third-party libraries, security testing of code — rather than testing only its quality, as is often the case — issuing security patches and minimising the attack surface are not new disciplines. What is new is the manufacturer’s legal responsibility to ensure they are actually applied.
A company with well-established DevSecOps and a Secure Software Development Lifecycle (SSDLC) certainly does not have to start building its security practices from scratch. The CRA is not a security revolution. To a large extent, it merely turns existing good practice into an obligation, and many companies will adapt easily. Others, however, will have to make significant progress. Much like the GDPR did with personal data, the CRA turns a manufacturer’s voluntary promise regarding products with digital elements into a legal obligation.
Who does the Cyber Resilience Act apply to?
The CRA applies to products with digital elements placed on the European Union market. These include installable desktop and mobile applications, operating systems, firmware, connected hardware and separately sold software components. A cloud backend may also fall within the scope if it is essential to the remote operation of the product itself, as in the case of smartwatches or smart refrigerators. The scope is broader than the word “software” might suggest. From an attacker’s perspective, a smart TV is another computer on the network,even though its user probably sees it as an ordinary household appliance.
However, a standalone SaaS service provided solely as a web application in a browser does not automatically fall under the CRA. Its architecture, functionality and the way the solution is made available are what matter. Moreover, the manufacturer does not necessarily have to be the original developer. The obligations may also be assumed by a company that places the product on the market under its own brand or substantially modifies it. The scope of the CRA therefore needs to be assessed separately for each product.
Even if you only fall into the “Default” category, you still have obligations
A large proportion of standard installable applications will not qualify as important or critical products listed in the CRA annexes. They will fall into the basic category known as “Default”. For Slovak and Czech software companies, this may be the most common scenario.
The advantage is a simpler conformity assessment. The manufacturer can use internal self-assessment and is not required to involve a notified and certified third party. However, it must still meet the technical requirements, carry out a risk analysis, actively issue necessary security updates, report severe security incidents and known actively exploited vulnerabilities. It must also prepare documentation, issue an EU declaration of conformity and affix the CE marking.
Default does not necessarily mean a lower security standard. It only means that the manufacturer assesses and declares compliance itself. At the same time, it assumes responsibility for that compliance.
The first obligation is already in force
Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and severe security incidents to the Slovak National Security Authority (NBÚ) through the Unified Information System for Cybersecurity.The CRA will become fully applicable on 11 December 2027. The reporting obligations also apply to products placed on the market before this date.
An initial warning must be submitted within 24 hours of the manufacturer becoming aware of the event, followed by a more detailed notification within 72 hours. A final report then follows — in the case of a severe incident, within one month of the notification.
Reporting is therefore not just a matter of filling out a form. A company needs to know which product and version are affected, what the impact is, who decides whether a report must be submitted and what information can be communicated to customers.
What a secure product must now be able to do
The CRA turns the general word “security” into specific product characteristics. Its requirements include the following:
- Security must be built into a product with digital elements from the very first line of code — the principle known as security by default.
- A product with a known vulnerability that can realistically be exploited must not be placed on the market.
- Protective features should already be enabled in the default configuration.
- Unnecessary ports, services, interfaces and access points should remain disabled.
- Data must be protected against unauthorised access and modification through encryption, authentication and access controls.
- Updates must be delivered through a secure mechanism that an attacker cannot spoof or bypass.
- Users must be able to securely remove their data and settings from the product.
- The common denominator is the security-by-design principle, and the response should be the rigorous application of Secure Software Development Life Cycle standards.
Security requirements must be turned into a process
The Secure Software Development Life Cycle integrates security controls into the individual stages of development. During planning, a risk analysis and threat model are created to reduce the attack surface. The design stage addresses secure default settings and data protection. During coding, secure coding rules, third-party library dependencies, secrets management, code review and vulnerability scanning come into play. A standard code quality review alone is not a substitute for security analysis.
Static source code analysis, dependency checks and SBOM creation can be automated in the CI/CD pipeline. Dynamic testing and, depending on the level of risk, penetration testing are added before release. It is important for every finding to have an owner, a remediation deadline and a record of subsequent verification. Basic SSDLC documentation then demonstrates that security was not merely a one-off exercise carried out before an audit.
If a third-party library is vulnerable, it is still your problem
Modern applications consist of numerous open-source and commercial components. If a vulnerable library compromises the resulting product, the manufacturer cannot avoid responsibility by claiming that someone else wrote the faulty code. It must know what has been included in the product and what risks have been accepted as a result.
The foundation is a machine-readable inventory of software components and the relationships between them. However, the inventory itself only becomes useful when connected to vulnerability databases,enabling the company to quickly determine which products and versions are affected by a newly discovered flaw.
Responsibility continues after the sale
Once a product has been placed on the market, vulnerability management begins. The manufacturer needs a contact point where customers can submit reports, as well as processes for triage, severity assessment, patch planning and coordinated vulnerability disclosure. During the declared support period, the manufacturer must maintain the product’s security and inform customers about any necessary measures. As a rule, support must continue for five years after the product is placed on the market.
If a vulnerability begins to be actively exploited, incident response and reporting obligations become part of the process. The company must connect the technical findings to a specific product, version and affected customers. Without an up-to-date inventory, an SBOM and clearly assigned responsibilities, even a straightforward report can turn into a lengthy internal investigation.
Before the support period ends, the manufacturer must inform customers of the end-of-support date in good time.
Start with what your company is already doing
The first step is to map your products, their versions, their CRA categories, the components used, the support periods and the update methods. This can be followed by a gap analysis: which requirements the company already meets, where evidence is missing and where the underlying process itself has not yet been established.
Binary Confidence can help with the technical side of the preparation — from risk analysis and basic SSDLC documentation to source code scanning, dependency checks, SBOM creation, testing and incident reporting setup.
The CRA does not necessarily mean building security from scratch. For companies that have already been approaching it correctly, it is primarily an opportunity to organise their existing practices and demonstrate that a secure product is more than an empty promise in marketing materials.
This activity is supported by the European Cybersecurity Competence Centre (ECCC) as part of the project under grant code 101145856, and by the Ministry of Investments, Regional Development and Informatization as part of the state programme of the Recovery and Resilience Plan of the Slovak Republic under project grant code 17I04-04-V02-00001.
