Deep Dive: CRA Requirement (l) – Logging of Security-relevant Activity

Security incidents cannot always be prevented, which makes it critical to monitor what is happening inside a product. Requirement (l) ensures that connected devices provide this visibility by requiring logging and monitoring of security-relevant events. Requirement (l), one of the 13 essential requirements of the Cyber Resilience Act, states:

“provide security-related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user”

This requirement ensures that connected products enforce protections and make security events visible. Logging and monitoring are essential for detecting intrusions, troubleshooting incidents, and demonstrating compliance. At the same time, the CRA acknowledges user autonomy by requiring an opt-out mechanism, balancing transparency with privacy and usability.

What This Requirement Means

Imagine a vehicle manufacturing plant where robotic welding cells or conveyor systems are not monitored. A single misconfiguration or controller failure could stop the entire production line, with downtime costs reaching 2 million euros per hour. Monitoring internal activity in connected products works the same way: without visibility, intrusions or faults remain unnoticed until production is disrupted, and identifying the root cause becomes extremely difficult.

This requirement demands that products keep records of relevant activity, such as access to sensitive data, configuration changes, or modifications to services and functions. These records must be reliable, tamper-resistant, and useful both for operators who need to maintain systems and for regulators verifying compliance.

The inclusion of an opt-out mechanism is important. Users must have the choice to limit monitoring, especially when it could impact privacy or performance. But the default expectation is that monitoring is active, providing visibility unless explicitly disabled.

Relevant Standards and Guidelines

Logging and monitoring are covered in various established frameworks:

• EN IEC 62443-3-3 and 4-2 (industrial systems): Define requirements for logging, audit trails, and monitoring in industrial environments.

• ETSI EN 303 645 (consumer IoT): Requires devices to record security-relevant events and provide users with transparency.

• ISO/IEC 27001 and 27002 (general IT): Includes controls for logging, monitoring, and incident detection.

Most standards focus on enterprise IT or industrial systems and provide little guidance on implementing logging and monitoring in constrained embedded devices. They also do not fully address the balance between user opt-out options and maintaining a baseline of security-relevant visibility. CRA Requirement (l) will therefore likely drive harmonised standards tailored for IoT and OT contexts.

How to Approach Implementation

Meeting this requirement means building structured logging and monitoring into the product’s lifecycle and runtime behaviour.

Key capabilities to consider include:

• Recording of access to sensitive data, changes to configuration and modification of services

• Timestamped, tamper-resistant logs that can be audited

• Monitoring mechanisms to detect anomalies or unauthorized activity

• Secure storage and transmission of logs to ensure availability and integrity

• Opt-out controls for users with a clear explanation of what is disabled and the implications

In industrial IoT and OT systems, monitoring is critical for detecting malicious activity and supporting root cause analysis. Logs should be forwarded to central security information and event management (SIEM) systems, while retaining local records to ensure availability during connectivity disruptions. Ensuring integrity, segmentation, and role-based access to logs are necessary to prevent them from becoming an attack vector.

For embedded IoT devices, limited storage and compute resources pose challenges. Manufacturers should implement lightweight logging that captures only essential events, use circular buffers to manage limited storage, and forward logs to backend services when connectivity is available. Even small devices must be able to record security-critical events, such as configuration changes or failed login attempts.

Critical considerations include balancing log depth with performance, ensuring logs cannot be tampered with by attackers, and making opt-out mechanisms transparent so users understand the trade-offs.

Compliance and Strategic Considerations

From a compliance perspective, Annex VII requires that the technical documentation describes what activities are logged, how logs are stored or transmitted, and how monitoring is achieved. Annex II requires that the user guide explains available configuration options, including how opting out of monitoring may affect security visibility.

When choosing between in-house development and vendor platforms, consider long-term integration. There are many mature open-source tools for logging as well as established vendors that offer commercial solutions. Depending on your specific requirements, the size of your team, and the scale of your deployment, you should evaluate which option fits best. Frameworks and platforms provide the infrastructure for managing logs, but manufacturers must still implement logging within their software components to capture the security-relevant events that matter for their products.

Requirement (l) strengthens the role of logging by making it clear that security-related events must also be recorded in IoT and OT products. Logging itself is already a well-established practice for operations and troubleshooting, but under the CRA it becomes equally important for security and compliance. Manufacturers that implement reliable, transparent logging will not only meet regulatory obligations but also increase customer trust and operational resilience.

In our next post, we will explore Requirement (m): Secure deletion and data transfer, which defines how products must ensure the secure deletion of data and configurations, as well as the secure transfer of data.

Previous Blog CRA Requirement (k): https://www.tributech.io/blog/cra-requirement-k-mitigation-of-incident-impactNext Blog CRA Requirement (m):https://www.tributech.io/blog/cra-requirement-m-secure-deletion-and-data-transfer