CRA Vulnerability Handling Requirements

Skip key takeaways

Key takeaways: CRA vulnerability handling requirements 5

Updated August 12, 2026

Which of the eight Annex I Part II duties actually apply where, and the two Article 13 retention clocks that keep running long after a report is closed.

• Eight standing obligations, not one release drill Annex I Part II covers documentation, remediation, testing, disclosure, a coordinated vulnerability disclosure policy, information sharing, secure distribution and free dissemination of updates, and Article 13(8) adds the intake process for potential vulnerabilities that ties them together.
• The SBOM obligation is to have one, not to publish it Recital 77 confirms publication is not required; Annex II point 9 only covers the optional case where a manufacturer decides to share it.
• Two clocks outlive the product, and they live in Article 13, not Annex I Part II A support period of at least five years under Article 13(8), unless the product's expected use is genuinely shorter, documented under Annex VII point 4, plus a separate ten year availability window under Article 13(9) on every security update issued during it.
• Annex III and Annex IV route through different conformity procedures, not one blanket loss of self-assessment A Class I product keeps the Article 32(1) self-assessment menu if it fully applies harmonised standards, common specifications or an at-least-substantial certification scheme; Article 32(2) pulls it onto the EU-type examination or full quality assurance routes only where those standards, specifications or schemes were not applied, applied only in part or do not exist. Class II loses self-assessment outright under Article 32(3). Annex IV critical products route through Article 32(4), a certification scheme designated under Article 8(1), or, where the conditions in Article 8(1) are not met (in practice, where no delegated act has been adopted), the Class II procedures.
• The pipeline is infrastructure, not paperwork Dependency inventory, a branchable release process, a monitored disclosure intake and a durable distribution mechanism are what actually satisfy the eight requirements and the two Article 13 retention clocks together.

Copy takeaways

If you need to build the dependency inventory, disclosure channel and update distribution pipeline the CRA's vulnerability handling duties assume, we can help you design it.

See our cybersecurity services

The requirements that outlast the report

The loudest CRA conversation is about the 24-hour and 72-hour reporting clocks, not the two retention duties that keep running quietly long after an incident report is closed. Those deadlines are real and they matter, but they describe a response to an event that has already happened. Annex I Part II of the regulation describes something different: eight standing obligations a manufacturer carries for as long as a product with digital elements stays in support, whether or not anything has gone wrong yet.

In short: The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets eight standing vulnerability handling duties in Annex I Part II, covering a software bill of materials, remediation, testing, disclosure and secure update distribution. Article 13 layers two further duties on top: manufacturers must set a support period of at least five years under Article 13(8), unless the product's expected use is genuinely shorter, in which case that shorter expected use time applies instead, and under Article 13(9) every security update issued during that period has to stay available for at least ten years, or the rest of the support period if that runs longer. A Class I important product under Annex III keeps the Article 32(1) self-assessment menu, including module A, when a manufacturer applies harmonised standards, common specifications or an at-least-substantial certification scheme in full, and loses that menu only where those standards, specifications or schemes were not applied, applied only in part or do not exist; a Class II important product goes to Article 32(3) outright; and an Annex IV critical product routes through Article 32(4) instead of self-assessment.

Most of those eight obligations are infrastructure commitments with a long tail. A team that treats vulnerability handling as a policy document filed away and forgotten discovers, usually during an audit or a first real disclosure, that Regulation (EU) 2024/2847 actually expects a working pipeline: a documented dependency inventory, a way to ship a fix outside the normal release train, a disclosure channel someone actually monitors and a distribution mechanism that reaches every affected installation.

The scope question comes first, because it decides who has to care at all. Regulation (EU) 2024/2847 reaches products with digital elements made available on the market in the course of a commercial activity. The European Commission draws that line plainly:

“Products with digital elements that are not made available on the market, i.e. not supplied in the course of a commercial activity, are not subject to the CRA.”

A side project posted to a personal repository with no commercial distribution sits outside the regulation. A commercial product built around that same code does not. Timing follows a similarly fixed source: the CRA entered into force on 10 December 2024, and its main obligations apply from 11 December 2027. The earlier reporting clocks, running from 11 September 2026, are covered in a companion piece on CRA incident reporting deadlines.

Standing vulnerability handling obligations, the subject of this article, sit on the later date, 11 December 2027, alongside the rest of the core product requirements. Reporting obligations under Article 14, filed through the single reporting platform and covered in more depth in a companion piece on CRA severe incident classification, sit on the earlier clock, and nothing below depends on it.

