CRA requirements for manufacturers: what you must do

What Cyber Resilience Act requirements must a manufacturer meet?

If your company places a product with digital elements on the EU market, the Cyber Resilience Act requires you to design, develop and produce that product in line with the essential cybersecurity requirements in Annex I Part I, and to run effective vulnerability handling under Annex I Part II for the whole support period. You must also prepare technical documentation, draw up an EU declaration of conformity and affix the CE marking before the product is placed on the market. Reporting duties under Article 14 apply from 11 September 2026, and most of the regulation applies from 11 December 2027. A customer or regulator asking for CRA evidence will expect each of these duties to be traceable to a document, a test or a process record.

The exact obligations depend on two things: the product's class and whether a later change makes it a substantially modified product. A default product follows the self-assessment route under module A for most cases, while important products in class I and class II, and critical products, may need a notified body. Your product classification therefore decides how much third-party involvement you need and what you must have ready before the CE marking. Confirm the class against the Annex III and Annex IV categories and the Commission's technical descriptions before you plan the conformity route.

Start by listing every product in scope and recording its class, its intended purpose and the support period you expect to offer. For each product, identify who owns the cybersecurity risk assessment, who maintains the SBOM and coordinated vulnerability disclosure policy, and who will file Article 14 notifications through ENISA's Single Reporting Platform. Ask your auditor or notified body to confirm the evidence they will accept, and ask any implementation partner to state in writing which documents they prepare and which remain your responsibility. Only an independent conformity assessment body can issue the certification or assessment outcome that your customers and authorities rely on.

In what order do manufacturer obligations fall due?

This sequence shows how a manufacturer moves from deciding whether the Cyber Resilience Act applies to a product through to keeping the records regulators can ask for. Each step produces an artifact that the next step depends on, so gaps early in the sequence tend to surface later as rework.

Confirm scope and product classification
Start by confirming that the product is a product with digital elements in scope, and whether its core functionality places it in the default category or in the important (Annex III class I or II) or critical (Annex IV) category. The classification sets the conformity assessment route, so it has to come first. Use the Commission's technical descriptions of each category to check the match, and record the reasoning. The output is a written classification memo naming the product, its category and the reason for it, which the rest of the sequence relies on.
Complete the cybersecurity risk assessment
Under Article 13(2) and (3), assess the cybersecurity risks of the product against its intended purpose, reasonably foreseeable use and conditions of use. The assessment must state whether and how each Annex I Part I point (2) requirement applies and is implemented, and it must be documented and updated during the support period. Engineering, product security and legal teams usually own this step, with external help optional. The output is a dated risk assessment document that the design work and the technical documentation both reference.
Design and produce to Annex I Part I
Use the risk assessment to build the product so it meets Annex I Part I, covering the general requirement and points (2)(a) to (m), as Article 13(1) requires. Requirements cover areas such as secure-by-default configuration, access control, data protection, and resilience. Where a requirement does not apply, record the justification in the risk assessment rather than leaving it silent. The check that closes this step is a traceable mapping from each requirement to a design decision, a test or a configuration, with production controls that keep released builds consistent with what was assessed.
Operate the Annex I Part II vulnerability handling process
Set up the eight Annex I Part II vulnerability handling requirements before the product is placed on the market and run them for the whole support period, as Article 13(8) requires. This covers identifying and documenting vulnerabilities, including component vulnerabilities, a coordinated vulnerability disclosure policy, security updates delivered to users, and a way for others to report issues. The check is a working process with named owners, a component inventory and records of handled vulnerabilities, not a policy document alone. The process specifications feed directly into the technical documentation.
Prepare for Article 14 reporting
Put a procedure in place to notify any actively exploited vulnerability, and any severe incident, to the CSIRT designated as coordinator and to ENISA through the Single Reporting Platform. Article 14 sets an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. Reporting obligations already apply, so this step should be ready before the product is on sale. The output is a tested escalation runbook with named decision makers, a list of relevant CSIRTs and sign-off authority, and a contact for users.
Compile the Annex VII technical documentation
Gather the evidence from the previous steps into technical documentation covering the general product description, design and development information including system architecture, vulnerability handling specifications including the SBOM and coordinated vulnerability disclosure policy, the cybersecurity risk assessment, the basis for the support period, standards or solutions applied, and test reports. Engineering and compliance teams compile it, and testing partners can supply reports. The check is that a reviewer can trace each claim in the documentation to a source document. The output is a versioned technical file for each product or product family.
Carry out conformity assessment and issue the EU declaration
Complete the applicable conformity assessment before the product is placed on the market, as Article 13(12) requires. Most products follow self-assessment under module A, while class I important products without full application of harmonized standards and class II and critical products need a notified body. Once the assessment passes, draw up the EU declaration of conformity and affix the CE marking. The output is a signed declaration referencing the assessed product, and a conformity assessment record showing which module was used and by whom. Confirm the route against the current Commission guidance before committing.
Keep records for market surveillance
Keep the technical documentation and EU declaration of conformity available to market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer, as Article 13(13) requires. Article 13(18) sets the same period for the user information. Also retain vulnerability handling records, reporting submissions and update histories for the same horizon. The check is a retention schedule with owners and a tested retrieval process. The output is an indexed archive that can be produced to an authority on request.

