Posts

EU Cyber Resilience Act (CRA) – Overview

/in

What is the Cyber Resilience Act – CRA

The Cyber Resilience Act is the first European regulation to set a mandatory minimum level of cyber security for all connected products available on the EU market – something that did not exist before.

The CRA is a regulation from the European Union — formally Regulation (EU) 2024/2847 — but it is likely to be applied soon in other parts of the world, which produce for and sell products in the EU.

It covers both hardware and software products whose intended or foreseeable use involves connection (direct or indirect) to a device or network. That includes things like smartphones, laptops, IoT devices (smart-home cameras, smart fridges, connected toys), embedded systems, routers, industrial control systems, and even software with network connectivity.

Non-commercial open source software products are exempt from the CRA and therefore do not have to fulfill the requirements of the CRA.

Some product categories are excluded because they are already covered by other sector-specific regulation (e.g. certain medical devices, aviation, automotive, defense).

As can be seen, the aim is to increase cybersecurity within the European Union. The new regulation applies in all EU Member States and will be implemented gradually.

Timeline & Legal Effect

The CRA entered into force on 10 December 2024. There is a transition / compliance period: the full requirements become applicable by 11 December 2027 for new products.

Starting 11 June 2026, the Conformity Assessment Bodies can assess the fulfillment of the requirements.

Reporting of vulnerabilities and security incidents starts on 11 September 2026.

*CABs = Conformity Assessment Bodies

Source: BSI

Key Requirements & Obligations

For manufacturers, importers or distributors of in-scope products, CRA demands:

Secure-by-design and secure-by-default

During design and development, implement baseline cybersecurity controls (minimizing attack surface, secure defaults, applying cryptography, access control, integrity protection, etc.).

If you design or manufacture hardware or software intended for the EU market — start including security early: threat modelling, secure defaults, update mechanisms, patch management, SBOM (software-bill-of-materials) for components, documentation.

Lifecycle security

Maintain security across the lifecycle — through production, deployment, maintenance, updates (patches), and eventual decommissioning.

Prepare to collect and maintain documentation of the build, supply chain components, update/maintenance history, and test results for many years.

Vulnerability & incident reporting

If a product becomes subject to a “actively exploited vulnerability” or a “severe security incident”, the manufacturer must report promptly (early warning within 24 h, full notification within 72 h, final report within certain timeframes) via the CRA Single Reporting Platform.

For software vendors — ensure update/patch infrastructure is robust and built-in, and notification processes in place for vulnerabilities.

Documentation & traceability

Maintain technical documentation, data inventories and evidence of security measures for a defined period (often many years) after placing the product on the market.

CE-marking with security

Products that comply must carry the CE-mark, indicating conformity with the CRA’s cybersecurity requirements — similar to CE marking for safety or environmental compliance.

For buyers/customers — expect CE-mark + transparency regarding security posture. Choose vendors who commit to long-term patching and vulnerability response.

Conformity assessments for higher-risk products

While many products (roughly 90%) fall under a “default” tier and can be self-assessed by manufacturers, certain more critical or important product types (e.g. firewalls, security modules, intrusion detection systems, certain embedded systems) may require third-party assessment before being placed on market.

Why It Matters

The CRA establishes a common, EU-wide baseline for cybersecurity of digital products. This helps avoid fragmentation where different member states might otherwise have different rules. It forces manufacturers and vendors to adopt security by default + lifecycle security, rather than treating cybersecurity as an optional afterthought. This helps reduce the attack surface and improves resilience against cyber threats.

It increases transparency for consumers and businesses: when they buy a product with digital elements, they can expect a baseline of security and support — including updates and vulnerability management.

For vendors and developers — in enterprise, embedded, IoT or consumer space — it’s a legal obligation. Non-compliance when required could lead to regulatory consequences, and non-compliant products will not be allowed on the EU market once the deadlines lapse.

 

CRA Product Classification

Criteria & Examples

The CRA divides “products with digital elements (PDEs)” into four classification tiers. Classification drives what conformity assessment, certification, and compliance rigour you must apply.

