Cyber Resilience Act (CRA)

Key Requirements under the CRA

The Cyber Resilience Act introduces a range of important requirements that affected organizations must meet. Key obligations include.

• Security by Design & Default
  Products must be built secure by design – meaning cybersecurity is embedded at every stage of development – and secure by default, with out-of-the-box settings that do not expose users to risk. Manufacturers are expected to integrate protective measures during planning, coding, and testing so that devices and software have robust defenses from day one. Default configurations should enforce security (e.g. no universal default passwords, minimal open ports), requiring minimal user effort to maintain safety. Notably, any security fixes or patches applied to a product should persist – for instance, a factory reset must not roll the product back to an insecure state without those updates. In short, the CRA makes proactive security engineering an essential part of product development.
• Product Vulnerability Management & Updates
  Manufacturers must establish processes to handle and remediate vulnerabilities throughout the product’s entire lifecycle. The CRA obliges companies to continuously monitor for new vulnerabilities in their products (including third-party components) and to address any identified issues “without delay” via security fixes. Organizations need a clear coordinated vulnerability disclosure (CVD) policy, providing a channel for security researchers and users to report flaws responsibly. Equally important, vendors are required to provide necessary security patches to users free of charge during the product’s support period. In fact, the CRA mandates a minimum support period (for many products, at least 5 years of security updates) to ensure products are not left unprotected shortly after purchase. Keeping products updated and patching known issues promptly is not just good practice – it’s a legal requirement under the CRA.
• Technical Documentation & Risk Assessment
  Compliance with the CRA must be demonstrated through comprehensive technical documentation. Manufacturers are required to perform a thorough cybersecurity risk assessment for each product and document the results. This involves analyzing how the CRA’s essential requirements apply to the product, identifying potential threats and misuse scenarios, and detailing the security controls implemented to mitigate those risks. The technical documentation (or “technical file”) should compile all evidence of the product’s cybersecurity by design – for example, the system architecture and design specifications related to security, the applied security measures and test results, a Software Bill of Materials (SBOM) listing third-party components, and the procedures in place for vulnerability management. Regulators or market surveillance authorities may request this documentation to verify that a product meets the CRA’s standards. Maintaining up-to-date documentation is crucial, as it creates accountability for manufacturers to continually assess and mitigate cyber risks in their products.
• CE Marking and Conformity Assessment
  The CRA operates within the EU’s product compliance framework, which means products must bear the CE marking to indicate they conform to these new cybersecurity requirements. Before affixing the CE mark, a manufacturer must draw up an EU Declaration of Conformity stating that the product fulfills all applicable CRA provisions. Most products can be self-assessed for conformity (by following harmonized cybersecurity standards or internal checks), but higher-risk categories of products require third-party evaluation. Specifically, if a product is classified as “important” or “critical” (per the CRA’s annexes), an independent notified body may need to perform a security assessment or certification before the product can be placed on the market. This step is comparable to a formal audit of the product’s cybersecurity. The CE marking, once obtained, signals to customers and regulators that the device/software complies with the CRA, and without it, the product cannot be legally sold in the EU. Consequently, meeting the CRA is not just about internal best practices; it’s a market access issue. Non-compliant products risk penalties or even removal from the EU market.
• Incident and Vulnerability Reporting Obligations
  In addition to preventive measures, the CRA imposes strict reporting duties when things go wrong. Manufacturers must notify authorities about certain cyber incidents and exploited vulnerabilities affecting their products on very short timelines. If you discover that a vulnerability in your product is being actively exploited (attackers are using it against users), or if a cybersecurity incident with significant impact occurs, you are required to send an initial report (an “early warning”) to the relevant national Computer Security Incident Response Team (CSIRT) and the European cybersecurity agency (ENISA) within 24 hours. Further, a more detailed technical report must follow within 72 hours, and a final incident analysis or remediation report within a specified period (e.g. 14 days after fixing a vulnerability, or one month after a major incident). These tight deadlines mean companies need well-drilled internal incident response processes to detect issues and gather information fast. The goal is to enable EU authorities to monitor emerging threats and coordinate response if a product’s security flaw is being widely abused. Failing to report in time is itself a compliance breach. In summary, CRA not only requires you to build secure products, but also to act swiftly and transparently when serious vulnerabilities or breaches are found.

