When Is Software “Placed on the Market” Under the EU Cyber Resilience Act?

What the European Commission's FAQs tell us about intangible products, substantial modifications, and support periods

Under the CRA, a product is “placed on the market” the first time it is made available for distribution or use on the EU market in the course of a commercial activity. For a traditional hardware product, each individual unit is placed on the market separately. Software needed a different interpretation.

The FAQ guidance explains the logic clearly. Once your software’s development phase is complete and you offer it to prospective users in the EU, you’ve effectively created a virtually infinite number of copies of that product. Unlike a physical product, software supplied digitally isn’t limited by production runs or stock levels. Every time someone downloads or accesses your software, a new identical copy is created.

The key takeaway is this: your software is considered placed on the market at the moment you first offer it for distribution or use in the EU. Every subsequent download of that same version is simply another instance of it being “made available” — but the date of placement on the market stays the same.

To put this into a practical example from the guidance: imagine you release version 1.0.0 of your software on 1 January 2028 via your website. A customer buys a copy that same day. Another customer buys a copy on 15 January. Both copies are considered placed on the market on 1 January 2028 — the date you first made the software available.

This is an important distinction. The placement date is tied to when you, the manufacturer, first offer the product for distribution, not to when each individual customer acquires their copy.

What About Updates? Understanding Substantial Modifications

Software development is iterative by nature. You ship a version, then release updates, patches, and new features over time. So how do updates affect the placement date?

The answer depends on whether an update qualifies as a “substantial modification.” The CRA defines this as a change that either affects the product’s compliance with essential cybersecurity requirements or modifies the intended purpose for which it was originally assessed.

If an update does not qualify as a substantial modification, it does not change the original placement date. Building on the earlier example: if you release version 1.0.1 on 15 January 2028 as a minor update, and a customer purchases that version on 30 January, both the original version 1.0.0 and the updated version 1.0.1 are still considered placed on the market on 1 January 2028. The minor update doesn’t reset the clock.

However, if an update does qualify as a substantial modification, the modified product is treated as a completely new product for CRA purposes. Making it available on the market constitutes a new placement, with a new date.

What Makes a Modification “Substantial”?

The FAQ guidance provides helpful criteria for assessing whether a software update crosses the threshold into substantial modification territory. It’s not about the size or complexity of the change — even a seemingly minor update can qualify if it affects your product’s cybersecurity risk profile in material ways.

In practical terms, a modification may be substantial if the update introduces new ways that threats could reach your product, such as additional interfaces or external dependencies. It could also qualify if the update enables entirely new attack scenarios that weren’t previously possible, changes how likely or impactful previously identified risks are, or results in a shift to the product’s intended purpose that wasn’t covered in your original risk assessment.

On the other hand, security updates are generally not considered substantial modifications. A patch that fixes a vulnerability without changing the product’s intended purpose or introducing new risks should not trigger a new placement. The guidance also makes clear that if you’ve planned ahead and your original risk assessment already covers functionalities you activate later, those updates are less likely to be considered substantial.

The guidance includes some illuminating examples. Adding a “remember me” login feature that stores authentication tokens locally might seem minor, but if it introduces token theft and session hijacking risks that weren’t in your original risk assessment, it could qualify as a substantial modification. Conversely, activating a group chat feature that was already described and assessed in your original risk documentation would likely not qualify.

One important point: where a substantial modification is made, the person or organisation making the change becomes the manufacturer of the modified product under the CRA. If you’re the original manufacturer issuing the update, you remain the manufacturer — but the product is treated as newly placed on the market.

How Placement on the Market Connects to Your Support Period

This is where the concept of placement on the market becomes particularly significant for software manufacturers, because it directly affects your obligations around the support period.

The CRA requires manufacturers to determine and declare a support period during which they will handle vulnerabilities effectively. This period must be at least five years, unless the product is genuinely expected to be in use for a shorter time. Products expected to be used for longer than five years should have correspondingly longer support periods. Five years is a minimum safeguard, not a default.

For software products developed iteratively, each version placed on the market must have its own declared support period that complies with the CRA’s requirements. If you release a substantially modified version, that version needs its own support period declaration.

Here’s where the guidance offers some practical flexibility. The CRA allows manufacturers to focus their vulnerability handling — specifically, addressing and fixing vulnerabilities — on the most recent version of their software, provided that users of earlier versions can upgrade to the latest version free of charge and without incurring additional costs.

The concept of “additional costs” is interpreted practically. Routine operational effort like testing, configuration adjustments, or updating software dependencies is not considered an additional cost. However, requiring users to buy new hardware, replace infrastructure, or make fundamental changes to their operating environment would be. Think of it this way: if upgrading is a normal part of maintaining the software, that’s fine. If upgrading forces users into unexpected expenses, it’s not.

This means that for fast-moving software products where you release substantially modified versions frequently and expect users to upgrade regularly, you can declare a support period for each new version but potentially discontinue active vulnerability fixes for older versions once users can move to the latest release. You still need to maintain other vulnerability-handling obligations across all versions, including maintaining a coordinated vulnerability disclosure policy and facilitating information sharing about potential vulnerabilities.

The guidance also stresses transparency. You must clearly indicate the support period end date at the time of purchase, and where technically feasible, notify users when the support period expires or when they’re running a version that is no longer actively maintained.

Products Already on the Market Before the CRA Applies

There’s one more dimension worth understanding. Products placed on the market before 11 December 2027 are only subject to the CRA if they undergo a substantial modification from that date onwards.

If you placed software on the market before that deadline and you’re continuing to issue updates, you’ll need to be able to demonstrate to market surveillance authorities that your updates don’t constitute substantial modifications. The guidance suggests that carrying out a cybersecurity risk assessment covering the relevant CRA requirements will help you establish that updates remain within the bounds of your original product’s scope.

If an update does cross the substantial modification threshold, you’ll need to comply with the CRA in full before placing the modified product on the market, and for the duration of its support period.

What Should You Be Doing Now?

Understanding these concepts early gives you a real advantage in planning your CRA compliance strategy. Here are some practical considerations.

First, document your placement dates carefully. Know when each version of your software was first offered on the EU market, because this anchors your compliance obligations and support period calculations.

Second, invest in thorough risk assessments upfront. If your initial risk assessment anticipates features and functionalities you plan to roll out later, you’re less likely to find that future updates trigger a substantial modification. Good planning now saves significant effort later.

Third, design your update and versioning strategy with the CRA in mind. Think about how you’ll manage support periods across multiple versions, how you’ll ensure users can upgrade without incurring additional costs, and how you’ll communicate support period information clearly.

Finally, remember that this guidance applies specifically to standalone software delivered digitally. If your software comes bundled with hardware, or is supplied via physical media like a USB drive, the traditional rules around placement on the market continue to apply.

The CRA represents a significant shift in how software security is regulated in the EU. The good news is that the Commission’s FAQ guidance is making the practical implications clearer. The concepts of placement on the market, substantial modification, and support periods are deeply interconnected, and understanding how they work together is essential for any software manufacturer doing business in the EU.