Category When a product is placed here (criteria / rationale) Typical product examples*
Default Products that are not listed in the “Important” or “Critical” annexes — i.e. no particularly sensitive cybersecurity function or high risks associated with compromise. Many consumer devices & software: smart toys, basic IoT devices, simple smart-home equipment, non-security-critical apps, common consumer electronics.
Important – Class I PDEs that provide a cybersecurity-relevant function (authentication, access control, network access, system functions) but whose compromise would have a moderate risk (less than Class II). Identity management systems / privileged-access software or hardware (e.g. access readers), standalone/embedded browsers, password managers, VPN clients, network management tools, operating systems, microcontrollers/microprocessors with security-related functions, routers/modems/switches.
Important – Class II PDEs whose function involves a significant cybersecurity risk, or whose compromise could have wide or severe impact, especially on many other systems — thus higher criticality than Class I. For these, third-party conformity assessment is mandatory. Firewalls, intrusion detection/prevention systems (IDS/IPS), virtualisation/hypervisor/ container runtime systems, tamper-resistant microprocessors/microcontrollers, industrial-grade network/security systems.
Critical PDEs with cybersecurity-related functionality whose compromise could disrupt or control a large number of other products, critical infrastructure, supply chains or sensitive services. These must either get an EU cybersecurity certificate (per relevant scheme) or undergo strict third-party assessment. Hardware security modules (“security boxes”), smart meter gateways, smartcards / secure-elements, secure cryptoprocessing hardware — i.e. devices central to critical infrastructure, secure identity, secure communication or supply chain security.

* These examples reflect currently published annex examples and guidance. Regulatory technical specification updates (e.g. by the European Commission) may refine or expand the lists.

 

Assessment & conformity requirements per class

Below are examples of software products affected by the Cyber Resilience Act, organized into two tables and classified into the CRA categories:

  • Default Category – non-critical, low inherent risk

  • Important Class I – higher exposure, widely deployed, could be abused at scale

  • Important Class II – products with elevated security relevance, including security software and products in Annex III

  • Critical – core components of cybersecurity, identity, encryption, or essential network infrastructure

These classifications follow the CRA’s conceptual tiers, not an official certification list, because exact classification depends on the manufacturer’s intended use and applicability of Annex III.

Examples of Software Products Classification

Disclaimer: this is my current understanding of products with digital elements (PDEs). There is no official list of categories of products published, or at least I did not find one.

This list was created with help of AI and it is no guarantee to be complete or correct.

 

Software Type Example(s) CRA Category Rationale
CRM Platforms Salesforce, HubSpot, MS Dynamics Default General business software; no direct security function.
Blogging/CMS Platforms WordPress, Ghost, Drupal Default Consumer and enterprise web software; not security-critical by default.
Office Productivity Tools LibreOffice, MS Office Default Widely used but not security components.
Developer Tools IDEs, build systems Important Class I Used in software supply chains; compromise impacts downstream.
Cloud Management Consoles AWS CLI tools, Azure Portal extensions Important Class I Access to infrastructure; security implications.
Antivirus / Endpoint Protection CrowdStrike, Defender, Bitdefender Important Class II Security products explicitly listed under risk-sensitive categories.
EDR/XDR Platforms SentinelOne, Trellix, Microsoft XDR Important Class II Security monitoring and threat response capabilities.
Firewalls (Software-based) pfSense, OPNsense, Cisco, Juniper Important Class II Security enforcement components.
VPN Clients OpenVPN Client, WireGuard clients Important Class II Encryption and secure communications; directly covered.
Identity & Access Software SSO, MFA clients, IdP agents Critical Core identity systems; high systemic impact.
Key Management & Crypto Libraries OpenSSL, libsodium Critical Cryptographic primitives/implementations; part of critical components.
Secure Configuration Agents MDM agents, compliance agents Important Class II Affect system posture and policy enforcement.
Network Monitoring / SIEM Splunk, Elastic, QRadar Important Class II Security event analysis and detection.
Container Security Tools Aqua, Twistlock Important Class II Protect containerized workloads; tied to infrastructure security.

 

Further reading and sources

The post EU Cyber Resilience Act (CRA) – Overview first appeared on Sorin Mustaca’s blog.

Introduction to CISA’s Secure by Design Initiative

/in

 

