CRA Vulnerability Handling Requirements: Annex I Part II’s 8 Duties as a PSIRT Procedure Before 11 December 2027

Annex I Part II of the Cyber Resilience Act lists eight duties, all introduced by the words “Manufacturers of products with digital elements shall”. Read together, they describe a product security incident response team (PSIRT) without using the term: a component inventory, risk-based fixes, tests, public advisories, a disclosure policy, a contact point, secure update delivery, and free updates with user advisories. None of the eight sets a number of days. The legal test is “without delay” and “in relation to the risks posed”, so what you can defend in front of a regulator is a written procedure with named owners and records, not a stopwatch.

The duties apply to products placed on the EU market from 11 December 2027, and to older products substantially modified from that date (for the modified parts, or the whole product if the change negatively affects its overall cybersecurity). They run for the whole support period, and two record-keeping duties can outlast it: update availability under Article 13(9) and documentation retention under Article 13(13). The Article 14 reporting clock has run since 11 September 2026 and depends on the same intake and triage steps, so the procedure is needed before the handling duties formally bite. Below, the eight points become a seven-step procedure. Each step has an owner and a record, and the guide closes with the evidence file a market surveillance authority can ask for, the owner map and the penalty exposure. The main sources are Regulation (EU) 2024/2847, the Commission’s guidance of 27 July 2026 and the Commission services’ FAQ.

Does Annex I Part II apply to your product?

In plain terms: it applies to every product with digital elements you place on the market from 11 December 2027, for its support period. Older products owe Article 14 reports but not the eight handling duties, unless you substantially modify them.

Situation	Part II handling duties	Article 14 reporting	Basis
Product placed on the market on or after 11 December 2027	Yes, for the whole support period	Yes	Art 13(8); Art 71(2)
Product placed before 11 December 2027 and not substantially modified	No	Yes, since 11 September 2026	Art 69(2) and (3); Commission FAQ 5.3
Product placed before 11 December 2027 and substantially modified from that date	Yes, for the modified parts; for the whole product if the modification negatively affects its overall cybersecurity	Yes	Art 69(2); Commission guidance para 124
Earlier version of a software product, once a substantially modified version is available free of charge and without additional costs	Point (2) remediation may be limited to the latest version. Other Part II duties, such as the disclosure policy and information sharing, continue	Yes	Art 13(10); Commission guidance paras 129–131
Third-party or open-source component inside your product	For products within the handling duties: handled as part of your product, and the flaw is reported upstream, subject to the exceptions in Step 3	Depends on exploitation in your product	Art 13(6) and (8)

For legacy products the Commission services’ FAQ states the position directly: manufacturers are “required to notify the vulnerability or incident but are not required by the CRA to comply with other obligations, e.g. in relation to vulnerability handling.” Many teams will still run one procedure for old and new products, because splitting intake by placing-on-market date is error-prone.

Article 13(8) sets the support period at a minimum of five years, or at the expected use time if the product is expected to be in use for less than five years. The Commission’s CRA guidance says a five-year period “is therefore not to be considered as the default for all products” (para 126). Citing Recital 60, the guidance says products reasonably expected to be in use for longer than five years should have longer support periods. A controller customers expect to run for twelve years is the obvious case, and your PSIRT procedure runs for all of it.

The eight duties, translated into PSIRT tasks

In plain terms: each point becomes a task with an owner and a record. The table keeps the regulation’s own qualifiers, because they set how much discretion you have.

Annex I Part II point	Qualifier in the text	PSIRT task	Default owner	Record
(1) Identify and document vulnerabilities and components, including an SBOM covering “at the very least the top-level dependencies”	Machine-readable, commonly used format	Generate an SBOM per release and match it against vulnerability sources	Build / product engineering	SBOM per version; component matches passed to the PSIRT register
(2) Address and remediate vulnerabilities “without delay”, including through security updates	“In relation to the risks posed”; separate from functionality updates “where technically feasible”	Rate the risk of each confirmed flaw, choose a remedy, ship it	Product engineering, with the PSIRT lead rating the risk	Triage decision, remedy, release ID
(3) Apply effective and regular tests and reviews	“Effective and regular”, read by the guidance as review-driven (see below)	Review the test set when new threat input arrives; regression-test fixes	QA / security testing	Test reports and review notes
(4) Publicly disclose fixed vulnerabilities once an update is available	Delay only “in duly justified cases”, until users have been able to apply the patch	Publish an advisory	PSIRT lead with communications	Advisory archive; delay justifications
(5) Put in place and enforce a coordinated vulnerability disclosure (CVD) policy	None	Publish the policy and run cases under it	PSIRT lead; legal sign-off	Policy version history; case log
(6) Facilitate sharing about vulnerabilities, including in third-party components, and provide a contact address	None	Run the intake channel; report upstream	PSIRT	Intake log; upstream reports
(7) Securely distribute updates, automatically for security updates	“Where applicable”	Signed update channel; automatic updates where users expect them	Platform / DevOps	Description of the distribution solution
(8) Disseminate available security updates without delay, free of charge, with advisory messages	Charging allowed only for a tailor-made product by agreement with a business user	Release the update with a user-facing advisory	Product management with support	Release notes and advisory messages

