The Cyber Resilience Act (CRA), an EU cybersecurity regulation established in December 2024, is now defining new market-entry standards for products with digital elements. For device manufacturers, software suppliers, and system integrators, the message is clear: security is no longer an add‑on—it is a specification of both the product and its processes. Companies need to prove their security strengths in a verifiable way, covering everything from design and development to operations and vulnerability management.

Focusing on Two Core Demands: Secure by Design and Vulnerability Handling

The CRA addresses a broad range of products with digital elements, intending to enhance overall cyber-resilience across the market. It specifies not only technical requirements but also manufacturer responsibilities, incident reporting, and update obligations. Simply put, compliance is now a continuous engineering process, not just a one-time audit. Verifiable security capabilities allow organizations to lower risks and penalties, while also building market differentiation and customer trust. Two dimensions are especially critical:

1. Beyond encryption and passwords: security engineering grounded in secure by design

When we talk about secure by design, it is not just about adding a few security options to a feature list. The core idea involves placing security decisions at the front end of development, in requirements and architecture, and integrating control mechanisms throughout the entire development life cycle. Several requirements in Annex I Part I of the CRA align with this strategy, such as:

• No known exploitable vulnerabilities (Annex I Part I 2(a)): Before release, products must not contain known, exploitable vulnerabilities. This requires manufacturers to integrate vulnerability scanning, remediation, and verification into production.
• Secure defaults and secure configuration (Annex I Part I 2(b)): Products must be secure‑by‑default at launch and capable of restoring the original state. Therefore, products should not ship with weak encryption or high‑risk services left enabled.
• Access control and protection against unauthorized access (Annex I Part I 2(d)): Implementing appropriate control mechanisms, including authentication, access and identity management, and the ability to report unauthorized access.
• Protection of data confidentiality (Annex I Part I 2(e)): Applying state‑of‑the‑art mechanisms for data at rest and in transit, such as modern cryptography and related techniques.
• Protection of the integrity of data and commands (Annex I Part I 2(f)): Protecting data, commands, code, and configurations from unauthorized modification and being able to report tampering.
• Data minimization by purpose (Annex I Part I 2(g)): Processing only data that is necessary and relevant to the product’s function.

With these clauses, security requirements shift from being about what’s achieved to how it’s done. Beyond having specific security features, you are required to provide engineering evidence showing their correct design, implementation, testing, operation, and traceability across their entire life cycle.

2. Vulnerability handling is more than patching; it's an end‑to‑end responsibility chain

Vulnerability handling is inherently a continuous cycle of intake, analysis, remediation, notification, and update release, and it should be synchronized with incident reporting. Under the CRA, it falls within Annex I Part II, “Vulnerability handling requirements,” with key points including:

• Vulnerability identification and component visibility (Annex I Part II 1): Manufacturers must identify and record vulnerabilities and components, and provide a software bill of materials (SBOM) in a commonly used, machine‑readable format.
• Establish and implement a coordinated vulnerability disclosure (CVD) policy (Annex I Part II 5): Manufacturers must have a public vulnerability disclosure policy and ensure coordination mechanisms for related disclosures.
• Provide vulnerability reporting contact points (Annex I Part II 6): Taking measures to facilitate sharing of potential vulnerability information for products with digital elements and their third‑party components, including providing a reporting contact.
• Timeliness and transparency of update releases (Annex I Part II 8): Regarding identified security issues, prompt publication of security updates is required, along with necessary user notices and action guidance.

In practical terms, this means building standardized intake channels, classification and remediation timelines, regression testing, and secure distribution mechanisms, supported by consistent notifications and recommendations for customers. Furthermore, vulnerability management needs to encompass the entire supply chain, ensuring third-party and open-source components align with remedial efforts and proof of completion to prevent a single point of faiNormallure.

Supplier Upgrade: How Processes, Evidence, and Supply‑chain Governance Convert to Market Trust

The CRA essentially calls for better suppliers rather than just more secure products. Companies need to:

• Establish a comprehensive Secure Development Life-cycle (SDL), embedding security controls across the product life cycle: clause‑mapped requirements, threat modeling, code analysis, penetration testing, and update management. Keep traceable evidence aligned to Annex I Part I.
• Build end‑to‑end vulnerability management from intake and remediation to notification and update release, aligned to Annex I Part II, to demonstrate speed, transparency, and consistency when addressing vulnerabilities and incidents.
• Implement supply‑chain governance, maintaining SBOMs, conducting dependency risk analysis, and operating a coordinated vulnerability disclosure (CVD) process to ensure third‑party components do not create compliance breakpoints.
• Develop customer communication strategies by maintaining clear policies and auditable records across security advisories, support guides, and version life cycles (including end‑of‑maintenance), turning technical capability into visible trust.

Make Security an Engineering Capability, Not a Compliance Checklist

For device manufacturers, the key is to implement the CRA clauses across their SDL and vulnerability management controls, while keeping auditable records. By doing this, security evolves from a passive compliance task into a competitive advantage that is repeatable, measurable, and justifiable.

System integrators should verify supplier security through engineering practices and evidence, not just statements or checklists. Long‑term resilience and reliability for critical systems can only be achieved by working with vendors that prioritize security as a core engineering discipline.

Visit our microsite to learn more about Moxa's commitment to the CRA.