Cyber Resilience Act deadlines are the staged dates on which the EU product-security rules begin to apply. Reporting obligations under Article 14 started on 11 September 2026; most other obligations apply from 11 December 2027.
Four dates, four different implications
| Date | Milestone | Practical implication |
|---|---|---|
| 10 December 2024 | Regulation entered into force | The transition period began |
| 11 June 2026 | Notified-body provisions apply | Conformity infrastructure begins operating under the relevant provisions |
| 11 September 2026 | Article 14 reporting applies | Manufacturers need a working reporting process now |
| 11 December 2027 | Most obligations apply | In-scope products placed on the EU market must meet the applicable CRA requirements |
The transition is not permission to ignore existing security or sector rules. Radio equipment already has separate cybersecurity obligations under the Radio Equipment Directive delegated act. Requirements and standards for that route should be checked independently. A CRA preparation project does not replace RED assessment, safety, privacy or other applicable product legislation.
Reporting cannot wait for the technical file
An exploited vulnerability can create an immediate reporting duty even while your wider conformity project is still underway. The first 24 hours begin when the manufacturer becomes aware of the qualifying vulnerability or severe incident. They do not begin when a weekly triage meeting next happens. Create an escalation process that can operate outside one person’s working hours and record the point of awareness.
Within 24 hours, the early warning communicates the available facts. Within 72 hours, the notification provides the required further information. A final vulnerability report follows within 14 days after a corrective or mitigating measure becomes available. Severe incidents use a different final-report rule: one month after notification. These are distinct branches, so do not use a single generic final deadline for every case.
Plan backwards from market placement
December 2027 is a regulatory application date, not a sensible date to start your first engineering assessment. Product classification, standards selection, lab availability and remediation can all affect the schedule. Determine whether you can use the default self-assessment route or need third-party involvement. Confirm the build inputs and the supported-release inventory before booking a documentation handover.
For each product family, identify the last release window that can include architectural changes. Secure defaults, update mechanisms and deletion features may need product engineering rather than a policy document. If a product cannot receive updates safely, that is unlikely to be solved in a final-week paperwork exercise. Reserve time to test changes, gather evidence and review customer-facing information.
A useful 90-day starting plan
In days 1–30, inventory products and supported versions. Name the manufacturer and incident contact. Complete an initial classification, generate a build-linked SBOM and test the reporting escalation channel. In days 31–60, triage vulnerabilities and assess the Annex I requirements. Identify architecture changes, external tests and gaps in user information. Agree the support-period rationale with the product owner.
In days 61–90, start the highest-priority engineering work and assemble the technical documentation structure. Run a reporting drill using an illustrative exploited vulnerability. Check that a substitute can prepare and review an early warning. Set a recurring review for release evidence and a separately owned deadline for each remaining action. This plan begins preparation; it is not a promise that every product can reach conformity in ninety days.
Products already in circulation
Whether a particular unit, release or modification falls under a transitional rule depends on facts about placement on the market and subsequent changes. Do not treat a model’s launch date as proof for all later units. Keep distribution and release records and seek qualified review for substantial modifications or mixed product portfolios. Reporting applicability also needs its own check; it should not be inferred solely from the full-compliance date.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Make the next action measurable
Choose one supported release and identify the specific evidence missing for this topic. Write an action that a reviewer can close: an inventory validated against the image, a timestamped reporting drill, a classification rationale or an approved customer statement. “Improve compliance” is too broad to verify. Name the artifact, the responsible person and the date for review.
At the next meeting, check the artifact rather than the percentage complete in a tracker. Record any remaining uncertainty and whether the product boundary or release has changed. This keeps progress grounded in technical facts and prevents a documentation task from becoming disconnected from the product it describes.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.