Two qualifiers decide most remediation and disclosure calls. “In relation to the risks posed” in point (2) means you do not have to patch every finding. The Commission services’ CRA FAQ says the CRA “does not require manufacturers to provide a patch for all vulnerabilities” found during the support period. Its example is a router whose firmware contains a vulnerable library whose functions are never called: the manufacturer may be expected to document the flaw, may decide not to fix it with a dedicated update, and may remove the library in the next regular firmware release. The second qualifier is “duly justified” in point (4). Point (4) allows one exception to publishing: in duly justified cases, where you consider that the security risks of publication outweigh the benefits, you may delay publication until users have been able to apply the patch.

Of the eight points, point (3) is the hardest to evidence. The guidance clarifies that regular testing “does not require the mechanical repetition, at fixed intervals, of an unchanged test campaign” (para 238). Regularity is shown by reviewing whether new input, such as a new threat or a newly found flaw, changes the tests. So the record that matters is the dated review decision, including the ones that find no new input, where para 240 says additional tests “need not be devised”.

The PSIRT procedure in seven steps

In plain terms: one path from report to closed case. Each step names the Annex I Part II points it serves and a rough effort level for setting it up. The steps draw on the service areas of the FIRST PSIRT Services Framework, which defines a PSIRT as the function that “focuses on the identification, assessment and disposition of the risks associated with security vulnerabilities” in an organisation’s products.

Step 1: Intake (points 5 and 6; Article 13(17)). Owner: PSIRT lead. Effort: Low

Article 13(17) requires a single point of contact that users can find easily. It must let users “choose their preferred means of communication and shall not limit such means to automated tools”, so a chatbot alone fails. A monitored mailbox plus a web form is the usual minimum. Annex II point 2 puts that contact, and the location of your CVD policy, into the user information shipped with the product. Recital 76 indicates that the policy should also let reporters go through the CSIRT designated as coordinator under NIS2 Article 12(1), anonymously if they ask. Many PSIRTs also publish a security.txt file. RFC 9116 makes its “Contact” and “Expires” fields mandatory and recommends an expiry less than a year ahead, so put the renewal date in the calendar. Record the time each report arrives. If the report later turns out to describe exploitation, that entry shows when your assessment started. Under the guidance, you become aware once that initial assessment gives you a reasonable degree of certainty (para 213), so log that moment too.

Step 2: Triage (points 1 and 2). Owner: PSIRT lead; engineering generates the SBOM and supplies component matches. Effort: Medium

Answer three questions. Is the flaw in our product, and in which versions? Is it exploitable under practical operating conditions? Is there evidence that someone is exploiting it? The guidance says a flaw should be regarded as known once it appears in public databases such as the European vulnerability database under NIS2 Article 12(2), and that it may also be known when it reaches you through coordinated disclosure, internal testing or prominent media reports (paras 233–234). A report alone does not prove exploitability. You “will need to investigate it and confirm” that it applies to your product, and “the emphasis should be on prompt action” (para 235). If signs of malicious use appear at any point, assess them immediately (para 213) and switch to the actively exploited vulnerability test, because the 24-hour early warning under the CRA reporting requirements runs from awareness. The CRA names no scoring system. Point (4) only requires advisories to state severity, so choose one method, such as CVSS, and apply it consistently. Record the three answers and the severity in the register.

Step 3: Upstream reporting (point 6; Article 13(6)). Owner: PSIRT lead. Effort: Low to Medium

When you find a flaw in an integrated component, including open source, Article 13(6) requires you to report it to whoever manufactures or maintains that component. If you build a fix, you must share the code or documentation, in machine-readable form where appropriate. The guidance narrows the duty in practice. You report only for the version you integrate, and through the maintainer’s own disclosure channel where one exists. You need not report where you can confirm the maintainer already knows, so check public advisories and issue trackers first. The duty covers only flaws in the component itself, not ones caused by your integration. It lapses when the component has no maintainer, and you are not obliged to get your fix accepted (paras 223–228). Record either the upstream report or the reason no report was needed.

Step 4: Remediation (point 2). Owner: product engineering. Effort: High

