EU Cyber Resilience Act timelines: what practitioners must prioritise

At a glance

What this is: This is a phased compliance overview of the EU Cyber Resilience Act, showing that the first hard operational deadline is vulnerability reporting in September 2026, followed by full conformity and CE marking in December 2027.

Why it matters: It matters because product security, vulnerability disclosure, and lifecycle governance now need to be planned as regulatory deliverables, which affects software supply chain controls, security engineering, and identity-adjacent access to update and reporting workflows.

By the numbers:

• The Cyber Resilience Act was published in November 2024 and entered into force on 10 December 2024.
• Manufacturers must start vulnerability reporting from 11 September 2026, with a 24-hour early warning required from the moment of awareness.
• Full conformity, including CE marking, applies from 11 December 2027 for products placed on the EU market.

👉 Read FOSSA's guide to the EU Cyber Resilience Act timeline and readiness plan

Context

The EU Cyber Resilience Act creates a compliance problem that is as much operational as it is legal. Product teams cannot treat the regulation as a single cutoff date because the obligations arrive in phases, and the earliest phase demands disciplined vulnerability reporting, incident triage, and evidence capture. For engineering and security leaders, the real challenge is turning scattered product security activity into a governed lifecycle.

The article also intersects with identity and access governance because vulnerability reporting, SBOM maintenance, update channels, and disclosure workflows depend on controlled access, accountable ownership, and auditable process. That makes the CRA relevant not only to product security teams, but also to IAM, PAM, and GRC functions that support release, remediation, and compliance evidence.

The organizations most likely to struggle are those that only begin compliance work when the final deadline approaches. That starting position is common in product security programmes, but it is now risky because the CRA requires both process maturity and regulatory evidence well before full conformity is due.

Key questions

Q: How should organisations prepare for phased Cyber Resilience Act deadlines?

A: Break the work into two tracks. First, make vulnerability disclosure, incident triage, and reporting operational before September 2026. Second, close the longer-horizon product assurance work, including SBOMs, secure-by-design defaults, support periods, and conformity assessment, well before December 2027. Treat each deadline as a separate delivery stream with named owners and evidence checkpoints.

Q: Why do Cyber Resilience Act requirements create more risk for product teams than a simple deadline would?

A: Because the CRA is not a single compliance switch. It requires organisations to operationalise reporting, documentation, update governance, and product assurance across different dates, which exposes weak ownership and slow evidence gathering. Teams that only track the final deadline often discover they have no tested process for the earlier reporting mandate.

Q: What breaks when vulnerability reporting is not rehearsed before the CRA deadline?

A: The first failure is usually coordination, not detection. Teams may know a vulnerability exists, but they cannot produce a verified early warning, assign decision authority, or assemble the required report fields quickly enough. That creates regulatory exposure and makes incident handling look improvised rather than controlled.

Q: Who is accountable when a product fails CRA conformity or reporting expectations?

A: Accountability usually sits across product security, engineering, compliance, and legal, but one function must own the evidence chain. The best practice is to name a primary control owner for reporting readiness and a separate owner for conformity readiness, so responsibilities do not collapse into a shared but unmanaged obligation.

Technical breakdown

Why phased CRA compliance changes the operating model

The CRA is not a one-date compliance event. It introduces a staged operating model where reporting duties, product documentation, secure-by-design requirements, and conformity assessment mature at different times. That matters because many of the required controls are procedural, not just technical. A team can have secure code and still fail if it cannot prove vulnerability intake, escalation, ownership, and evidence retention across the product lifecycle. The regulatory burden therefore sits across engineering, security, legal, and release management.

Practical implication: build a phased delivery plan that maps controls to each CRA milestone rather than waiting for the final conformity deadline.

How vulnerability reporting under the CRA works

From September 2026, the reporting obligation is triggered by awareness of an actively exploited vulnerability or severe incident. The requirement is not just to detect a problem but to produce a 24-hour early warning, then complete structured reporting to ENISA and the relevant national CSIRT using the required fields. In practice, that means disclosure policy, triage workflow, evidence collection, and reporting tooling must already be tested. If those controls are ad hoc, the organisation will know about the vulnerability faster than it can govern the response.

Practical implication: stand up a documented vulnerability disclosure and reporting workflow before the deadline so the first report is not the first rehearsal.

What full conformity and CE marking require in practice

By December 2027, products with digital elements placed on the EU market must satisfy the CRA's essential requirements, including secure-by-design defaults, SBOMs, technical documentation, security support periods, and decoupled security updates. This is a supply chain and lifecycle problem as much as a product security problem. Teams need repeatable evidence that the product can be secured, supported, and updated over time, not just patched once after release.

Practical implication: treat SBOM generation, update governance, and support-period definition as product lifecycle controls, not optional documentation tasks.