What Annex I Part II actually requires

Annex I Part II lists eight vulnerability handling requirements manufacturers must meet for products with digital elements. Read as a legal recital they sound abstract. Read as an engineering checklist, each one maps to a specific piece of infrastructure or process a team either already has or needs to build.

• Identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format. The floor set by the annex is the top level dependencies, not the full transitive graph, which is a lower bar than most SBOM discussions assume.
• Address and remediate vulnerabilities without delay, including by providing security updates, and where technically feasible provide those updates separately from functionality updates. This line quietly forces a branching and release strategy on any team that currently ships everything through one train, because a security fix now needs to be able to leave the building on its own.
• Apply effective and regular tests and reviews of product security.
• Once a security update is available, share and publicly disclose information about the fixed vulnerability, including a description, enough detail for users to identify the affected product, the impact, the severity and clear remediation guidance. There is an escape hatch here: in duly justified cases, where the security risk of publishing outweighs the benefit, disclosure can be delayed until users have had the chance to apply the update.
• Put in place and enforce a coordinated vulnerability disclosure policy.
• Facilitate information sharing about potential vulnerabilities in the product and in the third party components it contains, including by providing a contact address for reporting them.
• Provide mechanisms to securely distribute updates, so that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, automatically.
• Disseminate available security updates without delay and, unless otherwise agreed with a business user for a tailor made product, free of charge, accompanied by advisory messages telling users what action to take.

Article 13(8), in its final subparagraph, adds a requirement that sits above all eight: manufacturers need appropriate policies and procedures, including the coordinated vulnerability disclosure policy from the fifth item, to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources. That closes a gap teams sometimes leave open. A disclosure policy that only describes how the organization publishes advisories, without also describing how an inbound report gets triaged, assigned and tracked to resolution, satisfies the letter of one obligation while missing the intent behind all eight.

The software bill of materials obligation is narrower than it sounds

Of the eight items above, the software bill of materials draws the most attention and the most confusion. Vendors selling SBOM tooling routinely describe the regulation as a mandate to publish a full transitive dependency graph for every release. It asks for something more modest.

The obligation is to draw one up, in a commonly used machine-readable format, covering at minimum the top level dependencies. Recital 77 makes the publication question explicit: manufacturers are not obliged to make the software bill of materials public. Annex II point 9 covers only the case where a manufacturer chooses to make it available to users, and in that case the accompanying information needs to say where it can be accessed. That is an optional disclosure mechanism, not a baseline requirement.

A practical reading is to have one and to be able to produce it on request, not to publish it by default. That distinction changes what a team actually needs to build. A generation pipeline that produces an accurate, current SBOM for every release and stores it somewhere retrievable satisfies the annex requirement on its own. A public-facing SBOM portal is a business decision layered on top of that, not something the regulation itself compels. Teams that jump straight to publication infrastructure before they have a reliable generation and retention pipeline underneath it are solving the wrong problem first.

Two retention clocks that outlive the product

The support period is the most consequential term in the vulnerability handling requirements, and it is not a phrase most teams define for themselves before the regulation forces the question. Article 3(20) defines it as the period during which a manufacturer is required to handle vulnerabilities effectively, in line with Annex I Part II.

Article 13(8) is where the criteria and the floor actually live, not the definition. A manufacturer sets the length, but not arbitrarily: the second subparagraph requires it to reflect how long the product is genuinely expected to be in use, weighing reasonable user expectations, the nature and intended purpose of the product and other Union law bearing on product lifetimes. The third subparagraph sets the floor at five years, unless the product's expected use is genuinely shorter, in which case the support period matches that shorter expected use time instead. A team cannot declare a two year support window for a product reasonable users would expect to run for a decade.

Whatever period a manufacturer settles on, the reasoning behind it has to be recorded in the technical documentation required under Annex VII, point 4. That turns support period length from an implicit product management assumption into a documented decision someone has to be able to defend, with the same rigor as any other technical documentation entry.

The second clock runs independently of the first and is easy to miss because it attaches to individual updates rather than to the product as a whole. Article 13(9) requires that every security update made available during the support period remain available for at least ten years after it was issued, or for the rest of the support period if that period runs longer. A five year support window with updates issued near its end can still leave a manufacturer holding artifacts for close to fifteen years.

