NIS2 for Software Vendors: How the CRA’s SBOM Mandate Makes You a NIS2 Supply-Chain Risk

Most software vendors read the NIS2 Directive’s sector list, don’t see “software publisher,” and close the tab. On the narrow question of “am I a regulated NIS2 entity,” they’re often right. But that’s the wrong question. The right one is whether the customers buying your product are regulated — because if they are, Article 21(2)(d) already requires them to interrogate your security practices, and the Cyber Resilience Act (CRA) has quietly made you a directly regulated “manufacturer” whether or not you ever touch a physical product.

This guide separates the two regimes cleanly: which one regulates you directly, which one regulates you through your customers, what the deadlines actually are, and where the real penalty exposure sits — because it isn’t where most vendors assume.

Are You a NIS2 Entity? Run the Scope Test Before Your Customers Do

In plain terms: a company that only licenses software products — no managed services, no marketplace, no search or social platform — is usually not itself a NIS2 essential or important entity. NIS2 regulates sectors, not software categories, and “software vendor” isn’t a listed sector. Two exceptions change that answer completely.

The first exception is Annex I, sector 9: “ICT service management (business-to-business).” Under Article 6(39), a managed service provider (MSP) is “an entity that provides services related to the installation, management, operation or maintenance of ICT products, networks, infrastructure, applications or any other network and information systems, via assistance or active administration carried out either on customers’ premises or remotely.” Article 6(40) adds managed security service providers (MSSPs) — an MSP that also carries out or assists with cybersecurity risk-management activities [5]. The B2B qualifier matters: if you sell a support contract that includes actively administering the software for a business customer, you’ve likely crossed from “vendor” into “MSP” — and MSPs and MSSPs sit in Annex I, the essential-entity tier, not the lighter Annex II tier.

The second exception is Annex II’s “digital providers” category, which covers exactly three business models: online marketplaces, online search engines, and social networking services platforms. A SaaS product that isn’t one of those three doesn’t inherit this scope just because it’s delivered over the internet.

There’s a third, narrower trap: Article 2(2) pulls certain entities into scope regardless of size — trust service providers, TLD registries and DNS operators, entities that are the sole provider of an essential service in a Member State, entities whose disruption could significantly affect public safety or health, or those posing a systemic risk [4]. Most product vendors don’t meet any of these, but a vendor whose software has become the de facto sole platform for a critical process in a given country should check this list specifically, not assume it’s only for utilities.

Your business model	NIS2 status	Why
Pure software licensing (no managed service)	Not directly regulated	No matching Annex I/II sector
Software + managed hosting/administration for the customer	Likely Annex I, sector 9 (MSP)	Matches Article 6(39) — active administration on or for customer systems
Managed security monitoring/response service	Likely Annex I, sector 9 (MSSP)	Matches Article 6(40)
Online marketplace, search engine, or social platform	Annex II (important entity)	Named “digital provider” category
Sole critical-process platform in a Member State	Check Article 2(2)	Regardless-of-size triggers

Run the full five-step version of this test — sector, size threshold, entity classification, group consolidation, jurisdiction — using the NIS2 scope test before assuming either answer.

Even If NIS2 Doesn’t Regulate You, You’re Still a Supply-Chain Risk

Here’s the part most “am I in scope?” content stops short of: your customer’s NIS2 obligations don’t disappear when they outsource to you — they double back. Article 21(2)(d) requires every essential and important entity to address “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” [3]. If your customer is NIS2-regulated and you’re a direct supplier, that obligation runs straight through your contract with them.

Germany’s BSI — the national competent authority — states this plainly in its NIS2 FAQ: “Even if IT is completely outsourced, you as an important or essential entity remain responsible yourself. You must ensure that your service providers implement the necessary NIS-2 requirements, these are regularly reviewed and incidents are properly reported.” [8] The BSI adds a detail vendors underestimate: no generic supply-chain compliance certificate exists. A customer can’t just ask “are you certified?” and check a box — they have to impose concrete, verifiable cybersecurity requirements on your product, typically referencing recognised standards, and document that review.

Compliance teams running these reviews report the same gap on the vendor side, repeatedly: a sales engineer who can describe the product’s features fluently but has no answer when asked for an SBOM, a documented vulnerability-disclosure process, or evidence of a secure development lifecycle. That gap is now showing up as a deal-blocker in procurement, not just an audit footnote — because your customer’s own auditor will ask for it on their behalf.

If your product is specifically a remote-monitoring, remote-administration, or managed-services tool, the exposure is sharper still — see how RMM and managed-service tooling became NIS2’s highest-flagged supply-chain category after the 2021 Kaseya VSA incident.

CRA Article 13: The Regulation That Actually Calls You a “Manufacturer”

