The Cyber Resilience Act (CRA) requires products with digital elements, where applicable and on the basis of their cybersecurity risk assessment, to record and monitor relevant internal activity. Annex I Part I point 2(l) makes logging and monitoring part of product cybersecurity rather than merely an operational preference. It does not require manufacturers to collect every event a product can generate. The practical task is to identify activity that matters for security, make those records useful and trustworthy, and show why the chosen controls are appropriate to the product's risks.
For product teams, that means deciding what must be observable before implementation is complete. Authentication failures, privilege changes, security-configuration changes, update events, integrity failures and suspicious use of exposed interfaces may all matter, depending on the product. The exact event set should follow from the cybersecurity risk assessment and architecture rather than from a generic logging checklist.
The CRA's main product requirements apply from 11 December 2027. Manufacturers can use the implementation period to make security observability part of product design, verification and lifecycle evidence instead of trying to reconstruct it during conformity work.
What Annex I actually requires
Annex I Part I point 2(l) requires products, based on the cybersecurity risk assessment and where applicable, to record and monitor relevant internal activity, including access to or modification of data, services or functions. The provision also requires an opt-out mechanism for users, unless separate Union or national law applies.
Three parts of that wording are important.
First, the requirement is risk-based. A product does not become better aligned with the CRA simply by producing a larger volume of logs. Telemetry should correspond to relevant threats, security controls and security-sensitive operations.
Second, the text covers both recording and monitoring. Recording creates evidence of events. Monitoring makes relevant activity observable so that suspicious or security-significant behaviour can be detected or investigated. Depending on the product, monitoring may be local, remote, periodic or event-driven.
Third, the requirement is not limited to login events. Access to or modification of data, services and functions can include many product-specific actions that matter to the security model.
Start with security-relevant events
A useful event catalogue begins with the risk assessment and the product's trust boundaries. For each identified threat or important security control, ask what activity would help demonstrate that the control operated, failed or was challenged.
Depending on the architecture, useful event categories can include:
- successful and failed authentication attempts;
- account, role and privilege changes;
- creation, rotation, revocation or failure of credentials;
- access to security-sensitive data or functions;
- changes to security configuration;
- enabling or disabling interfaces, services or remote access;
- software, firmware and security-update events;
- integrity-verification failures;
- repeated rejected requests or abnormal use of exposed interfaces;
- recovery, reset and factory-service operations; and
- security-control failures that materially change the product's protection state.
These are engineering examples, not a mandatory CRA event list. A manufacturer should select events because they are relevant to the product's risks, intended purpose and reasonably foreseeable use.
Record enough context to make an event useful
An event that says only authentication failed may be too weak for investigation. At the same time, a record that captures excessive personal or secret data creates additional risk.
For each event type, define the minimum context needed to interpret it. Useful fields may include:
- event type and outcome;
- a reliable time reference where the product supports one;
- affected function, service or component;
- relevant account, role or pseudonymous identity reference;
- source interface or connection context;
- security state before and after a change; and
- a correlation identifier that links related events without copying sensitive content into every record.
Avoid logging passwords, private keys, authentication tokens or other secrets. Sensitive log data should itself be treated as security-relevant information and protected accordingly.
Protect the logging mechanism and its records
Logs are useful only if teams can trust them. An attacker who can silently disable recording, erase evidence or rewrite events may defeat the purpose of the control.
The required safeguards depend on the product, but engineering teams should consider:
- who may read, export, configure or delete security records;
- whether privileged users can disable monitoring without an observable trace;
- how records are protected against unauthorised modification;
- what happens when storage is full or unavailable;
- whether clock changes can make event ordering misleading;
- how log export is authenticated and protected; and
- whether failure of the logging subsystem affects other product functions.
These decisions should be explicit. A design that merely states that the product "has logs" does not explain whether those records remain reliable under the threats identified in the risk assessment.
Treat monitoring as a product decision
Monitoring does not necessarily mean operating a cloud security operations centre for every product. The appropriate model depends on product architecture and risk.
A device may expose security events locally to an administrator. An enterprise product may support forwarding selected events to the customer's monitoring system. A manufacturer-controlled remote service that forms part of the product may monitor service-side events. Some products may combine these approaches.
The important design question is whether relevant activity can be observed and acted on in the intended operating model. Document which party is expected to monitor which events, what the product itself detects, and what remains the responsibility of the operator or deployment environment.
Account for the user opt-out requirement
Annex I Part I point 2(l) explicitly requires an opt-out mechanism for users, except where separate Union or national law applies. Product teams should therefore avoid designing optional security monitoring as an irreversible hidden behaviour.
The implementation should define what the user can disable, how the choice is presented, and what security consequences follow. If some recording is required for another legal reason, document the legal basis and distinguish it from optional CRA-related monitoring rather than treating all telemetry as one undifferentiated feature.
This is also a reason to separate security-event design from analytics and marketing telemetry. Different purposes can carry different technical and legal requirements.
Verify logging instead of assuming it works
Logging controls should be tested like other security mechanisms. Verification can include triggering defined events and checking that the expected records are produced with the required context.
Useful tests include:
- trigger each high-priority security event and verify its record;
- attempt unauthorised access to log configuration and stored records;
- test behaviour when storage or the monitoring destination is unavailable;
- verify ordering and timestamps across restart or clock changes where relevant;
- exercise user opt-out behaviour and confirm the documented result;
- verify that secrets and unnecessary sensitive data are not exposed; and
- confirm that updates do not silently remove required event coverage.
For release evidence, retain the event catalogue, design rationale, representative test results and known limitations. Those records help show that the logging design is connected to the actual product and risk assessment rather than being a generic policy statement.
Keep logging evidence tied to product changes
Security telemetry changes as products change. A new API, administrative role, remote service or recovery path may introduce events that did not exist in the previous release. A removed interface may make old event requirements obsolete.
That makes logging a lifecycle concern. Teams should review the event catalogue when threat models, access-control models or product architecture change, and should connect verification results to the release in which the behaviour was tested.
This is where evidence management becomes operationally difficult: event requirements, test results and security decisions often live in separate tools. AA-sec is designed around traceability between requirements, evidence, decisions and exact product or lifecycle context, so logging requirements and their verification evidence can remain connected as releases change. It does not make the manufacturer's conformity decision.
Practical evidence checklist
For each product or release, a defensible logging and monitoring evidence set can include:
- the security-event catalogue and its link to identified risks;
- architecture showing where events originate and where they are stored or monitored;
- access-control rules for log configuration, records and export;
- retention, capacity and failure-behaviour decisions where relevant;
- user opt-out design and verification;
- tests showing that high-priority events are captured correctly;
- tests showing that sensitive information is not unnecessarily exposed;
- known limitations and accepted residual risks; and
- review evidence showing that event coverage was reconsidered after material product changes.
The goal is not maximum telemetry. It is a proportionate, testable observability design that supports the product's cybersecurity objectives and can be explained through retained evidence.
Conclusion
The CRA turns security logging and monitoring into an explicit product-security requirement where the risk assessment makes it applicable. Manufacturers should identify relevant internal activity, record enough context to make events useful, protect the records, define how monitoring works, implement the required user opt-out mechanism and verify the behaviour through testing.
A smaller, risk-driven event set with clear ownership and reliable evidence is more useful than indiscriminate logging. The strongest implementation is one that can explain which risks each important event addresses, how the event is protected and tested, and which product release the evidence describes.
Official sources
- Regulation (EU) 2024/2847 - Cyber Resilience Act — EUR-Lex
- Cyber Resilience Act - Manufacturers — European Commission
- Cyber Resilience Act - Standardisation — European Commission