Spelled out in infrastructure terms, that means hosting and artifact retention for a decade per update at minimum, not per product. Signing keys and certificates need their validity, rotation and archival planned to outlast the individuals, and sometimes the teams, that issued the original update. The obligation also means retaining the ability to rebuild, or at minimum re-serve, an update issued years earlier, a different capability than simply keeping the current release buildable. And it means that discontinuing sale of a product changes nothing about the obligation: end of sale is not end of support, and certainly not end of the ten year availability window on whatever updates already shipped.

What changes for higher risk products

Everything above applies uniformly, but the regulation does not treat all products the same way when it comes to proving compliance. Products whose core functionality falls into a category listed in Annex III count as important products. A Class I product stays on the general Article 32(1) menu, including the internal control procedure based on module A, as long as the manufacturer applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial, in full. Article 32(2) pulls a Class I product off that menu only where those standards, specifications or schemes were not applied, applied only in part or do not exist, and routes it instead to either the EU-type examination procedure followed by conformity to EU-type based on internal production control, or a conformity assessment based on full quality assurance. A Class II product loses self-assessment outright: Article 32(3) requires EU-type examination followed by internal production control, full quality assurance or, where available and applicable, a European cybersecurity certification scheme at an assurance level of at least substantial.

Annex III splits into two classes. Class I is the larger group and includes, among others, identity and privileged access management software, browsers, password managers, antimalware products, VPN products, network management systems, security information and event management systems, boot managers, public key infrastructure and certificate issuance software, network interfaces, operating systems, routers, modems and switches. Class II is narrower and includes hypervisors and container runtimes, firewalls and intrusion detection and prevention systems and tamper resistant microprocessors and microcontrollers.

Annex IV sits above both classes and covers critical products, a genuinely short list: hardware devices with security boxes, smart meter gateways and similar devices used for advanced security purposes and smartcards or similar devices including secure elements. Conformity for these runs through Article 32(4): a European cybersecurity certification scheme designated under Article 8(1), or, where the conditions in Article 8(1) are not met (in practice, where no delegated act has been adopted), the same procedures Class II uses under Article 32(3).

One point worth stating clearly because it gets misread often, and now settled directly in the text: Article 7(1) sets the core-functionality test itself. A product whose core functionality falls into an Annex III category is an important product. Article 7(1)'s second sentence answers the integration question directly: integrating an Annex III product into a broader product does not by itself render that broader product subject to the conformity assessment procedures under Article 32(2) and (3). A web application that happens to run behind a firewall the team also builds does not inherit the firewall's classification. Classification tracks the product's own core functionality, not everything it happens to touch.

A method for a defensible support period

Article 13(8) gives criteria, not a procedure. Annex VII, point 4, then requires the technical documentation to contain “relevant information that was taken into account to determine the support period pursuant to Article 13(8) of the product with digital elements”. The sequence below is one defensible way to work through those criteria and produce that file. It is practitioner judgment, not a step-by-step process the regulation itself sets out, and it should be read that way.

1. Pull the mandatory inputs together first. Article 13(8) reuses language already sitting in the Article 13(3) cybersecurity risk assessment, specifically the product's intended purpose, so start from that document rather than starting a new one.
2. Add the optional inputs the regulation names, where a team already tracks them: comparable products' support periods, the availability of the operating environment, the support periods of any sourced integrated components that provide core functions and any relevant guidance from the dedicated administrative cooperation group (ADCO) and the Commission. Article 13(8) also instructs that these matters be weighed proportionately, not treated as a rigid checklist.
3. Check the floor. If expected use is at least five years, five years is the floor regardless of the inputs above. If expected use is genuinely shorter, the support period equals that shorter expected use time, not five years.
4. Record the reasoning, not just the number, in the Annex VII entry. Annex VII point 4 asks for the information taken into account, so a single figure with no supporting criteria does not satisfy it on its own.
5. Revisit the record when the product's use context changes materially, since the criteria that justified the original length can shift under the product.

Article 13(8) input	Where the evidence usually already exists	What lands in the Annex VII, point 4 entry
Reasonable user expectations	UX research, support ticket history on older versions, sales and marketing lifecycle statements	A cited estimate of expected in-use duration
Nature and intended purpose of the product	The intended purpose section of the Article 13(3) cybersecurity risk assessment	A cross-reference to that assessment rather than a rewritten description
Relevant Union law on product lifetimes	Legal or regulatory affairs review for sector-specific rules that also touch the product	A list of applicable law and how each item bounds the period
Five year floor, or the shorter expected use exception	The calculation from step three above	The resulting support period length and which subparagraph produced it

Mapping the eight duties onto existing security frameworks

