CRA reporting: why 24 hours needs a standing inventory
CRA reporting gives manufacturers 24 hours to send an early warning. That only works if the answer to "which releases are affected?" already exists today.
TL;DR: Since 11 September 2026, manufacturers under the Cyber Resilience Act have had to report actively exploited vulnerabilities and severe incidents, starting with an early warning within 24 hours. The hard part of that deadline is knowing which products and releases contain the affected component. That answer has to exist before the clock starts, which means an inventory that is kept current with every change. Earnie keeps that record running from the code itself.
What does Article 14 of the Cyber Resilience Act require?
The Cyber Resilience Act is the regulation. According to the European Commission, manufacturers are required to report actively exploited vulnerabilities and severe incidents, and these reporting obligations have applied since 11 September 2026. The rest of the regulation becomes fully applicable on 11 December 2027.
The deadlines are tight. A manufacturer submits an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available for an actively exploited vulnerability, or within a month of the notification for a severe incident. Reports go once, through the CRA Single Reporting Platform operated by ENISA, to the CSIRT where the manufacturer has its main establishment, and are made available to ENISA at the same time.
In practice, this means a product security team now works to a regulatory clock that starts at awareness. Therefore the speed of the first answer matters as much as its accuracy.
What has to be known before the 24-hour clock starts?
An early warning is only useful if the manufacturer can say which of its products are affected. That question has a precise form: which products and which releases contain the vulnerable component, in which version, and where?
In practice, this means most of the 24 hours go on establishing scope. A team that can query its own records for a component and get a list of affected releases in minutes has most of the day left for assessment and communication. A team that has to rebuild that list from build systems, repositories and memory can lose the whole window to discovery.
Therefore the inventory behind Article 14 has to exist before any incident. It is the precondition for meeting the deadline, and it cannot be produced on demand.
Why does a point-in-time SBOM fall short?
A software bill of materials generated at release time records the composition of one build on one day. That is useful evidence, and many organisations already produce it. The difficulty is that products keep changing after the snapshot is taken.
In practice, this means a team relying on periodic SBOMs is answering an Article 14 question with a document that may be weeks or months old. Patches, dependency updates and hotfixes can all change what a release contains, and each one makes the last snapshot less reliable as a source of truth.
Therefore the useful unit is a record that updates whenever the code does, with the history of every past release still retrievable. When the 24-hour clock starts, the team should be able to query that record directly.
Where do undeclared components and AI-written code fit in?
An inventory is only as complete as its sources. A list built from package manifests records what developers declared. Code also arrives without a manifest entry: libraries vendored into the tree, functions copied from public repositories, and code written out by coding agents that reproduces existing open source.
In practice, this means a vulnerability can sit in a component that never appeared in a dependency list. If the inventory only reflects declared packages, the team may not find that component until after the clock has started, or at all.
Therefore an inventory built for CRA reporting has to come from the code itself. Declared dependencies are part of the picture, and the parts nobody declared are where the surprises tend to be.
How does Earnie keep the inventory standing?
Earnie connects to a repository once, scans everything, and then checks every commit and every pull request after it. It reads the dependencies declared in package manifests and fingerprints every file, matching those fingerprints against the knowledge base of open source code. That is how it finds components, including code that never appeared in a manifest. We keep fingerprints, not your code.
Each matched component carries its licence and known vulnerability data, so Earnie reports vulnerabilities in what you actually ship, found where they live. The same finding keeps the same ID and the same evidence whichever surface caught it, from pre-commit to merge. SBOM snapshots are frozen records of a project's inventory and decisions that can be exported for any release, and an audit trail records what was decided and when.
In practice, this means the scoping question at the start of an Article 14 report becomes a lookup. The record already exists, it reflects the code as shipped, and it was kept current without anyone scheduling a scan.
What should product security leaders do now?
The reporting obligations are already running, so the useful question is how long scoping would take today. Pick a component that appears across several products and ask the team to list every affected release, with versions. The time that takes is a fair estimate of how much of the 24-hour window would go on discovery.
If the answer is hours rather than minutes, the inventory is where to start. Closing it means putting composition analysis where the code changes, including the code nobody declared, and keeping every release's record retrievable. The CRA's full application in December 2027 will add further obligations, and the same inventory will be the foundation for those too.