S
For software users, that means security as part of what they buy, a manufacturer who remains responsible, notice when exploitation requires action, a support life that matches expected use, a visible end date, no second bill for the mandated fix, and released patches that stay available to fetch.
The Cyber Resilience Act (CRA) is usually explained from the manufacturer’s side: requirements to meet, processes to run, vulnerabilities to report, conformity to demonstrate.
We spend so much time on CRA compliance that it is easy to miss the obvious point. Those obligations exist to protect the people who buy and run products with digital elements. The manufacturer duties are the mechanism. The user protections are the reason.
That is also why the CRA is worth explaining in plain language from that side.
There is a practical reason too. If you only see the CRA as a list of duties, you will treat it as compliance overhead. If you see what the user is supposed to get, you can design a better product — not merely a compliant one.
So the useful question is:
What does the software user get from those obligations?
For the manufacturer, a support period is an obligation. For the user, it means security maintenance should not simply disappear.
For the manufacturer, vulnerability handling is a process. For the user, it means someone remains responsible for addressing vulnerabilities in the product.
For the manufacturer, free security updates are a regulatory requirement. For the user, the security fix cannot ordinarily become a second purchase.
The obligation and the protection are two sides of the same rule.
Looked at that way, the CRA is more than a compliance framework. It starts to describe what users can reasonably expect from a software product across its cybersecurity life. Not perfect security — no regulation can guarantee that. A clearer allocation of responsibility after the product is placed on the market.
This is my personal view. It is not legal advice. It is not my employer’s position.
Covered products are meant to be designed, developed, and produced with cybersecurity as a product requirement, not as a patch bolted on after the first incident.
Users should be able to expect a secure-by-default configuration, a way to receive security updates, and vulnerability handling that continues for a declared support period. They should also get the information needed to use the product securely: intended purpose, relevant security properties, and how to install updates.
That is the baseline. It does not mean every product is secure in practice. The user should not have to wonder whether security was part of what shipped. After the sale, the vendor can no longer treat it as optional.
You bought a solution. The party that placed that product on the market remains responsible for its cybersecurity, including when the hole sits in a component they did not write.
The work can move through the supply chain. The product-level responsibility does not.
A hole in somebody else’s library does not make those duties disappear. You should still get the security response the solution requires, including a fix and, where applicable, notice of what you need to do.
Behind that, the manufacturer also has to tell the component maintainer and share a fix when it has one. That is background work. It is not a reason to send you looking up the supply chain.
That is true when the product includes open-source components: you still bought a commercial solution, and that solution still has a manufacturer.
Not every open-source project automatically becomes a commercial manufacturer. Non-commercial projects and open-source stewards are treated differently.
The product-level responsibility arises when someone places a commercial product on the market — including one built with open source. That party has the duty.
Keeping a product secure requires you to be able to act. If a product is being exploited, or a severe security incident hits it, you need to know what to do.
From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability — or a severe incident affecting the product’s security — must report it to the relevant CSIRT and ENISA on a short clock.
That first report is not a public live vulnerability feed. It goes to authorities.
Users still get something from it. The manufacturer must inform impacted users — and, where appropriate, all users — of the issue and of mitigation or corrective measures they can take. Manufacturers also need a clearly identifiable contact for vulnerability reporting, not only an automated form. If the manufacturer fails to inform users in time, the notified CSIRT may tell them itself, where that is considered proportionate and necessary.
A different duty covers public information after a fix exists. Once a security update is available, the manufacturer must generally disclose what was fixed, which product is affected, how serious it is, and how to remediate it. Publication can be delayed in justified cases until users have had a chance to apply the patch. Separately, once a vulnerability has been fixed, ENISA will disclose it to the European Vulnerability Database, in agreement with the manufacturer.
Users anywhere — not only in Europe — can search published vulnerabilities in the European Vulnerability Database (EUVD) and pull them via its API for automated workflows.
So the sequence for users is: actionable notice when exploitation is happening → public detail once a mitigation exists → database entry where those rules apply. It is not an instant public dump of every 24-hour regulatory filing.
Users should not buy a product with a long expected life and watch security maintenance vanish halfway through it.
The support period has to reflect how long the product is reasonably expected to be in use. Five years is the minimum, unless the product is expected to be used for less. If it is reasonably expected to remain in use longer, the support period should be longer.
That period is not the same thing as the length of an individual commercial subscription. A subscription can be how support is delivered, but it does not define the support period itself — a distinction I explore separately in CRA ‘Free Patches’ Doesn’t Mean ‘No Subscription Needed’.
For software that ships in successive versions, there is a further limit. Under Article 13(10), and as further explained in the European Commission’s CRA guidance, a manufacturer may concentrate remediation on the latest version it has placed on the market if users of the earlier version can move to that later version free of charge and without extra cost to adjust the hardware or software environment. Reasonable operational effort — testing, configuration, and other needed changes — can still sit with the user.
That support period also does not mean you can stay on every old version and still get free security maintenance forever. Paid maintenance of an older release can still be offered as a separate commercial arrangement.
Security support should not be a date you discover after a vulnerability appears.
The manufacturer must specify the end of the support period — at least the month and year — at the time of purchase. Where technically feasible, users should also be notified when that period actually ends.
For you as a buyer, that date is not paperwork. It is investment protection: you can tell how long the security of what you paid for is supposed to last.
Bear in mind that this is the product’s committed security lifetime: the end date stated when you buy that product. That date is not a ceiling on what the manufacturer can offer. The manufacturer can have or add offerings with longer support periods or extensions, at different prices. But those alternatives do not shorten the committed security lifetime of the product you bought.
That gives consumers a clearer buying signal and gives enterprises something they can put into procurement, lifecycle planning, and risk management: a visible cybersecurity lifetime for the product.
You should not have to make a second purchase just to keep the product secure during its committed security lifetime.
As a buyer, that matters because it makes the cost of keeping your product secure more predictable.
During the applicable support period, security updates must generally be disseminated without delay and free of charge. The exception is a tailor-made product where the manufacturer and a business user agree otherwise.
The manufacturer should not ordinarily say: “You already paid for the product, but fixing this vulnerability costs another €500.”
“Your product” here means the offering you bought as it was placed on the market — not every older or unsupported version still running on a machine.
The security fix should not become a second SKU.
Where technically feasible, new security updates should also be provided separately from functionality updates. Users should not have to accept an unrelated feature release simply to obtain the security fix.
None of this means the product is free. It does not mean the subscription, the repository access, the SLA, or the person who applies the upgrade is free. It means the mandated security remediation for that product should not become a second sale.
You should still be able to fetch a patch that has already been released — if you reinstall, or if you wait before applying it. You should not have to archive every update the day it ships.
The manufacturer has to keep those updates available. If a security update was delivered as a new minor version, that update does not stop being an update merely because of how it was packaged.
“Free of charge” is empty if the update disappears.
Article 13(9) requires that each security update made available to users during the support period remain available for at least ten years after it is issued, or for the remainder of the support period, whichever is longer.
That is a different protection from the duty to keep remediating new vulnerabilities. It is about continued access to patches that have already been released.
These protections do not make you a passenger. They give you better means to act — and make responsible action more reasonable to expect.
Security is not a fixed state. It is a path — in software, a moving picture, not a still. No certification, regulation, or vendor promise keeps a product secure if nobody does anything after the day it ships. “If it works, don’t touch it” is the usual form of that mistake.
The CRA does not make your product secure by itself. It gives you the means — dates, updates, and notice — to stay on the path.
If the product comes with a visible support period, a way to get security updates, and notice when something is being exploited, “we did not know” becomes a weaker story. That matters most when the user is not only a customer, but also a provider: a company running the software to deliver a product or service to someone else.
The CRA does not, by itself, turn every user into a manufacturer. It does change the facts available to that user. Once the security lifetime is published, the patch is obtainable, and the mitigation has been communicated, failing to act looks less like a gap in the law and more like a gap in posture.
Security remains an active responsibility for the user. Negligent behaviour can still create liability under other rules — contracts, sector regulation, NIS2 where it applies, and ordinary duty of care. The CRA does not try those cases. It does make “we could not have known” a weaker defence.
The CRA’s user protections remove an excuse. They do not replace those duties.
Taken together, these duties answer a broader question: should commercial software placed on the market carry continuing responsibility for its cybersecurity, instead of treating security as finished at the moment of sale?
The CRA’s answer is increasingly yes.
Software is still not a toaster. It changes continuously, depends on components that change independently, and can grow newly discovered vulnerabilities long after it ships. Versioning, upgrades, and support periods have to reflect that.
But placing covered software on the EU market now comes with an expectation that security is part of the product, that someone remains responsible when a component breaks, that users are told what to do when exploitation starts, that maintenance lasts for a declared life and that life is visible, that the fix is not sold again as a separate item, and that an issued update remains there to be fetched.
The CRA does not guarantee secure software. It does not move every cybersecurity risk from the user to the manufacturer. It moves the boundary of responsibility.
For the people who build the product, that list is also a design brief: these are the user outcomes the work is supposed to produce, not only the boxes compliance has to tick.
Looked at from the manufacturer’s side, these are compliance obligations.
Looked at from the user’s side, they are product protections.
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 how you use one, get proper legal advice for your specific situation.
The Cyber Resilience Act (CRA) is usually explained from the manufacturer’s side: requirements to meet, processes to run, vulnerabilities to report, conformity to demonstrate.
We spend so much time on CRA compliance that it is easy to miss the obvious point. Those obligations exist to protect the people who buy and run products with digital elements. The manufacturer duties are the mechanism. The user protections are the reason.
That is also why the CRA is worth explaining in plain language from that side.
There is a practical reason too. If you only see the CRA as a list of duties, you will treat it as compliance overhead. If you see what the user is supposed to get, you can design a better product — not merely a compliant one.
So the useful question is:
What does the software user get from those obligations?
For the manufacturer, a support period is an obligation. For the user, it means security maintenance should not simply disappear.
For the manufacturer, vulnerability handling is a process. For the user, it means someone remains responsible for addressing vulnerabilities in the product.
For the manufacturer, free security updates are a regulatory requirement. For the user, the security fix cannot ordinarily become a second purchase.
The obligation and the protection are two sides of the same rule.
Looked at that way, the CRA is more than a compliance framework. It starts to describe what users can reasonably expect from a software product across its cybersecurity life. Not perfect security — no regulation can guarantee that. A clearer allocation of responsibility after the product is placed on the market.
This is my personal view. It is not legal advice. It is not my employer’s position.
1. Security is supposed to be part of the product
Covered products are meant to be designed, developed, and produced with cybersecurity as a product requirement, not as a patch bolted on after the first incident.
Users should be able to expect a secure-by-default configuration, a way to receive security updates, and vulnerability handling that continues for a declared support period. They should also get the information needed to use the product securely: intended purpose, relevant security properties, and how to install updates.
That is the baseline. It does not mean every product is secure in practice. The user should not have to wonder whether security was part of what shipped. After the sale, the vendor can no longer treat it as optional.
2. You bought a product, not a supply-chain disclaimer
You bought a solution. The party that placed that product on the market remains responsible for its cybersecurity, including when the hole sits in a component they did not write.
The work can move through the supply chain. The product-level responsibility does not.
A hole in somebody else’s library does not make those duties disappear. You should still get the security response the solution requires, including a fix and, where applicable, notice of what you need to do.
Behind that, the manufacturer also has to tell the component maintainer and share a fix when it has one. That is background work. It is not a reason to send you looking up the supply chain.
That is true when the product includes open-source components: you still bought a commercial solution, and that solution still has a manufacturer.
Not every open-source project automatically becomes a commercial manufacturer. Non-commercial projects and open-source stewards are treated differently.
The product-level responsibility arises when someone places a commercial product on the market — including one built with open source. That party has the duty.
3. When a vulnerability is being exploited, users are told what they can do
Keeping a product secure requires you to be able to act. If a product is being exploited, or a severe security incident hits it, you need to know what to do.
From 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability — or a severe incident affecting the product’s security — must report it to the relevant CSIRT and ENISA on a short clock.
That first report is not a public live vulnerability feed. It goes to authorities.
Users still get something from it. The manufacturer must inform impacted users — and, where appropriate, all users — of the issue and of mitigation or corrective measures they can take. Manufacturers also need a clearly identifiable contact for vulnerability reporting, not only an automated form. If the manufacturer fails to inform users in time, the notified CSIRT may tell them itself, where that is considered proportionate and necessary.
A different duty covers public information after a fix exists. Once a security update is available, the manufacturer must generally disclose what was fixed, which product is affected, how serious it is, and how to remediate it. Publication can be delayed in justified cases until users have had a chance to apply the patch. Separately, once a vulnerability has been fixed, ENISA will disclose it to the European Vulnerability Database, in agreement with the manufacturer.
Users anywhere — not only in Europe — can search published vulnerabilities in the European Vulnerability Database (EUVD) and pull them via its API for automated workflows.
So the sequence for users is: actionable notice when exploitation is happening → public detail once a mitigation exists → database entry where those rules apply. It is not an instant public dump of every 24-hour regulatory filing.
4. Security maintenance should last as long as the product is expected to last
Users should not buy a product with a long expected life and watch security maintenance vanish halfway through it.
The support period has to reflect how long the product is reasonably expected to be in use. Five years is the minimum, unless the product is expected to be used for less. If it is reasonably expected to remain in use longer, the support period should be longer.
That period is not the same thing as the length of an individual commercial subscription. A subscription can be how support is delivered, but it does not define the support period itself — a distinction I explore separately in CRA ‘Free Patches’ Doesn’t Mean ‘No Subscription Needed’.
For software that ships in successive versions, there is a further limit. Under Article 13(10), and as further explained in the European Commission’s CRA guidance, a manufacturer may concentrate remediation on the latest version it has placed on the market if users of the earlier version can move to that later version free of charge and without extra cost to adjust the hardware or software environment. Reasonable operational effort — testing, configuration, and other needed changes — can still sit with the user.
That support period also does not mean you can stay on every old version and still get free security maintenance forever. Paid maintenance of an older release can still be offered as a separate commercial arrangement.
5. Users should know when that support ends
Security support should not be a date you discover after a vulnerability appears.
The manufacturer must specify the end of the support period — at least the month and year — at the time of purchase. Where technically feasible, users should also be notified when that period actually ends.
For you as a buyer, that date is not paperwork. It is investment protection: you can tell how long the security of what you paid for is supposed to last.
Bear in mind that this is the product’s committed security lifetime: the end date stated when you buy that product. That date is not a ceiling on what the manufacturer can offer. The manufacturer can have or add offerings with longer support periods or extensions, at different prices. But those alternatives do not shorten the committed security lifetime of the product you bought.
That gives consumers a clearer buying signal and gives enterprises something they can put into procurement, lifecycle planning, and risk management: a visible cybersecurity lifetime for the product.
6. The security fix is part of your product, not a second product
You should not have to make a second purchase just to keep the product secure during its committed security lifetime.
As a buyer, that matters because it makes the cost of keeping your product secure more predictable.
During the applicable support period, security updates must generally be disseminated without delay and free of charge. The exception is a tailor-made product where the manufacturer and a business user agree otherwise.
The manufacturer should not ordinarily say: “You already paid for the product, but fixing this vulnerability costs another €500.”
“Your product” here means the offering you bought as it was placed on the market — not every older or unsupported version still running on a machine.
The security fix should not become a second SKU.
Where technically feasible, new security updates should also be provided separately from functionality updates. Users should not have to accept an unrelated feature release simply to obtain the security fix.
None of this means the product is free. It does not mean the subscription, the repository access, the SLA, or the person who applies the upgrade is free. It means the mandated security remediation for that product should not become a second sale.
7. Once issued, the security update should remain obtainable
You should still be able to fetch a patch that has already been released — if you reinstall, or if you wait before applying it. You should not have to archive every update the day it ships.
The manufacturer has to keep those updates available. If a security update was delivered as a new minor version, that update does not stop being an update merely because of how it was packaged.
“Free of charge” is empty if the update disappears.
Article 13(9) requires that each security update made available to users during the support period remain available for at least ten years after it is issued, or for the remainder of the support period, whichever is longer.
That is a different protection from the duty to keep remediating new vulnerabilities. It is about continued access to patches that have already been released.
What this does not excuse
These protections do not make you a passenger. They give you better means to act — and make responsible action more reasonable to expect.
Security is not a fixed state. It is a path — in software, a moving picture, not a still. No certification, regulation, or vendor promise keeps a product secure if nobody does anything after the day it ships. “If it works, don’t touch it” is the usual form of that mistake.
The CRA does not make your product secure by itself. It gives you the means — dates, updates, and notice — to stay on the path.
If the product comes with a visible support period, a way to get security updates, and notice when something is being exploited, “we did not know” becomes a weaker story. That matters most when the user is not only a customer, but also a provider: a company running the software to deliver a product or service to someone else.
The CRA does not, by itself, turn every user into a manufacturer. It does change the facts available to that user. Once the security lifetime is published, the patch is obtainable, and the mitigation has been communicated, failing to act looks less like a gap in the law and more like a gap in posture.
Security remains an active responsibility for the user. Negligent behaviour can still create liability under other rules — contracts, sector regulation, NIS2 where it applies, and ordinary duty of care. The CRA does not try those cases. It does make “we could not have known” a weaker defence.
The CRA’s user protections remove an excuse. They do not replace those duties.
What this adds up to
Taken together, these duties answer a broader question: should commercial software placed on the market carry continuing responsibility for its cybersecurity, instead of treating security as finished at the moment of sale?
The CRA’s answer is increasingly yes.
Software is still not a toaster. It changes continuously, depends on components that change independently, and can grow newly discovered vulnerabilities long after it ships. Versioning, upgrades, and support periods have to reflect that.
But placing covered software on the EU market now comes with an expectation that security is part of the product, that someone remains responsible when a component breaks, that users are told what to do when exploitation starts, that maintenance lasts for a declared life and that life is visible, that the fix is not sold again as a separate item, and that an issued update remains there to be fetched.
The CRA does not guarantee secure software. It does not move every cybersecurity risk from the user to the manufacturer. It moves the boundary of responsibility.
For the people who build the product, that list is also a design brief: these are the user outcomes the work is supposed to produce, not only the boxes compliance has to tick.
Looked at from the manufacturer’s side, these are compliance obligations.
Looked at from the user’s side, they are product protections.
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 how you use one, get proper legal advice for your specific situation.