NHI Mgmt Group analysis

Phased regulation changes the control ownership problem: the CRA forces product organisations to separate reporting readiness from final conformity readiness. That distinction matters because the first deadline is about incident governance, while the second is about product lifecycle assurance. Security leaders should treat this as a maturity test for whether product, security, and compliance teams can execute on different timelines without creating control gaps.

CRA readiness is really lifecycle governance: the regulation rewards teams that can prove how vulnerabilities, updates, support periods, and product documentation are controlled from development through market release. That overlaps with identity governance wherever release approvals, access to build systems, and evidence collection depend on accountable human and machine identities. The practical conclusion is that lifecycle controls and identity controls now need to be designed together.

Reporting obligations expose the absence of operational discipline: many organisations assume they can assemble disclosure evidence after an incident occurs, but the CRA assumes the opposite. If ownership, triage, and reporting pathways are not predefined, the 24-hour early warning becomes unrealistic. The governance gap is not technical detection alone, but the lack of a repeatable response model under regulatory pressure.

Secure-by-design has become an auditable product state: the CRA turns previously advisory practices into evidence-backed obligations. That means product security claims must be backed by release records, update processes, and documentation that can survive scrutiny. Practitioners should view the regulation as a signal that product assurance is moving from internal policy to externally testable control.

What this signals

The CRA is a reminder that product security programmes now need regulatory-grade evidence, not just secure engineering intent. For identity and access teams, the practical implication is that release systems, reporting workflows, and vulnerability handling must be built around accountable ownership and auditable access, not shared assumptions. Lifecycle evidence gap: this is the point at which many organisations discover that they can describe control ownership but cannot prove it under deadline pressure.

That shift also reinforces the value of lifecycle discipline in adjacent identity programmes. When build systems, signing keys, and release approvals are not governed cleanly, compliance evidence becomes fragile and slow to reconstruct. Teams should expect more demand for traceable control ownership, better separation of duties, and tighter alignment between product governance and identity governance.

For practitioners, the signal is clear: by the time a regulation requires reporting or conformity evidence, the enabling controls must already be embedded in the operating model. That is especially true for organisations with shared development platforms, multiple product lines, or externalised release dependencies. Delayed governance will look like delayed compliance.

For practitioners

• Map controls to each CRA milestone Build a phased compliance plan that separates September 2026 reporting obligations from December 2027 conformity work, with named owners for each control family and evidence stream.
• Publish and test vulnerability disclosure workflows Create a coordinated vulnerability disclosure policy, then rehearse the 24-hour early warning path, escalation roles, and data capture needed for ENISA reporting.
• Automate SBOM and update evidence Put machine-readable SBOM generation, release attestation, and decoupled security update tracking into the build and release pipeline so evidence is produced continuously.
• Assign governance to lifecycle owners Tie support-period definitions, documentation maintenance, and conformity assessment preparation to product lifecycle owners rather than leaving them as ad hoc compliance tasks.

Key takeaways

• The CRA creates two separate governance deadlines, and the reporting deadline arrives first.
• Compliance readiness depends on lifecycle evidence, not just secure code or policy language.
• Teams that do not rehearse reporting, SBOM, and conformity workflows will face avoidable regulatory pressure.

Key terms

• Coordinated vulnerability disclosure: Coordinated vulnerability disclosure is a process in which researchers notify a vendor privately and allow time for remediation before public release. It aims to balance public accountability with defensive readiness, but it only works when the vendor can respond faster than attackers can weaponise the issue.
• Conformity assessment: A conformity assessment is the formal process used to show that a high-risk AI system meets the obligations required before it is placed on the market. It combines documentation review, technical verification, and evidence of operational controls, rather than relying on policy statements alone.
• Embedded SBOM: An embedded software bill of materials lists the software components inside a firmware or device image. In practice, it only supports risk management when it is matched to the exact build and deployed version, so teams can tell what is present, vulnerable, and remediated.
• Secure-By-Design Defaults: Product settings and behaviours that minimise risk without requiring users to harden them manually. In regulatory contexts, this means the product is shipped with safer configurations, clear update paths, and lower exposure by default.

What's in the full article

FOSSA's full post covers the operational detail this post intentionally leaves for the source:

• A milestone-by-milestone CRA readiness checklist for the 2026 reporting phase and the 2027 conformity phase
• Practical guidance for coordinating vulnerability disclosure, ENISA reporting fields, and internal incident workflows
• A 30/60/90-day plan for closing SBOM, secure-by-design, and update-governance gaps
• The specific compliance questions organisations should resolve with legal and product leadership before enforcement tightens

👉 The full FOSSA post covers the 2026 reporting phase, 2027 conformity steps, and readiness planning detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and compliance programmes.