In a world where everything from baby monitors to industrial sensors is connected, cybersecurity is becoming a crucial legal requirement. Europe is addressing the need for digitally safe products with the CRA, or Cyber Resilience Act.
For decades, we in the compliance sector have focused on preventing shocks, fires, and mechanical failures, but the rise of the Internet of Things (IoT) has introduced a far more pervasive risk. The European Union has recognized a smart toaster can cause systemic harm if it lacks proper security. An industrial controller can be just as dangerous as a faulty circuit breaker under the same conditions. This realization birthed the Cyber Resilience Act (CRA), a landmark piece of legislation that changes the definition of what it means for a product to be “safe.” As we move into 2026, the transition from theory to enforcement is becoming a reality. No manufacturer can afford to ignore this change.
The EU Cyber Resilience Act (CRA), which entered into force in late 2024 and enters its first critical enforcement phase in 2026, represents the first “horizontal” (all-encompassing) cybersecurity legislation for digital products in the European Union.
The Digital Safety Revolution
In the world of regulatory compliance, we often speak about “horizontal” versus “vertical” legislation. Most safety standards, like IEC 62368-1, are vertical, meaning they apply only to a specific type of product. The CRA is different because it is a horizontal regulation, casting a wide net over almost every product with “digital elements” that connects to a network. This includes everything from the simple smart bulb in your living room. It also includes the complex sensors used in a chemical processing plant.
If your product has software or hardware that communicates with the outside world (who doesen’t nowadays!), the CRA likely applies to you.
The core philosophy of this regulation is simple yet demanding: security must be baked into the product from the very first day of design and maintained until the product is retired. This shift requires a fundamental change in how companies approach the product development lifecycle.
EU is demanding a disciplined, documented, and transparent approach to digital safety that mirrors the rigorous testing we have always applied to electrical safety and EMC.
Understanding the sheer breadth of this regulation can be daunting for even the most seasoned safety technician. It isn’t just about code; it’s about the entire supply chain, the transparency of components, and the long-term commitment to the consumer.
This article serves as your roadmap through the complexities of the CRA, helping you decode the legal jargon and understand the practical steps required for compliance as we approach the critical 2026 milestones.
What is the CRA?
The CRA is an EU regulation designed to address two main problems: low levels of cybersecurity in products with “digital elements” and the lack of consistent security updates.
Unlike the GDPR (which protects personal data) or NIS2 (which protects critical infrastructure entities), the CRA focuses on the product itself. It requires hardware and software to be “secure by design” and “secure by default.”
Key Obligations for Manufacturers
- Vulnerability Management: Identifying and patching security flaws throughout the product’s entire lifecycle.
- Transparency: Providing a Software Bill of Materials (SBOM)—essentially an ingredient list of all the software components inside a product.
- The Support Period: Manufacturers must provide security updates for at least five years (or the expected lifetime of the product).
- CE Marking: Products that meet CRA standards will carry the CE mark, signaling they are safe for sale in the EU market.
Risk Categories and Penalties
The CRA classifies products into three tiers based on risk assessment:
- Default (90% of products): Includes most home gadgets. Manufacturers can perform a “self-assessment.”
- Important (Class I & II): Includes password managers, routers, and firewalls. Requires stricter third-party audits.
- Critical: Reserved for the most sensitive hardware and software (e.g., smartcard operating systems).
The Cost of Failure
Non-compliance is expensive. Fines can reach €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Beyond fines, authorities can order a total product recall or ban the product from the EU market entirely.
Defining the Scope: What Exactly is a “Product with Digital Elements”?
One of the most frequent questions I receive is whether a specific, niche product falls under the CRA’s shadow. The definition provided by the regulation is intentionally broad to prevent manufacturers from finding loopholes through clever naming conventions. A “product with digital elements” is any software or hardware product and its remote data processing solutions, including software or hardware components to be placed on the market separately. This means that even if you only sell a specific software module intended for use in a larger system, you are likely still on the hook for compliance.
Product with Digital Elements
But we must be careful not to overcomplicate the definition. Essentially, if your device has a processor, runs code, and has a data connection (wired or wireless), the CRA applies to you. This includes consumer goods and industrial equipment. For industrial equipment in particular, it goes along with prEN 50742. It also includes some software-only products like mobile apps or desktop programs that interact with hardware. The goal is to close the “security gap.” A single weak link in a network, such as an unpatched smart camera, could serve as an entry point for a massive cyberattack on a home or a corporation.
The regulation creates a clear distinction between the hardware you can touch and the software that makes it run. This point is crucial for quality technicians to understand. Your compliance file must now include more than just circuit diagrams. It must also include material lists. You will need to account for the “invisible” parts of your product.
Software parts to be addressed are:
- Firmware and Operating Systems: The base-level code that controls the hardware.
- Application Software: The high-level programs that provide user functionality.
- Network Components: Any part of the product that handles data transmission, like Wi-Fi modules or Ethernet ports.
- Remote Processing: If your product relies on a cloud service to function, that cloud interaction is also part of the security assessment.
By categorizing these elements, the CRA ensures that no part of the digital ecosystem is left unprotected. It forces a holistic view of the product where the hardware and the software are treated as a single, integrated unit for the purposes of safety and certification. This integrated approach is how we have treated electrical insulation or electromagnetic shielding for years. It’s high time we applied that same rigor to bits and bytes.
Critical Deadlines: Why 2026 is the Real Start
While the CRA was officially entered into force in 2024, there is a grace period before the full weight of the law is applied. However, 2026 is the year where the “soft” phase ends and the “hard” requirements begin. Many companies are making the mistake of waiting until the final December 2027 deadline to start their compliance journey. This is a dangerous approach. By the time 2027 rolls around, the infrastructure for testing and certification will be backlogged, and you may find yourself unable to get your product to market.
Specifically, 2026 introduces two critical milestones. First, the rules for “Notified Bodies” come into play. These are the third-party organizations that will audit and certify high-risk products. If your product falls into the “Important” or “Critical” categories, you will need to establish a relationship with a Notified Body early. Second, and perhaps more daunting, is the reporting requirement starting in September 2026. This means that if you have a product on the market, and someone finds a way to hack it, you have a 24-hour window. You must report that vulnerability to the authorities within that time.
To help you manage your timeline, here is a detailed breakdown of the critical dates you need to mark in your calendar:
| Date | Milestone | Practical Impact for Manufacturers |
| Mid-2024 | Entry into Force | The regulation is officially part of EU law. |
| June 11, 2026 | Notified Body Rules | Third-party auditors begin the accreditation process; start booking your audits now. |
| Sept 11, 2026 | Reporting Launch | Your Incident Response Team must be operational. 24-hour reporting becomes law. |
| Dec 11, 2027 | Full Application | No non-compliant products can be sold in the EU. CE mark is mandatory. |
Managing these deadlines requires a project management approach to compliance. You should be conducting “gap analyses” right now to see how far your current processes are from the CRA requirements. If you wait until September 2026 to figure out how to report a vulnerability, you have already failed.
But don’t panic—2026 is also an opportunity. Companies that are ready early will have a significant competitive advantage. They will be able to prove to their customers and distributors that their products are “CRA-Ready,” which will become a powerful marketing tool as awareness of digital safety grows among consumers and industrial buyers alike.
The Pillars of Compliance: Secure by Design and Default
The CRA is built on several fundamental requirements that act as the pillars of the new regulatory framework. The most significant of these is the concept of “Secure by Design.” In our traditional safety work, we wouldn’t design a high-voltage device and then try to figure out how to ground it as it’s leaving the factory. We design the grounding first. The CRA demands this same proactive mindset for cybersecurity. You must identify potential threats during the design phase. Implement mitigations before a single line of code is written. Ensure safeguards are in place before a chip is soldered.
Following closely is “Secure by Default.” This is a rule that many manufacturers find challenging because it often conflicts with “ease of use.” In the past, many IoT devices shipped with a default password like “admin” or “1234” to make setup easy for the customer. Under the CRA, this is a major violation. Products must be shipped with the most restrictive security settings possible. This includes forcing users to change default passwords, disabling unused ports and services, and ensuring that security features are turned on from the moment the device is unboxed.
To help you visualize these requirements, I have simplified the primary obligations. Every manufacturer must now integrate these obligations into their quality management systems.
CRA Obligations to fulfill:
- Risk Assessment: A formal document identifying cyber threats and how the product’s design addresses them.
- Vulnerability Management: A proactive system for discovering, documenting, and patching security flaws.
- The Software Bill of Materials (SBOM): A comprehensive list of every software component, including open-source libraries, used in the product.
- Transparency and Instructions: Clear documentation for the user on how to set up and maintain the product’s security.
- Reporting Obligations: A legal requirement to notify EU authorities of any actively exploited vulnerabilities within strict timeframes.
- Tip: if your product use AI, the EU AI ACT also applies.
The implementation of these pillars requires a tight collaboration between the engineering team and the compliance department. It’s no longer enough for the “security guys” to work in a silo; their work must be documented and audited just like the results of a dielectric strength test. This documentation is what will eventually allow your product to carry the CE mark.
Once these pillars are in place, they form the foundation of your ongoing compliance strategy. You cannot simply build a secure product once and forget about it; you must maintain these standards through the entire support period, which we will discuss in more detail when we look at lifecycle management.
The Software Bill of Materials (SBOM): The CRA Ingredient List
In the food industry, every package must list its ingredients. If a batch of peanuts is contaminated, the manufacturer can quickly identify which products are affected. The CRA brings this same level of transparency to the software world through the Software Bill of Materials, or SBOM. In my experience as a technician, this is often the most overlooked aspect of compliance, yet it is one of the most vital. Most modern software isn’t written from scratch; it’s assembled using hundreds of smaller, open-source components and libraries.
An SBOM is a formal, machine-readable record of all those components. It includes the version numbers, the authors, and the license types of every piece of code inside your device. Why does this matter? When a major vulnerability is discovered in a common library, like the infamous Log4j flaw, the SBOM helps. It allows you and your customers, to instantly know if your product is at risk. Without an SBOM, you are essentially flying blind, hoping that your code is secure without actually knowing what’s inside it.
The creation and maintenance of an SBOM is a continuous process that should be integrated into your automated build systems.
Here is what a standard, compliant SBOM needs to track:
- Component Name: The specific name of the library or module.
- Version String: The exact version used in the final product build.
- Author/Supplier: Who created the code?
- Relationship: How does this component connect to other parts of the system?
- Vulnerability Status: Known security issues associated with that specific version.
Setting up an SBOM system is a technical challenge, but it is also a massive benefit for your internal quality control. It allows your developers to keep track of technical debt. It ensures that you aren’t using outdated or unsupported libraries. These could lead to a security breach down the road.
Furthermore, the SBOM is a key part of the technical documentation you must provide to the market surveillance authorities. If you cannot produce an accurate SBOM upon request, your product could be deemed non-compliant, regardless of how secure the code actually is. Transparency is a requirement, not a suggestion.
Vulnerability Management and the Lifecycle Support Period
One of the most radical changes introduced by the CRA is the mandatory support period. Historically, manufacturers of cheap IoT gadgets would sell a product and then abandon the software immediately. If a security flaw was found a year later, the consumer was left unprotected. The CRA ends this practice by requiring manufacturers to provide security updates for the “expected lifetime” of the product, or for a minimum of five years, whichever is shorter.
This means that your “Safety File” is no longer a static document that you file away once the product is launched. It is now a living entity. You must have a system in place to monitor for new vulnerabilities throughout the entire time the product is in the hands of consumers. This is known as the Vulnerability Management Process. It involves scanning your SBOM against public vulnerability databases (like the CVE list) and having a team ready to develop and push out patches as needed.
To stay compliant, your vulnerability management system should follow these basic steps:
- Identification: Regularly scanning your software for known flaws.
- Triage: Determining the severity of a discovered flaw and how it affects your product.
- Remediation: Developing a patch or a workaround to fix the security gap.
- Distribution: Ensuring the patch actually reaches the end-user, preferably through an automatic update mechanism.
- Reporting: Notifying the relevant EU agency if a vulnerability is being actively used by hackers.
This long-term commitment changes the financial model for many products. You have to factor in the cost of five years of software maintenance into the initial sale price of the hardware. From a quality technician’s perspective, this means we need to audit not just the product, but the company’s ability to support that product for half a decade.
And remember, the CRA doesn’t just ask you to fix bugs; it asks you to do it quickly. The 24-hour reporting rule for exploited vulnerabilities is incredibly strict. It requires a level of organizational readiness that most small-to-medium enterprises (SMEs) simply don’t have yet. Building this response capability should be a top priority for 2026.
CRA Risk Categories: Do You Need a Third-Party Audit?
Not all products are created equal in the eyes of the CRA. The regulation uses a risk-based approach to determine how much oversight a product needs. This is very similar to the “Classes” we see in medical device regulations. Understanding where your product fits is essential because it determines whether you can “self-certify” (like a standard CE mark process) or if you must pay for an expensive third-party audit from a Notified Body.
The vast majority of products (roughly 90%) fall into the Default category. This includes most consumer electronics, smart home gadgets, and simple software. For these, a manufacturer can perform their own internal assessment, document their compliance, and apply the CE mark. This is designed to reduce the burden on small businesses and avoid slowing down innovation in low-risk sectors.
CRA Categories
However, if your product performs a security-sensitive function, you move into the “Important” categories. This is where the 2026 Notified Body milestones become critical.
- Class I (Important): Includes things like password managers, network interfaces, and browsers. These are tools where a failure has a significant impact but isn’t necessarily catastrophic.
- Class II (Important): Includes firewalls, routers, and “operating systems” for critical sectors. These require a full third-party assessment.
- Critical: This is the highest tier, reserved for products that are essential for the most sensitive infrastructure (like smartcard chips or certain high-level industrial controllers).
The “Critical” list is managed directly by the EU Commission and can be updated as technology evolves. As a safety technician, I always advise clients to aim for a higher standard than they think they need. The gap between a “Default” product and a “Class I” product is often just a few extra layers of documentation and testing. If you are on the borderline, err on the side of caution.
But be warned: the penalties for misclassifying your product are severe. If you self-certify a product that should have had a third-party audit, you are essentially selling a non-compliant product. This opens you up to the massive fines we discussed earlier—up to €15 million or 2.5% of global turnover. It’s better to spend the money on an auditor in 2026 than on a legal defense team in 2027.
Practical Tips for Your CRA Compliance
Transitioning to this new era of digital compliance doesn’t happen overnight. It requires a cultural shift within your organization. As someone who has spent years on the factory floor and in testing labs, I’ve seen where these transitions usually fail. It’s rarely a lack of technical skill; it’s usually a lack of communication between the “safety” people and the “coding” people.
To help bridge that gap, here are some actionable tips you can implement starting today. These are created to guide you beyond the theory of the CRA. They aim to place you into the practical reality of making secure products.
The flow
- Appoint a “Cyber-Safety Liaison”: Someone who understands both hardware safety standards and software security. They will be the bridge between your engineering teams.
- Audit Your Supply Chain: Ask your component suppliers for their SBOMs now. If they can’t provide them, start looking for new suppliers who are CRA-ready.
- Automate Your Patching: If possible, design your products with over-the-air (OTA) update capabilities. It is the only way to manage vulnerabilities effectively at scale.
- Clean Up Your Code: Use automated tools to scan for “low-hanging fruit” vulnerabilities like buffer overflows or hardcoded credentials.
- Document Everything: In the eyes of a regulator, if it isn’t documented, it didn’t happen. Treat your security logs with the same reverence you treat your lab test reports.
And finally, don’t be afraid to challenge your developers. If an engineer tells you that a certain security feature is “too hard” to implement or will “slow down the launch,” remind them of the €15 million fine. Compliance is a non-negotiable part of the product’s specification. In 2026, a fast launch is worthless if the product is illegal to sell six months later.
By following these tips and staying informed through resources like ‘Regulatory Decoded’, you can turn the CRA from a bureaucratic nightmare into a standard operating procedure. We’ve mastered electrical safety, and we’ve mastered EMC; we will master cyber resilience too.
Conclusion: Don’t Wait Until 2027
The reporting requirements starting in September 2026 mean that manufacturers need their security incident response teams (CSIRTs) ready by mid-year. It’s a core feature of the product lifecycle.
Cyber Resilience Act (CRA) FAQ
This section defines the Act and its primary objectives for digital products.
EU has pubblished an official CRA FAQ page, below you can find some of the most asked questions:
The CRA is an EU regulation that introduces mandatory cybersecurity requirements for products with digital elements throughout their whole lifecycle.
The main aim is to ensure that hardware and software products are placed on the market with fewer vulnerabilities and that manufacturers remain responsible for security throughout a product’s life.
It is a “secure by design” framework that forces manufacturers to meet baseline security standards before selling digital goods in the EU.
Non-compliance can lead to significant administrative fines, often calculated as a percentage of a company’s total worldwide annual turnover.
The CRA is a regulation, meaning it applies directly and uniformly across all EU member states without needing to be transposed into national law.
Category 2: Regional Context and the UK
This section explores how these laws apply specifically to the UK market and upcoming changes.
While the CRA is an EU initiative, the UK has its own similar frameworks, such as the Product Security and Telecommunications Infrastructure (PSTI) Act, to regulate the security of consumer connectable products.
The mind map highlights a focus on “Cyber Law 2025 UK,” which likely refers to the full implementation and enforcement phases of existing security acts like the PSTI.
Category 3: Comparisons (NIS2, GDPR, & Standards)
NIS2 focuses on the resilience of entities (like energy or health providers) and their services.
CRA focuses on the security of products (the actual hardware and software).
No. GDPR is focused on data privacy and the protection of personal information, while the CRA is focused on product security and the prevention of cyberattacks on hardware/software.
IEC 62443 is a series of international standards for industrial automation security, whereas the CRA is a legal regulation that may point to such standards for compliance.
ISO 21434 is specifically tailored to cybersecurity in automotive engineering, while the CRA has a much broader scope covering almost all digital products.
Category 4: Implementation and Pillars
Core concepts for achieving compliance and building a resilient framework.
Manufacturers must perform risk assessments, document security measures, ensure “secure by default” configurations, and report actively exploited vulnerabilities.
While definitions vary, they typically include: Identify, Protect, Detect, Respond, and Recover (often aligned with the NIST framework).
Certain products already covered by stricter regulations—such as medical devices, aviation equipment, or motor vehicles—may be exempt from specific CRA requirements.
