Cyber Resilience Act for .NET Library Authors: Read the Fine Print

If you publish .NET libraries to NuGet, open source or commercial, the EU Cyber Resilience Act is heading straight for your roadmap. Regulation (EU) 2024/2847 entered into force on 10 December 2024, and its main obligations apply from 11 December 2027. That part most people already have circled.

What gets missed is that two dates arrive well before then. The notified-body machinery in Chapter IV starts on 11 June 2026, and the vulnerability and incident reporting duties in Article 14 apply from 11 September 2026. Report an actively exploited vulnerability after that date and the CRA is already live for you, more than a year before the rest of the regulation shows up.

I maintain several open-source NuGet packages myself, and this is the map I have been building for my own release pipeline: not legal advice, just the practical rundown of what ships, when, and to whom.

What the CRA Actually Regulates

The CRA regulates products with digital elements. Article 3(1) defines that as “a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately.”

Read that literally and it stops being about finished applications only. A NuGet package is a software component, and once you place it on the market separately from any particular application, it falls under this definition in its own right, not just as a passenger inside whatever consumes it. I had assumed the CRA was aimed at shipped products, not the packages that go into them, until I read the text closely enough to be corrected.

Whether it actually applies to you comes down to a second question: is your library “made available on the market,” meaning supplied in the course of a commercial activity? A recital in the final text explicitly excludes free and open-source software developed or supplied outside a commercial activity, precisely so the regulation doesn’t chill research and hobby projects.

That exemption is real, but narrower than a lot of the early press coverage implied. I get into exactly where the line sits further down.

The Three Things Every Library Author Should Care About

1. Vulnerability handling: there is a defined process and notification timeline.
2. Security by design and default: the product must ship in a secure state.
3. Documentation and SBOM: you have to be able to tell users what is in your library and how to use it safely.

None of these three ideas is new. What the CRA does is turn them into binding law across the EU, with hard deadlines and paperwork attached.

Vulnerability Handling: The 24/72 Cadence

Article 14 sets a reporting timeline measured in hours, not days, and it is the first CRA obligation that actually bites, starting 11 September 2026.

Once you know about an actively exploited vulnerability or a severe incident affecting your product, both go to your national CSIRT and ENISA, through the single reporting platform:

• Early warning within 24 hours of becoming aware, even if you do not yet have all the details.
• A fuller notification within 72 hours, including severity and, where available, indicators of compromise.
• A final report within 14 days of a fix becoming available (for vulnerabilities) or within one month of the 72-hour notification (for incidents).

For a maintainer who tends to triage on a Saturday morning, this is the part that mostly needs new process, not new code. A 24-hour clock does not care that you have a day job.

What you need in place before the law applies:

• A documented vulnerability handling policy, written before you need it, not drafted under pressure during the first report.
• A coordinated disclosure address that someone actually reads. Have a rough plan for who is reachable outside office hours.
• A way to publish security advisories quickly, through GitHub Security Advisories or an equivalent channel your users already watch.
• A way to ship a fix without breaking dependents. For a widely referenced library, that is usually the slower part of the 14-day clock, not the reporting itself.

SBOM and Provenance

Article 3(39) defines the software bill of materials the CRA expects. Annex I requires you to be able to produce one, at minimum listing top-level dependencies, in a commonly used machine-readable format. It does not mandate a specific standard, which in practice leaves you with two realistic choices: CycloneDX or SPDX.

For .NET, CycloneDX is the pragmatic default. The CycloneDX/cyclonedx-dotnet tooling gives you two integration points:

# One-off SBOM from a solution or project, no build-file changes required
dotnet tool install --global CycloneDX
dotnet-CycloneDX MySolution.sln -o ./artifacts -j

<!-- Or wire it into every build via the CycloneDX.MSBuild NuGet package,
     which emits bom.xml/bom.json automatically on `dotnet build` / `dotnet pack` -->
<ItemGroup>
  <PackageReference Include="CycloneDX.MSBuild" Version="x.y.z" PrivateAssets="all" />
</ItemGroup>

SPDX tooling for .NET exists but is less mature than the CycloneDX ecosystem. Unless a downstream customer specifically requires SPDX, CycloneDX gives you the least integration friction.

If you cannot generate an SBOM for your own library in under 10 minutes today, that is the gap to close first. The tooling exists; the integration is the actual work.

Secure by Default

