Annex I Part II of the EU Cyber Resilience Act is about vulnerability handling — intake, inventory, triage, remediation, disclosure, and proof the loop works. That is not Article 14. Article 14 is the reporting clocks (24h / 72h / final) via ENISA’s Single Reporting Platform, which already applies to manufacturers from 11 September 2026.
Main essential requirements, including vulnerability handling, apply from 11 December 2027 (Commission CRA overview). Use this post as the handling checklist; use the Article 14 reporting post for the clocks.
What Annex I Part II is asking teams to evidence
Manufacturers need processes — and records — to identify and document vulnerabilities (including dependencies), assess and prioritize by risk, remediate or mitigate with clear ownership, and inform users. Auditors and buyers want a trail: finding → decision → fix → verification → communication — not a slide.
Checklist: evidence that usually holds up
1. Intake that is not a black hole
- Public or coordinated vulnerability disclosure channel with SLA language
- Ticket or case ID for every accepted report
- Duplicate / out-of-scope decisions recorded (not just deleted)
2. Inventory that maps to the product
- SBOM or equivalent dependency inventory for each in-scope product version
- Mapping from component → product SKU / release train
- Clear owner for third-party and open-source components
3. Triage with intent, not only severity labels
- Exploitability and exposure context (where the code runs, who can reach it)
- Business impact note (data, safety, availability) in plain language
- Priority that can disagree with raw CVSS when justification is documented
4. Remediation that engineering will merge
- Fix path is a reviewable change (PR / patch / config) — not a PDF recommendation
- Intent preserved: what the system was supposed to do still holds after the fix
- Verification steps and regression notes attached to the case
5. Disclosure and customer communication
- Template for security advisories / release notes
- Timeline of when customers were notified for material issues
- Archive of what was said, to whom, and when
6. Metrics that prove the loop works
- Time-to-triage and time-to-fix for high/critical
- Backlog age for open vulns (not just count)
- Recurrence / reopen rate after “fixed”
What fails audits (and buyers)
- Scans without owners or without a path to a merged fix
- “We use vendor X” with no product-level evidence for your digital element
- Severity theater that never becomes a shipped change
CRA readiness here is a loop: discover → decide → fix safely → evidence. Detection alone is not Annex I handling.
How UnitOne fits the handling loop
Intent-preserving remediation turns findings into Fix Specs and reviewable PRs — the mergeable middle of Annex I handling. Reporting clocks stay on the Article 14 runbook and the SRP.
Request a remediation POC when you need scoped proof on real findings. Read CRA Article 14 reporting for the 24/72/final path.
Sources: Commission — Cyber Resilience Act; Commission — CRA reporting obligations.