How Annex I shapes the product requirements

Annex I divides the CRA's technical requirements into product properties and vulnerability handling processes. The manufacturer's cybersecurity risk assessment links the two halves, because it decides which product requirements apply and how each one is implemented across the support period.

Part I: general product requirement

Part I opens with a general requirement that the product be designed, developed and produced to minimize cybersecurity risks. Everything in points (2)(a) to (m) elaborates that baseline. Manufacturers should read the general requirement first, then map each specific point to a design decision, a test or a document they can show an assessor.

Points (2)(a) to (m) as a checklist

The thirteen lettered points describe concrete product properties, such as secure default configuration, protection against unauthorized access, data confidentiality and integrity, and the availability of essential functions. Each point needs a decision: it applies and is implemented in a stated way, or it does not apply and the reason is recorded. Treat the list as a set of engineering questions for each product family, not a single yes or no for the whole product.

Part II: eight vulnerability handling requirements

Part II sets out eight process requirements that apply for the whole support period, not only at launch. They cover identifying and documenting vulnerabilities, including component vulnerabilities, providing security updates, testing, publishing advisories, a coordinated vulnerability disclosure policy and a way for third parties to report issues. Manufacturers should check that each requirement has a named owner, a written procedure and a record that shows it ran.

Risk assessment as the decision record

The cybersecurity risk assessment is the document that ties Annex I together. It analyzes risks from the intended purpose, reasonably foreseeable use and conditions of use, and it must state whether and how each Part I point applies and is implemented. Manufacturers should keep it current during the support period, since a change in use or a newly found vulnerability can change which points apply.

Justifying points that do not apply

A point that does not apply to a product is not a gap, but the reason must be written down and defensible to a market surveillance authority or notified body. Weak justifications, such as claiming a feature is absent without checking the architecture, are a common source of assessment findings. Ask the engineering team to show the design evidence behind each exclusion, and review exclusions whenever the product's functions or network exposure change.

Linking product and process evidence

Auditors and authorities read the two halves together. A Part I implementation, such as an authentication design, should trace to the Part II process that tests it, patches it and reports on it. Build a traceability matrix from each Part I point to its design record, test report and vulnerability handling procedure. This matrix becomes the spine of the technical documentation described in Annex VII.

How the risk assessment and support period set the scope of work

The risk assessment and the support period decide how much work a CRA product needs, so the manufacturer should settle both before engineering plans are locked. Article 13(2) requires the manufacturer to assess the cybersecurity risks of the product and to apply the outcome across planning, design, development, production, delivery and maintenance. Under Article 13(3), that assessment must be documented and kept current during the support period. It has to analyze risks against the product's intended purpose, its reasonably foreseeable use and the conditions under which it is used. It must also state, for each point (2) requirement in Annex I Part I, whether the requirement applies and how it is implemented. A risk assessment that skips the foreseeable misuse of a product will leave requirements unjustified, and an assessor will notice.

