Why should a product manager care about vulnerability disclosure and handling? What outcomes does the CRA want?
CRA vulnerability obligations are tied to the product and last the whole support period. Annex I Part II lists eight vulnerability handling requirements; according to the 2024 mapping analysis by the EU JRC and ENISA:
| Standard | Annex I Part II coverage |
|---|---|
| ISO/IEC 29147 | Four of the eight (points 2, 4, 5, 6) |
| ISO/IEC 30111 | Five of the eight (points 2, 4, 5, 6, 8) |
SBOM (point 1), regular testing and review (point 3) and secure distribution of updates (point 7) are not mapped to these two standards and must be covered by other standards or procedures. The report is an analysis, not a harmonised standard, and creates no presumption of conformity.
What do we publish externally? How do customers and researchers find our reporting contact?
The typical 29147 deliverables are the product's external vulnerability front door:
- security.txt and a reporting mailbox or form
- Intake and response SLAs
- A CVD policy (with a safe-harbour statement)
- Advisory templates and a publishing process, plus a CVE ID request procedure where needed
The CRA also requires a contact address for reporting vulnerabilities (Annex I Part II point 6) and a single point of contact (Article 13(17)). This information goes into product documentation and the website, so the product manager should make sure the contact has an owner and the response times can be met.
How do fixes and security updates fit into product releases and shipping cadence?
30111 splits handling after a report into five gates, each needing an owner and a time limit:
| Gate | What to decide |
|---|---|
| Intake and verification | Whether the report holds, whether it can be reproduced, which products and versions are affected |
| Rating | Which criteria set severity and handling time |
| Remediation | Who owns fixes, workarounds and testing |
| Release | How security updates reach users and when the advisory is published |
| Review | Root cause analysis and process improvement |
The CRA requires remediation without delay and, where technically feasible, security updates provided separately from functional updates. Common gaps are bundling the two together and having no product and component inventory, so the impact cannot be judged.
Do old and discontinued models still need vulnerability handling during the support period?
Yes. The CRA requires manufacturers to handle vulnerabilities effectively under Annex I Part II from launch and throughout the support period (Article 13(8)):
- The support period is at least five years, or the expected use time if shorter
- The end date (at least month and year) must be clearly indicated at the time of purchase (Article 13(19))
- Each security update issued during the support period stays available for at least 10 years or the rest of the support period, whichever is longer (Article 13(9))
- Security updates are free of charge unless otherwise agreed for tailor-made products
"Nobody owns old versions and discontinued models" is a common gap at the remediation gate; the end-of-life plan should name an owner for the support period.
Will CRA reporting deadlines disrupt post-launch maintenance?
The Article 14 reporting obligations have applied since 11 September 2026 and also cover products placed on the market before 11 December 2027:
- Actively exploited vulnerabilities: early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days after a corrective or mitigating measure is available
- Severe incidents affecting product security: early warning within 24 hours, notification within 72 hours, final report within one month of the incident notification
Reports go through the ENISA single reporting platform. An existing security incident procedure is a good base, but incident handling deals with attacks that have happened while vulnerability handling deals with reported weaknesses; triggers, deadlines and outputs differ, so a vulnerability-specific process and records are still needed.
Does a small company need a PSIRT? How far must we go to have evidence to show?
No large team is needed, but a clear intake channel, owners and a response process are. Outputs are built to be auditable by notified bodies and customers:
- Vulnerability handling policy and process documents
- Rating criteria (for example localised CVSS criteria)
- Handling records and SLA reporting
- An SBOM linkage procedure
- Interface documents with the 29147 disclosure side
The editions in force are ISO/IEC 29147:2018 and ISO/IEC 30111:2019; revisions have been registered in ISO/IEC JTC 1/SC 27, but new editions have not yet been published.
How does Winners Consulting help product managers with ISO/IEC 29147 and 30111?
Winners Consulting implements 29147 and 30111 as a pair so that no audit gap is left at the hand-over:
- security.txt, a reporting mailbox or form, intake and response times, a CVD policy and an advisory process
- "Who takes the report, who verifies, who rates, who fixes, who releases, how fast" written as an auditable process with SLAs
- For multi-product-line companies, a cross-line mechanism for assessing vulnerability impact
- For ISO 27001 holders, the CVD process attached to the existing ISMS, sharing documents and audits
Winners' own delivery pipeline generates, signs and monitors SBOMs daily; VP- and director-level consultants lead the work end to end, never outsourced. Read more: ISO/IEC 29147, ISO/IEC 30111, Choosing a 29147 consultant, Choosing a 30111 consultant. Request a free mechanism diagnosis
How other roles see this service
Other services for this role
- EU CRA for product managers: is my product in scope, and what must be ready before launch?
- EU AI Act for product managers: what must the AI in our product complete before launch?
- IEC 62443-4-2 for product managers: will industrial product certification delay our launch?
- ISO/SAE 21434 for product managers: how does an automotive product pass carmaker development audits?
- ISO 42001 for product managers: how do we answer customer demands on AI product governance?
- TISAX prototype protection for product managers: will a missing label block a carmaker project?
- ISO 27701 and GDPR for product managers: which privacy work comes first when selling into each market?