EU Cyber Resilience Act: Vulnerability Handling Guide (Art 13-14)

What the CRA Actually Is, in One Paragraph

The Cyber Resilience Act is a regulation, not a directive. It applies directly in every EU Member State without national transposition. It sets cybersecurity essential requirements (Annex I Part 1) and vulnerability-handling essential requirements (Annex I Part 2) that every product with digital elements placed on the EU market must meet. It defines four product classes by risk level, four conformity-assessment routes that depend on class, and a continuous obligation across the support period that does not stop when the product ships. The vulnerability-handling and reporting obligations sit on the manufacturer; importers and distributors carry due-diligence obligations rather than primary handling obligations.

Two articles do most of the operational work. Article 13 codifies the manufacturer vulnerability-handling discipline: identify and document vulnerabilities and components, address them without delay, provide security updates separately and free of charge, maintain a coordinated vulnerability disclosure policy, and keep evidence for the support period. Article 14 codifies the reporting obligations: early warning within 24 hours, notification within 72 hours, and final report within 14 days for actively-exploited vulnerabilities and severe incidents impacting the security of the PDE. These are not aspirational targets. They are statutory deadlines tied to the manufacturer's awareness of the underlying event.

For an AppSec, product security, or GRC owner, the practical CRA posture is a recurring vulnerability-handling record per product covered by the regulation, reconcilable across the support period, defensible against a market surveillance authority that asks to read it, and operable by an internal team that does not scale linearly with the product portfolio. The work is the work; what changes is the audit-readiness discipline behind it.

Who Must Comply, and When

The CRA covers manufacturers placing a product with digital elements on the EU market. The definition of PDE is broad: any software or hardware product, and any remote data-processing solution provided alongside it, whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. That is, in practice, almost every commercial software and hardware product, including pure SaaS where remote data processing forms part of the product, except for narrow exclusions (medical devices already covered by MDR and IVDR, motor vehicles covered by UN Regulation No. 155, civil aviation under Regulation 2018/1139, marine equipment under Directive 2014/90, and free and open- source software not made available in the course of a commercial activity).

The application-date staircase has three load-bearing dates. Reporting obligations under Article 14 begin to apply on 11 September 2026, around four months from this writing. Conformity-assessment-body designation rules apply on 11 June 2026. The full body of CRA obligations applies on 11 December 2027. Manufacturers selling into the EU market on or after these dates need the corresponding evidence in place; placing a non-conformant product on the market triggers market-surveillance enforcement, which can include withdrawal orders and administrative fines up to EUR 15 million or 2.5 percent of global annual turnover, whichever is higher.

Three populations of buyers ask for the supporting record: market surveillance authorities directly, EU customers running supplier security reviews against the CRA expectation, and increasingly, non-EU customers reading the CRA evidence pack as a baseline because it is broader than most national PDE regimes. Internal AppSec teams at PDE manufacturers find themselves drafting the same evidence multiple times per quarter unless they consolidate it onto a single record.

CRA vs NIS2 vs DORA: Three Regulations, Different Subjects

The EU cybersecurity regulatory landscape is dense, and CRA is often confused with the directives next to it. The three pieces compose; they do not replace each other.

Article 13: The Vulnerability Handling Discipline

Article 13 codifies the manufacturer vulnerability-handling discipline across the support period. The article reads through Annex I Part 2 of the regulation, which enumerates the operational requirements. The seven obligations below are the operating shape of the article, each with the supporting evidence a market surveillance authority or a customer reading the record expects to see.

Article 14: The Reporting Cascade

Article 14 codifies the reporting obligations for actively-exploited vulnerabilities and severe incidents impacting the security of the PDE. The cascade is a three-step timeline anchored on the manufacturer's awareness of the event. Reporting goes through the single reporting platform operated by ENISA together with national CSIRTs; the manufacturer does not pick the recipient.

The clock starts when the manufacturer becomes aware. "Awareness" is read as the moment a credible internal owner can no longer dismiss the event; a triage queue timestamp on the ticket is the practical anchor. The 24-hour, 72-hour, and 14-day deadlines are statutory; missing them is a violation independently of whether the underlying remediation is on track. This is why the timestamp discipline behind the awareness moment matters more than the calendar arithmetic on the deadline.

"Actively-exploited" is read narrowly: there must be reliable evidence of exploitation in the wild, not theoretical exploitability or proof-of-concept availability. "Severe incident" is read against the impact on the security of the PDE: confidentiality, integrity, availability, or authentication compromise that affects users. Routine vulnerability discovery does not trigger Article 14; handling under Article 13 is the path. Manufacturers running both paths in parallel without confusing them is the operational shape the regulation expects.

The Support Period and the Five-Year Default