The support period must be at least five years. Where a product is expected to stay in use for less than five years, the support period must match that expected use time. The manufacturer sets this basis, not the regulator, so the reader should confirm internally who owns the expected-use estimate, how it was derived and how it will be reviewed as the product ages. The basis must be justified in the technical documentation listed in Annex VII, which includes the support period basis, so that market surveillance authorities can test the reasoning. Ask engineering, product management and legal to agree the figure in writing, because a longer support period carries ongoing costs for patching, vulnerability handling and documentation that continue for as long as the product is supported.

Both decisions feed directly into the work plan. The risk assessment determines which Annex I Part I requirements apply and what evidence each one needs, and the support period determines how long the vulnerability handling process in Annex I Part II must run. Teams that treat them as paperwork often discover late that a product needs more test reports or a longer maintenance commitment than budgeted. Confirm the scope of the risk assessment, its update triggers and the support period basis before scoping any implementation or testing engagement, and record the decisions and their owners so they can be shown to an auditor or authority. For how the support period interacts with later updates, see the guidance on the Commission's CRA guidance.

What Article 14 reporting requires from manufacturers since 11 September 2026

Article 14 reporting has applied since 11 September 2026, and it applies to in-scope products already on the market, not only to products placed on the market after that date. Article 14 requires a manufacturer to notify any actively exploited vulnerability in its product, and any severe incident affecting the product's security, to the CSIRT designated as coordinator and to ENISA at the same time. The notification moves through three stages: an early warning within 24 hours of becoming aware, a vulnerability notification within 72 hours, and a final report within 14 days after a corrective or mitigating measure is available. Each stage has its own clock, so the manufacturer needs to know when it became aware of an issue, which is the point the clock starts.

Notifications are filed through ENISA's CRA Single Reporting Platform, which ENISA launched as an initial operating capability on 11 September 2026. Before the first incident, the manufacturer should confirm three things: who inside the company can declare awareness and authorize a filing at any hour, how a suspected exploited vulnerability travels from the security or support team to that person, and which CSIRT will receive the notification as coordinator for the manufacturer's Member State or main establishment. Confirm the CSIRT choice with the relevant national authority rather than assuming it, and check the current platform guidance in ENISA's Single Reporting Platform frequently asked questions before writing the procedure into the vulnerability handling process.

A practical test is to run a tabletop exercise against the escalation path using a hypothetical exploited flaw in a shipped component, then time how long it takes to produce an early warning draft. Record the result in the vulnerability handling records, since the same process feeds the technical documentation and the support period. Ask the implementation partner or internal team to map where the product's SBOM and coordinated vulnerability disclosure policy would supply the facts needed for each stage, because reporting cannot be reliably met if the vulnerability data sits in an unrelated ticketing tool.

What the technical documentation must contain

Annex VII lists the parts of the technical documentation a manufacturer must hold before placing a product on the EU market. Each component below is a file or record you own, and several depend on work done by engineering, security and legal teams together.

General product description

This component describes the product, its intended purpose, its versions and how it is identified, including the type, batch or serial number that Article 13 also requires on the product. Write it so a market surveillance authority can match the documentation to a unit on the shelf or in a deployment. You own this record. Check that the intended purpose matches the wording in your user information and marketing claims.

Design and development information

Annex VII asks for design and development information, including the system architecture. Diagrams should show components, trust boundaries, data flows and third-party services so that the risk assessment and the Annex I Part I measures can be traced to real parts of the product. Engineering owns this material. External architects can help structure it, but the manufacturer must confirm that it reflects the shipped product.

Vulnerability handling process specifications

This component documents how you handle vulnerabilities for the whole support period, including the software bill of materials (SBOM) and your coordinated vulnerability disclosure policy. Assessors will look for a written process with named roles, intake channels and update delivery, not a general commitment. The process must be run by your own product security team. Outside help can draft the procedures and set up tooling, but operating them stays with the manufacturer.

Cybersecurity risk assessment

