CRA End-of-Life Planning: Responsible Product Transitions

Your product's support period will end. Under CRA, how you handle that transition affects both compliance and customer relationships. A poorly managed EOL leaves customers with vulnerable products and you with potential liability.

This guide covers responsible end-of-life planning: timelines, communication, and what happens after support ends.

EOL Under CRA: What's Required

The CRA doesn't explicitly mandate EOL procedures, but several requirements affect how you handle end-of-life:

Support Period Obligation

Article 13 requires security updates for the support period (minimum 5 years or expected product lifetime). When that period ends, your update obligation ceases, but your responsibility to have planned for this doesn't.

Customer Information

Annex I requires providing information about the support period. Customers should know from purchase when support will end.

Documentation Retention

Technical documentation must be kept for 10 years after the last unit is placed on the market. EOL doesn't end documentation obligations.

Non-Compliance Handling

If at EOL you know the product has unfixed vulnerabilities, you may have notification obligations under market surveillance provisions.

EOL Timeline Framework

18 Months Before EOL: Planning

EOL PLANNING PHASE (18 months before)

Internal:
[ ] Confirm EOL date based on market placement + support period
[ ] Assess outstanding vulnerabilities
[ ] Plan final security updates
[ ] Identify successor products/migration paths
[ ] Prepare customer communication materials
[ ] Brief support teams

External:
[ ] Begin mentioning EOL in product roadmap communications
[ ] Update product documentation with EOL date
[ ] Identify large customers for proactive outreach

12 Months Before EOL: First Notification

This is your formal EOL announcement.

12-MONTH EOL NOTIFICATION

Recipients:
- All registered customers
- Distribution partners
- Published on product pages

Content:
- Product name and version
- Support end date
- What "end of support" means
- Migration options
- Timeline for remaining updates
- Contact for questions

Channels:
- Email to registered users
- Product update notification (in-app)
- Website announcement
- Press release (for significant products)
- Partner communication

Template: 12-Month Notice

Subject: Important: [Product Name] End-of-Support Notice

Dear [Customer],

This notice confirms that [Product Name vX.X] will reach
end of support on [Date].

WHAT THIS MEANS:
- After [Date], we will no longer provide security updates
  for [Product Name vX.X]
- Technical support will end
- The product will continue to function but may become
  vulnerable to security issues discovered after [Date]

TIMELINE:
- Today: This announcement
- [Date - 6 months]: Reminder notice
- [Date - 1 month]: Final notice and last security update
- [Date]: End of support

YOUR OPTIONS:
Option 1: Upgrade to [Product Name v2.0]
- [Benefits of upgrade]
- Upgrade pricing: [Details]
- Migration guide: [Link]

Option 2: Move to [Alternative Product]
- [Brief description]
- [Link to comparison]

Option 3: Continue using unsupported version
- Not recommended
- Product functions but no security updates
- You accept security risks

MIGRATION SUPPORT:
We're here to help with your transition:
- Migration documentation: [Link]
- Support team: [Contact]
- Webinar on [Date]: "Migrating from [Product vX] to [v2]"

Questions? Contact [support email/phone]

Thank you for being a [Product Name] customer.

[Company Name] Product Team

6 Months Before EOL: Reminder

Reinforce the message and provide updated migration information.

6-MONTH EOL REMINDER

Updates since 12-month notice:
- Migration tools available
- Promotional pricing for upgrades
- Success stories from early migrators
- Updated FAQ

Additional channels:
- In-product banner/notification
- Login page notice
- Social media reminder

Template: 6-Month Reminder

Subject: Reminder: [Product Name] Support Ends in 6 Months

Dear [Customer],

This is a reminder that [Product Name vX.X] will reach
end of support on [Date], six months from now.

STATUS UPDATE:
- X customers have already migrated to [v2.0]
- Migration tools are now available
- Special upgrade pricing valid until [Date]

WHAT'S NEW:
- Self-service migration wizard: [Link]
- Migration webinar recording: [Link]
- Upgrade FAQ: [Link]

REMAINING UPDATES:
We will release one final security update approximately
one month before end of support, addressing all known
vulnerabilities at that time.

DON'T WAIT:
We recommend starting your migration now to:
- Avoid last-minute issues
- Take advantage of upgrade pricing
- Ensure uninterrupted security coverage

Need help? Contact [migration support contact]

[Company Name] Product Team

1 Month Before EOL: Final Notice

The last reminder before support ends.

1-MONTH FINAL NOTICE

Critical content:
- This is the final notice
- Last security update released (or releasing now)
- Support channels closing procedures
- Final migration opportunity

Urgency elements:
- Clear deadline emphasis
- Known vulnerability disclosure (if any remain unfixed)
- Consequences of inaction

Template: 1-Month Final Notice

Subject: Final Notice: [Product Name] Support Ends [Date]

Dear [Customer],

This is the FINAL notice before [Product Name vX.X]
reaches end of support on [Date].

FINAL SECURITY UPDATE:
We are releasing the final security update today. This
update addresses all known vulnerabilities as of this
date. We strongly recommend applying this update.

Download: [Link]
Installation guide: [Link]

AFTER [DATE]:
- No further security updates will be released
- Technical support will no longer be available
- Any vulnerabilities discovered after this date
  will not be patched

LAST CHANCE TO MIGRATE:
This is your final opportunity to take advantage of
our assisted migration support.

- Upgrade to [v2.0]: [Link]
- Migration assistance: [Contact]
- Upgrade pricing expires: [Date]

CONTINUING TO USE [PRODUCT vX.X]:
If you continue using [Product Name vX.X] after [Date]:
- The product will continue to function
- You accept security risks from unfixed vulnerabilities
- You should implement compensating controls
- Consider network isolation and monitoring

We appreciate your business and hope you'll continue
with us on [v2.0] or [alternative product].

[Company Name] Product Team

EOL Date: Support Ends

EOL DATE ACTIONS

Execute:
[ ] Support channels closed/redirected
[ ] Product documentation updated to "no longer supported"
[ ] Automatic update checks disabled (or point to "no update available")
[ ] Download pages updated with EOL notice
[ ] Archive product in internal systems

Communicate:
[ ] Final confirmation email to remaining users
[ ] Website banner/notice
[ ] Support redirect message

Retain:
[ ] Technical documentation (10-year retention continues)
[ ] Customer communication records
[ ] Known vulnerability list at EOL

Template: EOL Confirmation

Subject: [Product Name] Has Reached End of Support

Dear [Customer],

As of today, [Date], [Product Name vX.X] has reached
end of support.

WHAT THIS MEANS NOW:
- No further security updates will be provided
- Technical support is no longer available
- Product documentation remains accessible at [Link]

IF YOU'RE STILL USING [PRODUCT vX.X]:
We recommend:
1. Upgrade to [v2.0]: [Link]
2. Implement compensating security controls
3. Consider network isolation

SECURITY CONTACT:
While we no longer provide updates, we maintain a
security contact for responsible vulnerability disclosure:
security@company.com

If you discover a vulnerability, please report it.
We will assess whether extraordinary circumstances
warrant action and will notify affected users if
significant risks are discovered.

DOCUMENTATION:
Product documentation remains available at: [Link]
This documentation is retained for regulatory purposes.

Thank you for being a [Product Name] customer. We hope
to serve you with [successor product] or other solutions.

[Company Name] Product Team

Migration Path Planning

Defining Migration Options

Customers need clear alternatives:

MIGRATION OPTIONS FRAMEWORK

OPTION 1: Direct Upgrade
├── New version of same product
├── Data migration supported
├── Feature parity (or better)
└── Pricing: [upgrade pricing]

OPTION 2: Alternative Product
├── Different product that meets same needs
├── May require workflow changes
├── Migration tools available
└── Pricing: [new customer pricing]

OPTION 3: Competitor Product
├── Be honest if your solution doesn't fit
├── Provide data export capability
└── Don't lock customers in

OPTION 4: Continue Unsupported
├── Document the risks clearly
├── Provide compensating control guidance
├── No support, no updates
└── Customer accepts responsibility

Migration Support Resources

Prepare before EOL communications begin:

Handling Customers Who Won't Migrate

Some customers will continue using unsupported products. Your responsibilities:

Do:

• Clearly communicate risks
• Provide final security update
• Document their choice (for your records)
• Maintain security contact for critical disclosures
• Keep documentation accessible

Don't:

• Force product to stop working (in most cases)
• Delete customer data without notice
• Completely abandon security contact
• Remove documentation

Post-EOL Responsibilities

Documentation Retention

Your documentation obligations don't end with support:

POST-EOL DOCUMENTATION REQUIREMENTS

Technical File:
- Keep for 10 years from last unit placed on market
- Must be available for market surveillance authorities
- Include final state at EOL

Records to Maintain:
- EU Declaration of Conformity
- Risk assessments
- Test results
- SBOM (final version)
- Conformity assessment evidence
- Customer communications

Note: If product was on market for 3 years and support
period was 5 years, documentation retention continues
for 10 years from year 3, not year 8.

Known Vulnerability Handling

What if vulnerabilities are discovered after EOL?

For vulnerabilities reported externally:

