CRA Severe Incident Classification
The Cyber Resilience Act never defines severe as a standalone term. The threshold sits in Article 14(5), narrowing the general incident definition to sensitive or important data or functions, or to malicious code, while Article 3(42) sets a separate evidentiary bar for actively exploited that a high severity score alone does not meet.
21 min read
32 views
Key takeaways: CRA severe incident classification 5
Where the severity gate actually sits in the text, what evidence actually satisfies the actively exploited bar, and how the manufacturer and steward duties diverge.
- Severe is three added words, not a new test Article 14(5)(a) takes the Article 3(44) definition of incident having an impact on the security of the product and narrows it to sensitive or important data or functions, and that substitution is the whole severity gate for that limb. Article 14(5)(b) is a separate, disjunctive test: any confirmed introduction or execution of malicious code in the product or a user's systems is severe on its own, regardless of data sensitivity.
- Product scope reaches beyond the device itself Article 3(1) covers a product's remote data processing solutions as well as its software or hardware, and Recital 11 draws the line functionally: a cloud backend a product cannot work without is part of the product, while a standalone SaaS a customer buys and runs on its own is not.
- Actively exploited means evidence of abuse, not evidence of risk A proof of concept, a high CVSS score or a listing on a public exploited-vulnerability catalog does not meet the Article 3(42) bar. Reliable evidence of unauthorized exploitation does.
- Free of charge is not an exemption from being a manufacturer Article 3(13) covers products marketed under a person's own name whether paid, monetized or free. White-labeling another company's product also makes you its manufacturer.
- Steward duties scale with the type of support given, and the role is per project Non-technical support carries no Article 14 duty, infrastructure support carries a severe-incident duty and engineering support adds an actively-exploited-vulnerability duty. The same organization can be a steward for one project and a manufacturer for another.
In short: the EU Cyber Resilience Act, Regulation (EU) 2024/2847, does not define severe as a standalone term. Article 3 contains no definition of a severe incident. The severity threshold sits in Article 14(5), which narrows the general incident definition in Article 3(44) to incidents affecting sensitive or important data or functions under limb (a), or incidents involving the introduction or execution of malicious code under limb (b), either limb sufficient on its own. A separate provision, Article 3(42), sets the evidentiary bar for an actively exploited vulnerability: reliable evidence that a malicious actor has exploited it without permission, not a high severity score or a listing on a public exploited-vulnerability catalog. Who owes either duty also varies: Article 3(13) defines manufacturer broadly enough to catch a free or rebranded product, while Article 24 gives open-source software stewards a separate, scaled regime tied to what kind of support they actually provide.
The severity gate hides in three words
A companion piece on this site walks through the Cyber Resilience Act's 24-hour, 72-hour, 14-day and one-month reporting deadlines in detail, and a further piece covers filing those notifications through the coordinating CSIRT channel via the CRA Single Reporting Platform. This one stays upstream of both, at the two gates that decide whether any of those clocks starts running in the first place. Both gates are narrower than most internal runbooks assume, and the gap between what teams think triggers a report and what the Regulation actually requires is where over-reporting and under-reporting both happen.
A bug that merely touches data handling or a function's behavior clears the incident definition almost automatically, in principle. Article 3(44) defines an incident having an impact on the security of a product as one that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions. That net is wide by design, which is exactly why the regulation does not stop there.
Article 3 does use the word severe once, in point (38)'s definition of significant cybersecurity risk, which describes a risk that can be assumed to have a high likelihood of an incident that could lead to a severe negative impact. That occurrence does not define a severe incident, though, and a surprising amount of secondary coverage gets this wrong by treating severity as if it were set in the same clause as the incident definition. Article 3 contains no definition of a severe incident at all. The threshold sits one article later, in Article 14(5), and it works by narrowing the same test rather than introducing a new one.
Article 14(5) makes an incident severe where either of two conditions applies. The first, limb (a), restates the Article 3(44) test almost word for word, with one substitution: instead of data or functions in general, it requires an effect on the availability, authenticity, integrity or confidentiality of sensitive or important data or functions. Three added words carry the entire severity gate for that limb. Everything else in the sentence is identical to the general incident definition it narrows.
For an engineering team doing triage, that substitution is the whole exercise. A cosmetic display setting reverting to its default, a non-authoritative cache that corrupts and quietly self-heals on the next sync or a purely presentational rendering defect plainly fails that bar, because none of them touches sensitive or important data or functions. The judgment call shifts from whether something bad happened to data or a function, which is nearly always yes at some level, to whether the thing affected was sensitive or important, which is a much smaller set.
Limb (b) is a different test entirely and does not depend on sensitivity at all: the incident has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user. The two limbs are disjunctive, joined by or rather than and, so a manufacturer only needs one of them. The practical consequence removes a whole category of internal debate: any confirmed arbitrary code execution path that reaches a customer environment is severe by definition under limb (b), regardless of how sensitive the data sitting next to it happens to be.
Actively exploited is not the same test as exploitable
The other trigger under Article 14 is an actively exploited vulnerability, and Article 3(42) sets a specific evidentiary bar for it: reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner. That definition rules out several things a security team's instinct might otherwise treat as sufficient.
A proof of concept existing does not on its own meet the bar, whether written internally, published by a researcher or shared on an exploit development mailing list. A high CVSS score does not meet it either, no matter how alarming the number looks in a dashboard. Appearing on a public catalog of vulnerabilities known to be exploited in the wild does not automatically meet it for a specific product either, because that catalog entry may describe exploitation of a different implementation, with no evidence the manufacturer's own customers were touched. What Article 3(42) actually asks for is evidence of actual unauthorized exploitation, not evidence that exploitation is plausible, likely or has happened somewhere to something similar.
Article 3 also defines a related but distinct term, exploitable vulnerability, as one with the potential to be effectively used by an adversary under practical operational conditions. That phrase describes a capability, not an event, and almost every vulnerability a scanner flags as critical is, by this definition, exploitable in the abstract. Whether it has been actively exploited is a separate factual question, and the gap between those two categories is where most triage disputes inside a security team actually live. A vulnerability can sit in the exploitable bucket for months without ever crossing into actively exploited, and it is only the second category that starts an Article 14(1) clock. What a manufacturer has to do about a vulnerability once it exists, separate from whether or when it has to be reported, is covered in a companion piece on CRA vulnerability handling requirements.
Two related definitions in Article 3, at paragraphs 43 and 45, import the definitions of incident and near miss directly from Article 6 of Directive (EU) 2022/2555, the NIS2 Directive, rather than restating them from scratch. A security team already running an incident classification process for NIS2 is not starting from a blank page for the CRA's incident vocabulary, even though the manufacturer duty under the CRA and the entity-level duty under NIS2 are separate obligations, and neither reporting regime relieves an organization of the other, a distinction a companion piece covers in full for the overlap between the CRA, NIS2 and DORA.
Recital 68 draws a deliberate line around good faith security work. Vulnerabilities discovered with no malicious intent, for the purposes of testing, investigation, correction or disclosure carried out to promote security, are not intended to be subject to mandatory notification. A researcher probing a product, an internal red team exercise or a coordinated disclosure process running exactly as designed does not, by itself, generate the kind of exploitation evidence Article 3(42) requires. What triggers the clock is a malicious actor abusing the vulnerability without permission, not the mere fact that someone found it.
A decision table for triage
The two triggers under Article 14 run on separate tests and start separately. The table below orders them into the sequence an engineer can actually run against a live event: check the vulnerability track first, then the incident track, because the two are independent and a single event can clear both.
| Step | Question | Provision | If yes | If no |
|---|---|---|---|---|
| 1 | Vulnerability track: is there reliable evidence a malicious actor has exploited the vulnerability in a system without permission of the system owner? | Article 3(42) | It is an actively exploited vulnerability. The Article 14(1) notification duty and its 24-hour, 72-hour and 14-day clocks start, regardless of what the incident track below shows. Also run steps 2 to 4: a single event can start both sets of clocks. | Not an actively exploited vulnerability under Article 14(1), even if the vulnerability is exploitable in the abstract. Move to the incident track; the two tracks are checked independently. |
| 2 | Incident track: has something happened that negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of data or functions? | Article 3(44) | It is an incident having an impact on the security of the product. Continue to step 3 to test severity. | Neither track applies to this event on the facts as known. No Article 14 clock starts from it. |
| 3 | Limb (a): is the effect specifically on sensitive or important data or functions, rather than on data or functions in general? | Article 14(5)(a) | The incident is severe. The Article 14(3) notification duty and its 24-hour, 72-hour and one-month clocks start. | Not severe under limb (a) alone. Continue to limb (b); the two limbs are disjunctive, so either one independently makes the incident severe. |
| 4 | Limb (b): has the incident led, or is capable of leading, to the introduction or execution of malicious code in the product or in a user's network and information systems? | Article 14(5)(b) | The incident is severe, regardless of the answer at step 3. The Article 14(3) clock starts. | Not severe under either limb on the facts as known. Reassess if new facts emerge; voluntary reporting under Article 15 stays available in the meantime. |
A vulnerability that is actively exploited can also be the event that produces a severe incident, for example where the exploitation itself negatively affects sensitive or important data. When that happens, the Article 14(1) and Article 14(3) clocks both start, running in parallel against the same underlying event.
The table settles the easy cases. It does not settle several that come up constantly in practice, because the Regulation does not define sensitive or important for the purposes of Article 14(5)(a), and the four cases below are where that gap actually bites. Below, incident is shorthand for that Article 3(44) term, not for plain incident at Article 3(43).
Recital 68 also describes severe incidents as situations where a cybersecurity incident affects a manufacturer's development, production or maintenance processes in such a way that it could result in an increased cybersecurity risk for users, citing an attacker who introduces malicious code into the release channel used to ship security updates.
Pseudonymous telemetry: whether it counts as sensitive or important data turns on what Article 14(5)(a) means by sensitive, and the Regulation does not define that word for this purpose or tie it to any other instrument's category of sensitive data. Pseudonymization reduces identifiability, which weighs against treating the data as sensitive on its own, but a telemetry stream that would reveal something material about a user once combined with other data, or that documents the behavior of a security-relevant function, has a real argument on the important side of the same test even without being sensitive on the data side. The text does not resolve which reading governs. What would settle it is Commission guidance or CSIRT and ENISA notification practice defining sensitive or important for this purpose, which the Regulation's own text does not currently supply.
Consider a debug interface left enabled. Article 3(40) treats a weakness like this as a vulnerability, and Article 3(44) treats an incident as a separate concept from a vulnerability. A standing misconfiguration with no evidence anyone has used it does not, on the text, become an incident merely by existing, and it does not meet the Article 3(42) evidentiary bar for an actively exploited vulnerability without reliable evidence of unauthorized use. Whether the interface's mere presence is itself capable of negatively affecting the product's protective ability under Article 3(44), in a case where it exposes sensitive or important functions to access they were never supposed to have, even absent any actual access attempt, is a closer question the operative definitions leave open rather than answer directly, because capable of negatively affecting could describe an ongoing weakened state or could require some event beyond the vulnerability itself, and Recital 68 addresses that gap only obliquely, not enough to settle it. What would settle it is whether a change in the product's own protective posture, without any third-party access, counts as an incident at all, a boundary the definitions do not draw explicitly.
Take a rate limiter that fails open. If the failure directly degrades the availability of a function, that is a plain effect within Article 3(44), and whether it clears limb (a) then turns on whether the function the rate limiter protects is itself sensitive or important, for example because it gates authentication or a payment flow. If the failure instead just removes a control without yet causing a measurable effect, it reads more naturally as a vulnerability than as an incident, on the same distinction as the debug interface case above, until it is actively exploited or until it actually degrades a protected function. The operative definitions do not fix a bright line between a standing control failure and an incident, and Recital 68 gestures toward that boundary without resolving it; the fact pattern, not a definition, is what decides it.
A feature flag store: nothing in Article 14(5)(a) turns on what kind of store is involved, only on what the affected data or function is. A flag store that only toggles cosmetic behavior is unlikely to reach sensitive or important on any reading. A flag store that gates a security control, such as whether encryption or an authentication requirement is enforced, has a strong argument for important, because compromising it would compromise the very functions the essential requirements in Annex I are meant to protect, even though the store itself holds no sensitive data. The Regulation gives no cross-reference to resolve this by category, unlike Annex III's separate and unrelated concept of important products with digital elements; each flag store has to be assessed by what it actually gates, not by its label as configuration infrastructure.
Who counts as a manufacturer, and giving software away is not an exemption
Arrangements that do not look like manufacturing at all can still fall within the CRA's manufacturer definition. The severity and exploitation tests above only matter for entities the CRA actually reaches, and Article 3(13) defines manufacturer broadly enough to catch those arrangements. A manufacturer is a person that develops or manufactures products with digital elements, or has such products designed, developed or manufactured and markets them under its own name or trademark, whether for payment, for monetization or free of charge.
Two consequences of that definition are worth stating without hedging, because they contradict assumptions that show up repeatedly in how teams scope their own compliance work. Giving software away does not exempt a manufacturer from the duty. A company distributing a free client application, a free tier of a connected device firmware image or an internal tool released publicly with no monetization attached is still marketing a product under its own name, and free of charge is written into the definition precisely so pricing decisions cannot route around the obligation. Second, white-labeling somebody else's product under your own brand makes you the manufacturer of it for CRA purposes, not a reseller sitting outside the regulation's reach. An organization that takes a third-party component, rebrands it and ships it as its own has stepped into the manufacturer role for that product, whatever contractual language describes the underlying supply relationship.
What counts as a product with digital elements
Article 3(1) defines a product with digital elements as a software or hardware product and its remote data processing solutions, including components placed on the market separately. Remote data processing solutions is where most scoping confusion starts, because it sounds like it could pull ordinary SaaS into scope wholesale, and Recital 11 exists specifically to draw that line more narrowly.
Recital 11 explains that the remote data processing limb covers processing at a distance that is designed by, or for, the manufacturer, where the absence of that processing would prevent the product from performing one of its functions. That test is functional, not categorical. A standalone SaaS product that a customer buys and operates on its own is not, as such, a product with digital elements under the CRA. A cloud backend that a manufacturer's connected device or client application cannot work without, because a function the product was sold on depends on that backend being reachable, is treated as part of the product rather than as a separate service outside it. The practical test an architecture team can apply is whether removing the remote component breaks a function the product was marketed as having. If it does, that component sits inside the same scope boundary as the local software or hardware.
Connectivity, not networking as a headline feature, is the trigger for scope under Article 2(1), which sets the overall condition: products whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. A device that exposes a maintenance port, accepts firmware updates over a wired connection or logs telemetry through an intermediary gateway can satisfy an indirect connection even where it has no network stack a user would recognize as such.
The categories the CRA does not touch
A short list of product categories sits outside the CRA entirely, and it is worth naming them plainly rather than assuming a product falls under one of them without checking the actual regulatory boundary. Medical devices regulated under Regulation (EU) 2017/745 and in vitro diagnostic medical devices under Regulation (EU) 2017/746 are excluded, because those sectors already carry their own dedicated cybersecurity and safety regimes. Vehicles falling under Regulation (EU) 2019/2144 are excluded on the same logic, as are civil aviation products certified under Regulation (EU) 2018/1139. Equipment falling within the scope of Directive 2014/90/EU, the marine equipment directive, is excluded under Article 2(4) for the same reason.
Identical spare parts are excluded, which matters for manufacturers maintaining long product lifecycles where a replacement part reproduces an already-assessed component rather than introducing a new one. Products developed exclusively for national security or defense purposes, or specifically designed to process classified information, are also outside scope. None of these exclusions is a blanket carve-out for an entire industry. A connected medical accessory that does not itself qualify as a medical device under Regulation (EU) 2017/745 does not inherit the exclusion just because it sits near a regulated device in a hospital, and each exclusion needs to be checked against the specific product rather than the sector it ships into.
Open source stewards get a genuinely different regime
The CRA does not simply exempt open source, and it does not treat every organization touching it the same way. It creates a distinct category, the open-source software steward, with a scaled set of obligations that depends on what the steward actually does. Article 3(14) defines the steward as “a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.”
The European Commission describes the design intent behind that category directly, noting that stewards “are subject to a light-touch and tailor-made regulatory regime.” Light-touch is not the same as no obligation. Commission guidance published on 27 July 2026 makes clear at paragraph 79 that while every steward has to comply with Article 24(1) and (2), how far the Article 14 reporting duties actually apply varies with the type of support the steward provides, under the scaling mechanism set out in Article 24(3).
That scaling produces three practical tiers. Guidance paragraph 80 states that a steward providing only non-technical support, meaning branding, governance, event organization or handling donations, is by definition not involved in development, and is not required to report actively exploited vulnerabilities or severe incidents at all. A steward that also provides the underlying IT infrastructure a project depends on, covered at guidance paragraph 81, must notify severe incidents related to that infrastructure under Article 14(3), but still carries no duty on actively exploited vulnerabilities. And a steward that goes further still and also provides engineering resources, under paragraph 82, must notify actively exploited vulnerabilities under Article 14(1) and, where appropriate, inform users, closest to a manufacturer's reporting posture without actually being one. That last element is worth flagging precisely: Article 24(3) itself groups the duty to inform users, Article 14(8), together with the infrastructure limb, Article 14(3), not with Article 14(1). The guidance's placement of user-informing in the engineering tier is the Commission's gloss on top of the operative text, not a distinction Article 24(3) draws in those words.
A separate scoping question is what counts as commercial activity for a free project, because Article 24's steward regime only applies where the manufacturer route does not. The Commission is explicit that “the provision of products with digital elements qualifying as free and open-source software that are not monetised by their manufacturers should not be considered to be a commercial activity.” A project with no monetization attached, published by an entity that otherwise looks like it could be a manufacturer, sits outside that route by default. Guidance paragraph 78 gives the clearest example of who lands in the steward category to begin with: foundations offering sustained support to commercially intended free and open source software are stewards, which covers most of the nonprofits that host critical infrastructure projects and maintain the shared tooling downstream manufacturers depend on.
Two further points change how an organization should think about its own role. Guidance paragraph 216 ties the steward's reporting duty to becoming aware of actual exploitation, not to a vulnerability merely existing in the codebase, mirroring the actively exploited standard above. Guidance paragraphs 73 and 76 assign the role per project, not per legal entity: the same organization can be a steward for one project and a manufacturer for another, and an entity publishing a free community edition alongside a monetized edition is a steward for the free edition and a manufacturer for the paid one. A compliance program that classifies an organization once, at the entity level, will misclassify at least one project it touches.
Once a steward's Article 14 duty is triggered, its scope is fixed by Article 24, which the Commission summarizes as covering “the obligations laid down in Article 24, notably putting in place a cybersecurity policy to foster secure development and handling of vulnerabilities; cooperating with market surveillance authorities; reporting actively exploited vulnerabilities and severe incidents having an impact on the security of products with digital elements.” That is the same reporting subject matter a manufacturer files on, applied to a narrower set of triggering roles and, per the tiers above, sometimes a narrower set of triggering events. The financial exposure is deliberately different too. Article 64(10)(b) removes, by way of derogation from paragraphs 3 to 9, the administrative fines referred to in those paragraphs for any infringement of the Regulation by an open-source software steward. That derogation is scoped to the fines set out in Article 64(3) to (9); Article 64(2), the tier addressed to non-compliance with the essential requirements in Annex I and the obligations in Articles 13 and 14, sits outside paragraphs 3 to 9 and outside that derogation. How far the carve-out actually reaches for a steward is accordingly not settled on the face of the text. Article 64(10)(a) makes a narrower, separate point, under the same paragraphs-3-to-9 scope limit: manufacturers that qualify as microenterprises or small enterprises are not subject to those fines specifically for missing the deadlines in Article 14(2), point (a), and Article 14(4), point (a), the 24-hour early warning window. Neither derogation changes what has to be reported. Both change, within whatever their actual scope turns out to be, what happens if a report is late.
How Pharos Production helps
Most of the compliance work that goes wrong on the CRA does not go wrong at the deadline stage. It goes wrong earlier, at the classification stage this article covers, when a triage playbook is built around whatever the team already believes counts as severe rather than around the actual three-word test in Article 14(5)(a), or when a project's role in the steward-versus-manufacturer split has never been checked against how it is funded and maintained. We build that classification logic into the incident response tooling itself: severity gates keyed to sensitive or important data or functions rather than data or functions in general, exploitation evidence pipelines that distinguish a CVSS score from reliable evidence of unauthorized abuse and role mapping that tracks manufacturer and steward status per project rather than per organization.
Where a client publishes both a monetized product and an adjacent open-source project, we help set up the governance record that documents which entity is acting in which role for which codebase, so the answer exists before a regulator asks for it rather than being reconstructed under pressure during an active incident. None of this replaces the deadline mechanics the companion piece covers. It is the layer that decides whether those clocks ever start at all.
Sources: European Commission, Cyber Resilience Act summary (digital-strategy.ec.europa.eu/en/policies/cra-summary); European Commission, Cyber Resilience Act and open source software (digital-strategy.ec.europa.eu/en/policies/cra-open-source); Regulation (EU) 2024/2847 of the European Parliament and of the Council (eur-lex.europa.eu/eli/reg/2024/2847/oj), Articles 2, 3, 14, 15, 24 and 64, and Recitals 11 and 68; European Commission guidance on the Cyber Resilience Act, 27 July 2026, paragraphs 73, 76, 78 to 82 and 216.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 7
No matches
Try a different keyword, change the topic or clear filters
-
The Regulation does not hand over a checklist; the two definitions are worded to be mutually exclusive instead. Article 3(13) turns on whether a person develops, manufactures or has manufactured a product and markets it under its own name or trademark.
Article 3(14) turns on whether a legal person, other than a manufacturer, systematically supports the development of free and open-source software intended for commercial activities and ensures its viability, without itself marketing the product under its own name. In practice, marketing a product under your own name or trademark is the fork in the road: doing that makes you the manufacturer regardless of how you also support the underlying project, while sustaining a project without branding it as your own product points to the steward definition instead, subject to the commercial-activity threshold the Commission's guidance addresses separately.
-
Article 3(44) defines incident having an impact on the security of the product with digital elements as one that negatively affects, or is capable of negatively affecting, the ability of a product to protect the availability, authenticity, integrity or confidentiality of data or functions in general. Plain incident is a separate term, defined in Article 3(43) by cross-reference to Article 6 of the NIS2 Directive.
Article 14(5)(a) takes the Article 3(44) test and narrows it to sensitive or important data or functions. Sensitive or important are the three words that carry the entire severity gate for that limb.
-
Article 3(42) states only the standard itself: reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner. Recital 68 gives the closest thing to worked content, describing actively exploited vulnerabilities as instances where a manufacturer establishes that a security breach affecting its users or other persons has resulted from a malicious actor making use of a flaw in one of its products, and it names weaknesses in a product's identification and authentication functions as an example of the kind of flaw involved.
Neither provision sets out a checklist of qualifying evidence types, so what satisfies the bar in a given case is a factual determination for the manufacturer and the CSIRT designated as coordinator, not a fixed list the Regulation supplies in advance.
-
No. Article 3(42) requires reliable evidence that a malicious actor has exploited the vulnerability in a system without the permission of the system owner. A proof of concept, a high severity score and appearance on a public catalog of known exploited vulnerabilities are all evidence of exploitability, not evidence of actual unauthorized exploitation, which is the bar Article 3(42) sets.
-
No. Article 3(13) defines manufacturer to include products marketed under a person's own name or trademark whether for payment, for monetization or free of charge. A company distributing free software under its own brand is still a manufacturer.
White-labeling another company's product under your own brand also makes you the manufacturer of it.
-
No, and Commission guidance reads the duties as scaling with the type of support the steward provides under Article 24(3). A steward offering only non-technical support such as branding or handling donations has no Article 14 reporting duty at all.
A steward providing infrastructure must report severe incidents affecting that infrastructure. A steward also providing engineering resources must report actively exploited vulnerabilities too, closest to a manufacturer's position without being one. Article 24(3) itself only ties the Article 14(1) duty to involvement in development, and groups the Article 14(3) infrastructure duty with the duty to inform users at Article 14(8).
-
Yes. Commission guidance states the role is assigned per project, not per legal entity.
An organization publishing a free community edition of a product alongside a monetized edition is a steward for the free edition and a manufacturer for the paid one, and the two classifications can sit inside the same organization at the same time.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