The risk assessment must be documented, analyze risks based on intended purpose, reasonably foreseeable use and conditions of use, and state whether and how each Annex I Part I requirement applies. It must be updated during the support period. The manufacturer owns the conclusions and must sign off on them. A consultant can run the method and facilitate workshops, but cannot accept the residual risk on the manufacturer's behalf.

Support period basis

You must record why the support period you declared is right for the product. The regulation sets a floor of five years, or the expected time in use if shorter. Keep the reasoning, the expected use profile and any market or contract evidence that supports the period chosen. Product management and legal should own this record together, since the same figure appears in user information.

Standards, solutions and test reports

List the harmonized standards, common specifications, certification schemes or other solutions you applied, and attach the test reports that show how each Annex I requirement was met. Where you did not apply a standard in full, the notified body route may apply, so this list drives the conformity assessment choice. Testing can be outsourced to accredited labs or security testers, but the manufacturer must hold the reports and confirm their scope.

EU declaration of conformity copy

Annex VII requires a copy of the EU declaration of conformity inside the technical documentation. The manufacturer signs the declaration once the conformity assessment is complete and before CE marking. Keep the signed version and its version history together with the technical file. No third party can issue this declaration for you, although a notified body may be involved in the assessment that supports it.

Which conformity assessment route applies to each product class

This table compares the conformity assessment route for default products, class I and class II important products, and critical products. Read each row against your product's category under Annex III or Annex IV, since the category decides whether you self-assess or must involve a notified body. The main takeaway is that a notified body is never chosen for you: you select one listed in NANDO, and it only issues the conclusion of the assessment you need.

Product class	Usual route	When a notified body is needed
Default products (not listed as important or critical)	Module A internal control, self-assessment by the manufacturer	Not required for the conformity assessment itself
Class I important products (Annex III)	Module A self-assessment only if harmonized standards, common specifications or certification schemes are applied in full	Where those standards or schemes are not applied in full, or are only partly applied
Class II important products (Annex III)	Notified body involvement required before placing on the market	Always, for the conformity assessment route the regulation prescribes for this class
Critical products (Annex IV)	Notified body involvement required before placing on the market	Always, under the route for critical products
Who selects the notified body	The manufacturer chooses a body from the Commission's NANDO list	Check that the body is listed for the relevant product category and module before contracting
What the notified body issues	A certificate covering the conformity assessment, not a general approval of the product	Confirm scope, timing and deliverables in writing with the body before work starts
Responsibility that stays with the manufacturer	Technical documentation, risk assessment, EU declaration of conformity and CE marking	Even when a notified body is involved, the manufacturer keeps these obligations

How the EU declaration, CE marking and record keeping close the file

The conformity file closes in a fixed order. Before a product is placed on the market, the manufacturer must have the technical documentation in place and the applicable conformity assessment carried out under Article 13(12). Only then does the manufacturer draw up the EU declaration of conformity and affix the CE marking. Treat the declaration as the last step of the file, not the first. If the technical documentation is incomplete, the declaration has nothing to stand on, and an assessor or market surveillance authority will ask for the underlying evidence first. Check that the risk assessment, the vulnerability handling specifications, the test reports and the support period basis are all signed off before anyone prints the declaration.

The product itself must carry identifying information that ties it back to that file. Article 13 requires a type, batch or serial number, the manufacturer's name and contact details, and a single point of contact for users. The Annex II information and instructions must be provided in a language that users and authorities can easily understand. Confirm the exact wording of each requirement against the regulation, and decide early which language set you will ship in each market. Product labels, packaging, the online product page and the user manual should all show the same identifiers, so that a user report or an authority request can be matched to one product version without guesswork.

Record keeping is the duty most often underestimated. The technical documentation and the EU declaration of conformity must be kept available for market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer, under Article 13(13). Article 13(18) applies the same period to the user information. Set retention in your document management system now, assign an owner for the archive, and record which version of each document belongs to which product release. A support period of five years or more means that records for a product still in service will outlast most engineering teams' memory of it, so plan storage and access before the first release.

Who owns each CRA obligation and who can prepare the evidence