• Assess severity and impact
• For critical, actively-exploited vulnerabilities affecting many users, consider:
  • Extraordinary security update (not required but responsible)
  • Customer notification with mitigation guidance
  • Public advisory

For vulnerabilities discovered internally:

• Same assessment process
• Document decision and rationale

Documentation:

POST-EOL VULNERABILITY LOG

Vulnerability: ________________________________
Reported/Discovered: __________________________
Severity: ____________________________________
Affected versions: ____________________________
Exploitation status: ___________________________

Decision:
[ ] No action (standard for post-EOL)
[ ] Customer notification only
[ ] Extraordinary update released
[ ] Public advisory issued

Rationale:
______________________________________________

Decided by: __________________________________
Date: _______________________________________

Market Surveillance Cooperation

Even after EOL, you must cooperate with market surveillance authorities if they investigate your product. Keep records accessible.

Special EOL Scenarios

Early EOL (Before 5 Years)

Can you end support before the minimum period?

Generally no. The CRA requires minimum 5-year support. Ending early would be non-compliance.

Exceptions:

• Product expected lifetime genuinely shorter than 5 years (rare, must be documented and communicated at sale)
• Extraordinary circumstances (company bankruptcy, etc.)

If forced to early EOL:

• Communicate transparently
• Consider open-sourcing to enable community maintenance
• Provide extended security update commitment if possible
• Explore acquisition/handoff to another entity

Acquired Product EOL

You acquire a company with products nearing EOL:

ACQUIRED PRODUCT EOL HANDLING

Assessment:
[ ] When was product first placed on EU market?
[ ] What support period was communicated?
[ ] What is remaining obligation?

Options:
1. Honor original commitment
   - Maintain support through original end date
   - Integrate into your support infrastructure

2. Extend support
   - Reset clock (customer benefit)
   - Communicate extension positively

3. Accelerate migration
   - Offer compelling migration to your product
   - Don't cut support short

Never:
- End support earlier than committed
- Abandon without migration path
- Leave customers worse off than pre-acquisition

Multi-Version EOL

Multiple versions reaching EOL around the same time:

MULTI-VERSION EOL COORDINATION

Stagger if possible:
- v1.0 EOL: Jan 2028
- v1.1 EOL: Jul 2028
- v2.0 EOL: Jan 2029

Benefits of staggering:
- Reduces support burden at any one time
- Gives customers clear upgrade path
- Spreads migration support load

Communicate clearly:
- Version-specific EOL dates
- Migration path between versions
- Recommended target version

Customer Communication Principles

Transparency

• Never surprise customers with EOL
• Communicate dates as early as possible
• Be clear about what "end of support" means

Respect

• Customers invested in your product
• Give adequate time to migrate
• Provide genuine alternatives

Support

• Make migration as easy as possible
• Offer assistance during transition
• Don't penalize long-term customers

Continuity

• Data export must be possible
• Documentation should remain accessible
• Security contact should persist (even if limited)

EOL Planning Checklist

EOL PLANNING CHECKLIST

18 MONTHS BEFORE:
[ ] EOL date confirmed
[ ] Successor product identified
[ ] Migration tools planned
[ ] Communication timeline set
[ ] Support team briefed
[ ] Documentation updated with EOL date

12 MONTHS BEFORE:
[ ] Formal EOL announcement sent
[ ] Website updated
[ ] Product documentation updated
[ ] Migration guide published
[ ] Upgrade pricing established
[ ] Support channels prepared

6 MONTHS BEFORE:
[ ] Reminder notice sent
[ ] In-product notification active
[ ] Migration tools available
[ ] Webinar/training offered
[ ] Large customer outreach

1 MONTH BEFORE:
[ ] Final notice sent
[ ] Final security update released
[ ] Support closure announced
[ ] Migration deadline emphasized
[ ] Documentation finalized

EOL DATE:
[ ] Support channels closed/redirected
[ ] Website EOL notice live
[ ] Download pages updated
[ ] Documentation archived (but accessible)
[ ] Internal systems updated

POST-EOL:
[ ] Confirmation sent to remaining users
[ ] Documentation retention confirmed
[ ] Security contact maintained
[ ] Vulnerability log initiated
[ ] 10-year retention timer started

Related Guides

• CRA Support Period Planning: 5 Years of Security Updates
• CRA Implementation Timeline 2025-2027
• CRA Penalties and Enforcement Guide

How CRA Evidence Helps

CRA Evidence supports EOL planning:

• Support period tracking: Automatic EOL date calculation
• Customer registry: Track who needs notification
• Communication templates: EOL notice templates
• Documentation archive: Retained technical files
• Vulnerability log: Post-EOL vulnerability tracking

Plan your product transitions at 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.