The CRA introduces a support period during which the manufacturer must address vulnerabilities and provide security updates. The default is the expected lifetime of the product, with a minimum of five years from placing on the market unless the expected use period is genuinely shorter (consumer accessories with a known twelve-month replacement cycle are the canonical short-lifetime case). The support period must be communicated to users at the time of purchase or download, and a manufacturer cannot silently shorten it after the fact.

Manufacturers commonly underestimate the operational weight of the support period. The same security-update obligation, the same vulnerability handling, and the same reporting cascade apply equally to a product placed on the market in the first month of CRA enforcement and a product still in the support period four years later. Engineering planning has to account for back-port maintenance, and the evidence record has to reconcile across the entire window, not just the most recent release.

For free and open-source components shipped inside a commercial PDE, the manufacturer is responsible for the support-period obligation, not the upstream maintainer. The OSS exclusion in the CRA covers software not made available in the course of a commercial activity; the moment a manufacturer ships an OSS component as part of a commercial PDE, the obligation lands on the manufacturer. This is why SBOM completeness and pinned-version discipline matter more under the CRA than they do under most other compliance regimes.

The Supporting Evidence Stack

The CRA does not enumerate a fixed evidence list. It requires a manufacturer to be able to demonstrate compliance under Article 32 if a market surveillance authority asks. In practice the defensible record covers eight artefact families, each tied to a verifiable process behind it.

The first time a manufacturer assembles this stack the work is substantial; the recurring cycle once the stack is stood up is materially shorter because most of the artefacts are already produced as part of the engineering programme. The failure mode is treating each customer audit, market surveillance review, or self-assessment as a bespoke evidence draft rather than a read of the same canonical record.

Common Failure Modes

CRA, NIS2, and the Supply-Chain Reading

CRA does not stand alone in the supply-chain reading. NIS2 Article 21 obliges essential and important entities to manage supply-chain security, including the security of suppliers and direct providers. CRA gives those NIS2 entities a structured artefact to read against: the supplier's CRA conformity record, the published SBOM, the coordinated disclosure policy, and the support-period statement. A supplier who cannot produce these artefacts is structurally weak in any NIS2 buyer's supplier review, even if the buyer is technically reading NIS2 and the supplier is technically reading CRA.

For DORA-regulated financial entities buying PDEs from CRA-regulated manufacturers, the same shape applies: DORA Article 28 third-party ICT risk management reads against the supplier's CRA evidence pack. The financial entity is not asking for a different artefact; it is asking for the same artefact through a different regulatory lens. Manufacturers operating one canonical evidence record answer all three reads (CRA conformity, NIS2 supplier review, DORA third-party risk) without drafting three separate packs.

How SecPortal Helps Manufacturers Run the Stack

SecPortal does not place products on the EU market, file declarations of conformity, submit to the ENISA single reporting platform, or act as the manufacturer's authorised representative. Those actions remain the manufacturer's, taken through the relevant regulatory interfaces. What SecPortal does is hold the recurring evidence record that Articles 13 and 14 read against, on a single workspace, reconcilable across the support period, and exportable to the customer, the 3PAO, the notified body, or the market surveillance authority that asks.

• The CRA programme per product becomes a versioned engagement record with named participants, the support-period start and end dates, the conformity route, and the renewal triggers documented in one place.
• The vulnerability inventory lives in findings management with CVSS-aligned severity, the CVE identifier, the affected versions, the owner, the target close date, and the audit trail of every state change.
• The SBOM, the coordinated disclosure policy, the technical documentation, the EU declaration of conformity, and the per-cycle support-period statement land in document management with versioning, timestamps, and author attribution.
• The Article 13 test and review cadence comes from external scanning, authenticated scanning, code scanning via Semgrep SAST and SCA, and continuous monitoring with scheduled scans, with each scan result carrying its own audit trail.
• The Article 14 reporting timeline runs against the activity log, with timestamped state changes per user, retained on the plan-defined window, and exportable to CSV when a regulator or customer reads the cascade.
• The CRA expectations map to compliance tracking alongside ISO 27001, SOC 2, PCI DSS, and NIST framework mappings, so closing a control reflects across every parallel compliance read at once.
• The development-environment posture lands behind MFA, team management with role-based access controls, and AES-256-GCM encrypted credential storage for credentials referenced by the evidence record.
• The narrative read for a notified body, a 3PAO, or a market surveillance authority can be drafted by AI report generation from the live evidence; named author edits, named approver signs off, and the AI accelerates the draft rather than substitutes for the security author.

The platform is the recurring evidence record, not the regulatory submission. The manufacturer still files the conformity declaration, the technical documentation, and the Article 14 reports through the relevant authority interfaces. SecPortal keeps the supporting record reconcilable across the support period so the submissions are grounded in the evidence rather than reconstructed from email threads.

A Practical Rollout Plan

Manufacturers approaching the CRA for the first time benefit from a sequenced rollout rather than a horizontal compliance push. The order below reflects the dependencies inside the regulation: classification first, because conformity route depends on class; SBOM and vulnerability ledger second, because every other obligation reads against them; disclosure programme third, because that is the public-facing intake the regulation expects; reporting readiness fourth, because September 2026 is the closest deadline; and the recurring discipline last, because the support-period obligation continues for at least five years.