CRA in Context: NIS2, AI Act and Other Regulations

The Cyber Resilience Act is part of a broader push by the EU to strengthen cybersecurity across the board. It complements other regulations like the NIS2 Directive and the upcoming AI Act, ensuring a cohesive approach to digital security governance. Notably, the CRA was explicitly designed to work in tandem with NIS2 (the EU directive on network and information security for essential services). While NIS2 focuses on organizational cybersecurity (e.g. requiring companies in critical sectors to implement security controls and report incidents), CRA focuses on the security of the products those organizations (and others) use and provide. Together, these laws reinforce each other – for instance, a company that is both a service provider under NIS2 and a manufacturer under CRA will need to secure its operations and ensure its products are cybersecure. Compliance efforts can be aligned so that improving product security under CRA also helps meet NIS2’s goals of overall resilience.

Meanwhile, the EU AI Act (expected to be finalized soon) will regulate the use of AI, especially high-risk AI systems, with requirements around transparency, safety, and risk management. If you develop smart or AI-driven products, you may fall under both CRA and the AI Act. The good news is the regulations are being aligned: for example, a high-risk AI system that meets the CRA’s essential cybersecurity requirements is presumed to comply with the AI Act’s overlapping security requirements (Article 15) – avoiding duplicate work. In other words, fulfilling CRA’s security-by-design obligations will also satisfy the AI Act’s cybersecurity expectations for AI systems. This reflects the EU’s intent to harmonize its tech regulations. Similarly, the CRA builds on existing standards and strategies (it aligns with the EU Cybersecurity Strategy 2020 and Security Union Strategy) and fits alongside other initiatives like the EU Cybersecurity Certification Framework. For organizations, this means CRA shouldn’t be viewed in isolation – it’s wise to integrate CRA compliance with your existing security and compliance programs (such as ISO/IEC 27001 for information security management or IEC 62443 for industrial product security) to achieve consistency. Ultimately, the CRA, NIS2, AI Act, and related laws all share the common goal of raising cyber resilience – addressing it from different angles (products, services, AI) but moving toward the same more secure digital ecosystem.

Common Challenges in Achieving CRA Compliance

Adapting to the Cyber Resilience Act can be demanding, particularly for organisations that have not dealt with EU product regulation or a formal cybersecurity programme before. These are the challenges we see most often.

• Understanding scope and requirements
  The first hurdle is usually working out what the CRA means for you. Its scope is very broad — in principle anything that communicates digitally can be covered, from IoT devices to software applications. Many organisations, and smaller software companies or device manufacturers in particular, are not used to EU compliance regimes. Determining whether your products are in scope, and if so which risk class they land in, and interpreting the legal and technical requirements, can be confusing. The regulation introduces new concepts and terminology — “products with digital elements”, “essential requirements”, “class I and II critical products” — that take time to absorb. And the main requirements, secure updates, an SBOM, secure default configurations, are substantial for manufacturers of any size. The learning curve is steep, and many need support to understand their obligations and avoid missteps.
• Integrating security into development
  Achieving secure by design can take significant change in how an organisation builds products. Many manufacturers, startups and those that historically put function before security especially, have no formal security process in the product lifecycle. The CRA requires security activity built into every phase: from concept and design with threat modelling and secure architecture review, through implementation with secure coding standards and code review, into testing with vulnerability scanning and penetration testing, and on into operation and maintenance with secure configuration management and update mechanisms. For a team that has not done this, building a secure development lifecycle from nothing feels overwhelming. Even organisations with some security in place have to check that every CRA requirement is covered — making sure a device does not lose its patches on a factory reset can require a design change. Breaking down silos matters too: development, security and legal need to work more closely than before. That usually takes training, updated pipelines and sometimes new tooling or competence. It is a large but necessary shift, and the initial implementation is where many struggle.