The manufacturer carries the legal obligations under the Cyber Resilience Act. Article 13 places the duty on the manufacturer to design, develop and produce the product in line with Annex I, to run effective vulnerability handling for the support period, and to draw up the technical documentation and EU declaration of conformity before placing the product on the market. No partner can take these duties over, and a consultant's involvement does not change who answers to market surveillance authorities.

Risk assessment decisions: You decide which risks apply to the product, document the assessment and state whether and how each Annex I Part I point (2) requirement applies.
Vulnerability handling and reporting: You run the PSIRT process, coordinated vulnerability disclosure policy and Article 14 notifications through the Single Reporting Platform.
Technical documentation and record keeping: You own the Annex VII file and keep it for at least 10 years or the support period, whichever is longer.
Declaration and CE marking: You sign the EU declaration of conformity and affix the CE marking.
Support period commitments: You set and communicate the support period to users.

Confirm with your legal or regulatory counsel which entity in your group is the manufacturer for each product.

What usually delays CRA work and how to avoid it

Most CRA programs stall on the same few gaps rather than on the technical requirements themselves. The cards below pair each common delay with one practical fix, starting with the dates that set the order of work.

Planning from the 2027 date

Teams often treat December 2027 as the deadline and leave vulnerability reporting for later. Article 14 reporting already applies from 11 September 2026 to in-scope products, including products placed on the market earlier. Fix: build the reporting path first, then schedule the 2027 conformity work behind it. Confirm with counsel which of your products are already on the market.

Undocumented cybersecurity risk assessment

Annex I requirements are applied on the basis of the manufacturer's risk assessment, so an informal or unrecorded one leaves every later decision unsupported. Article 13(3) expects the assessment to be documented, updated during the support period, and to state whether and how each point (2) requirement applies. Fix: write one versioned risk assessment per product family with intended purpose, foreseeable use and the justification for any requirement marked as not applicable.

Unclear support period basis

The support period must be at least five years, or match the expected time in use if that is shorter. Teams that cannot explain how they set the period struggle to answer assessors and customers. Fix: record the basis for each product, such as expected service life, customer contracts and update commitments, and review it when the product changes. Ask the assessor which evidence they expect for the basis.

Missing SBOM and vulnerability process

Annex VII expects a vulnerability handling process specification that includes the SBOM, and Annex I Part II sets the process requirements for the whole support period. Without a maintained SBOM, a team cannot tell whether a newly published vulnerability affects its product. Fix: generate the SBOM from the build pipeline for every release and tie each component to a named owner who triages advisories.

No coordinated vulnerability disclosure policy

Researchers and customers need a published route for reporting flaws, and the technical documentation must include the coordinated vulnerability disclosure policy. Many organizations have an informal inbox but no written policy, so reports arrive without an owner. Fix: publish a short disclosure policy with a contact point, response expectations and a commitment to advisories, then rehearse it with the product security team.

Untested 24-hour escalation path

Article 14 requires an early warning within 24 hours of becoming aware of an actively exploited vulnerability, sent to the designated CSIRT and to ENISA through the Single Reporting Platform. A path that exists only on paper usually fails on the first real event, because nobody knows who decides that awareness has occurred. Fix: run a tabletop exercise that walks one hypothetical exploited flaw through the decision, the drafting of the early warning and the platform submission, then record the gaps.

Common questions about CRA manufacturer obligations

Can a manufacturer meet Cyber Resilience Act obligations without outside help?

Yes, a manufacturer can meet the obligations with its own staff, because the duties fall on the manufacturer and not on any consultant. The work is cross-functional, though. Product security, development, release engineering, legal and customer support all touch the risk assessment, the vulnerability handling process, the Article 14 reporting duty and the technical documentation. Organizations with small teams or many product families often bring in an implementation partner to prepare systems, logs, SBOM generation and evidence, while keeping decisions and sign-off in-house. Ask any partner to show which tasks it performs and which remain with your staff. DeployOpen prepares systems and evidence; it does not issue reports, certificates or declarations.

What does Cyber Resilience Act work need from engineering and legal staff?

