Cyber Resilience Act: a practical guide

The Cyber Resilience Act is the EU regulation establishing cybersecurity requirements for products with digital elements made available on the European market. Regulation (EU) 2024/2847 covers product security throughout the lifecycle, from design and conformity assessment to vulnerability handling and security updates.

For a small manufacturer, the practical challenge is connecting requirements to the actual product: its builds, dependencies, update mechanism, supported versions and incident process. A documentation template cannot do that alone. This guide explains the main obligations and the evidence you can begin collecting now. It is engineering guidance and does not provide legal advice.

What products are in scope?

The CRA generally covers hardware and software products with a direct or indirect logical or physical data connection. An EU sale can bring a non-EU manufacturer’s product into scope. Necessary remote data processing is included where the product cannot perform one of its functions without it. A device, its companion application and a necessary backend therefore need a deliberate product-boundary review.

Pure SaaS is generally outside this product scope, but a remote element required by an in-scope product is a different question. Exclusions also cover specified medical devices, motor vehicles, civil aviation and marine equipment, certain defence and national-security products, and non-commercial open source. Do not apply a label such as “cloud” or “open source” as a shortcut. The actual commercial activity, intended purpose and legal sector rules matter.

A connected industrial sensor, a consumer smart plug and an installable business application can all be relevant even though their architectures differ. Record the product description, market, intended users, release structure and connected functions. Check economic-operator responsibilities for the manufacturer, importer and distributor. If an interpretation is borderline, resolve it with qualified review and keep the rationale.

The dates and what they mean

Reporting is already mandatory as of this guide’s October 2026 review date. An incomplete technical file does not postpone the reporting clock. A manufacturer needs an incident contact, a way to identify affected releases, access to the SRP and an authorised reviewer who can act within hours. Read the deadline guide for a preparation sequence and transition caveats.

Full application affects products placed on the market from the relevant date, subject to the regulation’s detailed transitional provisions. Do not assume that an old product model makes every later unit exempt, or that a modified release can use the original assessment unchanged. Keep release and distribution evidence, and check substantial-modification questions separately. Other applicable product legislation continues to matter during the CRA transition.

Product classes and conformity routes

Most connected products fall in the default class, where self-assessment is generally available. Important Class I and Class II categories appear in Annex III. Critical categories appear in Annex IV. Classification begins with the primary function and intended purpose, not the size of the company or a generic risk score.

Default examples include ordinary smart plugs, lights, sensors and most applications. Class I examples include routers, operating systems, VPNs, password managers, browsers and smart-home products with security functions such as security cameras, locks, baby monitors and alarms. Connected toys with interactive or location features and health or children’s wearables also need attention. Class II includes hypervisors and container runtimes, firewalls, IDS/IPS and specified tamper-resistant processors.

Class I can use self-assessment only when the relevant harmonised standards or permitted specifications are fully applied under the applicable route. Otherwise third-party involvement is needed. Class II requires third-party conformity assessment. Critical products require review of the applicable EU cybersecurity certification arrangements. In October 2026, the brief identifies no cited harmonised CRA standard; the EN 40000 series remains in drafting. Check the current Official Journal position before relying on a standard.

A security feature added to a product can affect the classification reasoning, so keep the rationale with the technical documentation. An ordinary light and a camera marketed as a security product should not receive the same conclusion merely because both use Wi-Fi. The product classes guide explains the categories and the scope checker provides an initial screen.

Annex I Part I: product security properties

The first part of Annex I sets the essential product-security properties, to be applied on the basis of the cybersecurity risk assessment. The engineering review should explain which risks are relevant, which controls address them and what evidence supports the conclusions. Avoid treating the requirements as an identical feature list for every architecture.

1. Deliver products without known exploitable vulnerabilities.
2. Use secure defaults and provide a way to reset the product.
3. Provide security updates, automatic by default with the relevant opt-out arrangements.
4. Protect against unauthorised access.
5. Protect confidentiality of stored, transmitted and otherwise processed data.
6. Protect integrity of data, configuration and functions.
7. Minimise data processing to what is necessary for the intended purpose.
8. Protect availability, including resilience against denial of service.
9. Minimise adverse effects on other networks and services.
10. Limit attack surfaces, including exposed interfaces.
11. Mitigate the impact of potential exploitation.
12. Provide appropriate security logging and monitoring with the relevant opt-out.
13. Support secure deletion and transfer of data.

For each property, capture the design decision and verification evidence. For example, secure defaults can involve onboarding, account provisioning, credentials and exposed services. Update security can involve authenticity, integrity, rollback behaviour and user communication. A policy stating that the product is secure does not demonstrate any of those behaviours. Existing test results may be useful, but must refer to the product configuration and supported release under assessment.

Annex I Part II: vulnerability handling

The second part sets eight continuing vulnerability-handling requirements. A machine-readable SBOM covering at least top-level dependencies is one of them. The others include remediation without delay, regular security testing, publication of fixed vulnerabilities, a coordinated vulnerability disclosure policy, a reporting contact, secure distribution of updates and free security updates with appropriate advisories.