Here’s the terminology trap: under the Cyber Resilience Act, if you place software with a data connection on the EU market, the law calls you a “manufacturer” — the same legal category as a company that builds routers or industrial sensors. The European Commission defines the covered “product with digital elements” as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately,” where the intended or reasonably foreseeable use includes a direct or indirect data connection [6]. A desktop app, a mobile app, a library, an API client — all in scope. Unlike NIS2’s sector test, the CRA doesn’t care what industry your customer is in.

Article 13 sets out what that “manufacturer” status requires. Security-by-design isn’t a marketing phrase here — paragraph 1 requires products to be “designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I,” and paragraph 2 requires a documented cybersecurity risk assessment integrated into planning, design, development, production, delivery, and maintenance [1] — not a one-off assessment before launch, but a process that runs for the product’s entire support period.

The SBOM mandate sits in the same article. Annex I Part II, point 1 requires a software bill of materials in “a commonly used and machine-readable format covering at least the top-level dependencies,” which market surveillance authorities can request on demand [1]. You’re not obliged to publish it, but you are obliged to be able to produce it — which means the dependency-tracking tooling has to exist before anyone asks, not get built the week a customer’s auditor requests it.

Vulnerability handling closes the loop: paragraph 6 requires reporting a vulnerability found in a third-party component back to that component’s maker or maintainer, and paragraph 8 requires a coordinated vulnerability disclosure (CVD) policy under Annex I Part II, point 5 [1]. Vendors already running an incident-response process may recognise the shape of this — see how a compliant vulnerability disclosure policy is structured under the parallel NIS2 obligation, since a CRA-grade CVD process and a NIS2-grade one share almost the same operational skeleton.

None of this is optional-by-date-far-away. Reporting obligations for actively exploited vulnerabilities and severe incidents begin 11 September 2026, via the CRA’s Single Reporting Platform to ENISA and the relevant national CSIRT. Full application of the essential requirements, conformity assessment, and CE marking obligations lands 11 December 2027 [6]. Building the SBOM pipeline and CVD process the month before the deadline is not realistic for most engineering teams — this is a 2026 build item, not a 2027 one.

Penalty Exposure: Why an SBOM Gap Costs More Than a Late Filing

Most vendors mentally file “SBOM” and “vulnerability disclosure” under paperwork — process obligations, not the kind of thing that draws the largest fine. Article 64’s penalty structure says the opposite. Non-compliance with the essential cybersecurity requirements in Annex I and the obligations set out in Articles 13 and 14 sits in the CRA’s top penalty tier: up to €15,000,000 or 2.5% of worldwide annual turnover, whichever is higher [2]. That’s the same tier as failing to meet the core security-by-design requirement itself — because legally, SBOM and CVD failures under Article 13 are essential-requirement failures, not administrative ones.

Penalty tier	What triggers it	Maximum fine
Highest	Essential cybersecurity requirements (Annex I) + Articles 13 & 14 obligations — security-by-design, SBOM, vulnerability handling, CVD	€15,000,000 or 2.5% of global turnover, whichever higher
Middle	Reporting and procedural obligations (Articles 18-23, 28, 30-33, 39, 41, 47, 49, 53)	€10,000,000 or 2% of global turnover, whichever higher
Lowest	Incorrect, incomplete, or misleading information to notified bodies/market surveillance authorities	€5,000,000 or 1% of global turnover, whichever higher

Microenterprises and small enterprises get an exemption from fines tied specifically to Article 14(2) and (4) deadline failures, and open-source software stewards are exempt from administrative fines generally [2] — but that exemption doesn’t extend to the core Article 13 obligations for a commercial vendor above the micro/small threshold. If your compliance roadmap treats SBOM tooling as a lower priority than incident-notification workflow because it “feels” more procedural, the fine structure disagrees with that instinct.

CRA Product Risk Classes: Does Your Software Face Stricter Scrutiny?

Not every product with digital elements gets the same conformity route. Most fall into the default class, where a manufacturer self-assesses conformity with Annex I. A narrower “important” category (Annex III) requires conformity assessment against harmonised standards or, for the stricter Class II tier, a notified third-party body — practitioner guidance consistently names password managers, network management tools, VPNs, operating systems, and firewalls as software squarely in this bracket. A small “critical” category (Annex IV) requires mandatory certification and is reserved for products like smart meters and secure elements — general-purpose software rarely lands there [7].

Treat that classification list as a starting signal, not a legal ruling — the underlying delegated acts that finalise exact category boundaries are still being worked through at EU level, so a vendor building an identity-management, endpoint-security, or remote-access product should track official guidance for its specific category rather than assume it stays in the default self-assessment tier. What doesn’t change: the higher your product sits in this ladder, the earlier you need a notified body relationship lined up, because Class II conformity assessment isn’t something you complete in the weeks before a launch.

Security-by-Design as Your Sales Differentiator

Flip the compliance burden into a sales argument. Because no generic supply-chain certificate exists for a NIS2 customer to rely on [8], every one of your competitors is being asked the same Article 21(2)(d) questions during procurement — and most can’t answer them without weeks of scrambling. A vendor that already holds CRA conformity documentation, a current SBOM, and a published CVD policy walks into that same procurement conversation with the customer’s audit already half-finished.

