Six-Step Vulnerability Handling: How CRA Ensures Product Security Throughout Its Lifecycle

Introduction

The EU Cyber Resilience Act (CRA) Annex I Part II explicitly requires manufacturers to establish and maintain a vulnerability handling process spanning the entire product lifecycle. This means that cybersecurity is not an “add-on option” after product launch, but a continuous obligation from design to decommissioning.

This article will provide an in-depth interpretation of the six-phase vulnerability handling process defined in prEN 40000-1-3, helping enterprises understand how to build a vulnerability management system that complies with CRA requirements.

What is a Vulnerability Handling Process?

A vulnerability handling process refers to a systematic approach used by manufacturers to identify, assess, remediate, and release security vulnerabilities. It differs fundamentally from traditional “patching”:

Traditional Patch Management	CRA-Required Vulnerability Handling
Passive response to vulnerabilities	Proactive monitoring of internal and external sources
Temporary fixes	Structured six-phase process
Lack of transparency	Complete documentation and records
No clear time requirements	Risk-based SLA

Spanning the Product’s “Lifetime”

CRA requires vulnerability handling to cover the entire support period of the product, minimum 5 years:

Product Design ──► Product Release ──► Operations ──► Decommissioning
    │              │                │              │
    └──────────────┴────────────────┴──────────────┘
                 Continuous Vulnerability Handling

Relationship with ISO Standards

prEN 40000-1-3 is built upon the following international standards:

• ISO/IEC 29147:2020 - Vulnerability disclosure standard
• ISO/IEC 30111:2020 - Vulnerability handling process standard
• ISO/IEC 27036-3:2023 - Supply chain security standard

Detailed Six-Step Process

prEN 40000-1-3 divides the vulnerability handling process into six phases, each with clear objectives, activities, and outputs.

graph TB
    subgraph PRE["[PRE] Preparation Phase"]
        PRE1[Policy Development<br/>Policy]
        PRE2[Component Identification<br/>SBOM]
        PRE3[Distribution Mechanism<br/>Distribution]
    end

    subgraph RCP["[RCP] Receipt Phase"]
        RCP1[Monitor Vulnerabilities<br/>Monitoring]
        RCP2[Receive Reports<br/>Receive]
        RCP3[Regular Testing<br/>Regular Tests]
    end

    subgraph VRF["[VRF] Verification Phase"]
        VRF1[Initial Assessment<br/>Assessment]
        VRF2[Risk Assessment<br/>Risk Analysis]
        VRF3[Prioritization<br/>Prioritization]
    end

    subgraph RMD["[RMD] Remediation Phase"]
        RMD1[Remediation Decision<br/>Decision]
        RMD2[Develop Remediation<br/>Development]
        RMD3[Test Validation<br/>Testing]
    end

    subgraph RLS["[RLS] Release Phase"]
        RLS1[Distribute Updates<br/>Distribute]
        RLS2[Publish Advisory<br/>Advisory]
        RLS3[Provide Information<br/>Information]
    end

    subgraph PRA["[PRA] Post-Release Phase"]
        PRA1[Monitor Effectiveness<br/>Monitor]
        PRA2[Lessons Learned<br/>Lessons]
        PRA3[Process Improvement<br/>Improve]
    end

    PRE --> RCP
    RCP --> VRF
    VRF --> RMD
    RMD --> RLS
    RLS --> PRA
    PRA -.->|Continuous Improvement| PRE

    style PRE fill:#e3f2fd
    style RCP fill:#fff3e0
    style VRF fill:#f3e5f5
    style RMD fill:#ffebee
    style RLS fill:#e8f5e9
    style PRA fill:#fce4ec

PRE: Preparation Phase

The preparation phase is the foundation of the vulnerability handling process, establishing necessary policies, processes, and capabilities for all subsequent activities.

Core Activities

Activity	Description	Key Output
Vulnerability Handling Policy	Establish internal handling processes and responsibilities	Vulnerability handling policy document
CVD Policy	Establish external coordinated disclosure mechanism	CVD policy document
Component Identification	Create Software Bill of Materials (SBOM)	SBOM file
Distribution Mechanism	Design secure update distribution system	Update mechanism documentation
Testing Plan	Develop regular testing and review plans	Testing and review plan

CVD Policy Key Points

