Tech Support
Documentation
Login
Contact Us
Go straight to an AI summary of this blog post instead 
Key Takeaways
- Since 11 September 2026, CRA Article 14 requires you to notify within 24 hours of becoming aware that an actively exploited vulnerability exists in your product.
- A top-level SBOM, the Annex I minimum, will not find a package several levels down; a release-level inventory of every shipped build will.
- A compatible backport of the version you already run fixes a buried dependency without changing everything above it.
- Your CRA support period outlasts upstream maintenance, so each package version needs a fix path that continues after its upstream end of life.
A new entry appears in CISA’s KEV catalog on a Tuesday. It names a vulnerability being actively exploited in a package nobody on your team chose, sitting three levels down in a dependency tree nobody intentionally assembled. Within 24 hours, someone at your company must determine whether that package is included in a release you shipped and whether your CSIRT and ENISA need to be informed.
Article 14 of the EU Cyber Resilience Act (CRA) looks like from the inside. The deadlines are short, and the trigger is narrower than most summaries suggest, but what hurts is rarely the reporting itself. It is establishing what is actually in the build while the clock runs.
The CRA’s 24-hour clock is running
Since 11 September 2026, Article 14 of the CRA has applied. It is the first CRA reporting requirement to land on manufacturers, and it runs on a clock. Once you become aware that a vulnerability in your product is being actively exploited, you have 24 hours.
The CRA uses “manufacturer” to mean an organization or person that develops a product with digital elements, or has it developed, and places it on the EU market under its own name or trademark in the course of a commercial activity. Commercial activity does not only mean charging a price. Paid support counts when it does more than recover your actual costs. So can monetizing through a platform, or requiring users to hand over personal data for reasons beyond improving the software’s security, compatibility, or interoperability. If that is your company and your product ships open source, Article 14 is already your problem.
Article 14 sets three reporting deadlines. Each report goes through ENISA’s Single Reporting Platform to the CSIRT designated as the coordinator, typically the one for your main establishment, and to ENISA itself, the EU cybersecurity agency.
The first is the 24-hour early warning notification. Within 72 hours, you send a fuller vulnerability notification. No later than 14 days after a corrective or mitigating measure is available, which is the CRA’s term for a fix or a workaround, you send a final report. The 24-hour and 72-hour windows are outer limits rather than waiting periods. The text says “without undue delay and in any event within” those windows.
“Actively exploited” has a precise meaning. There must be reliable evidence that a malicious actor has exploited the vulnerability in a system without the system owner’s permission. A published CVE is not enough. A proof of concept is not enough either. Article 14 also covers severe incidents impacting a product’s security. Those run on a separate track, with a final report due one month after the incident notification. This article is about vulnerabilities and the open source dependency side of the CRA. Risk assessment, conformity assessment, and the other manufacturer duties are outside its scope.
The CRA compliance deadline for the remaining manufacturer obligations, and for fines, is 11 December 2027. Article 14 is already in force and covers products placed on the EU market before that date.
Where this comes from: Article 14(1), (2), (4) and (7); Article 3(13) and 3(42); Article 64; Article 71(2); Article 69(3); recitals 15 and 18.
Why a top-level SBOM cannot tell you whether you are affected
Evidence that a vulnerability is being exploited usually reaches you from outside: an entry in CISA’s Known Exploited Vulnerabilities (KEV) catalog, an advisory from a vendor or a maintainer, or a message from a CSIRT, a researcher, or a customer. From there, three things happen. You learn that a vulnerability is being exploited somewhere. You work out whether your product is affected. Then you identify which releases and which users are affected.
The clock starts when you become aware of an actively exploited vulnerability in your product, so start assessing credible alerts straight away. A matching package name does not by itself mean your product is affected, and an accurate inventory is what lets you settle that quickly. The steps overlap in practice, and you do not wait for a complete user list before sending an early warning as the deadline approaches.
The package in the alert is often a transitive dependency, pulled in by one of your direct dependencies, and chosen by no one on your team. Log4Shell (CVE-2021-44228) is the familiar case. log4j-core was present in many applications as a dependency of frameworks and connectors, and most teams’ first job was working out whether they had it at all.
This is where the CRA’s inventory requirement comes in. Annex I requires manufacturers to identify and document the components of a product, including by preparing a software bill of materials (SBOM) in a commonly used, machine-readable format. The minimum depth is “at the very least the top-level dependencies.” That floor is reasonable. It is also not enough for the 24-hour question.
A top-level SBOM records what you added directly. The question in front of you is whether a specific version of a specific package appears anywhere in the product, and there are three places to look.
Your manifest, whether that is package.json, pom.xml, or requirements.txt, lists the dependencies you declared, often as version ranges. Your lockfile records the resolved dependency graph for a build, though what finally ships can still vary due to platform-specific and optional dependencies, build tooling, vendoring, and any regeneration of the lockfile along the way. Your release inventory shows what the shipped artifact contains: resolved component versions, anything bundled or vendored into the artifact, and none of the development dependencies that never leave your build.
The lockfile is an essential input, but it does not prove what shipped. To say whether the reported vulnerability is in a particular release, you need the release inventory.
There is one more wrinkle for anything past its upstream end of life. When a vulnerability is fixed, the advisory usually reads something like “fixed in 4.2, older branches are no longer supported”. The 3.x version in your tree may well be affected, but upstream may never say so, because nobody there is looking at that branch anymore. The analysis falls to you.
Where this comes from: Article 14(1); Article 3(42); Annex I, Part II(1).
Why “we did not know” does not protect you
The Article 14 clock does not start until you become aware of an actively exploited vulnerability contained in your product. That is a narrow limit on a single trigger, and it does nothing to address the rest of the CRA.
From 11 December 2027, the broader CRA obligations apply. For products placed on the market before that date, the transitional rules bring them in when the product undergoes a substantial modification on or after that date. Those obligations require you to identify and document the components and vulnerabilities in your product and to conduct effective, regular security tests and reviews. It requires due diligence when you bring in third-party components, including open source ones. And it requires you to handle vulnerabilities in the product, “including its components”, effectively for the whole support period.
A component your tooling missed does not, by itself, prove that your process falls short. It may well prompt an authority to look at whether your component identification and vulnerability handling are adequate. Those duties sit in the CRA’s highest fine tier, which is up to EUR 15 million or 2.5% of your company’s total worldwide annual turnover for the preceding financial year, whichever is higher. Market surveillance authorities can also order corrective action, restrict or prohibit sales, or require a withdrawal or recall.
The enforcement date is still some way off. The next alert is not. If your tooling missed a package, the first hours of a 24-hour window are spent determining whether that package is even in your stack, leaving far less time for everything else the report needs.
Where this comes from: Annex I, Part II(1) and (3); Article 13(5) and (8); Article 54; Article 64(2); Article 69(2).
Now fix it without breaking everything above it
The 72-hour notification asks for what you know so far: general information about the product, the general nature of the exploit and of the vulnerability, any corrective or mitigating measures you have taken, and the measures your users can take. You do not need a finished patch to submit it. For a transitive dependency three levels down, though, the effort still goes into working out those measures.
Consider the usual situation. The fix exists upstream in version 4.2. The intermediate package in your tree is stuck on the 3.x line, and its maintainer has not moved. None of your options are free. You can wait for the maintainer. You can force an override in your lockfile and accept the risk that something above it breaks. You can move the intermediate package to a major version that supports 4.2, and ship any unrelated changes that come with it as part of a security release. You can replace the component, or patch it yourself. Or you can obtain a compatible backport, which is the security fix applied to the 3.x branch you already use.
From December 2027, Annex I requires two things here. You have to address and remediate vulnerabilities without delay. And where technically feasible, you ship security updates separately from feature updates. The CRA does not prescribe which route you take. It also lets you provide the security update for your latest version only, as long as users on earlier versions can move to it free of charge and do not incur extra costs to adapt their environment.
A compatible backport fits that separation and keeps migration work small. It is a fixed build of the version already in your tree, compatible with its dependents, with dependent packages rebuilt as needed. When done properly, your own manifests remain untouched, and compatibility testing happens once in your product.
When a backport includes a committed delivery date, you have a concrete remediation timeline to report alongside the measures you have already taken. The rest is yours: integrating the patched component, testing it, and releasing it as an update to your product. The sooner the component arrives, the more of the window you keep for that.
Where this comes from: Article 14(2)(b); Annex I, Part II(2); Article 13(10); Article 69(2).
The final report comes after the fix, and the obligation runs for years
The final report is due no later than 14 days after a corrective or mitigating measure is available. It describes the vulnerability, its severity and impact, what is known about the attacker, and the security update or other measures you have made available.
Separately, once you become aware of the vulnerability, you have to inform the users it affects and all users, where appropriate, all users. The notice has to tell them what they can do to mitigate or fix the problem. Where appropriate, it goes out in a structured, machine-readable format. The CRA does not prescribe a particular one. CSAF is the widely used machine-readable advisory format, and VEX statements, which say whether a vulnerability affects a particular product, can be expressed as CSAF VEX, CycloneDX VEX, or OpenVEX.
From December 2027, the update itself must also be distributed securely, without delay, and free of charge.
Then comes the long tail, where the arithmetic of open source stops working in your favor.
For as long as your support period lasts, you must continue to address vulnerabilities in the product. You set the support period yourself, but it must reflect how long the product is expected to be in use and be at least 5 years unless the product is expected to be used for less time. On top of that, every security update you issue during the support period must remain available for at least 10 years after it’s issued, or until the end of the support period, whichever is later, so a user who updates late can still get it.
Upstream maintenance for a package version can end well before your support period does. When it does, the CRA still holds you to your period. You are not bound to that exact version, since replacing or upgrading a component can be a legitimate remedy. You are bound to continue addressing vulnerabilities in your product, by whatever means, for the entire support period.
Where this comes from: Article 14(2)(c) and (8); Annex I, Part II(7) and (8); Article 13(8) and (9); Article 69(2).
Nobody upstream shares your clock
The CRA deliberately keeps free and open-source software developed or supplied outside a commercial activity clear of the manufacturer’s obligations.
It creates a separate category, the open-source software steward, for legal persons that provide sustained support for the development of open source software intended for commercial activities. Stewards get a lighter, tailor-made regime that applies from December 2027, with limited Article 14 duties in defined circumstances. Individual community maintainers are not automatically manufacturers or stewards.
Whatever their obligations and support commitments are, they are different from yours, and they do not take yours away. Article 13(6) makes this concrete. When you identify a vulnerability in a component you ship, you must report it to the person or entity manufacturing or maintaining that component, remediate it in your product whether or not they respond, and share the relevant code or documentation if you developed a fix. You can patch, replace, or upgrade the component. What you cannot do is let upstream inaction justify delaying your own response.
These Article 13 obligations apply from 11 December 2027. The operational lesson applies now. For code deep in your tree that you did not write and may never have read, the vulnerability in your product is still yours to resolve, even when upstream does not help.
Where this comes from: Article 24; Article 3(14); Article 13(6); Article 69(2); recitals 18 and 19.
What a workable answer has to do
The CRA leaves you room to decide how to approach Article 14 compliance. What follows is a practical set of capabilities for the open source in your product. They matter most where keeping existing versions compatible saves you migration work.
Start with a release-level inventory of everything in the product, down to the last transitive dependency, recorded as resolved versions and mapped to what each product release actually ships. The 24-hour question then gets answered from records rather than from a scan you kicked off after the alert landed.
Next, you need fixes that arrive in time, including compatible backports for the versions already in your tree where upgrading isn’t practical, with dependent packages rebuilt as needed. Security changes can then ship separately from feature changes, and the migration work stays small. That fix path also has to continue after a package’s upstream end of life, for the duration of your support period rather than the maintainer’s interest.
The last two are about what leaves your building. Affected users need prompt notification, in machine-readable formats where appropriate, and security updates that stay available for at least 10 years after you issue them, or for the remainder of the support period if that is longer. And you need equivalent coverage across every language ecosystem in your product, because Article 14 does not care where a component came from.
Most of the remaining manufacturer obligations, and the enforcement that comes with them, apply from 11 December 2027. The reporting obligation is already here. The months in between are the time to put those capabilities in place.
Where SecureChain and Endless Lifecycle Support fit
SecureChain and Endless Lifecycle Support (ELS) from TuxCare are built around those capabilities, in the same order.
Inventory first. Open source packages enter your product through the SecureChain catalog, which tracks the package versions it maintains and publishes machine-readable SBOMs for them, CycloneDX included, with dependency details underneath. That is the component side of your release inventory. You connect it to your build records and shipped artifacts, and from there, working out whether the affected component is present is a lookup rather than a scramble. When a vulnerability is confirmed, TuxCare publishes the vulnerability data for you to match against the package versions in that inventory.
Then the fixes. While upstream is still shipping them, SecureChain rebuilds them from source and delivers drop-in replacements for the supported package versions you already run. When upstream goes quiet, SecureChain patches the package itself and keeps it compatible. When a buried dependency is patched, dependent packages are rebuilt against the fix, which is what keeps your own manifests out of it. Patching follows published target response times by severity, set out in the lifecycle coverage datasheet. That gives your 72-hour notification a concrete timeline to report, alongside the measures already taken and the mitigations available to your users. Integrating, testing, and releasing the update as your own is still your step.
Then comes the part upstream stops doing. When upstream stops fixing a version, whether by missing a CVE deadline or by shipping no release for nine months, SecureChain keeps patching it for an additional three months. After that, Endless Lifecycle Support takes over and backports fixes for as long as you run the version, which is to say for as long as your own support period demands.
Advisories and updates are published through the TuxCare security portal as CSAF and VEX documents, with RSS feeds and signed metadata, ready to be connected to your own affected releases and user notices. TuxCare is also a CVE Numbering Authority (CNA), so it can assign CVE identifiers to vulnerabilities within its own scope and publish them in its advisories rather than queuing behind someone else.
The model spans JavaScript, Python, Java, Go, Rust, and PHP. One catalog, one SBOM model, one remediation model, regardless of which ecosystem a package came from.
TuxCare is a manufacturer under the CRA in its own right for the products it places on the EU market, so the same Article 14 obligations apply to it, along with the duty under Article 13(6) to report component vulnerabilities upstream and share the fixes. What the two products change for you is how much of the window between an alert and a fixed release gets spent waiting on somebody else’s component fix, and the quality of the record you can submit while the clock is running.
Before the next alert
You can test most of this in an afternoon. Take one current release and one alert, real or assumed. Log4Shell will do if it touched you. Otherwise, assume a KEV entry for a library three levels down in your tree. Then follow the path the alert would take through your company and answer each question based on the last time it actually happened, or using an honest estimate if it has never occurred before.
Does your release inventory say whether the package is in that build? Where would the fix come from, and is anyone committed to a date for it? How long did your last security release take, from patched component to shipped update? How would your users hear about it? Wherever you have no answer is where the next alert will first find a gap.
Somebody in your company owns the 24 hours after that alert arrives. The drill tells you whether they could work out in time whether Article 14 applies and file it if it does.