Build an inventory from the actual release rather than a source manifest that never reaches the device. Validate names and versions, particularly where vendors backport patches or bundle code. Keep inventories for older supported releases. Connect each public vulnerability match to an applicability decision that an engineer can inspect. The SBOM guide explains how CycloneDX and SPDX fit this workflow.

A disclosure policy should tell researchers where to report, what information helps, how you acknowledge reports and how coordination works. Publish a monitored security contact, including security.txt as a discovery mechanism. Establish a route from an external report to an internal incident owner. Do not promise safe harbour, response times or testing permissions that the organisation has not approved and cannot operationally support.

Article 14 reporting

An actively exploited vulnerability or a severe security incident can start a short reporting clock. The manufacturer submits through ENISA’s Single Reporting Platform to the relevant coordinator CSIRT, with the information also available to ENISA under the platform arrangements. Check coordinator selection and account access before a real event. The process should have a backup owner and a documented authority to submit.

Record awareness as a timestamp and maintain a versioned account of what the team knows. Early information can be incomplete, so distinguish confirmed facts, working assumptions and unanswered questions. Do not delay escalation until an investigation is finished. Separately assess user-information duties and safe distribution of mitigations. Keep the submission acknowledgment and copies of the approved reports in the incident record.

Roja prepares copy-ready drafts and tracks the clock; the manufacturer reviews and submits. That division avoids confusing an internal draft with a filed notification. The Article 14 guide expands the workflow and the deadline calculator shows local and UTC times, including calendar-month treatment for the incident final report.

The documentation set

The technical documentation should tell a coherent story about the product. Annex VII covers the technical file, including product information, design and development information, the cybersecurity risk assessment and supporting evidence. Annex II contains user information, while Annex V sets out the EU declaration of conformity. These documents serve different audiences and should agree on identifiers, versions, support period and the applicable conformity route.

Collect evidence as the engineering work happens. Keep the product description, architecture, relevant interfaces, component information, risk assessment, test records and security-update arrangements together with references to their owners and releases. Record unresolved items rather than concealing them inside an apparently complete export. A reviewer should be able to follow a requirement to a conclusion and then to the underlying artifact.

The manufacturer approves and signs the declaration of conformity. A service provider can prepare a draft, but should not imply that its document is independent certification. Where the route requires a notified body or a particular certification scheme, involve the appropriate organisation and verify its designation and scope. Lab testing, statutory conformity assessment and engineering support are complementary roles, not interchangeable names for the same purchase.

Support periods and record retention

The manufacturer must determine a support period that reflects the expected use and the relevant product factors. The baseline is at least five years unless expected use is shorter. A five-year baseline is not automatically sufficient for a long-lived industrial product. The support end date must be clearly presented at purchase. Explain the commitment in user information and keep it consistent across packaging, distribution material and the technical file.

Each security update must remain available for at least ten years or for the remainder of the support period, whichever is longer. This availability rule is distinct from promising ten years of new security engineering for every product. Technical documentation and the declaration of conformity must be retained for at least ten years under the applicable Article 13 duties. Plan durable storage, access and responsibility so evidence is not lost when a repository or employee account changes.

Use the support period calculator as a planning aid, then review the result against the product’s actual expected use. Record why a shorter support period would be justified if expected use is below five years. Avoid publishing a date until the organisation can support the update distribution and vulnerability-handling process behind it. A date printed on a box is a customer commitment with operational consequences.

What happens if you don’t comply

Article 64 provides maximum fines up to the higher of €15 million or 2.5% of worldwide annual turnover for essential requirements and manufacturer obligations under Articles 13 and 14. The next tier is up to €10 million or 2% for other obligations, while incorrect or misleading information can reach €5 million or 1%. These are statutory ceilings; national authorities decide actual penalties in the relevant circumstances.

Market surveillance measures also matter. Authorities can require corrective action and restrict, withdraw or recall non-compliant products under the applicable powers. From full application, market placement requires the appropriate conformity work and CE marking. A retailer or marketplace may remove non-compliant listings under its applicable rules and duties. Do not treat a compliance project as a promise that every sales channel will accept the product.

Micro and small enterprises have a narrow Article 64(10) exemption from fines for missing the 24-hour early warning. The warning duty and the other deadlines still apply. The exception does not remove the broader essential requirements or manufacturer obligations. Read the penalties guide for the tier distinction and use the fine calculator only to understand the arithmetic maximums.

A 90-day preparation plan

In the first thirty days, establish the product boundary and responsibilities. Inventory product families, releases and EU sales channels. Document likely classification and identify external-review dependencies. Generate an initial build-linked SBOM. Create the vulnerability contact and confirm that an incident report can reach a decision-maker. Set up the SRP registration process and read the current ENISA guidance.

During days thirty-one to sixty, validate the inventory and triage the most relevant vulnerabilities. Review the essential requirements against the product architecture. Identify gaps in secure defaults, update security, deletion and logging. Draft the risk assessment structure and support-period rationale. Gather existing test evidence and check whether it refers to the current release. Agree remediation priorities based on risk, time and the chosen conformity route.

