I keep hearing the same interpretation of the Cyber Resilience Act (CRA): when the CRA says that security updates must be provided “free of charge,” it means the enterprise open-source subscription model is effectively over in Europe.

The reasoning sounds simple. Open-source software is available to anyone. Therefore, enterprise Linux and other commercial open-source providers will be required to make their security patches available to anyone, without a subscription, for at least five years.

If you are in a hurry, here is the answer:

No. CRA “free patches” does not mean “no subscription needed.”

This is my personal view. It is not legal advice. It is not my employer’s position.

It means that a manufacturer generally cannot impose an additional charge for the security update itself when fulfilling its CRA obligations.

Two other misconceptions hidden in that interpretation are also worth correcting: the support period is not always five years, and the CRA is not limited to European vendors.

The support period has to reflect the product's expected use. Five years is the minimum unless the product is expected to be used for less; if the product is reasonably expected to remain in use longer, the support period should be longer. That support period should not be confused with the duration of an individual customer's commercial subscription.

The Commission services’ CRA FAQ makes the distinction particularly relevant for open source. Some subscription software stops being usable when the subscription expires, so its expected use can end with the subscription. Free and open-source software can be different because the software may remain in use after the user stops paying for support. The FAQ specifically addresses that case when discussing how the support period should be determined.

The CRA is also not limited to European software vendors. A software manufacturer does not escape the CRA simply because it is based outside the EU. If an in-scope product with digital elements is made available on the EU market, the CRA can apply.

So, this is not merely a European software-industry issue. It affects companies around the world that make covered software products available in Europe.

Those distinctions matter for commercial open-source business models.

The Cyber Resilience Act is not a campaign to make patches free. It is product cybersecurity law: build security into products with digital elements, keep fixing vulnerabilities for a defined support period, and do not charge extra for the security update itself.

That helps users — including users outside the EU when vendors apply the same security processes globally — in a few concrete ways:

• Users can expect security to be part of the product, not something bolted on later.
• Users should not have to buy the security fix as a second product.

Those protections have real value.

I set them out separately in What the CRA Actually Gives Software Users.

None of them means a vendor cannot sell software, an enterprise Linux distribution, support, or a subscription.

What the CRA Actually Says About “Free Patches”

Annex I, Part II requires manufacturers to address vulnerabilities without delay and, when security updates are available, disseminate them without delay and generally free of charge.

But an important note: this does not mean every piece of software is suddenly subject to the same commercial obligations.

There are important distinctions.

1. If you build tailor-made software for a business customer, don't panic yet.

The CRA explicitly allows a manufacturer and a business user to agree differently on charging for security updates when the product is tailor-made for that business user.

That does not mean custom software is automatically outside the CRA. It means that this specific “free of charge” rule has contractual flexibility for tailor-made products.

But a catalogue product does not become tailor-made simply because a customer bought an enterprise support contract.

2. If you contribute to non-commercial open source, also don't panic yet.

The CRA is specifically designed not to treat software developed or supplied outside the course of a commercial activity in the same way as a commercial product placed on the market.

So contributing code to a community project, publishing research software, or maintaining a genuinely non-commercial open-source project does not automatically turn you into a commercial software manufacturer with the full set of CRA manufacturer obligations.

The legal definitions are more nuanced — particularly around commercial activity and the separate category of open-source stewards — but the important distinction is simple:

Open source does not automatically mean commercial software, and commercial software does not stop being commercial merely because its source code is open.

That second distinction is particularly important for enterprise open source.

Now, return to the words “free of charge.”

There are really three questions:

What must be free? What does “free of charge” mean? And who is entitled to receive it?

The first answer is explicit in the CRA:

The security update.

The second does not mean that the product itself must be free. It means that the manufacturer should not ordinarily impose an additional charge for the security update required for that product.

The third question — who is entitled to receive the security update? — is particularly important for the enterprise open-source model.

There is a critical difference between code freedom and product entitlement.

Having access to the underlying open-source code does not mean you are automatically entitled to a vendor’s commercial infrastructure. Under the CRA, the manufacturer's vulnerability-handling obligations apply to the product with digital elements during its applicable support period.

But neither should we assume that a commercial subscription can always define the boundary of the CRA obligation.

A commercial subscription can define access to repositories, binaries, SLAs, and other commercial services. But that commercial entitlement and the manufacturer's statutory security obligations are not necessarily the same thing.

The CRA's “free of charge” requirement does not, by itself, turn the vendor's commercial distribution infrastructure into a free public service.

Open-source licences may give users rights to use, modify, and redistribute the underlying code. Those rights are separate from the manufacturer's CRA obligations and from entitlement to the vendor's commercial distribution and services.

The Commission's 2026 guidance makes this particularly visible when discussing substantially modified software versions: a manufacturer may stop remediating an earlier version under Article 13(10) when users can move to the latest version free of charge and without additional costs. The guidance also makes clear that continued support for earlier versions may still be offered under separate commercial arrangements.

Enterprise Linux provides a useful example. Enterprise Linux is commonly offered through a subscription that is not tied to a single minor release.

When a new minor — or potentially major — release becomes the version through which the vendor fulfils its CRA remediation obligations, the vendor does not necessarily have to continue providing free security maintenance for every previous release.

Subject to the conditions of Article 13(10), this is possible only where users of the earlier version can access the newer version free of charge and without incurring additional costs to adjust the hardware or software environment in which they use the original version. That does not mean upgrading must be a costless operationally or that every customization or third-party component must be guaranteed to remain compatible. The Commission's guidance expressly recognizes reasonable operational effort, including testing and configuration adjustments.

Longer-term maintenance of an older release may still be offered through an additional paid subscription or other commercial arrangement. The Commission guidance explicitly confirms that the CRA does not require such continued maintenance of earlier versions to be provided free of charge.

That creates an important distinction between product entitlement, security-update entitlement, and optional extended maintenance.

For enterprise open source, that distinction matters. The fact that the underlying source code is open does not make every commercial service around it free. But the fact that access is organized through a subscription does not necessarily mean that every CRA obligation disappears when that subscription ends.

So “security updates must be free of charge” and “enterprise software can be sold through a paid subscription” are not contradictory statements.

What the CRA does is constrain where the commercial boundary can be drawn: the manufacturer cannot simply turn a security obligation for the covered product into a second sale.

A vendor can still charge for software.

A vendor can still sell subscriptions.

A vendor can still charge for support, implementation, monitoring, SLAs, managed services, consulting, additional features, or someone actually performing the upgrade.

CRA does not turn any of those services into free services.

The distinction is between paying for the product or the commercial services around it and being asked to pay an additional fee for security remediation that the manufacturer is required to provide for that product.

The security update cannot ordinarily become a second sale.

A simple example makes the distinction clearer. Where the manufacturer is required under the CRA to provide a security update for the product, it generally cannot say:

“You already paid for the product, but fixing this vulnerability costs another €500.”

That is different from security maintenance being included in the price of the product or subscription.

And that is the distinction behind the title:

CRA “free patches” does not mean “no subscription needed.”

The CRA constrains how manufacturers can charge for the security remediation they are required to provide. It does not turn every surrounding commercial product, subscription, support service, repository, or enterprise offering into a free service.

One last note: Regulation is complex, and the CRA is no exception. These are my own views, not those of any company or organization. This article includes simplifications and interpretations to make the regulation easier to understand. It is not legal advice. If the CRA affects your product or business model, get proper legal advice for your specific situation.