Who in the company is responsible for ensuring compliance with the CRA requirements, and how is it ensured that this responsibility is clearly assigned?

The Cyber Resilience Act (CRA) is a legal compliance requirement affecting all products with digital elements which shall be sold to the EU market in future. It involves substantial organizational and technical effort and requires investments into processes and product development. Therefore, the decision of targeting compliance must be taken by company management.

Based on this decision, different companies may have different organizational setups for implementation and control. At Moxa, the management has established a clear framework, including cross-functional expert groups from R&D, Product Security, Quality, and Product Management to manage CRA compliance.

This ensures that ownership for CRA-related activities is traceable from corporate policy down to individual product development and production.

Which pragmatic methods can be used to demonstrate CRA compliance when resources are limited?

Moxa uses structured checklists and templates to map product features and processes against CRA requirements in a consistent and transparent way.

These checklists support a risk-based prioritization of actions, ensuring that high-impact requirements and vulnerabilities are addressed first, even when resources are limited. The results feed into technical documentation and internal conformity assessment.

How can security requirements and design decisions be documented across the entire product lifecycle?

Security requirements and design decisions are managed through Moxa’s Secure Development Lifecycle (SDL) process.

Within the SDL, security requirements, architecture and design choices, implementation notes, and test results are recorded in lifecycle artefacts (e.g. requirements specifications, design reviews, change requests, and test reports). This procedure ensures that CRA-relevant decisions are documented from initial concept through verification and validation, and it demonstrates Moxa‘s commitment to the continuous improvement of our Secure Development Lifecycle, which supports the stability and competitiveness of our products.

How is technical documentation structured so that CRA compliance can be clearly demonstrated?

The technical documentation is built from the outputs of the SDL and related product security processes.

It typically consolidates the risk assessment, security requirements, design and implementation details, test evidence, vulnerability and update handling, support period, and SBOM information. Responsible functions are defined per document type, and version control ensures that changes to CRA-relevant information are tracked over the product lifetime.

Is there a formal declaration that products are CRA-compliant? Who prepares and reviews this declaration?

Under the Cyber Resilience Act, every product in scope requires a conformity assessment and an EU Declaration of Conformity.

Depending on the product category and risk level, the applicable conformity assessment can range from internal self-assessment based on our own production controls up to third-party conformity assessment or product certification by a notified body, as required by the CRA.

The regulation specifies different conformity assessment procedures:

For the majority of products in the default category and for those classified as Important Class I, manufacturers can perform a self-assessment based on their internal production controls and technical documentation.

For products classified as Important Class II, a mandatory third-party assessment conducted by a notified body is required.

So-called Critical Products, which are essential to critical infrastructure, must pass a specific European Common Criteria (EUCC) certification scheme.

In all cases, Moxa, as a manufacturer, remains responsible for issuing and maintaining the EU Declaration of Conformity and the CE marking, based on supporting technical documentation and, where applicable, independent assessment reports. This is an established process for us. For example, we already manage these requirements for our wireless products under the Radio Equipment Directive (RED). EU Declarations of Conformity for these products are made publicly available on our company website.

How is supplier security evaluated, and how are the results integrated into the product documentation?

Supplier security is assessed using security and quality criteria derived from relevant standards, such as EN IEC 62443-4-1 / 4-2 and related amendments.

These criteria are reflected in supplier selection, contracts, and component approvals. Information about critical third-party components, their security properties, and support commitments is then captured in the SBOM, risk assessment, and technical documentation for the product.

Which security tests should companies perform (e.g., penetration tests, automated scans), and how are the results documented?

The choice of tests is product- and risk-specific. Depending on the risk profile, Moxa applies a combination of static and dynamic code analysis, automated vulnerability scans, security functional tests, and targeted penetration tests which refer to IEC 62443-4-1.

The performed tests, their scope, and their results are recorded in test plans and test reports, which are part of the SDL artefacts.

What does “Secure by Default” mean, and how is it ensured that products are delivered in this state?

“Secure by Default” is a fundamental design principle to ensure that a product is shipped in a secure state for its intended use and security context. The term “default” refers to the configuration when the product is first delivered or after a factory reset.

This principle aims to design and configure products so that they are adequately secure upon operation. In practice, this means products are delivered with a restricted attack surface and minimal privileges. For some devices, this secure state is active immediately, while others require a mandatory, guided setup process to be put into service, for example by forcing the user to change a default password before the device becomes fully operational.

These secure configurations are defined and validated as part of the Secure Development Lifecycle (SDL). Clear instructions on these settings and further hardening options are provided in product security guidelines and installation manuals to support customers in maintaining an appropriate security posture.

For particularly critical products: what type of independent review or assessment is conducted, and how is it documented?

Under the CRA, “Critical Products with digital elements” are subject to stricter conformity assessment procedures, mandatorily involving a notified body applying the European Cybersecurity Certification Scheme (EUCC). This new scheme aims to harmonize cybersecurity assessments and certifications in Europe.

How is traceability from requirements to tests ensured (documented evidence of “requirements-to-test”)?

At Moxa, traceability is implemented as part of SDL and IEC 62443-aligned development practices.

Security requirements are linked to corresponding design elements and test cases in the development tools, so that each requirement can be traced to one or more tests and their results. This provides documented evidence of “requirements-to-test” coverage across our entire product, including all functions relevant to the CRA.

Which documents contain information on secure default settings, hardening, updates, incident handling, and product end-of-life?

Information on secure default settings and hardening is provided in installation manuals, configuration guides, and security or hardening guides.

At Moxa, details on software and firmware updates, vulnerability and incident handling, and product end-of-life (including support time windows) are described in product documentation and company-level lifecycle policies. As CRA-related harmonized standards become available, these documents will be aligned accordingly.

How can it be demonstrated that product decisions take CRA requirements into account (design reviews, risk analyses, patch strategies)?

Speaking of Moxa, Product decisions are demonstrated to take CRA requirements into account through documented, auditable processes integrated into our Secure Development Lifecycle (SDL).

For example, design reviews include mandatory security checkpoints, with evidence documented in threat models and formal sign-off records. Additionally, the public vulnerability management policy defines remediation timelines and governs the patch strategy, ensuring it aligns with CRA requirements.

These artefacts create a clear, traceable link from requirements to our product decisions. The evidence is consolidated in the product’s technical documentation, which forms the basis for the EU Declaration of Conformity and the CE marking.