The next Cyber Resilience Act deadline is no longer a distant 2027 compliance project. It is 48 days away.
On September 11, 2026, CRA vulnerability and incident reporting obligations begin. From that date, manufacturers of products with digital elements must be ready to report actively exploited vulnerabilities and severe security incidents that affect their products. The European Commission’s CRA reporting guidance sets the pace: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final vulnerability report no later than 14 days after a corrective measure is available.
That is not a paperwork deadline. It is an operational deadline.
If a serious vulnerability lands on a Friday afternoon, the hard question is not “do we have a compliance deck?” It is: can we prove which products are affected quickly enough to make a defensible reporting decision?
September 11 is the first operational CRA deadline
The full CRA application date in December 2027 still matters. That is when the broader product requirements, conformity work, CE marking, secure-by-design obligations, and lifecycle documentation become fully enforceable for new products placed on the EU market.
But September 2026 comes first for security teams.
The Commission says that from September 11, manufacturers must report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements. Reports go through the CRA Single Reporting Platform. ENISA’s Single Reporting Platform page explains that the platform is intended to simplify reporting, route notifications to the relevant CSIRT and ENISA, and support the mandatory process from that date onward.
There is also a very practical setup step that teams should not leave until the incident itself: the people expected to submit or back up CRA reports need access before the clock starts. The public EU Login registration page is already available, but account creation, ownership, backups, and internal approval paths still need to be handled by the organization. A 24-hour reporting window is a bad time to discover that only one person can log in, that the backup owner never registered, or that nobody knows which shared mailbox should receive platform notifications.
Teams should also be careful with automation assumptions. ENISA’s procurement material for implementing the SRP says the architecture should be future-proof and support future integration with incident and vulnerability reporting systems, and that Member States and ENISA should be able to put in place electronic notification endpoints. That is not the same as a public manufacturer API being available on day one. Until ENISA publishes clear API onboarding for manufacturers, plan for a human-operated web portal at go-live: automate evidence gathering, impact analysis, case tracking, and approval preparation internally, but do not make your reporting process depend on an API submission path that may not exist yet.
This changes the preparation question. The issue is not only whether your organization understands the CRA. The issue is whether your engineering, security, and reporting workflows can answer impact questions while the clock is already running — and whether the right person can actually submit the report when the evidence is ready.
The 24-hour question
The first 24 hours are where many teams will feel the pain.
When a vulnerability is actively exploited, you need to know at least four things quickly:
- Which products contain the affected component?
- Which released versions or deployed builds contain it?
- Is the product actually affected, or is the component present but not reachable?
- Who can approve the reporting decision, remediation plan, and customer communication?
If those answers live in different places — one spreadsheet, three CI systems, an old dependency scan, a Slack thread, and someone’s memory — the 24-hour window disappears fast.
That is why “we generate SBOMs” is not enough. A folder of SBOM files is better than nothing, but it does not automatically give you product impact, ownership, triage history, evidence, or a repeatable response path.
For September, SBOMs need to become operational.
Operational SBOMs, not archived SBOMs
An archived SBOM answers one narrow question: what did this build contain when the file was produced?
An operational SBOM workflow answers more useful questions:
- Which projects and products does this component appear in?
- Which versions are currently shipped, deployed, or supported?
- Which teams own those products?
- Which vulnerabilities are new since the last scan?
- Which findings have already been investigated?
- Which findings are not exploitable in this product context?
- Which reports, customer answers, or audit records depend on that decision?
This is the difference between compliance inventory and vulnerability operations.
The CRA pressure is not only that SBOMs must exist. It is that teams must be able to use their component inventory when a vulnerability turns into a reporting event.
Where Dependency-Track fits
A fair comparison here is OWASP Dependency-Track, because it is one of the most widely known open-source SBOM platforms.
Dependency-Track is a strong project. Its own documentation describes it as an API-first component analysis platform that consumes and produces CycloneDX SBOMs and VEX, tracks component usage across applications, and helps identify what is affected and where. The public site says it is used by more than 20,000 organizations and is built around operationalizing SBOMs across a software portfolio.
For teams that want to run their own SBOM analysis stack, have the infrastructure capacity, and are comfortable operating the application, database, workers, upgrades, vulnerability feeds, authentication, notifications, backups, and monitoring, Dependency-Track can be a very good building block.
The question is not whether Dependency-Track is good. It is.
The question is whether your team needs a building block, or a product workflow.
By September, the hard parts are often not just “can we ingest an SBOM?” They are:
- connecting SBOMs to the project that produced them,
- keeping CI uploads simple enough that teams actually use them,
- mapping vulnerability findings to owners,
- preserving evidence for reporting decisions,
- avoiding fragmented spreadsheets and one-off investigations,
- giving smaller teams a managed path instead of another platform to operate.
That is the operational gap teams should look at honestly. If you already run Dependency-Track well, the next question is how your reporting workflow, evidence retention, and product ownership model connect to it. If you do not have that operating model yet, deploying a tool is only the first step.
A practical pre-September checklist
This is the work worth doing before September 11.
1. Register the reporting owners
Every person expected to submit, approve, or cover CRA reports should have the required EU Login access before the first incident. Do not make the platform login, backup owner, mailbox, or approval chain something you discover during a live 24-hour reporting window. Treat the final SRP submission as a manual portal step until ENISA documents a public manufacturer API.
2. Map products to owners
Every product with digital elements needs a responsible owner. Not just a Git repository. Not just a team channel. A person or team that can answer: is this product in scope, is it affected, and who approves the response?
3. Generate SBOMs from CI
Manual SBOM exports will drift. Generate CycloneDX or SPDX artifacts as part of your build and keep them tied to the project, commit, build, and release.
4. Monitor SBOMs continuously
A stored SBOM is static. Vulnerability intelligence changes every day. New CVEs, updated advisories, exploit status, and affected-version ranges need to be matched against the products you still support.
5. Record investigation decisions
Not every CVE in an SBOM means the product is affected. Sometimes the component is present but not reachable. Sometimes a vulnerable function is not used. Sometimes the affected package is only in a build-time path.
Those decisions need evidence. If you decide not to report, suppress, defer, or wait for an upstream fix, keep the reasoning somewhere you can find later.
6. Dry-run the 24/72-hour process
Pick a real recent CVE and run the process as if the deadline were already active.
Can you identify products in scope? Can you assign owners? Can the right person log in and submit? Can you produce an initial impact statement? Can you draft a report? Can you explain what evidence supports the decision?
If the answer is no, the problem is not September. The problem is the workflow.
The serious version of panic
Panic is not helpful if it turns into noise. But a little urgency is appropriate here.
September 11 is close enough that teams should stop treating CRA reporting as a future legal task. The practical work is already due: product inventory, SBOM generation, vulnerability monitoring, ownership, triage evidence, and a response path that works under time pressure.
The uncomfortable truth is that the first actively exploited vulnerability after September 11 will not wait for your compliance project to finish. It will ask a much simpler question:
Which of your products are affected, and can you prove it today?
If the answer depends on manual searches across repositories and chat history, you are not ready yet.
boring.tools helps teams make SBOMs operational: connect projects to dependency inventories, upload SBOMs from CI/CD, monitor vulnerabilities continuously, and keep impact evidence close to the products that actually ship. The CRA reporting deadline is not the time to discover your inventory is just a pile of files.