The EU Cyber Resilience Act (CRA) puts security duties on everyone who sells software or connected hardware in the EU. Two parts touch logging: your product must be able to record security-relevant activity, and since 11 September 2026 you must report actively exploited vulnerabilities and severe incidents within 24 hours. This guide explains both and what you need in your own logs to meet the clock.
Not legal advice
This is general guidance on Regulation (EU) 2024/2847. Which products fall under the CRA, and in which class, is a legal question for your own counsel.
Who the CRA applies to
The CRA covers products with digital elements: software and hardware with a data connection that are placed on the EU market. The duties fall mainly on the manufacturer, but an importer or distributor who sells a product under its own name, or changes it substantially, becomes one too.
| Date | What applies |
|---|---|
| 11 September 2026 | Reporting of actively exploited vulnerabilities and severe incidents |
| 11 December 2027 | Most other obligations, including the security requirements of Annex I |
The 24-hour reporting clock
When you become aware of an actively exploited vulnerability in your product, or a severe incident that affects its security, you report to the CSIRT of your member state and to ENISA through the single reporting platform:
- Within 24 hours: an early warning.
- Within 72 hours: a notification with more detail.
- Final report: for a vulnerability, at the latest 14 days after a fix or mitigation is available; for a severe incident, within one month of the notification.
The clock starts when you become aware. Without logs from your own build, update and cloud systems, you cannot tell quickly whether an exploit hit your product, or answer what happened when.
Logging inside your product (Annex I)
From December 2027 products must, among other things, provide security-related information by recording and monitoring relevant internal activity, such as access to or changes of data, services or functions, with an opt-out for the user. In practice:
- Log sign-ins, failed sign-ins and permission changes in the product.
- Log configuration changes and firmware or software updates.
- Use a structured format with timestamps, so customers can send the logs to their SIEM.
- Keep personal data in those logs to a minimum (see GDPR and PII in logs).
Logs you need on your own side
- Source control, CI/CD and signing: who changed what and what was released.
- Update servers and download portals: which versions went out, and anomalies.
- Cloud services behind the product: access, errors and attack traffic.
- A list of the components in each release (SBOM), to see fast whether a new CVE affects you.
How LogPulse helps you meet the clock
LogPulse collects the logs of your build, update and cloud systems in one EU-hosted place. The Intelligence Hub checks known-exploited vulnerabilities (CISA KEV, EPSS, NVD) against the software your agents and scanners report, and tested detection rules look for exploitation in your logs, including a look back over the last 30 days. See threat intelligence for how that chain works.
What LogPulse does not do
LogPulse does not file reports with your CSIRT or ENISA and does not build an SBOM for you. It gives you the facts you need for the 24 and 72-hour reports. LogPulse supports your CRA programme; it is not a conformity assessment.