Choose the remedy that matches the risk. The FAQ lists immediate patches, workaround advisories later followed by a software update, updates to user manuals, and configuration guidance that disables the affected feature (FAQ 4.3.1, the same answer that gives the router example above). Ship the fix separately from new features where you can. The FAQ’s example is a certificate-validation fix delivered on its own. Replacing an unsafe file parser that changes behaviour is a case where separation is not technically feasible (FAQ 4.3.5). If a component’s supplier no longer helps, you remediate another way: disable the function, swap the component or write the patch yourself (FAQ 4.3.6). Where a serious flaw cannot be remediated and the product cannot be brought back into conformity, Article 13(21) requires corrective action, withdrawal or recall; the FAQ expects this only in exceptional cases (FAQ 4.3.4). Record the remedy chosen and the release that carries it.

Step 5: Verification (point 3). Owner: QA / security testing. Effort: Medium

Regression-test every fix before release, and run the test-set review from the previous section. Keep the reports. Annex VII point 6 lists “reports of the tests carried out to verify the conformity” of the vulnerability handling processes as part of the technical documentation.

Step 6: Distribution and user advisory (points 7 and 8). Owner: platform team with product management. Effort: Medium

Deliver updates through a channel that protects their integrity, and make security updates automatic where applicable. Recital 56 says the automatic-update requirements do not apply to products mainly intended to be integrated as components, or to products for which users would not reasonably expect automatic updates, such as those used in professional ICT networks and critical or industrial environments. Security updates are free of charge, unless otherwise agreed with a business user for a tailor-made product. Each one goes out with an advisory telling users what to do. Keep the release notes and advisory messages. Under Article 13(9), every security update stays available for at least 10 years after release or for the rest of the support period, whichever is longer. That clock is separate from the retention of the technical documentation under Article 13(13), covered below.

Step 7: Disclosure and closure (point 4; Article 13(7)). Owner: PSIRT lead with communications. Effort: Low

Once the update is out, publish an advisory, unless a duly justified delay applies until users have been able to apply the patch. Cover the five elements point (4) names: a description of the flaw, how users identify affected products, the impact, the severity, and clear remediation guidance. Publishing it also in the OASIS Common Security Advisory Framework (CSAF) 2.0 format makes it machine-readable. That is good practice, not a CRA requirement. Credit the finder if they agree. Then close the case. Article 13(7) requires you to systematically document the vulnerabilities you become aware of, for example in your vulnerability register, and, where applicable, to update the cybersecurity risk assessment.

“Without delay” has no number: set targets you can defend

In plain terms: Annex I Part II sets no deadline in days for handling vulnerabilities. Article 14’s reporting clocks are a separate duty. Set your own targets, tie them to risk, write them into the procedure and measure against them.

The targets below are an illustrative starting point that we suggest. They do not come from the CRA or the guidance. Adjust them to your product’s risk profile and release engineering, and record why you chose them.

Milestone	Suggested internal target (ours)	Legal anchor the target serves
Acknowledge a report	2 working days (reports that describe exploitation go straight to on-call assessment, next row)	Shows the CVD policy is enforced (point 5)
Assess signs of active exploitation	Immediately, on-call	Guidance para 213: assess “immediately”; the Article 14 deadline is 24 hours from awareness
Triage decision: affected versions, exploitability, severity (signs of exploitation go to the row above)	7 calendar days	Guidance para 235: prompt investigation and confirmation
Fix or mitigation, critical exploitable flaw	14 calendar days from the triage decision for a fix or an interim mitigation advisory; full fix as soon as feasible	Point (2) “without delay” in relation to the risk
Unreachable flaw, such as an unused library	Document now; consider removing the unused code in the next scheduled release	FAQ 4.3.1 router example

If your customers are NIS2 entities, they will hold their own patch targets, often set by CVSS score, as described in our guide to NIS2 vulnerability patch management. Your remediation targets decide whether they can meet theirs, so expect them to ask about yours in supplier questionnaires.

The evidence file a market surveillance authority can request

In plain terms: Annex VII lists what goes into the technical documentation. Article 13(22) lets an authority request it with a reasoned request, and Article 13(13) requires you to keep it for 10 years after placing on the market or for the support period, whichever is longer.

• Specification of the vulnerability handling processes, including the SBOM, the CVD policy, “evidence of the provision of a contact address” and the description of the secure update distribution (Annex VII point 2(b)).
• SBOM per product version. Recital 77 says manufacturers “should not be obliged to make the SBOM public”. Article 13(24) lets the Commission fix its format by implementing act. See our SBOM requirements guide.
• Test reports for the vulnerability handling processes (Annex VII point 6).
• Support-period rationale (Annex VII point 4) and the end date, at least month and year, shown at the time of purchase (Article 13(19)).
• Risk assessment stating how you apply Part II (Article 13(3)).
• Vulnerability register and case records showing what you documented and decided (Article 13(7)).

