EU Cyber Resilience Act (CRA): Robustel Readiness

Robustel’s Cyber Resilience Act (CRA) programme builds on security processes that are already established and adds product-specific engineering work for the software branches identified in the readiness roadmap. This distinction is important: Robustel’s secure development process is already independently certified, while a number of product-level security capabilities are still being implemented, validated and assessed for the planned CRA delivery versions.

Product security requirements are being developed using product risk analysis and the technical requirements of IEC 62443-4-2 Security Level 2 (SL2) as engineering references. These requirements are applied by product model, hardware configuration and software branch, with final delivered capabilities confirmed through the applicable release and product-security documentation.

Secure development from requirements through maintenance

Robustel’s Cyber Security Development Process V1.0 is certified to IEC 62443-4-1:2018 Maturity Level 2. The certification covers security management, specification of security requirements, security by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidance.

In practice, this means cybersecurity requirements are incorporated throughout the development lifecycle rather than added only at final product testing:

• Requirements and risk analysis: identify product use, exposed interfaces, sensitive data and attack surfaces, then use threat analysis to define security requirements.
• Secure design: define authentication and authorisation, key protection, trusted updates, network protections and logging while reviewing hardware and software dependencies.
• Implementation and component management: review implementation and code, maintain component and version records and assess vulnerabilities affecting third-party components.
• Verification and independent assessment: test security functions, boundaries and abnormal conditions using vulnerability scanning, fuzzing and independent penetration testing where applicable.
• Release and ongoing maintenance: review unresolved security issues, release versions and deployment guidance, then feed new vulnerability information back into future requirements and updates.

Customer findings, security incidents and assessment results are also fed back into requirements, test cases and release controls so that significant software, hardware and component changes can be reassessed for security impact.

Product security baseline for CRA delivery versions

The current Robustel roadmap defines a common software-security baseline for the planned CRA delivery builds. Existing hardware platforms are expected to support these builds without a general hardware redesign, although the implementation and validation method varies by product architecture.

The planned baseline includes:

• Signed firmware and Secure Boot: Software authenticity and integrity are verified against the applicable trust anchor, with unauthorised firmware images rejected before execution.
• Anti-rollback protection: The compliance builds are designed to prevent a device from being deliberately downgraded to software versions that are no longer permitted by the security baseline.
• Protected storage of credentials and keys: Sensitive credentials and cryptographic material are protected in storage, using hardware-backed protection where the platform supports it.
• Secure default configuration: Default product configuration is being hardened to reduce unnecessary exposure, including removal of default passwords and disabling services that are not required.
• Hardened management interfaces: Management access is designed around protected protocols such as Hypertext Transfer Protocol Secure (HTTPS) and Secure Shell (SSH), together with role-based permissions and session-security controls.
• Secure software updates and recovery: Update packages are verified before installation, with the planned process including controlled installation and recovery behaviour if an update fails or is interrupted.
• Security event logging: Relevant security events are recorded and made available for review and export to support investigation and operational monitoring.
• Software component and vulnerability management: Machine-readable component inventories are combined with Robustel’s Product Security Incident Response Team (PSIRT) processes and security advisories to support identification, assessment and remediation of vulnerabilities.

These capabilities form the current engineering baseline. The roadmap itself notes that the requirements definition is based on an initial IEC 62443-4-2 benchmark and may be refined as the standards applied under the CRA become more clearly defined.

Trust anchors and software integrity

The method used to establish trust in authorised software varies between Robustel platforms.

Under the current roadmap, most R-series products use a software trust anchor, while products including the EG and MG series, EV8100, R1520LG, LG3120e, LG5120 and R5030 use a hardware chipset trust anchor. In either case, the objective is the same: establish a verifiable chain of trust so that authorised software can be validated and altered or unauthorised images can be rejected.

Validation is not limited to confirming that a legitimate firmware image installs successfully. Robustel’s product-security testing also considers rejection of tampered images, rollback behaviour, interrupted upgrades, recovery and the effect of security changes on customer applications and normal product operation.

Identity, access and network protection

Product-security requirements also address how devices and management services are accessed after deployment. Robustel’s engineering requirements include secure default settings, strong authentication, least privilege, session protection and protection of credentials and keys throughout storage, transmission, updates and device handover.

Network and remote-management validation examines exposed services, protected management connections, access controls, protocol configuration, remote-management privileges and malformed inputs. The objective is to reduce unnecessary attack surface without disrupting the industrial communications and operational functions for which the product is deployed.

For Robustel Cloud Manager Service (RCMS), security controls are assessed against the service and deployment boundaries of RCMS Cloud and RCMS Stack separately, including identity and permissions, protected communications, device identity, update management and customer account administration.

Component security and supply-chain transparency

CRA readiness also depends on understanding the software and hardware components incorporated into a product.

Robustel manages open-source components, third-party software and supplier firmware as part of its component inventory. A Software Bill of Materials (SBOM) is used to correlate known vulnerabilities with the relevant product version and determine whether a component-level issue creates an actual product-level exposure. For components maintained by external suppliers, Robustel coordinates with the supplier to obtain analysis, patches or mitigations and then assesses the impact on the complete product.

The CRA programme is also developing Hardware Bill of Materials (HBOM) evidence and uses component and supplier monitoring as part of the wider security-management process. This allows security assessments to remain tied to the hardware, software and component configuration actually being supplied rather than to a generic product-family description.