• Resource and technical constraints
  The CRA can be resource-intensive, particularly where budget or cybersecurity competence is limited. Some requirements mean continuous work: you have to monitor vulnerabilities not only in your own code but in every third-party component and open source library you use. Establishing that monitoring, and the ability to act quickly — develop a patch, test it, distribute the update — takes real operational capacity. Producing and maintaining a detailed SBOM is also hard without automation, and many organisations have no infrastructure today for tracking components and their vulnerabilities as they change. A smaller manufacturer may have no security engineer, incident handler or compliance owner in-house, yet the CRA still calls for work — penetration testing, cryptographic implementation, formal conformity documentation — that needs specialist competence. That means recruiting, training or bringing in help, which costs. Larger companies can face high volume instead, with many products and many updates. The CRA is not a one-off project; it introduces an ongoing technical workflow. Without planning and allocated resources, organisations get overwhelmed.
• Maintaining compliance and coordinating with other standards
  Meeting the CRA is not a tick-and-finish exercise; it is a long-term commitment. Once products and documentation have been updated ahead of 2027, you still have to monitor threats, release patches, keep the documentation current and reassess security regularly as technology and rules develop. The risk of drifting out of compliance is real, particularly where cybersecurity has not been a core competence. It helps to integrate the CRA into the governance frameworks you already have rather than running it as an isolated project. But mapping the CRA against other frameworks — ISO 27001, ISO 9001, sector standards — takes care to avoid conflicts and duplicated work. If you are also in scope for NIS2, or preparing for the AI Act, you need incident handling, risk management and reporting coordinated so that everything is covered. Building one coherent compliance strategy instead of a silo per regulation is harder up front and more efficient afterwards. It takes cross-functional work and often outside guidance, so that the CRA becomes part of the business processes rather than colliding with other requirements. Without a plan for continuous improvement and integrated compliance, the initial effort stalls, documentation goes stale, or new product versions ship with weaker security — which is the opposite of the resilience the law is after.

Helping You Comply with the CRA

At Kristensson i Skåne AB we specialise in cybersecurity, information security governance and regulatory compliance. We are a practical partner guiding organisations through the CRA, from early planning to implementation and continuing improvement. Our team understands the technical and organisational challenges in the Cyber Resilience Act and fits the support to your context. Whether you are a device manufacturer that needs to strengthen its product security processes, or a software developer wanting to meet the EU requirements without losing pace on the roadmap, we can support you at each step. We offer the work as focused projects, to reach a specific milestone or prepare for 2027, or as ongoing advice for continuing expertise while you run and develop the security programme. Our approach is structured but hands-on: we map CRA measures against established practice and standards such as ISO 27001 and IEC 62443, so compliance does not only meet the requirement but raises your security level. These are the main ways we can help.

• Product lifecycle risk assessments
  We help you carry out cybersecurity risk assessments for your products: identifying the likely threat scenarios, misuse cases and vulnerabilities across the whole product lifecycle, from design and manufacture to deployment and maintenance. Our consultants work with your engineering and product teams to evaluate the product against the CRA’s essential requirements and against security practice. The result is a clear picture of the gaps and weaknesses that need work. A structured risk analysis, which the CRA requires, gives you a roadmap of security improvements prioritised by risk. It also produces documented evidence of due diligence, and feeds directly into the technical documentation and the action plan.
• Secure development lifecycle (SDLC) advisory
  With the risk assessment as the basis, we advise on building security into the product development lifecycle. We give guidance and practice for a solid SDLC aligned with the CRA and with frameworks such as IEC 62443-4-1. Concretely, we help you establish security checkpoints in each phase: defining security requirements in design, bringing threat modelling into design reviews, introducing secure coding standards and review techniques, and planning rigorous security testing — static analysis, fuzz testing, penetration tests — before release. We also work with secure-by-default configuration: hardened default settings and update mechanisms that actually work. For organisations new to this we run training workshops and provide templates so developers and QA get moving quickly. The aim is a durable process where security is built in, so future products and updates follow the CRA without endless trial and error.