1. Classify each PDE against Annex III and IV. Identify whether the product is default, important class I, important class II, or critical, and pick the conformity route that maps to the class. The classification frames every downstream decision.
2. Stand up the SBOM and the vulnerability ledger. Adopt SPDX or CycloneDX as the SBOM format, pin dependencies, ingest scanner output into the ledger, and establish the link between SBOM components and ledger entries. See the SBOM guide for the format-level treatment.
3. Publish the coordinated vulnerability disclosure policy. Use ISO/IEC 29147 as the structural anchor, name the safe harbour, define the triage SLA, and route intake into the same vulnerability ledger that holds scanner findings. See the vulnerability disclosure programme setup guide for the operating shape.
4. Stand up the Article 14 reporting readiness. Designate the awareness-timestamp owner, document the rubric for actively-exploited vs routine, draft the early-warning template, the 72-hour notification template, and the 14-day final-report template, and run a tabletop against a recent CVE to validate the cascade.
5. Stand up the security-update release path. Confirm the pipeline can ship security-only releases separately from feature releases, document the release notes discipline, and align the per-vulnerability advisory format with the public disclosure expectations.
6. Stand up the test and review cadence. Configure SAST and SCA in the pipeline, configure secret scanning, define the threat-modelling cadence per major feature, archive scanner result history per release, and reconcile the cadence against the Article 13 "regular tests and reviews" expectation.
7. Document the support-period statement per product, communicate it to users at point of purchase or download, and reconcile the statement to the engineering capacity plan that has to maintain the support obligation.
8. Brief the named CRA point of contact. Walk through the seven Article 13 obligations, the three Article 14 deadlines, the five-year support default, and the conformity route. Document the brief.
9. File the EU declaration of conformity, affix the CE mark where applicable, and place the product on the market. Archive the submission alongside the evidence pack. Set the recurring review cycle and the renewal triggers.

Wider Reading

• Cyber Resilience Act framework page for the product-class taxonomy, the essential requirements catalogue, and the conformity-assessment routes the regulation defines.
• NIST SSDF implementation guide for the practice catalogue the CRA Article 13 obligations read against.
• CISA SSDA form guide for the federal-procurement self-attestation that runs the same SSDF practice clusters from the US side, with a different reporting cadence.
• SBOM guide for the SPDX vs CycloneDX format treatment behind the CRA Article 13 inventory obligation.
• VEX guide for the per-CVE exploitability filter that pairs with SBOM in the vulnerability-handling cluster.
• SLSA framework guide for the build-integrity scaffold the CRA evidence pack references for code provenance.
• Vulnerability disclosure programme setup guide for the operating shape of the coordinated disclosure policy Article 13 requires manufacturers to maintain.
• Vulnerability management programme guide for the operational triage and remediation discipline the Article 13 vulnerability handling reads against.
• CISA KEV catalog guide for the actively-exploited signal that anchors the Article 14 reporting trigger.
• CVE Numbering Authority explained for the upstream identifier-issuance layer behind public advisories under the Article 13 dissemination obligation.
• PSIRT product security incident response workflow for the operational PSIRT case lifecycle that runs the Article 13 vulnerability handling and the Article 14 reporting cascade against one structured engagement record per case.
• Vendor security questionnaire response workflow for the customer-facing read that consumes the same CRA evidence pack.
• Control mapping cross-framework crosswalks for the canonical control library the CRA reads against alongside ISO, SOC 2, PCI DSS, and NIST.
• Audit evidence retention and disposal for the lifecycle policy that governs how long each CRA artefact stays in the record across the five-year support period.
• NIS2, DORA, ISO 27001, and CISA Secure by Design for the framework-side reads that share the same evidence stack the CRA consumes.
• SecPortal for product security teams and SecPortal for GRC and compliance teams for the persona-side reading paths into the CRA evidence record.

Scope and Limitations

This guide describes the structure and operational shape of the EU Cyber Resilience Act, Regulation (EU) 2024/2847, as the regulation reads at the time of writing. Specific implementation details, the harmonised standards referenced, the in-force product class lists, the implementing acts, and the operational interfaces of the ENISA single reporting platform evolve over time. The authoritative reference for the in-force obligations and implementation guidance remains the published text of the regulation and the European Commission acts that follow it.

The dates noted in this guide (11 June 2026 for conformity-assessment-body designation, 11 September 2026 for reporting obligations, 11 December 2027 for the full body of obligations) reflect the application-date staircase as published. Manufacturers should confirm the application dates against the current Official Journal text and any subsequent legislative amendments before committing programme deadlines. Nothing in this guide constitutes legal advice; CRA programme decisions should be reconciled with qualified legal counsel and, where applicable, with a notified body.