A suspected China-aligned threat activity cluster has been observed exploiting Roundcube webmail software belonging to physics and engineering departments of U.S. and Canadian universities as part of a new campaign.

The activity involves the exploitation of now-patched, critical security flaws in the open-source email solution, such as CVE-2024-42009 (CVSS score: 9.3), to siphon credentials,

The Hacker News – ​Read More

In this second part, we demonstrate how a Cyber Resilience Act (CRA) assessment is performed in practice. Using a low-cost IP camera as an example, we show how a product is classified, how threats are modelled, how hardware and firmware are analysed, and how compliance gaps against IEC 62443-4-2 can be identified.

You may want visit the Cyber Resilience Act – Part I, where we also explored the legal landscape of CRA and discuss the shifting responsibilities for digital product manufacturers, establishing that CRA compliance is a fundamental requirement for market access in the EU.

From Threats to Requirements

Consider a common consumer product: a budget IP camera sourced via marketplaces such as Wish or Temu.

The journey toward CRA readiness begins with defining the device’s attack surface through threat modelling for example using the STRIDE methodology, which categorizes threats into Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Threat modelling ensures that subsequent testing focuses on realistic attack scenarios and the security controls that matter most for the product, rather than relying on a generic checklist.

We map the ecosystem into three critical security zones: the device layer (hardware and firmware), the network layer (data in transit), and cloud integration (remote management and mobile applications). Given the nature of a low-cost consumer device, we assign lower priority to Denial of Service and Repudiation, while focusing on high-impact vectors such as Spoofing (identity theft), Information Disclosure (unauthorized video access), Tampering (firmware manipulation), and Elevation of Privilege (unauthorized administrative control).

The resulting threat profile provides the foundation for the remainder of the assessment. With a clear understanding of the attack surface and the most relevant risks, the next step is determining the device’s classification under the Cyber Resilience Act (CRA) and mapping the corresponding security requirements under IEC 62443-4-2.

Classifying the Product

For this scenario, we follow Annex III of the CRA and classify this IP camera as an “Important Class I” product. This classification determines which CRA obligations apply and serves as the basis for selecting the appropriate security requirements that must be verified during the assessment. As a result, its security requirements extend beyond basic protection against accidental failures. In this context, targeting Security Level 2 (SL 2) under IEC 62443-4-2 provides a suitable baseline, offering a defense-in-depth approach against intentional but non-targeted attacks and commonly available exploitation techniques.

The selected product class and target security level define the controls that must be validated. These requirements are then translated into practical test cases, guiding the technical assessment in a structured and repeatable manner.

Performing the Technical Assessment

Based on the defined test cases, we now validate whether the device actually implements the required security controls. This involves both non invasive testing, such as network traffic analysis, and hardware level examination to assess the security mechanisms built into the product.

We begin by deploying the device in a controlled laboratory environment to observe its behavior and analyze network communications. We then move to hardware level analysis to verify the security mechanisms implemented within the device. This includes disassembling the device, extracting and analyzing the firmware from flash memory, identifying debug interfaces, and connecting a serial adapter to observe the boot process and eventually obtain low-level system access for further investigation.

The laboratory assessment produced a comprehensive set of observations covering both hardware and software security. We can now evaluate these findings against the target security level and identify where the device meets or falls short of the required controls.

Security Findings

Following the completion of the analysis and execution of the defined test cases, multiple security weaknesses were identified across authentication, authorization, and integrity controls, with severities ranging from high to low. These include device enumeration vulnerabilities, unauthenticated access to video streams over the local network, unauthenticated UART-based shell access via a physical interface, and the absence of firmware integrity protections, among others.

We now evaluate the identified vulnerabilities against the target security level to determine whether the product satisfies the required security controls.

Overall, the device fails to satisfy any recognized security level requirements. In particular, it does not meet seven mandatory test cases required for Security Level 1, nor does it comply with an additional five criteria necessary to achieve Security Level 2. The only area demonstrating full compliance is Data Confidentiality (FR 4), which passes all test cases for both Security Level 1 and Security Level 2.

Taken together, these findings indicate that security was not systematically considered during the product’s development. Several weaknesses affect fundamental security controls required to protect the device against common attack scenarios.

While the identified vulnerabilities highlight concrete technical weaknesses, their real value lies in demonstrating where the product fails to satisfy the applicable CRA and IEC 62443 requirements. This provides manufacturers with a clear basis for prioritizing remediation and planning their path toward compliance.

This is not simply a penetration test. Every assessment activity is driven by the applicable CRA requirements and the corresponding IEC 62443 security controls.

From Findings to CRA Readiness

This sample assessment illustrates how a structured, CRA-focused security evaluation can be applied in practice, spanning from threat modelling and system classification through to hands-on technical validation and security testing. The accompanying sample report provides a detailed breakdown of the methodology, the identified vulnerabilities, and the resulting compliance assessment.

The Cyber Resilience Act represents a fundamental shift in how digital products must be engineered and maintained for the European market. As demonstrated through this assessment, achieving CRA readiness requires more than identifying vulnerabilities. It requires a structured methodology that translates regulatory requirements into measurable technical controls, validates their implementation, and provides manufacturers with a clear roadmap toward compliance.

Sample Report report_99200_IP_Camera_A2308_v1.0.pdf

Compass Security Blog – ​Read More

BeyondTrust has released updates to address two critical security flaws affecting Remote Support (RS) and Privileged Remote Access (PRA) products that, if successfully exploited, could allow unauthenticated attackers to take control of susceptible devices.

The vulnerabilities are listed below –

CVE-2026-40138 (CVSS score: 9.2) – A pre-authentication vulnerability exists in the

The Hacker News – ​Read More

A ransomware-as-a-service gang, an online foreign extremist group and drug traffickers were separately the targets of offensive operations in 2025, according to Canada’s Communications Security Establishment.

The Record from Recorded Future News – ​Read More