Many product and security teams are treating the Cyber Resilience Act as a 2027 problem.
That is a mistake.
The European Commission states that the CRA's main obligations apply from 11 December 2027. But the reporting obligations apply earlier, from 11 September 2026.
That changes the planning window completely.
If your product has an actively exploited vulnerability or a severe incident after the reporting obligations begin, you need more than a policy document. You need evidence.
You need to know what is in the product, where it came from, which supplier provided it, which versions are affected, whether customers are exposed, what mitigation exists, and what has already been communicated.
That is not something teams can assemble from scratch during an incident.
By the time reporting starts, the evidence system already needs to work.
Compliance programs often begin with documentation. Teams create policies, responsibilities, templates, and gap analyses. Those are useful.
But CRA readiness will not be won by documentation alone.
The harder question is whether your organization can generate reliable product cybersecurity evidence from day-to-day engineering and supplier workflows.
For software supply chain risk, that means:
current SBOMs for products and releases;
If that data is scattered across CI/CD tools, scanners, ticket systems, procurement folders, email attachments, and shared drives, the compliance program is fragile.
The CRA turns that fragility into business risk.
The 2027 date gets the attention because it is the date for the main obligations. But the 2026 reporting milestone is the first operational test.
From 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe incidents impacting the security of products with digital elements.
That means teams need answers quickly:
Is this vulnerability present in any shipped product?
These are not legal questions first. They are data questions.
And the data has to exist before the incident.
SBOMs are often described as ingredient lists for software. That analogy is useful, but incomplete.
For CRA readiness, an SBOM should not be treated as a static artifact. It should be the starting point for an evidence workflow.
A raw SBOM can tell you what components exist in a release.
An operational SBOM program can tell you:
which releases are affected by a new vulnerability;
That is the shift.
The compliance value is not in having a file. It is in being able to use the file under pressure.
The companies most exposed to CRA pressure are not necessarily the ones doing nothing.
Many already have scanners. Many generate SBOMs in CI/CD. Many have vulnerability management tools. Many have supplier questionnaires.
The problem is that these processes are fragmented.
Security teams see vulnerabilities. Legal teams see license obligations. Procurement sees supplier contracts. Engineering sees release pipelines. Compliance sees audit requests. Customer-facing teams see questionnaires and trust center demands.
Nobody sees the whole control system.
That creates four recurring gaps.
First, SBOM sprawl. Teams generate many SBOMs, but no one knows which are current, complete, approved, or tied to a product release.
Second, supplier uncertainty. Manufacturers rely on supplier software but cannot always get high-quality SBOMs or timely vulnerability responses.
Third, incident coordination. When a vulnerability appears, teams need to identify affected products and suppliers fast. Manual outreach does not scale.
Fourth, audit evidence. Even when the right action was taken, the evidence may be scattered and hard to reconstruct.
CRA readiness has to close those gaps.
Buying another scanner may help, but it does not automatically create CRA readiness.
The workflow matters more than the category label.
Start with the questions the organization must answer:
Which products with digital elements are in scope?
What exploitability context do we have?
Who owns remediation?
Then map the systems that provide each answer.
If the map has gaps, the CRA program has gaps.
For software supply chain readiness, a practical CRA evidence stack should include:
A central SBOM repository
Every product and release needs a structured place where SBOMs are stored, versioned, validated, and connected to inventory.
Automated ingestion
SBOMs should come from CI/CD, repositories, artifact systems, suppliers, and manual upload where needed. Manual-only collection will not scale.
Quality policy
An SBOM should be checked before it becomes compliance evidence. Missing versions, weak metadata, or incomplete dependencies should be visible.
Supplier exchange
Requests, responses, redactions, approvals, and supplier follow-up should be tracked as a workflow, not buried in email.
Continuous vulnerability monitoring
The SBOM is not done when generated. New vulnerabilities appear after release. Historic exposure matters.
VEX and exploitability context
A vulnerability is not always exploitable in a specific product. Teams need a way to capture and communicate that context.
Audit trail
Every decision should leave a record: what was known, when it was known, who acted, and what was communicated.
Customer-facing disclosure
Some organizations will need controlled ways to share SBOM and security evidence with customers, auditors, and partners.
That stack is not paperwork. It is operational infrastructure.
Some teams delay because not every detail is settled. They want final guidance, final standards, final internal policy, or final customer requirements.
That is understandable. It is also risky.
The core direction is already clear: products with digital elements need stronger cybersecurity governance, vulnerability handling, supplier visibility, and evidence.
SBOM adoption is accelerating because organizations see that software transparency is becoming a baseline expectation, not an optional best practice.
Waiting for perfect legal certainty will not make supplier software easier to trace. It will only compress the implementation window.
The practical starting point is simple.
Build a CRA evidence inventory.
For each major product, answer:
Do we have a current SBOM?
Score each answer red, yellow, or green.
The red areas are not theoretical compliance gaps. They are future incident-response delays.
The visible deadline may be 11 December 2027.
The operational deadline is earlier.
By 11 September 2026, teams need to be able to report with confidence. That means the SBOM, supplier, vulnerability, and incident evidence pipeline must already be working.
The companies that start now will treat CRA as a structured product security program.
The companies that wait will treat it as an emergency documentation project.
Only one of those scales.
Run a CRA evidence readiness check across one representative product line:
Generate or collect the current SBOM.
Document how long it takes to identify affected products, suppliers, and evidence.
If that takes days, the organization is not ready for reporting pressure.
CTA: Start with a Free CRA Assessment from Exodos Labs.
Sources
- European Commission: Cyber Resilience Act timeline and reporting dates: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- European Commission: CRA reporting obligations from 11 September 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- ENISA: SBOM Adoption State of Play 2026: https://www.enisa.europa.eu/publications/sbom-adoption-state-of-play-2026
- CISA: 2025 Minimum Elements for a Software Bill of Materials: https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom