CRA Support Period Planning: 5 Years of Security Updates (And What That Really Means)

Five years. That's the minimum you must provide security updates for your products under the CRA. For many manufacturers, this represents a fundamental shift in how they think about product lifecycle and support costs.

This guide covers what the support period requirement actually means, how to plan for it, and how to handle the inevitable end-of-support transition.

What the CRA Actually Requires

Article 13 and Annex I establish the support period obligations:

Minimum Duration

5 years from when the product is placed on the EU market, OR the expected product lifetime, whichever is shorter.

"Expected product lifetime" is determined by:

• Reasonable customer expectations based on product nature
• How similar products are typically used
• What you communicate about the product

For most software and IoT products, 5 years is the practical minimum.

What You Must Provide

During the support period, you must:

1. Address vulnerabilities without delay

   • Provide security patches for known vulnerabilities
   • Prioritize based on severity
   • No waiting for "next major release"

2. Deliver updates securely

   • Automatic updates where technically possible
   • Secure distribution (signed, verified)
   • Rollback capability if updates fail

3. Notify customers

   • Inform about available security updates
   • Provide clear installation instructions
   • Communicate security-relevant information

4. Provide updates free of charge

   • No pay-to-patch for security updates
   • Feature updates can be charged separately

When Does the Clock Start?

The support period begins when the product is "placed on the market," meaning when you make it available for the first time in the EU.

Not when:

• The customer purchases it
• The customer activates it
• A specific unit ships

This creates inventory risk: If your product sits in distribution for 18 months before sale, support still ends 5 years from initial market placement.

Example Timeline

Jan 2028: Product v1.0 placed on EU market
          → Support period begins
          → Must provide updates until Jan 2033

Jun 2029: Customer buys v1.0 from distributor
          → Customer has 3.5 years of support remaining

Jan 2033: Support period ends
          → No further obligation to patch v1.0
          → Customer has 18 months of unsupported product

Best practice: Track market placement dates per product version, not per unit.

Update Delivery Requirements

Automatic Updates (Preferred)

Where technically feasible and appropriate, the CRA expects automatic security updates:

AUTOMATIC UPDATE REQUIREMENTS:

Technical:
- Secure download channel (TLS, signed packages)
- Integrity verification before installation
- Rollback capability if update fails
- Graceful handling of connectivity issues

User Control:
- User must be able to opt out (with clear warning)
- User must be able to defer (with reasonable limits)
- Critical updates may override deferral for security
- Update status must be visible to user

Notification:
- Inform user when updates are available
- Explain what the update addresses
- Provide installation instructions if manual