Engineering owns most of the technical evidence, and legal owns the scope of the obligations and the wording of the declaration. Engineering typically documents the system architecture, the cybersecurity risk assessment, the design decisions against the Annex I Part I points, the vulnerability handling process, the SBOM and the coordinated vulnerability disclosure policy. Legal and compliance decide the role under the regulation, the support period commitment, the contractual terms with suppliers and the content of the EU declaration of conformity. Product management should confirm the intended purpose and conditions of use, because the risk assessment depends on them. Expect the workload to recur: the risk assessment must be updated during the support period.

Is a notified body always required for CRA conformity assessment?

No. Most products follow self-assessment under module A, where the manufacturer carries out the conformity assessment itself. A notified body is needed for class I important products where harmonized standards, common specifications or certification schemes are not applied in full, and for class II and critical products. The product's classification comes from its core functionality and the Annex III and Annex IV categories, so classify the product before choosing a route. The Commission's technical descriptions in Implementing Regulation (EU) 2025/2392 help with that step. Confirm the route against the Commission's FAQ and your own product class before budgeting for third-party assessment.

What documentation will an assessor ask for under the CRA?

Assessors and market surveillance authorities expect the technical documentation listed in Annex VII, with the evidence behind each part. The core items are a general product description, design and development information including the system architecture, the vulnerability handling process specifications with the SBOM and the coordinated vulnerability disclosure policy, the cybersecurity risk assessment, the basis for the support period, the standards or solutions applied, test reports and a copy of the EU declaration of conformity. Keep these records for at least 10 years after placing the product on the market or for the support period, whichever is longer. Use the same structure for every product family so that auditors can trace each claim to a test result or log.

Can an implementation partner sign the EU declaration of conformity?

No. The manufacturer draws up the EU declaration of conformity and affixes the CE marking, and that responsibility cannot be handed to a consultant or implementation partner. A partner can help prepare the technical documentation, the test evidence and the checklist that supports the declaration, but the manufacturer must review the content and accept responsibility for it. Independent conformity assessment bodies, including notified bodies where a route requires them, perform the assessment itself. Ask any partner to state in writing which parts of the declaration work it prepares and confirm that the signatory is a manufacturer representative.

What should we confirm with the CSIRT and Commission guidance before scoping?

Before scoping, confirm which CSIRT is designated as coordinator in each Member State where you place products, because Article 14 notifications go to that CSIRT and to ENISA through the Single Reporting Platform at the same time. Confirm the reporting timeline, which runs from 11 September 2026: a 24-hour early warning, a 72-hour vulnerability notification and a final report within 14 days of a corrective or mitigating measure. Then review the Commission's non-binding guidance published on 27 July 2026 on scope, free and open-source software, substantial modification, support periods and risk assessment. Treat the guidance as interpretation to check against the regulation itself, and record the version you relied on.

How DeployOpen prepares CRA systems and evidence

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the systems and records behind your CRA obligations sit where you control them. We prepare systems and evidence for your assessment; your organization owns its controls, and only an independent auditor, assessor or certification body issues reports or certificates.

How we scope

We agree the product scope, deliverables and timelines in writing before any work starts.
We confirm which platforms, environments and product components the written scope covers.
Engagements are fixed-scope, and ongoing support is available as a retainer once the initial work is delivered.

How we build

We implement and harden the self-hosted platforms that hold vulnerability handling, SBOM and risk assessment records.
We run security testing against applications, APIs and infrastructure to produce test reports for the technical file.
We customize and integrate tooling so that evidence is generated during normal engineering work rather than assembled later.

How we hand over

We document the cybersecurity risk assessment, the support period basis and the vulnerability handling process specifications.
We deliver technical documentation structured to the content listed in Annex VII, for your review and sign-off.
We set up backups and record retention so documentation can be kept for the period your obligations require.

How we support

We keep platforms patched, upgraded and documented throughout the support period, under a retainer if you choose.
We provide continuous testing so changes to a product can be checked against the Annex I requirements.
Your legal and compliance teams confirm final determinations, and your chosen assessor or notified body performs the independent assessment.