None of ISO 27001, SOC 2 or IEC 62443 appears anywhere in the Cyber Resilience Act. The table below is practitioner judgment about where a team's existing controls overlap with the eight Annex I Part II duties, not a legal claim. The Regulation attaches that legal effect only to harmonised standards, common specifications and European cybersecurity certification schemes adopted through the routes it names, and none of the three frameworks below is currently one of those things under the CRA. Treat every row as a starting point for a gap assessment, not evidence of compliance.

Practitioner judgment, not a legal claim. Holding any of these certifications does not satisfy, discharge or presume conformity with any CRA obligation.

Annex I Part II duty	ISO 27001	SOC 2	IEC 62443	Gap against the CRA duty
(1) Identify and document vulnerabilities and components, including a top-level SBOM	Asset management and vulnerability management controls identify components but rarely produce a machine-readable SBOM	The SOC 2 vulnerability identification criteria, no SBOM requirement	Component inventory requirements in the IEC 62443 secure development lifecycle series come closest	None of the three requires a machine-readable SBOM by default
(2) Remediate without delay, security updates separated from functionality updates where feasible	ISO 27001's technical vulnerability management controls set remediation timelines, not a branching requirement	The SOC 2 vulnerability response and remediation criteria cover patching cadence, not separation	Update mechanism requirements exist but do not mandate the split	The security-update-separate-from-feature-update requirement has no direct counterpart in any of the three
(3) Effective and regular tests and reviews	ISO 27001's security testing controls	The SOC 2 monitoring activities and system operations criteria	Secure development lifecycle testing practices	Broadly covered by all three
(4) Publicly disclose fixed vulnerabilities, with a delay escape hatch	Not required, internal risk management only	Not required	Vulnerability handling process exists but is not a public-disclosure mandate	Genuine gap: none of the three requires public disclosure of fixed vulnerabilities
(5) Coordinated vulnerability disclosure policy	Not specifically required, though many programs adopt one alongside certification	Not required	A defect and vulnerability handling process is the closest match	ISO 27001 or SOC 2 certification alone does not guarantee a CVD policy exists
(6) Facilitate information sharing, including a reporting contact address	Contact-with-authorities controls are adjacent, not equivalent	Not required	A defect reporting channel is closer, but not identical	A dedicated vulnerability-reporting contact is a CRA-specific artifact
(7) Secure mechanisms to distribute updates	ISO 27001's change management controls touch update processes generally	The SOC 2 change management criteria	Comes closest, since secure update mechanisms are a control-system staple	Automatic secure distribution as the CRA envisions is not explicitly required elsewhere
(8) Disseminate updates without delay, free of charge, with advisory messages	Not required	Not required	Patch advisories exist in some schemes but the free-of-charge duty does not	Genuine gap across all three

Building the pipeline these requirements assume

Put the eight Annex I Part II items and the two retention clocks together and a pattern emerges: none of this is satisfied by a policy document sitting in a compliance folder. It is satisfied by infrastructure that runs continuously, most of it work an engineering organization would recognize even without the regulation attached to it.

The first item comes from a dependency inventory process that generates an accurate top level SBOM on every release and stores it somewhere retrievable years later, which also covers half of what the retention clocks demand. Shipping a security fix on its own branch, independent of the next feature drop, needs a release pipeline built for exactly that, and building it covers the second item, often the single largest process change a team without one has to make. Pair a monitored intake address with a documented triage workflow, and both the disclosure policy and the information sharing requirements are covered, doubling as the mechanism Article 13 expects for processing reports that arrive from outside the organization. The seventh and eighth items come together in a secure, ideally automatic update distribution mechanism, which is also the piece of infrastructure that has to keep functioning for as long as the support period runs.

The retention clocks then set the durability bar for all of it. Artifact storage, signing infrastructure and the ability to reissue an old update all need to survive well past a normal three or four year infrastructure refresh cycle, because a decade of update availability does not pause for a platform migration. Teams that design this pipeline once, with the ten year horizon in mind from the start, avoid rebuilding it under pressure the first time an old update needs to be re-served and the original hosting or signing setup no longer exists.

How Pharos Production helps

We build the release and support infrastructure the vulnerability handling requirements assume already exists as part of our cybersecurity services: SBOM generation wired into the build pipeline, branching and release strategies that let a security fix ship independent of the next feature train, disclosure intake and triage workflows and update distribution mechanisms designed to keep running for as long as the support period requires. For teams still treating the support period as an assumption rather than a documented decision, we help set the length and record the reasoning in the technical documentation an audit will ask for. For teams that are also NIS2 essential or important entities, or DORA financial entities, we also help sort out where CRA vulnerability handling stops and separate reporting duties start, a distinction covered in more depth in a companion piece on CRA, NIS2 and DORA reporting overlap.