Manual Updates (When Automatic Isn't Possible)

Some products can't auto-update: air-gapped systems, industrial equipment, embedded devices without connectivity.

For these:

• Provide downloadable update packages
• Clear versioning and changelog
• Installation documentation
• Verification method (checksums, signatures)
• Notification via available channels (email, web portal, physical notice)

Update Signing

All security updates should be cryptographically signed:

UPDATE SIGNING REQUIREMENTS:

Code Signing:
- Sign all update packages
- Use dedicated signing key (HSM-protected)
- Include signature verification in update process
- Publish public key for verification

Metadata:
- Version number
- Release date
- Changelog/advisory reference
- Minimum compatible base version
- Signature timestamp

Vulnerability Response During Support Period

The support period isn't just about having updates available. It's about responding to vulnerabilities as they're discovered.

Response Expectations

These aren't CRA-mandated timelines, but they reflect industry expectations and what regulators will consider "without delay."

Tracking Vulnerabilities

You need a process for:

1. Discovery intake

   • CVD policy and contact point
   • Internal discovery pipeline
   • Dependency monitoring

2. Assessment

   • Does vulnerability affect our product?
   • What versions are affected?
   • What's the severity in our context?

3. Remediation

   • Develop patch
   • Test patch
   • Release patch

4. Communication

   • Notify customers
   • Publish advisory (if appropriate)
   • Report to ENISA (if actively exploited)

Dependency Vulnerabilities

Your product includes third-party components. When they have vulnerabilities:

• Direct dependencies: You must assess impact and update if affected
• Transitive dependencies: Same obligation, harder to track
• OS/platform vulnerabilities: May require you to update or communicate mitigation

SBOM is essential: You can't track what you don't know about.

Cost Modeling for Support Period

Many manufacturers underestimate support costs. Here's a framework:

Fixed Costs (Per Product Line)

Variable Costs (Per Year of Support)

Example Cost Model

SUPPORT PERIOD COST MODEL

Product: Smart Home Hub v2.0
Support Period: 5 years (Jan 2028 - Jan 2033)
Units Estimated: 50,000

FIXED COSTS (one-time):
- Update pipeline setup:     $15,000
- Signing infrastructure:    $5,000
- Notification system:       $10,000
- Documentation templates:   $5,000
SUBTOTAL:                    $35,000

ANNUAL COSTS:
- Security engineer (0.2 FTE): $30,000/year
- Dependency monitoring:       $2,000/year
- Testing infrastructure:      $5,000/year
- Customer support delta:      $3,000/year
SUBTOTAL:                      $40,000/year × 5 = $200,000

INCIDENT RESERVE (5 years):
- Critical vulnerabilities (est. 2): $20,000
- Regular patches (est. 15):         $30,000
SUBTOTAL:                            $50,000

TOTAL 5-YEAR SUPPORT COST:           $285,000
PER-UNIT SUPPORT COST:               $5.70

If selling at $99/unit:
Support = 5.8% of revenue

Key insight: Support cost per unit decreases with volume. Low-volume products have proportionally higher support burden.

End-of-Support Planning

The support period ends. Then what?

Before End-of-Support

12 months before:

• Announce end-of-support date
• Communicate to all registered users
• Publish on product pages and documentation
• Offer upgrade/replacement paths

6 months before:

• Reminder communications
• Final feature updates (if any)
• Documentation freeze (capture current state)
• Prepare final security update

At end-of-support:

• Issue final security update with all known fixes
• Publish end-of-support notice
• Update product documentation to reflect status
• Redirect support channels to alternatives

Customer Communication Template

END-OF-SUPPORT NOTICE

Product: [Product Name v1.0]
End-of-Support Date: [Date]

What this means:
- Security updates will no longer be provided after [Date]
- Technical support for this version will end
- The product will continue to function but may become vulnerable

What you should do:
- Option 1: Upgrade to [Product Name v2.0] - [link]
- Option 2: Replace with [Alternative Product] - [link]
- Option 3: Continue use at your own risk (not recommended)

Timeline:
- [Date - 6 months]: Final feature update
- [Date - 1 month]: Final security update
- [Date]: End of support

Questions? Contact [support channel]

Post-End-of-Support

Your obligations after support period:

• Keep technical file for 10 years total (from last unit placed on market)
• Respond to market surveillance requests
• No obligation to patch new vulnerabilities

Best practices (voluntary):

• Maintain security contact for responsible disclosure
• Consider publishing known-but-unfixed vulnerabilities
• Keep update infrastructure available for critical emergencies

Multi-Version Support

Most manufacturers have multiple product versions on the market simultaneously.

Staggered Support Periods

VERSION SUPPORT TIMELINE

v1.0: Jan 2028 ─────────────────────────── Jan 2033
v1.1:      Jul 2028 ─────────────────────────── Jul 2033
v2.0:           Jan 2029 ─────────────────────────── Jan 2034

Overlapping support: Jan 2029 - Jan 2033 = 4 years of dual support

Support Matrix Example

PRODUCT SUPPORT MATRIX (as of Jan 2030)

Version   Released    Support Ends    Status
────────────────────────────────────────────
v1.0      Jan 2028    Jan 2033        Maintenance
v1.1      Jul 2028    Jul 2033        Maintenance
v2.0      Jan 2029    Jan 2034        Current
v2.1      Jan 2030    Jan 2035        Current

Maintenance = Security updates only
Current = Security + feature updates

Reducing Multi-Version Burden

Strategies to minimize overlapping support:

1. Unified codebase: Share code between versions where possible
2. Backport process: Automated or semi-automated security backports
3. Shorter release cycles: More frequent releases = more predictable support windows
4. Aggressive deprecation: Encourage customers to upgrade

Industry-Specific Considerations

IoT Devices

• Many have 7-10 year expected lifetimes
• Update mechanisms may be limited
• Customer reachability is challenging
• Consider: remote update capability, heartbeat monitoring

B2B Software

• Enterprise customers expect longer support
• Support contracts may already exceed 5 years
• Integration complexity affects update deployment
• Consider: extended support tiers, professional services

Consumer Electronics

• Retail channel complicates customer communication
• End users may not register products
• Competing with planned obsolescence culture
• Consider: in-product update notifications, app-based updates

Industrial Equipment

• 15-20 year expected lifetimes common
• Downtime for updates is costly
• Air-gapped installations
• Consider: staged rollouts, compatibility testing, professional deployment services

Common Mistakes

Coupling Security to Feature Updates

Problem: Security patches only available in major releases.

Why it's wrong: Customers shouldn't need to accept new features (and potential new bugs) to get security fixes.

Solution: Maintain security-only update track for supported versions.

Ignoring Dependency Updates

Problem: Product code is maintained but dependencies rot.

Why it's wrong: Most vulnerabilities come from dependencies.

Solution: Include dependency updates in your security maintenance scope.

No Update Verification

Problem: Updates are available but customers can't verify authenticity.

Why it's wrong: Attackers can distribute fake "updates."

Solution: Sign all updates, publish verification procedures.

Unclear End-of-Support

Problem: Support just... stops. No communication.

Why it's wrong: Customers left with vulnerable products they don't know are unsupported.

Solution: Proactive, documented end-of-support process.

Support Period Not in Pricing

Problem: Product priced without considering 5-year support cost.

Why it's wrong: Support becomes a cost center eating into margins.

Solution: Model support costs before pricing. Consider support as cost of goods sold.

Support Period Checklist

SUPPORT PERIOD PLANNING CHECKLIST

BEFORE MARKET PLACEMENT:

Infrastructure:
[ ] Update build pipeline established
[ ] Secure update delivery mechanism
[ ] Code signing infrastructure
[ ] Customer notification system

Planning:
[ ] Support period determined (min 5 years)
[ ] End-of-support date calculated
[ ] Cost model completed
[ ] Support staffing planned
[ ] Dependency tracking established

Documentation:
[ ] Support period stated in product info
[ ] Update process documented
[ ] Customer notification templates ready

DURING SUPPORT PERIOD:

Monitoring:
[ ] Vulnerability monitoring active
[ ] Dependency updates tracked
[ ] Customer feedback channels monitored

Response:
[ ] Vulnerability triage process
[ ] Patch development workflow
[ ] Testing and release process
[ ] Customer notification process

Reporting:
[ ] ENISA reporting integration (if exploitation)
[ ] Advisory publication process
[ ] Support metrics tracking

END-OF-SUPPORT:

Communication:
[ ] 12-month advance notice sent
[ ] 6-month reminder sent
[ ] Final notice at end-of-support
[ ] Documentation updated

Transition:
[ ] Upgrade path documented
[ ] Final security update released
[ ] Support channels redirected
[ ] Technical file archived (10-year retention)

Related Guides

• CRA End-of-Life Planning: Responsible Product Transitions
• CRA Compliance Cost Estimation
• CRA Technical File (Annex VII) Guide

How CRA Evidence Helps

CRA Evidence provides support period management:

• Version lifecycle tracking: Market placement dates, support end dates
• Dependency monitoring: SBOM-based vulnerability alerts
• Customer notification: Templates and distribution tracking
• Documentation: End-of-support records for technical file
• Compliance dashboard: Support period status across products

Plan your support periods with app.craevidence.com.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.