• Vulnerability management and patching process
  We help you establish or improve an end-to-end vulnerability management process for products in the field. Under the CRA this is a critical capability, and we can set it up efficiently. We help you establish a coordinated vulnerability disclosure programme, with clear channels — a security@ address or a web portal — and policies for external reports. We work with support and development to create a workflow for triaging reported vulnerabilities, root cause analysis, and developing and testing patches. Being able to act without undue delay is the key, so we help you define internal SLAs for patch times and the mechanisms for distributing updates, from OTA for IoT to automatic updates for software. We advise on communicating security updates to customers and on coordinating patches so they land smoothly, separating security fixes from feature updates as the CRA encourages. With a repeatable patch process and a defined support period, five years or more, you meet the CRA and cut users’ exposure time sharply. You end up with a playbook for vulnerabilities across the lifecycle.
• Incident response and reporting procedures
  If your product is involved in a serious cybersecurity incident or an exploited vulnerability, preparation is what counts. We help you develop incident and reporting processes fitted to the CRA. That includes an internal incident plan for product incidents: how incidents are detected, through monitoring or user reports, how a response team is stood up, and how the threat is contained and dealt with. We tie this into your overall incident and crisis management, since product incidents often need coordination across engineering, PR and legal. It also matters that you can meet the CRA’s 24-hour reporting and the reports that follow. We produce the routines, notification templates and escalation flows so the team knows how to report to the national CSIRT and other authorities in time. Through simulations and walkthroughs you become reporting-ready, with no scramble over who tells whom and when. We help with the points of contact towards the authorities, the link to the vulnerability management system so that a zero-day triggers the reporting process directly, and training staff on the new obligations. With that in place you can meet the reporting requirements and handle the incident effectively at the same time, which protects both customers and reputation.
• Documentation and technical file preparation
  The CRA brings a substantial documentation burden, and we help you reduce it. We help you produce the documentation and evidence needed to demonstrate conformity. We assemble the technical documentation the CRA requires for each product: the risk assessment report, design and architecture descriptions covering the security functions, the list of standards and controls, results from testing and review, and the vulnerability handling policy including the SBOM and the update strategy. We provide templates and structure in line with what the EU expects, and see that you include the data and detail on the means used to ensure conformity, as required. We also help produce the EU Declaration of Conformity, the formal document you sign to attest that the product meets Annex I. Where the product requires third-party assessment, a notified body for a class II or critical product, we help integrate those results into the technical file. The result is documentation you can put in front of an authority or a customer. We can also establish version control and maintenance routines so the documents stay current as the product changes, which is what ongoing compliance rests on. In short: you become audit-ready and the CE marking process runs more smoothly.
• Alignment with NIS2, ISO 27001/IEC 62443 and the AI Act
  Cybersecurity regulation does not exist in a vacuum, so we help you integrate the CRA with your other security and compliance work. We map CRA requirements to the frameworks you already use, ISO 27001 or IEC 62443, so existing controls and policies can be reused. That avoids duplicated effort — an ISO 27001 risk register or incident process can be extended for the CRA instead of running a parallel one. If you are in scope for NIS2 or other regulation we coordinate the controls and the reporting flows so the same way of working satisfies several requirements. Incident notification can be synchronised so that a single flow meets both the NIS2 and the CRA reporting rules. If you build AI-driven products we also align the CRA with the AI Act, so that the work you do for the CRA — robust security and documentation — supports the AI Act’s requirements on safety and risk, and takes advantage of the presumption of conformity the frameworks give. The gain is efficiency and consistency: the programmes support each other and security is handled as a whole. With Kristensson the CRA is not an isolated checklist but part of one strategy for cyber resilience and regulatory compliance.