How Do Machinery Manufacturers Implement CRA Vulnerability Handling Under the VDMA Guideline?
The VDMA CRA Vulnerability Handling Guideline defines a structured process for machinery and component manufacturers to handle product vulnerabilities. It aligns organizational roles, engineering defect remediation, and mandatory ENISA Article 14 reporting with harmonised European standards.
Key takeaways
- The German Engineering Federation (VDMA) published practical guidance for manufacturers in scope of Regulation (EU) 2024/2847.
- The guideline implements draft standard prEN 40000-1-3, ISO/IEC 29147, ISO/IEC 30111, BSI TR-03183-3, and the FIRST PSIRT Framework.
- Manufacturers must establish both an internal vulnerability handling policy and a public Coordinated Vulnerability Disclosure (CVD) policy with an RFC 9116 security.txt file.
- Product Security Incident Response Teams (PSIRTs) must acknowledge incoming vulnerability reports within 7 calendar days.
- Actively exploited vulnerabilities require early warning to the ENISA Single Reporting Platform (SRP) within 24 hours and a detailed notification within 72 hours.
- Defect remediation priorities depend on functional safety impact, CVSS metrics, and practical exploitability.
What is the VDMA CRA Vulnerability Handling Guideline?
The VDMA Competence Center Industrial Security published the CRA Vulnerability Handling Guideline in April 2026. Authors from industrial manufacturers, including Siemens, ifm, Rolls-Royce Power Systems, Liebherr, GEA Group, and Weidmüller, defined this practical standard for Regulation (EU) 2024/2847 (Cyber Resilience Act).
The guideline addresses mechanical engineering companies, component manufacturers, software suppliers, and industrial system integrators. It provides baseline organizational, procedural, and technical controls across the product lifecycle.
| Requirement Domain | VDMA Guideline Recommendation | Applicable Standard |
|---|---|---|
| Primary Standard | prEN 40000-1-3 | CRA Article 13 and Article 14 |
| Public Disclosure | ISO/IEC 29147 | CRA Annex I Part II Point (5) |
| Internal Handling | ISO/IEC 30111 and BSI TR-03183-3 | CRA Annex I Part II Point (1) |
| Incident Framework | FIRST PSIRT Framework | CRA Article 14 |
| Reporting Effective Date | 11 September 2026 | CRA Article 69(2) |
The Six Phases of Vulnerability Management
The VDMA framework structures vulnerability management into six sequential phases.
+---------------------------------------------------------------------------------------------------+
| ORGANISATION |
| (Governance, Policies, PSIRT Structure, ECSF Skills, Cross-Department Coordination) |
+---------------------------------------------------------------------------------------------------+
| 1. Preparation | 2. Receipt | 3. Verification | 4. Remediation | 5. Release | 6. Post-Release |
+----------------+------------+-----------------+----------------+------------+------------------+
1. Preparation
Manufacturers must prepare inventories before reports arrive.
- Identify products and components with Software Bill of Materials (SBOM).
- Conduct initial risk assessments based on intended product use.
- Assign vulnerability verification roles to product development teams.
2. Receipt
Manufacturers must provide stable intake channels.
- Maintain dedicated functional mailboxes like [email protected] or [email protected].
- Publish web intake forms and RFC 9116 security.txt files on corporate websites.
- Provide public PGP keys for encrypted submissions.
- Monitor vulnerability databases such as the ENISA European Vulnerability Database (EUVD) and NIST NVD.
- Acknowledge incoming vulnerability reports within 7 calendar days.
3. Verification
Staff review incoming reports in two stages.
- Initial evaluation: Check scope, verify plausibility, and classify data sensitivity using Traffic Light Protocol (TLP 2.0).
- Detailed analysis: Reproduce the vulnerability on product hardware, calculate CVSS scores, and confirm practical exploitability.
4. Remediation
Engineering teams execute defect management under ISO 9001 quality controls.
- Perform root cause analysis.
- Develop and verify patches or temporary workarounds.
- Evaluate residual exploitation risk before release.
5. Release
Publish coordinated advisories.
- Issue structured security advisories using CSAF 2.0.
- Distribute security updates over authenticated channels.
- Coordinate disclosure timing with finders and authorities.
6. Post-Release
Integrate fixes into long-term operations.
- Include patches in regular production baselines to protect new units.
- Update supplier requirements for future component procurement.
- Review process performance in post-mortem sessions.
Vulnerability Handling Process Diagram
The diagram below maps the workflow across the security researcher, the PSIRT triage team, product engineering, and ENISA.
+-------------------------------------------------------------------------------------------------------------------------------+
| FINDER (Researcher) | FIRST RESPONDER (PSIRT Triage) | PRODUCT DEVELOPMENT (Engineering) | ENISA / AUTHORITIES |
+-----------------------------+----------------------------------+-----------------------------------+--------------------------+
| | | | |
| [Identifies Vuln in Product]| | | |
| | | | | |
| v | | | |
| (Submits via security.txt)=======> [Validate Report] | | |
| | | | | |
| | Is report valid? | | |
| | / \ | | |
| | (No) (Yes) | | |
| | | | | | |
| [Receives Invalid Notice] <-------+ v | | |
| [Close Ticket] | [Acknowledge within 7 days]| | |
| | [Determine Report Type] | | |
| | / \ | | |
| | (Claims Active) (Normal Vuln| | |
| | | | | | |
| | v v | | |
| | [Create Urgent Ticket] [Create | | |
| | || Ticket] | | |
| | || | | | |
| | \\===================\=========> [Verify in Product] | |
| | | | | |
| | | Reproducible in product? | |
| | | / \ | |
| | | (No) (Yes) | |
| | | | | | |
| [Receives Rejection] <-----------------------------------------------+ v | |
| [Close Ticket] | | [Mark Known & Potentially] | |
| | | [Exploitable Vulnerability] | |
| | | | | |
| | | Practical Exploitability? | |
| | | / \ | |
| | | (No) (Yes) | |
| | | | | | |
| [Receives Rejection] <-----------------------------------------------+ v | |
| [Close Ticket] | | [Known Exploitable Vuln] | |
| | | [Determine Urgency] | |
| | | | | |
| | | Reliable Active Exploitation? | |
| | | / \ | |
| | | (No) (Yes) | |
| | | | | | |
| | | | v | |
| | | | [Mark Actively] | |
| | | | [Exploited Vuln] | |
| | | | ! CRA ART. 14 ! | |
| | | | ! CLOCK STARTS! | |
| | | | | | |
| | | | +=================> [24h: Early Warning] |
| | | | | | | |
| | | | +=================> [72h: Notification] |
| | | | | | |
| | | v v | |
| | | [Root Cause Analysis] | |
| | | [Develop Mitigation] | |
| | | [Deploy Mitigation] | |
| | | [Assess Residual Risk] | |
| | | | | |
| | | Residual Risk Acceptable? | |
| | | / \ | |
| | | (No) (Yes) | |
| | | ^ | | |
| | | | v | |
| | | +-- (Iterate) [Advisory Docs] |
| | | | | |
| | | v | |
| | | [Notify Users / Responsible] | |
| | | [Disclosure Actions] | |
| | | | | |
| [Receives Mitigation &] <===================================================+ | |
| [Advisory Notice] | | | | |
| [Close Ticket] | | +=================> [14 Days: Final Report] |
| | | | | |
| | | | v |
| | | | [ENISA Processes &] |
| | | | [Publishes to KEV] |
+-------------------------------------------------------------------------------------------------------------------------------+
Remediation Priority Decision Logic
The VDMA guideline provides a decision tree to set engineering priority.
+-------------------------------------------------------------+
| Relevant Vulnerability Identified |
+-------------------------------------------------------------+
|
v
High CVSS Evaluation?
/ \
(Yes) (No: Low/Medium)
| |
v v
Functional Safety Impact? Standard Release Cycle
/ \
(Yes) (No)
| |
v v
Immediate Remediation Workaround Possible?
(Halt Project Work) / \
(No) (Yes)
| |
v v
Significant Damage? Prioritised Deployment
/ \
(Yes) (No)
| |
v v
Immediate Remediation Standard Release Cycle
Remediation Categories
- Immediate Remediation (Unverzügliche Bereitstellung): Applied when functional safety or operational integrity is compromised and no workaround exists. Teams halt active projects to remediate the vulnerability immediately.
- Prioritised Deployment (Priorisierte Bereitstellung): Applied when severe risks exist but interim mitigations protect systems. Teams prepare out-of-band updates on an accelerated timeline.
- Standard Release Process (Standard-Aktualisierungsprozess): Applied to low-risk or medium-risk defects. Fixes deploy in planned maintenance releases.
Mandatory CRA Article 14 Reporting Deadlines
Article 14 becomes mandatory on 11 September 2026. The VDMA guideline documents the notification schedule to the ENISA Single Reporting Platform (SRP):
| Notification Type | Statutory Deadline | Mandatory Content |
|---|---|---|
| Early Warning | Within 24 hours | Indication of active exploitation, suspicion of malicious acts, and affected EU Member States. |
| Vulnerability Notification | Within 72 hours | Technical description, sensitivity level, initial root cause, and remediation steps. |
| Final Report | Within 14 days | Root cause analysis, severity assessment, threat actor details, and corrective security updates. Deadline calculates from when a mitigation becomes available. |
| Severe Incident Final Report | Within 1 month | Comprehensive impact analysis, system effects, and remediation summary. Deadline calculates from initial incident report date. |
Mandatory Documentation for Manufacturers
The VDMA guideline defines four mandatory artifacts for compliance:
- Internal Vulnerability Policy: Defines internal responsibilities, engineering triage rules, and testing frequency.
- Public CVD Policy: Explains submission guidelines, safe harbor terms, and expected communication intervals.
- RFC 9116 security.txt File: Publishes contact routes, PGP keys, canonical URLs, and expiry dates at
/.well-known/security.txt. - Security Advisories: Issues CSAF 2.0 machine-readable advisories with product identification, CVE records, CVSS metrics, and remediation guidance.
Compliance Action for EU Manufacturers
CRA Article 14 reporting begins on 11 September 2026. Manufacturers must deploy intake infrastructure, assign PSIRT responsibilities, and test reporting channels before that date.
- Deploy an RFC 9116 security.txt file and a secure web intake portal.
- Form an internal PSIRT team and document Change Control Board procedures.
- Connect vulnerability intake to an Article 14 reporting system.
Register a free CRA-compliant disclosure portal on CVD Portal or review your posture with the CRA Readiness Checklist.