The CRA’s “security by design and default” language is broad, but for a library author it boils down to a short, familiar list:

• No insecure defaults (no MD5 for new APIs, no plaintext credentials in samples).
• Cryptography uses up-to-date primitives by default.
• Public APIs require explicit opt-in for risky behaviour, not opt-out.

If your library’s quick-start page contains an example that would not pass a basic security review, fix it now.

Documentation Obligations

Article 13, read together with Annex I Part II, is where “security by design” turns into paperwork you actually have to ship. For a library, the parts that matter are:

• The intended use and limits of the product, and the security-relevant configuration options a consumer needs to set correctly.
• The vulnerability handling process from the section above, written for an integrator to act on, not just a policy for your own team.
• The end-of-support date. The CRA sets a default support period of at least five years from when the product is placed on the market, shorter only if the product’s expected use is genuinely shorter. State that date clearly at the point a user gets the product, not three pages into a wiki.
• Once a security update ships during the support period, keep it available for at least 10 years, or for the rest of the support period, whichever is longer. Deleting old NuGet package versions during a “cleanup” is exactly what this obligation rules out.

Most NuGet packages do not have a written EoL policy today. They will need one, and it costs you an afternoon to write, not a quarter.

Does CE Marking Touch Library Authors?

Short answer: yes, in principle, though for most libraries the compliance route is lighter than “CE marking” sounds.

The Article 3(1) definition of “product with digital elements” explicitly includes software components placed on the market separately, which puts a standalone NuGet package inside the conformity assessment machinery in Chapter IV. Being “only a library” doesn’t exempt it.

What that means in practice depends on which category your library falls into. The CRA sorts products into a default category, “important” products (Annex III), and “critical” products (Annex IV). A general-purpose library, an ORM, a serialization helper, a logging framework, almost always lands in the default category. Default-category products can self-assess conformity (Module A): you verify against the essential requirements yourself and affix the CE marking, no notified body involved.

The bar is higher if your library’s core functionality matches an Annex III category, such as password managers, VPN clients, or identity and access management components. There, third-party involvement can become necessary. If in doubt, check your library’s function against Annex III before assuming self-assessment is available to you.

The Open-Source Carve-Out

The CRA tries to protect non-commercial open-source maintainers, and the mechanism is narrower than the headlines suggested. The test in the final text isn’t “is the code open source”, it is “was the product supplied in the course of a commercial activity.”

A recital spells out one concrete trigger: accepting donations that exceed the costs of designing, developing, and providing the software counts as commercial activity, and pulls you into scope. Recovering costs, or reinvesting surplus into non-commercial work, does not.

There is also a distinct role the regulation creates for larger open-source efforts: the open-source software steward. That is a legal person, other than a manufacturer, that systematically and sustainably supports the development of a specific free or open-source product intended for commercial use, and ensures its viability.

Stewards do not get full manufacturer-level obligations. They get a defined, lighter set of duties under Article 24, including maintaining a cybersecurity policy and reporting actively exploited vulnerabilities they become aware of. If your project is maintained by a foundation, or by a company that sponsors a maintainer full time, check whether that entity fits the steward definition. It changes who is responsible for what.

If your library is part of how your company makes money, even indirectly, assume you are in scope. That includes support contracts, a commercial edition built on top of it, or simply shipping inside a product you sell.

What I Recommend Library Authors Do Now

1. Audit your current vulnerability handling process, and write it down before Article 14 applies on 11 September 2026.
2. Add an SBOM generation step to your release pipeline. For .NET, start with CycloneDX.
3. Sign your packages. Stop treating signing as optional.
4. Publish an end-of-life policy with a real date, and plan for the minimum five-year support window.
5. Decide whether your project is in scope, using the commercial-activity test above, and tell your downstream users what you concluded.

What This Post Is Not

Legal advice. It is the engineering read that gets the conversation with your counsel started faster, not a substitute for having that conversation.

Guidance from the Commission, and the delegated acts covering the Annex III/IV categories, are still being clarified as the implementation dates approach. Treat the dates and definitions here as accurate today, and check them against the current official text before you commit engineering time to a specific deadline.

If dependency sprawl is already part of your problem, the practical next step is wiring up the supply-chain tooling this regulation assumes you have. I covered that ground in 247 Strangers Have Root Access to Your Production, which walks through Dependabot, dependency review, and SBOM generation against ISO 27001 A.15.