This is the practical version of the “compliance handshake” between the two regimes: CRA CE marking and technical documentation map onto much of what a NIS2 customer’s Article 21(2)(d) evaluation is trying to establish, so the same evidence can support both conversations. Compliance teams on the buying side are increasingly building exactly this expectation into vendor scorecards; see the customer-side view of how CRA certification reduces a NIS2 buyer’s supply-chain audit burden to understand what your prospect’s procurement team is being told to look for.

Building a Dual-Compliance Roadmap

Treat CRA and NIS2-driven customer requirements as one programme with two audiences, not two separate projects. The ownership split below is a starting allocation — adjust to your org chart, but don’t leave any row without a named owner.

Workstream	Primary owner	Effort to close a typical gap
SBOM generation and dependency tracking	Engineering / CISO	Medium — tooling exists (CycloneDX/SPDX generators), but needs CI/CD integration and a maintenance process
Coordinated vulnerability disclosure policy + intake channel	CISO / Security lead	Low-Medium — mostly a documentation and process exercise if an intake channel already exists
Product risk-class determination (default / Annex III / Annex IV)	Compliance / Legal, with Engineering input	Low — a classification exercise, but blocks everything downstream if skipped
Customer-facing NIS2 supply-chain documentation pack	Compliance / Legal	Medium — assembling evidence that already exists into an auditor-ready format
Notified-body engagement (Class II products only)	Board / Legal, budget owner	High — lead times and cost both scale with product category

Sequence it against the real dates: get the risk-class determination and SBOM pipeline running well before 11 September 2026, since that’s when exploited-vulnerability and severe-incident reporting obligations start — you can’t report from a process you haven’t built yet. Use the runway to 11 December 2027 for the harder conformity-assessment and documentation work, not for the basics. A general NIS2 compliance checklist covers the customer-facing side of this if your product also touches a physical component; the hardware-manufacturer variant of this dual-compliance problem is covered separately in our guide for NIS2 product manufacturers.

Frequently Asked Questions

Do I need to register as a NIS2 entity if I only sell software licences?
Generally no, unless you also provide managed services or administration that would classify you as an MSP/MSSP under Annex I sector 9, or you operate a marketplace, search engine, or social platform under Annex II. Run the full scope test rather than assuming either way — group structure and any incidental managed-service revenue can change the answer.

Does the CRA apply if I’m a non-EU software company selling into the EU?
The CRA’s obligations attach to placing a product with digital elements on the EU market, not to where the manufacturer is headquartered — a non-EU vendor selling into the EU is generally still expected to meet manufacturer obligations, typically through an EU-based authorised representative. Confirm your specific situation with a qualified adviser, since representative and import-chain requirements add detail this article doesn’t cover.

Does open-source software get an exemption?
The CRA exempts open-source software stewards from administrative fines, which is narrower than a blanket exemption for all open-source code — a commercial vendor that packages and sells a product built on open-source components is generally still a “manufacturer” for that product.

Is a CRA CE mark enough to pass a NIS2 customer’s supply-chain audit?
It can be strong supporting evidence — CE marking and the underlying technical documentation cover much of the same ground a NIS2 customer’s Article 21(2)(d) review is trying to establish. It’s not automatically a substitute for their own documented assessment, since the customer remains responsible for that assessment; treat your CRA documentation as the evidence pack that makes their review fast, not as a certificate that replaces it.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Key Takeaways

Two regulations, two different jobs. The CRA regulates your product directly, on its own timeline, whether or not a single customer is NIS2-regulated — and it calls you a “manufacturer” the moment your software has a data connection. NIS2 regulates the relationship: it doesn’t reach you directly unless you cross into MSP/MSSP or digital-provider territory, but it reaches you indirectly through every Article 21(2)(d) review your NIS2-regulated customers are now required to run. Build the SBOM pipeline and CVD process against the CRA’s 2026 date, not the customer’s next renewal date — and once it exists, use it as the answer that wins the deal instead of the gap that stalls it.

Sources

• Cyber Resilience Act, Article 13 — Obligations of Manufacturers (european-cyber-resilience-act.com)
• Cyber Resilience Act, Article 64 — Penalties (european-cyber-resilience-act.com)
• NIS2 Directive, Article 21 — Cybersecurity Risk-Management Measures (nis-2-directive.com)
• NIS2 Directive, Article 2 — Scope (nis-2-directive.com)
• “Am I a Managed Service Provider under NIS2?” — Article 6(39)/(40) and Annex I sector 9 (nisd2.eu)
• European Commission — Cyber Resilience Act: Summary of the Legislative Text (digital-strategy.ec.europa.eu)
• “Cyber Resilience Act Explained: Scope, Classes & Deadlines” (cyberresilienceact.eu)
• BSI (Germany) — NIS-2-FAQ, national competent authority guidance (bsi.bund.de)