Three CRA Scenarios: What the Cyber Resilience Act Means for Your Business 

Fact-сhecked

The EU Cyber Resilience Act applies broadly to products with digital elements sold in the European market. But “broadly” does not mean “uniformly.” Obligations vary by product type, business model, and where you sit in the supply chain. 

This article walks through three realistic scenarios and explains the CRA implications for each. Whether you are a SaaS startup, a hardware manufacturer, or an independent app developer, understanding your specific exposure is the first step toward practical compliance. 

Scenario 1: B2B SaaS Startup Launching in January 2027 

Profile: You are building a B2B SaaS platform for EU enterprise customers. Your product runs entirely in the cloud. You plan to launch commercially in January 2027. 

Are you in scope? 

It depends on your architecture. 

If your software runs entirely on your infrastructure and customers access it via browser or API (pure SaaS), it is generally not covered by the CRA. The regulation targets “products with digital elements,” which means software or hardware placed on the market and delivered to the user. 

However, you are in scope if your SaaS includes: 

• a client-side component (desktop agent, mobile app, browser extension) that customers install; 

• remote data processing that is essential to a connected product’s function and developed by or on behalf of the manufacturer. 

If your SaaS provides back-end processing for a customer’s IoT device or installed software, the remote data processing rules apply. In this case, the CRA treats your backend as part of the product’s security perimeter. 

What this means for a January 2027 launch 

If you are in scope, the timeline looks like this: 

• September 11, 2026: Article 14 vulnerability and incident reporting obligations go live. You must be ready to report actively exploited vulnerabilities within 24 hours and submit follow-up notifications within 72 hours. 

• December 11, 2027: Full CRA requirements apply, including conformity assessment, technical documentation (Annex VII), CE marking, and SBOM. 

Launching in January 2027 means you enter the market before full CRA application but after reporting obligations begin. If a vulnerability hits your product in Q1 2027, you must already have operational reporting infrastructure. 

Practical preparation 

1. Clarify scope early. If you have any client-side components or remote processing dependencies, assume you are in scope. 

2. Build SBOM into CI/CD now. Machine-readable software composition data is a prerequisite for fast vulnerability triage. 

3. Establish a vulnerability response workflow. Define owners, escalation paths, and reporting templates before go-live. 

4. Prepare Annex VII documentation. Technical files must be ready before placing the product on the market. 

How SaM Solutions can help 

For a startup, building CRA-ready infrastructure from scratch while also shipping product is a resource conflict. An engineering partner can absorb the compliance workload without slowing your roadmap. 

We support SaaS startups with: 

• SBOM pipeline integration into existing CI/CD, tied to release versions and build artifacts; 

• Secure development practices embedded in day-to-day engineering, not bolted on at audit time; 

• Vulnerability monitoring and triage as an ongoing service, reducing internal burden; 

• Technical documentation preparation aligned with Annex VII requirements. 

This allows startups to launch with reporting capability already in place, rather than building it reactively after go-live. 

Scenario 2: Wearable Manufacturer with an EOL Device Still in Use 

Profile: You manufacture smart wearables. Your first-generation device was discontinued (EOL) in 2024 and replaced with a second-generation model. You actively support the new device. The old device is no longer sold, but thousands of units remain in customer hands. These devices still connect to your backend for user profile sync and some features. 

Are you in scope? 

Yes — for both devices, but with different obligation profiles. 

The new device is straightforward: it is an active product with digital elements, subject to full CRA obligations from December 2027 and reporting obligations from September 2026. 

The legacy device is more complex. Products placed on the market before December 11, 2027 are not retroactively subject to the full CRA requirements, unless they undergo a “substantial modification” after that date. However: 

• Article 14 reporting obligations apply from September 11, 2026 to all products already on the market, including legacy devices. 

• If your EOL device still connects to your backend, and a vulnerability in that backend or device firmware is actively exploited, you must report it under the 24/72-hour timeline. 

The fact that a device is EOL does not remove your reporting obligation. It removes your obligation to ship new features, but your obligation to monitor, detect, and report security incidents remains. 

The back-end complication 

Your legacy wearable still accesses your backend for user profiles and features. This backend likely serves both old and new devices. A vulnerability in shared infrastructure triggers reporting obligations for both product lines. 

A common pattern is sunsetting the device while keeping the backend alive for legacy users, without maintaining security monitoring or incident response coverage for that legacy path. Under CRA, this creates unaddressed compliance exposure. 

Practical preparation 

1. Map your legacy exposure. Identify which back-end components serve EOL devices and what data flows remain active. 

2. Decide: maintain or decommission. If you keep back-end access alive, you accept ongoing monitoring and reporting obligations. If you cannot maintain security support, plan a secure decommissioning path with customer notice. 

3. Extend SBOM coverage to legacy firmware. If a CVE drops in a component used by your EOL device, you need to know within hours, not weeks. 

4. Communicate support boundaries. CRA requires manufacturers to state the end of the support period clearly to users. If your legacy device is past its support period, that must be documented and communicated. 

The CRA mandates a minimum 5-year support period from the date of placing the product on the market (Article 13). If your legacy device was sold in 2022 and EOL’d in 2024, you may still have support obligations running until 2027. 

How SaM Solutions can help 

Managing two product generations with different support levels, while maintaining shared infrastructure, requires careful architecture and process discipline. 

We help wearable manufacturers with: 

• Embedded firmware development and maintenance, including security patching for legacy codebases; 

• IoT back-end architecture that cleanly separates legacy and current device support, enabling targeted decommissioning; 

• Continuous vulnerability monitoring across both current and legacy firmware, with CVE-to-product mapping; 

• Secure EOL transition planning, including customer communication and back-end shutdown procedures. 

Our embedded and IoT teams have experience managing long-lived device fleets where security support must extend beyond active sales. 

Scenario 3: Independent iOS Developer with Ten Apps 

Profile: You are a solo developer or small team. Over the past eight years, you have published ten iOS apps on the App Store. The apps generate ongoing revenue from paid downloads. They work primarily offline or use publicly available free APIs (weather, currency rates, etc.). None of them connect to a backend you operate. 

Are you in scope? 

Yes, mobile apps distributed in the EU are covered by the CRA. 

The regulation explicitly includes software applications, and the European Parliament has clarified that mobile apps fall within scope. The fact that your apps run on Apple’s platform does not shift the manufacturer obligation to Apple. You, as the developer who places the app on the market, are the manufacturer under CRA. 

The good news 

Your exposure is lower than a SaaS company or device manufacturer for several reasons: 

1. No remote data processing. If your apps do not connect to a backend you control, you avoid the “remote data processing solution” complexity that pulls cloud infrastructure into scope. 

2. Default category likely applies. Consumer apps without critical security functions typically fall into the default product category, allowing self-assessment (Module A) rather than third-party conformity assessment. 

3. Reduced penalties for micro/small enterprises. SMEs and micro-enterprises cannot be financially sanctioned for failing to meet Article 14 notification deadlines. You still have the obligation, but the penalty risk is lower. 

The challenges 

1. You are still the manufacturer. Each app you sell is a product with digital elements. You must meet essential cybersecurity requirements, maintain technical documentation, and handle vulnerabilities throughout the support period. 

2. Third-party dependencies are your responsibility. If your app uses a library with a known vulnerability, that is your problem under CRA. You must monitor dependencies and issue updates. 

3. Ten apps means ten products. Each app may have different dependencies, different release branches, and different user bases. Managing SBOM and vulnerability response across ten products as a solo developer is operationally demanding. 

4. Support period obligations. You must provide security updates for the expected product lifetime or at least 5 years. If you abandon an app but leave it on the store, you remain liable. 

Practical preparation 

1. Consolidate your portfolio. Decide which apps you will actively maintain and which you will remove from sale. Reducing your product count reduces your compliance surface. 

2. Automate SBOM generation. Use tools like Syft or OWASP Dependency-Track to generate machine-readable component inventories for each app. 

3. Set up dependency monitoring. Subscribe to CVE feeds for your key dependencies. For a solo developer, this can be as simple as GitHub Dependabot or Snyk’s free tier. 

4. Document your support periods. Clearly state in your App Store descriptions and privacy policies how long you will provide security support. 

5. Prepare minimal technical documentation. Annex VII requires a cybersecurity risk assessment, SBOM, and conformity declaration. Start drafting these now. 

How SaM Solutions can help 

For an independent developer, the economics of full-time compliance staff do not work. But the obligations remain. An outsourcing partner can provide targeted support without fixed overhead. 

We help indie developers and small studios with: 

• iOS app maintenance and security updates, including dependency upgrades and regression testing; 

• SBOM generation and vulnerability monitoring as a managed service, covering your full app portfolio; 

• Technical documentation preparation for Annex VII, adapted to the scale of a small developer. 

This approach keeps apps compliant and revenue-generating while limiting the share of development time spent on regulatory requirements. 

Summary: Three Businesses, Three Compliance Profiles 

Final Takeaway 

The CRA does not apply identically to every business. A SaaS startup launching in 2027 faces different timing pressures than a hardware manufacturer managing legacy devices. An indie developer with ten apps has different resource constraints than an enterprise with a dedicated security team. 

What they share is a common timeline: reporting obligations begin in September 2026, well before full CRA application in December 2027. The infrastructure to detect, assess, and report vulnerabilities needs to be operational by that earlier date, regardless of business model. 

The right partner helps you build that infrastructure efficiently, matching effort to your actual risk profile rather than applying a one-size-fits-all compliance program. 

For detailed CRA timelines, penalty structures, and reporting requirements, see our companion article: EU CRA 2026 Readiness: Deadlines, Decisions, and Do-Nows. 

For information on how an engineering partner supports CRA readiness, see: CRA Compliance for SaaS: How to Prepare in 2026 and How an Engineering Partner Can Help. 

References 

• Regulation (EU) 2024/2847 – Cyber Resilience Act (Full Text) 

• European Commission – CRA Summary 

• Product Lifecycle Support Requirements: IoT Manufacturers & the EU CRA 

• EU Cyber Resilience Act: Key 2026 Milestones 

• CRA Guide for Software Developers