What is Secure by Design?

Secure by Design products are those where the security of the customers is a core business requirement, not just a technical feature. Secure by Design principles should be implemented during the design phase of a product’s development lifecycle to dramatically reduce the number of exploitable flaws before they are introduced to the market for broad use or consumption. Products should be secure to use out of the box, with secure configurations enabled by default and security features such as multi-factor authentication (MFA), logging, and single sign on (SSO) available at no additional cost. (Source)

Secure by Design is an initiative by the Cybersecurity and Infrastructure Security Agency (CISA) aimed at integrating cybersecurity practices into the design and development phases of technology products and systems. The goal is to ensure that security is considered a fundamental element from the outset, rather than an afterthought. This approach helps in reducing vulnerabilities and enhancing the resilience of systems against evolving cyber threats.

Sounds familiar?

Yes, because we know for the past 20 years or more the Microsoft initiative:   Secure by design – Secure by default – Secure operations

 

 

 

Who Should Be Interested?

This initiative is crucial for software developers, system designers, engineers, and manufacturers involved in creating and deploying digital solutions. It is also vital for policy makers and business leaders who oversee the management and governance of cybersecurity risks in their organizations.

Why Is It Important?

Incorporating cybersecurity measures early in the design process can significantly mitigate risks, reduce costs associated with addressing security flaws after deployment, and improve consumer trust. Secure by Design supports not only the protection of individual products but also the overall security posture of national infrastructure and business ecosystems.

Focus of the Initiative

The primary focus of the Secure by Design initiative is to create a systematic, standardized approach to cybersecurity, ensuring that every phase of technology development includes security as a core component. This involves collaborative efforts among stakeholders to adopt best practices that promote security from the initial stages of product and system development.

Topics Covered by the Initiative

Development and Implementation of Security Practices

  • Guidelines for integrating security into software development life cycles (SDLC).
  • Establishment of security benchmarks and standards for new technologies.

Stakeholder Collaboration

  • Engagement with private sector, academia, and international bodies to harmonize security standards.
  • Public-private partnerships to advance security innovations and solutions.

Regulatory Compliance and Risk Management

  • Frameworks for compliance with emerging laws and standards in cybersecurity.
  • Strategies for risk assessment and management integrated into the design process.

Implementation and Auditing

How to Implement

  • Create a Secure Software Development Lifecycle with security protocols and checklists tailored to each stage of the design and development processes.
  • Incorporate automated security testing tools to assess vulnerabilities during the development phase.
  • Continuous monitoring and updating of security measures as part of ongoing maintenance.

Auditing

  • Regular security audits conducted by internal or third-party auditors to ensure adherence to established standards.
  • Use of automated auditing tools to provide ongoing assessments of security posture.

Responsibility and Governance

Who Is Responsible?

  • Chief Information Security Officers (CISOs) and IT managers are primarily responsible for overseeing the implementation of Secure by Design principles.
  • Developers, engineers, and product managers are accountable for incorporating these principles into their workflows and outputs.

Governance

  • Establishment of a governance structure to enforce security standards and practices.
  • Regular reviews and updates to security policies to align with technological advancements and threat landscapes.

Conclusion and further steps

CISA’s Secure by Design initiative represents a proactive shift in cybersecurity strategy, emphasizing the importance of integrating security at the foundational level of technology development. By fostering a collaborative environment among all stakeholders, it aims to standardize and strengthen cybersecurity practices across industries, thereby enhancing the security and resilience of digital infrastructures and systems.

 

CISA’s Secure by Design Alert Series

highlights the prevalence of widely known and documented vulnerabilities, with available and effective mitigations, that have not been eliminated. Alerts are released in response to threat actor activity, but further demonstrate how secure by design software development can help reasonably protect against malicious cyber actors successfully exploiting predictable and well-known vulnerabilities.

Check here their page for Alerts: https://www.cisa.gov/securebydesign/alerts

Secure by Design Blogs

Learn what’s top of mind at CISA and our efforts to help make technology products secure by design.

https://www.cisa.gov/securebydesign/blogs

The post Introduction to CISA’s Secure by Design Initiative first appeared on Sorin Mustaca on Cybersecurity.