{"id":13171,"date":"2026-10-08T09:00:27","date_gmt":"2026-10-08T07:00:27","guid":{"rendered":"https:\/\/www.binaryconfidence.com\/?p=13171"},"modified":"2026-10-08T10:03:35","modified_gmt":"2026-10-08T08:03:35","slug":"hackeri-dnes-utocia-skor-nez-sa-dozviete-o-bezpecnostnej-diere-stary-sposob-manazmentu-zranitelnosti-uz-nestaci","status":"publish","type":"post","link":"https:\/\/www.binaryconfidence.com\/en\/cyber-resilience-act-manufacturer-obligations\/","title":{"rendered":"Cyber Resilience Act: Do you manufacture smart refrigerators or develop applications that users install on their computers? From now on, you are fully responsible for their cybersecurity"},"content":{"rendered":"

The Cyber Resilience Act (CRA) moves the security of digital products from the \u201cnice-to-have\u201d 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.<\/em><\/p>\n

Manufacturers see security as an extra hassle<\/h3>\n

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 \u2014 if there is still enough time and budget left.<\/p>\n

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.<\/p>\n

The CRA mandates what we have long regarded as good practice<\/h3>\n

Most of the CRA\u2019s 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 \u2014 rather than testing only its quality, as is often the case \u2014 issuing security patches and minimising the attack surface are not new disciplines. What is new is the manufacturer\u2019s legal responsibility to ensure they are actually applied.<\/p>\n

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\u2019s voluntary promise regarding products with digital elements into a legal obligation.<\/p>\n

Who does the Cyber Resilience Act apply to?<\/h3>\n

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 \u201csoftware\u201d might suggest. From an attacker\u2019s perspective, a smart TV is another computer on the network,<\/a>even though its user probably sees it as an ordinary household appliance.<\/p>\n

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<\/a>.<\/p>\n

Even if you only fall into the \u201cDefault\u201d category, you still have obligations<\/h3>\n

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 \u201cDefault\u201d. For Slovak and Czech software companies, this may be the most common scenario.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"The
The first obligation applies to companies producing products with digital elements starting in September 2026.<\/span><\/figcaption><\/figure>\n

The first obligation is already in force<\/h3>\n

Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and severe security incidents to the Slovak National Security Authority (NB\u00da) through the Unified Information System for Cybersecurity.<\/a>The CRA will become fully applicable on 11 December 2027. The reporting obligations also apply to products placed on the market before this date.<\/p>\n

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 \u2014 in the case of a severe incident, within one month of the notification.<\/p>\n

Reporting<\/a> 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.<\/p>\n

\"Security
Security must be built into a product with digital elements from the very first line of code - the principle known as \"security by default\".<\/span><\/figcaption><\/figure>\n

What a secure product must now be able to do<\/h3>\n

The CRA turns the general word \u201csecurity\u201d into specific product characteristics. Its requirements include the following:<\/p>\n