A harmonised standard is on the way. CEN-CENELEC’s draft prEN 40000-1-3 on vulnerability handling “covers CRA Annex I, Part 2”, and implementation is “demonstrated via documented process outputs and actions in the market”. In those March 2026 slides it was still a draft (prEN). Under Article 27(1), a harmonised standard gives a presumption of conformity only once its reference is published in the Official Journal, so build to the regulation’s text and map to the standard once it is cited.

Who owns what, and the penalty exposure

In plain terms: the CRA never uses the word PSIRT. The last subparagraph of Article 13(8) requires “appropriate policies and procedures, including coordinated vulnerability disclosure policies”. The CRA does not prescribe a team size, so in our reading one trained person can hold the role in a small company, provided the duties have named owners and deputies.

Role	Owns	First action
CISO / PSIRT lead	Steps 1–3 and 7, the CVD policy, the vulnerability register (engineering feeds it SBOM matches)	Publish the contact point and CVD policy; run a mock case end to end
Product engineering	SBOM and step 4; supports steps 5–6, which QA, the platform team and product management own	Generate an SBOM for every release in the build pipeline
Compliance officer / legal	Evidence file, support-period statement, legal review of disclosure delays	Map each Annex VII item to an owner and storage location
SME owner / board	Resourcing, support-period commitments	Approve the support period per product line; fund on-call cover

Breach	Maximum administrative fine	Basis
Annex I essential requirements, including Part II, and Articles 13 and 14	EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher	Art 64(2)
Incorrect, incomplete or misleading information to authorities on request	EUR 5 million or 1%	Art 64(4)

The full obligation map, from conformity assessment to CE marking, is in our Cyber Resilience Act compliance guide.

If your company is also a NIS2 entity, Article 21(2)(e) of Directive (EU) 2022/2555 adds “vulnerability handling and disclosure” for your own network and information systems. That is a second process with its own records, and it does not replace the product PSIRT.

Frequently asked questions

Must every vulnerability be patched?

Not with a dedicated update in every case. The FAQ says the CRA “does not require manufacturers to provide a patch for all vulnerabilities”, because point (2) ties remediation to “the risks posed”. Every flaw still needs a risk rating and a documented decision, and a serious flaw you cannot remediate triggers corrective action under Article 13(21). In the FAQ’s router example, a flaw in a library whose functions are never called may be documented without a dedicated update, and the unused library removed in a later regular release.

Do we have to publish our SBOM?

Recital 77 states that manufacturers “should not be obliged to make the SBOM public”, and Annex I Part II point (1) requires you to draw it up. It belongs in the technical documentation, which authorities can request.

Can we charge for security updates?

Not for the security updates point (8) covers, unless you have agreed otherwise with a business user for a tailor-made product.

How does this relate to NIS2 coordinated vulnerability disclosure?

Under NIS2 Article 12, each Member State designates a CSIRT as coordinator for coordinated vulnerability disclosure, and ENISA runs the European vulnerability database. Recital 76 of the CRA indicates that researchers should be able to report to manufacturers through those CSIRTs. Our guide to writing a vulnerability disclosure policy covers the NIS2 side.

Key takeaways

• Annex I Part II sets eight process duties and no day counts, so a documented, risk-based procedure is your main evidence that you handle vulnerabilities “without delay”.
• The duties apply to products placed on the market from 11 December 2027, for the support period; update availability and documentation retention can run longer. Products placed on the market before that date owe Article 14 reports only, unless they are substantially modified from 11 December 2027.
• Upstream reporting under Article 13(6) is narrower than it reads: only your component version, only flaws in the component itself, and none when you can confirm the maintainer already knows.
• Keep dated records of every triage decision, test review and disclosure delay. Article 13(7) requires systematic documentation of vulnerabilities, and the technical documentation, including test reports, must be kept for 10 years after placing on the market or for the support period, whichever is longer (Article 13(13)).

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 13, 14, 27, 64, 69 and 71, Annex I Part II, Annexes II and VII, Recitals 56, 60, 76 and 77. Official Journal of the European Union (linked above).
• European Commission, Annex to C(2026) 5252 final, Commission guidance on the application of Regulation (EU) 2024/2847, 27 July 2026, section 4.4.2 (para 124), section 5 (paras 125–131), section 9.1 (para 213) and section 9.2 (paras 222–240) (linked above).
• European Commission services, FAQs on the Cyber Resilience Act, version 1.4, 4 September 2026, sections 4.3 and 5.3 (linked above).
• CEN-CENELEC, CRA Unlocked part 2: STAN4CR webinar slides, 5 March 2026, on prEN 40000-1-3 Vulnerability handling (linked above).
• FIRST, PSIRT Services Framework, version 1.1 (linked above).
• Directive (EU) 2022/2555 (NIS2), Articles 12 and 21(2)(e).
• IETF, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, April 2022 (linked above).
• OASIS, Common Security Advisory Framework Version 2.0, Errata 01, 26 January 2024 (linked above).