Sources: European Commission, Cyber Resilience Act summary (digital-strategy.ec.europa.eu/en/policies/cra-summary); European Commission, Cyber Resilience Act policy overview (digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act); Regulation (EU) 2024/2847 of the European Parliament and of the Council, Annex I Part II, Annex II, Annex III, Annex IV, Annex VII, Articles 3(20), 7, 8, 13 and 32 and Recital 77.

FAQ

Last updated: August 12, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 7

• ★ Featured question. Do open-source software stewards owe the same vulnerability handling duties as manufacturers?

  Copy link Copies a direct link to this answer to your clipboard.

  No. Article 24 gives open-source software stewards a separate, lighter regime: a documented cybersecurity policy that fosters secure development and effective vulnerability handling by the product's developers, cooperation with market surveillance authorities on request and only a scaled subset of Article 14's reporting duties, tied to their own involvement in development or their own network and information systems. The eight Annex I Part II duties and the two Article 13 retention clocks apply to manufacturers, not to stewards acting in that separate capacity.

• Does the Cyber Resilience Act require publishing a software bill of materials?

  Copy link Copies a direct link to this answer to your clipboard.

  No. The obligation is to draw one up in a commonly used machine-readable format covering at minimum the top level dependencies, and to be able to produce it, not to publish it. Recital 77 states manufacturers are not obliged to make it public, and Annex II point 9 only covers the optional case where a manufacturer chooses to make it available to users.

• How long is the CRA support period?

  Copy link Copies a direct link to this answer to your clipboard.

  The manufacturer sets the length under Article 13(8), second subparagraph, to reflect how long the product is genuinely expected to be in use, factoring in reasonable user expectations, the product's nature and purpose and other Union law on product lifetimes. The third subparagraph of Article 13(8) sets a floor of at least five years unless the product's expected use is genuinely shorter, and the reasoning behind the chosen length has to be recorded in the technical documentation under Annex VII, point 4.

  Article 3(20) only defines the term; it does not set the criteria or the floor.

• Is the ten-year retention duty only about security updates, or does it cover documentation too?

  Copy link Copies a direct link to this answer to your clipboard.

  Both, but as two separately anchored duties. Article 13(9) requires each security update to remain available for at least ten years after it was issued, or for the rest of the support period if that runs longer, applying per update rather than to the product as a whole.

  Article 13(13) separately requires keeping the technical documentation and the EU declaration of conformity at the disposal of market surveillance authorities for at least ten years after the product has been placed on the market, or for the support period, whichever is longer. The two duties are similar in shape, both compare a ten year figure against the support period and keep whichever is longer, but their clocks start at different points: one from when the update was issued, the other from when the product itself was placed on the market. They are not the same obligation, and losing track of one does not excuse losing track of the other.

• Which products need full conformity assessment instead of self-assessment under the CRA?

  Copy link Copies a direct link to this answer to your clipboard.

  It depends on the class. A Class I product under Annex III stays on the general Article 32(1) menu, including self-assessment through internal control, as long as the manufacturer applies harmonised standards, common specifications or a European cybersecurity certification scheme at assurance level at least substantial in full; Article 32(2) removes that option only where those standards or schemes were not applied, applied only in part or do not exist, routing the product to EU-type examination or full quality assurance instead.

  A Class II product loses self-assessment outright under Article 32(3), which offers EU-type examination, full quality assurance or, where available and applicable, a certification scheme at assurance level at least substantial. Annex IV critical products route through Article 32(4) instead.

• Does holding ISO 27001, SOC 2 or IEC 62443 certification satisfy CRA vulnerability handling requirements?

  Copy link Copies a direct link to this answer to your clipboard.

  No. None of the three appears in the CRA, and the CRA grants no presumption of conformity for holding them. The Regulation attaches that legal effect only to harmonised standards, common specifications and European cybersecurity certification schemes adopted through the routes it names.

  The frameworks can still cover useful ground, but a certificate against any of them is not evidence of CRA conformity on its own.

• When do the Annex I Part II vulnerability handling requirements start applying?

  Copy link Copies a direct link to this answer to your clipboard.

  From 11 December 2027, the CRA's general application date, alongside the rest of the core product requirements. That is separate from the earlier 11 September 2026 date, which applies to the incident reporting obligations under Article 14, not to the standing vulnerability handling duties in Annex I Part II.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.