Coordinated Vulnerability Disclosure (CVD) policy is a mandatory requirement of CRA and must include:

• Contact mechanism: security@company.com, Web form, phone hotline
• Response commitment: Clear response time framework (e.g., confirmation within 48 hours)
• Coordination process: Explain how to coordinate disclosure timing with reporters
• Publicly accessible: Policy must be publicly published on the website

SBOM Requirements

Software Bill of Materials (SBOM) is the core tool for vulnerability handling:

SBOM Structure
├── Metadata: author, version, timestamp
├── Component List
│   ├── Component name, version, supplier
│   ├── Direct dependencies (top-level)
│   └── Transitive dependencies (enhanced requirement)
├── Dependency relationship graph
└── Component hash values (enhanced requirement)

Format requirements: SPDX (ISO/IEC 5962:2021) or CycloneDX

RCP: Receipt Phase

The receipt phase is responsible for monitoring information and receiving reports, serving as the first line of defense for proactive vulnerability discovery.

Monitoring Sources

External sources:

• EU Vulnerability Database (EUVD)
• NVD (National Vulnerability Database)
• CVE (Common Vulnerabilities and Exposures)
• Vendor security advisories
• Industry security alerts

Internal sources:

• Regular security testing
• Penetration testing results
• Code review findings
• Customer support feedback

Report Reception Mechanism

Manufacturers must provide publicly accessible reporting mechanisms:

Reporting Channels
├── Email: security@company.com
├── Web form: Online submission system
├── Phone hotline: Accessibility support
└── PGP encryption: Secure communication option

Regular Testing

Testing frequency based on product risk level:

Product Risk Level	Testing Frequency	Review Frequency
Low (Category I)	Annually	Annually
Medium (Category II)	Semi-annually	Semi-annually
High (Category III)	Quarterly	Quarterly
Critical Infrastructure	Monthly	Monthly

VRF: Verification Phase

The verification phase (also known as Triage phase) is responsible for assessing vulnerability validity and determining priority.

Verification Process

Receive Report → Information Integrity Check → Attempt Reproduction
    ↓
Assess Impact → Determine Severity → Assign Priority
    ↓
Notify Reporter (CVD case)

Verification Result Classification

Result	Description	Follow-up Handling
Confirmed	Vulnerability exists and applies to product	Enter remediation phase
Confirmed but not applicable	Vulnerability exists but does not affect this product	Record and archive
Cannot reproduce	Unable to reproduce as described	Request more information
Not a vulnerability	Reported issue is not a security vulnerability	Explain reasons

Risk Assessment Framework

Risk Assessment = Exploitability × Impact

Exploitability factors:

• Attack complexity
• Required privileges
• User interaction requirements

Impact factors:

• Data confidentiality
• Data integrity
• System availability
• Personal safety (functional safety)

Priority Assignment

Priority	CVSS Score	Response SLA	Remediation Target
Critical	≥ 9.0	48 hours	7-30 days
High	7.0-8.9	72 hours	30-90 days
Medium	4.0-6.9	1 week	90-180 days
Low	< 4.0	2 weeks	Next release

RMD: Remediation Phase

The remediation phase is responsible for making decisions, developing fixes, and testing validation.

Remediation Decision Options

Decision Types
├── Full remediation: Release security update
├── Mitigation measures: Temporary mitigation measures
├── Configuration changes: Change configuration/settings
├── Documentation update: Update user documentation
└── Accept risk: Business decision, requires documented justification

Remediation Development Principles

Security update separation: Where technically feasible, security updates should be provided separately from functional updates, with advantages including:

• Smaller update package size
• Faster deployment speed
• Clearer identification
• Mandatory installation capability
• Reduced risk of functional changes

Remediation Testing Requirements

Testing Levels
├── Unit testing: Verify remediation code
├── Integration testing: Verify component interactions
├── System testing: Verify overall functionality
├── Regression testing: Ensure no side effects
├── Security testing: Verify vulnerability is fixed
└── Compatibility testing: Verify compatibility with different versions

RLS: Release Phase

The release phase is responsible for distributing updates and publishing advisories.

Security Update Distribution Requirements

Requirement	Description
Free of charge	Security updates must be free (except for custom products)
Timely distribution	Time requirements based on priority
Secure distribution	Ensure authenticity and integrity
Installation instructions	Clear installation guidance