During days sixty-one to ninety, complete a first engineering increment and update the evidence accordingly. Run an Article 14 reporting drill that tests the backup owner as well as the primary contact. Review draft user information and the disclosure policy. Set dates for outstanding tests and external assessments. Establish a release gate that refreshes the SBOM, applicable decisions and documentation when the product changes. Ninety days is a useful beginning, not a guaranteed completion period for every product.

Choose help by the work you need

DIY software can suit a team that already has security ownership and time to run the process. Enterprise platforms can suit large portfolios with integration needs and dedicated product-security staff. Labs and notified bodies cover testing and conformity roles that a general engineering provider cannot replace. Compare deliverables, responsibility, data access, implementation time and recurring obligations before comparing headline prices.

Roja combines a platform with engineers. A free Snapshot reviews one product in 48 hours after agreed inputs. The readiness assessment documents classification, inventory and gaps. The Ready for 2027 project includes technical documentation and remediation engineering. Monitor provides continuing vulnerability work and reporting drafts. The pricing page states the boundaries and current prices for each engagement.

The aim is a product team that can explain and maintain its evidence. Start with one release, identify real gaps, fix the most consequential issues and make the process repeatable. A maintained inventory, a reachable incident contact and a defensible support commitment are concrete progress. They also make the next review easier because the reasoning remains available to the people who need it.

A release gate your team can repeat

Treat a release gate as a short, evidence-based review, not a final security guarantee. Start with the immutable release reference and compare it to the last supported version. Which components changed? Which interfaces or remote functions were added? Did the update mechanism, intended purpose or customer configuration change? Those questions determine which parts of the inventory, risk assessment and conformity reasoning need another look.

The release owner should confirm that the build-linked SBOM is generated and validated, that relevant findings have a documented disposition and that agreed remediation has been verified. The product owner should check the support statement and user information. The incident owner should confirm that the version will appear in monitoring and that escalation details remain current. If an important fact is unknown, keep it as an explicit release decision rather than hiding it in a green dashboard.

For a security fix, connect the patch, the affected versions, the advisory and the update distribution evidence. Retain how the team determined applicability and whether the reporting trigger was assessed. A package version may remain unchanged when a vendor backports a patch, so preserve the downstream evidence. Conversely, a version bump does not prove a vulnerable function was removed or that every user received the update.

Working with a lab or conformity reviewer

Prepare the product configuration and evidence index before the external review begins. Agree which hardware revision, firmware build, companion application and necessary remote service the assessment covers. Explain optional interfaces and customer configurations that affect security. Give the reviewer the classification rationale and any standards assumptions, with open questions clearly identified. This helps avoid testing one configuration while documenting a different one.

Confirm which organisation is responsible for each task. A lab can perform the agreed security tests, an appropriately designated conformity body can carry out its authorised statutory role, and the engineering team can implement fixes and assemble the supporting evidence. Check qualifications and scope directly. A company name on a comparison table should never be treated as proof that every location or service line is authorised for the required assessment.

When findings return, assign an owner and capture the change reference, retest evidence and documentation update. Check whether a fix changes the inventory or creates a new supported release. If a test is deferred, record the reason and the impact on the project decision. The manufacturer should receive a clear handover explaining what was reviewed, what was changed and what remains its continuing responsibility.

Supplier components and useful questions

The manufacturer needs due diligence on third-party and open-source components. Ask suppliers for version information, security contacts, update arrangements and evidence for backported fixes. Determine whether the component’s stated support period can sustain the product’s commitment. A device expected to remain in use for years may depend on a library or chipset whose vendor support ends much earlier. That mismatch needs an engineering plan, not just a note in procurement records.

Record what a supplier statement actually covers. An upstream advisory may apply to some configurations but not others. A vendor’s product certificate may have a narrower scope than your finished device. An SBOM from a module supplier can be an input to your inventory, but it needs mapping to the version actually integrated. Keep those relationships visible so a future vulnerability can be traced without repeating the entire discovery exercise.

What a useful handover contains

At the end of a readiness or implementation engagement, the customer should receive more than a score. Expect an agreed product boundary, a release evidence index, a classification rationale, a prioritised gap list and the assumptions that need continued review. Each action should have a responsible owner, an evidence expectation and a date. If external testing or a conformity decision is still pending, state that dependency plainly.

For ongoing work, agree how new releases enter monitoring, how findings are escalated and how reporting drafts reach an authorised submitter. Check the triage allowance and the treatment of additional engineering. Confirm access to records and the export or deletion process if the service ends. The goal is continuity: your team should understand the evidence and be able to maintain the product-security process after any individual project finishes.

The risk ledger

*Article 64: the higher of €15 million / 2.5% of worldwide annual turnover for essential requirements and manufacturer obligations; €10 million / 2% for other obligations; €5 million / 1% for incorrect or misleading information. These are maximums, decided by national authorities. Read the regulation. Article 14 reporting has applied since 11 September 2026. See the penalties guide for exceptions.

Frequently asked questions

Sources

• Regulation (EU) 2024/2847 — EUR-Lex
• ENISA Single Reporting Platform FAQ

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.