CRA security logging should capture product activity that is materially useful for understanding security events, particularly relevant access and modification activity. Manufacturers should define a product-specific event catalogue, include enough context for investigation, avoid unnecessary sensitive data, protect logs against tampering and verify the required user opt-out behaviour. Logging should support security without becoming uncontrolled telemetry collection.
Annex I Point 2(l) Combines Recording and Monitoring
Annex I Part I point 2(l) requires products with digital elements, on the basis of the cybersecurity risk assessment and where applicable, to provide security-related information by recording and monitoring relevant internal activity. The provision expressly includes access to or modification of data, services or functions. Security logging is the recording aspect of this requirement. The objective is not to capture every possible product event. Manufacturers should identify activity that has real security relevance and design records that can help users, administrators or security teams understand what happened when suspicious activity, misuse or compromise is investigated.
- Identify relevant internal activity.
- Record security-relevant access.
- Record important modifications.
- Provide enough context for investigation.
- Connect event selection to the cybersecurity risk assessment.
Start With a Security Event Catalogue
A useful logging design begins with a defined event catalogue rather than scattered log statements added by individual developers. The catalogue can identify event type, purpose, severity, required fields, data sensitivity, expected consumers and retention considerations. Events can include authentication attempts, privilege changes, administrative actions, access to high-value data, security configuration changes, update activity, integrity failures and other product-specific events. Not every product needs the same catalogue. A local consumer application, industrial controller and privileged-access system can have very different security-relevant activity.
- Define event identifiers.
- Define the security purpose of each event.
- Define required context.
- Classify sensitive fields.
- Identify the expected event consumer.
Access Events Can Be Security-Relevant
Point 2(l) specifically refers to access to data, services or functions. Manufacturers should identify access events whose recording can provide meaningful security information. Depending on the product, these can include successful and failed authentication, administrator access, access to protected data, use of privileged APIs, remote support sessions or access to security configuration. Recording every read operation can be unnecessary or technically impractical, so the cybersecurity risk assessment should guide event selection. The resulting records should distinguish routine authorised activity from events that can help identify possible unauthorised access or abuse.
- Identify sensitive access paths.
- Record relevant privileged access.
- Consider failed access attempts.
- Capture useful identity or session context.
- Avoid recording sensitive secrets.
Modification Events Can Support Investigation
Annex I point 2(l) also expressly mentions modification of data, services or functions. Important changes can include account privilege changes, security-policy changes, configuration updates, enabling or disabling services, changes to access controls, software updates or modification of high-value product data. Logs should provide enough information to identify what changed and, where appropriate, which identity or process initiated the change. This does not require storing the full original and modified value in every case. Doing so can create new confidentiality or data-minimisation problems. The event design should capture the information necessary for the security purpose.
- Record security-sensitive configuration changes.
- Record privilege changes.
- Record important service-state changes.
- Identify the responsible actor where appropriate.
- Avoid unnecessary sensitive before-and-after data.
Logging Should Not Create a New Confidentiality Problem
Security logs can become highly sensitive datasets. They may contain user identifiers, network addresses, filenames, resource names, system state or security configuration. Poorly designed logging can also capture passwords, session tokens, private keys or full sensitive payloads. Manufacturers should review log fields against confidentiality and data-minimisation requirements. Secrets should not be recorded simply because they are available to the application at event time. Where identifiers are needed, teams should determine the level of detail necessary for the security purpose. Access to log data should also be controlled because logs can reveal valuable information about product operation.
- Do not log passwords.
- Do not log cryptographic private keys.
- Avoid unnecessary access-token capture.
- Minimise sensitive payload content.
- Restrict access to security logs.
Security Logs Need Integrity Protection
An attacker who compromises a product can attempt to erase or alter evidence of the activity. Manufacturers should therefore consider how important security records are protected against unauthorised modification or deletion. The appropriate design can include restricted permissions, append-oriented storage, remote forwarding, cryptographic integrity mechanisms or protected logging services. The CRA does not prescribe one logging architecture. The manufacturer should select controls proportionate to the risk and the value of the records. Where logs leave the product, the transmission and destination should also receive appropriate confidentiality and integrity protection.
- Restrict log modification.
- Restrict log deletion.
- Protect forwarded logs.
- Consider tamper detection where appropriate.
- Test access to log storage.
Timestamps and Context Affect Log Usefulness
A security event without useful context can be difficult to investigate. Depending on the product, important context can include time, event type, identity, session, component, target resource, result and relevant error information. Time accuracy matters when events from several components need to be correlated, although the appropriate clock architecture depends on the product. Manufacturers should also consider behaviour when time is unavailable or manipulated. The goal is not to create a universal schema but to provide enough consistent context that relevant events can support security analysis rather than produce isolated text messages with ambiguous meaning.
- Record usable event time.
- Identify the relevant component.
- Identify actor or session where appropriate.
- Record success or failure.
- Use consistent event identifiers.
Retention Should Follow the Security Purpose
Point 2(l) does not establish a universal log-retention period for every product. Manufacturers should determine retention based on product design, security purpose, storage constraints, risk and other applicable legal requirements. A very short retention period can make investigation impossible, while indefinite retention can create unnecessary data exposure. Products with limited local storage may rely on configurable retention, rotation or secure export. Retention design should therefore be documented alongside event purpose and user controls rather than treated as an accidental consequence of available disk space.
- Define retention deliberately.
- Consider investigation needs.
- Consider product storage constraints.
- Use controlled rotation where appropriate.
- Document external retention dependencies.
The User Opt-Out Mechanism Must Be Considered
Annex I point 2(l) includes an opt-out mechanism for the user. Manufacturers should therefore identify how the user can exercise that option and what activity is affected. The product should make the behaviour understandable enough that engineering and compliance teams can verify it. The existence of an opt-out should not be silently ignored because logging is considered useful to the manufacturer. At the same time, the precise implementation should be assessed in the context of the product and applicable legal requirements. Teams should document the default state, opt-out path, resulting logging behaviour and any security implications.
- Define the default logging state.
- Provide the required user opt-out mechanism.
- Document which recording is affected.
- Verify opt-out behaviour.
- Explain relevant security consequences where appropriate.
Evidence for CRA Security Logging
Evidence can include the security event catalogue, logging architecture, field definitions, data-classification review, log-access controls, retention design, opt-out specification and test results. Security testing should confirm that expected events are generated and that sensitive secrets are not exposed. Tests can also verify whether unauthorised users can modify or erase important records. The evidence should identify the product version and configuration because event behaviour often changes between releases. Product changes that introduce new sensitive functions should trigger review of whether new security-relevant events are required.
- Security event catalogue.
- Logging architecture.
- Event-field specification.
- Sensitive-data review.
- Log protection evidence.
- Opt-out tests.
- Version-specific logging verification.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.