Distribution Mechanisms

Distribution Methods
├── Automatic Updates
│   ├── Background automatic download and installation
│   ├── Automatic download with user prompt to install
│   └── Regular check notifications
├── Manual Updates
│   ├── Download center
│   ├── Update server
│   └── Physical media (offline environments)
└── Hybrid Mode
    ├── Automatic detection
    └── User confirmation for installation

Security Advisory Content

Security advisories must include the following information:

• Vulnerability description
• Vulnerability identifier (CVE)
• Affected product versions
• Potential impact
• Severity (CVSS score)
• Remediation details
• Update download location
• Installation instructions
• Release date

PRA: Post-Release Phase

The post-release phase focuses on monitoring effectiveness and continuous improvement.

Monitoring Activities

Monitoring Content
├── Update deployment rate
├── Update success rate
├── Remediation effectiveness verification
├── New issue reports
├── User feedback collection
└── Performance impact monitoring

Lessons Learned

After each vulnerability handling completion, summarize:

• What went well: Successful experiences and practices
• What could be improved: Identify bottlenecks and issues
• Unexpected issue handling: Response to unexpected events
• Timeline analysis: Time spent evaluation for each phase
• Resource usage evaluation: Personnel and tool usage

Continuous Improvement Cycle

Release Update → Monitor Deployment → Collect Feedback → Assess Effectiveness
    ↑                                                        ↓
    └──────────── Capture Lessons → Identify Improvements → Implement Improvements ──┘

How Should Enterprises Implement?

Establish a Vulnerability Response Team

Recommended organizational structure:

Product Security Officer (PSO)
    │
    ├── Vulnerability Management Team
    │       ├── Triage Team (Assessment)
    │       ├── Remediation Team (Development)
    │       └── Release Team (Deployment)
    │
    ├── Security Team
    │       ├── Security Testing
    │       └── Risk Assessment
    │
    └── Support Team
        ├── Customer Support
        ├── Public Relations Communication
        └── Legal Counsel

Design Disclosure Mechanism

CVD policy publication:

1. Publish CVD policy on official website
2. Add security.txt file in website root directory
3. Provide multiple reporting channels
4. Clear response time commitment

Internal process:

1. Establish vulnerability tracking system
2. Assign case numbers
3. Set up automatic confirmation response
4. Regular status updates

Plan Update Distribution

Update mechanism design:

1. Support automatic and manual updates
2. Implement digital signature verification
3. Ensure secure transmission (HTTPS/TLS)
4. Provide offline update options

Distribution strategy:

1. Phased deployment (avoid updating all devices simultaneously)
2. Canary release (test in small scope first)
3. Rollback mechanism (restore when update fails)
4. Maintenance window coordination

Comparison with ISO Standards

Standard	Full Name	Relationship with prEN 40000-1-3
ISO/IEC 29147	Vulnerability disclosure	Basic requirements for CVD policy
ISO/IEC 30111	Vulnerability handling processes	Basic framework for six-phase process
prEN 40000-1-3	Product Cybersecurity - Vulnerability Handling	CRA harmonized standard, specific implementation requirements

prEN 40000-1-3 adds to ISO standards:

• SBOM requirements
• More specific six-phase activities
• Risk-based approach
• EU-specific requirements (EUVD)
• 5-year minimum support period

Key Takeaways

1. Vulnerability handling is a core CRA requirement (Annex I Part II), not optional
2. Six-phase process provides a structured methodology from preparation to post-release continuous improvement
3. SBOM is the core tool for component identification and impact analysis
4. CVD policy is mandatory and must be publicly published
5. Security updates must be free and distributed in a timely manner
6. Support period minimum 5 years, continuous obligation throughout product’s “lifetime”

Further Reading

• CRA Compliance Series: Product Cybersecurity Risk Assessment
• Vulnerability Management Services: Enterprise Vulnerability Management System
• SBOM Implementation Guide: Software Bill of Materials Implementation Method

---

Publication Date: March 14, 2026 Article ID: art-018 Related Standards: prEN 40000-1-3:2026, CRA Annex I Part II

This article is for reference only and does not constitute legal or compliance advice. For specific implementation, please refer to the original CRA regulations and harmonized standards.