Does the Cyber Resilience Act Apply to Your Library or SDK?
Clarify the legal boundary between open-source components, commercial developer toolkits, and mandatory supply-chain compliance under EU Regulation 2024/2847.
The Cyber Resilience Act (CRA) applies to a library or SDK if it is placed on the EU market during the course of a commercial activity. This includes proprietary developer kits, commercial libraries, or dual-licensed components sold with paid support. Purely open-source software developed without commercial intent remains largely exempt. However, commercial vendors integrating your code must perform strict due diligence, effectively shifting the burden of SBOM generation and vulnerability tracking onto library maintainers.
Defining Commercial Activity for Software Components
Regulation (EU) 2024/2847, effective since 10 December 2024, aims to bolster digital security across Europe. The scope depends on whether a software element is marketed as a 'product with digital elements' (PDE) through commercial activity.
Proprietary SDKs sold to enterprises, mobile SDKs for commercial platforms, and libraries bundled with paid SLAs fall directly under the CRA. In these instances, the distributing entity is legally classified as a manufacturer.
When is a library or SDK exempt?
The CRA clarifies that open-source software developed outside a commercial context is exempt from manufacturer duties. Accepting individual donations or hosting on public repositories does not trigger compliance. However, if you charge licensing fees, offer closed-source extensions, or sell commercial support, your library crosses the threshold into regulated territory.
Streamline SDK and Library Compliance with CRAcheck
CRAcheck integrates with your GitHub repository to evaluate your codebase against essential CRA security baseline requirements.
Multi-Ecosystem SBOM Generation
Generate comprehensive Software Bills of Materials (SBOM) for npm, PyPI, Go, Rust, .NET, PHP, Ruby, Java, and CycloneDX to meet client procurement audits.
Automated Vulnerability Monitoring
Track known Common Vulnerabilities and Exposures (CVEs) across your codebase with continuous scanning and instant security alerts.
Compliance Documentation Templates
Draft pre-filled Annex VII technical documentation, EU declarations of conformity, and standardized SECURITY.md files tailored to your modules.
ENISA Incident Response Workflows
Prepare structured response procedures aligned with CRA timelines: 24-hour early warnings, 72-hour notifications, and 14-day final reports.
Managing Downstream Customer Requirements
Even if your library is open source, commercial manufacturers integrating your package must comply with CRA Annex I. They are required to track vulnerabilities, maintain software inventories, and prove due diligence. Enterprise teams prioritize libraries with transparent SBOMs, active vulnerability disclosures, and professional security documentation. Providing these assets makes your SDK the preferred, secure choice for production environments.
- Integrators must document third-party components per CRA Annex I.
- Enterprises increasingly require standardized CycloneDX SBOMs for adoption.
- Documented vulnerability policies (SECURITY.md) establish institutional trust.
Manufacturer Obligations for Commercial Authors
If your SDK or library is commercial, EU Regulation 2024/2847 imposes specific requirements on your development lifecycle:
- Security by design: Products must be delivered without known exploitable vulnerabilities and with secure default configurations.
- Software Bill of Materials: Manufacturers must maintain a machine-readable SBOM identifying all dependencies and licenses.
- Vulnerability handling: Authors must implement a disclosure policy, provide security updates, and publish remediation guidance promptly.
- EU Declaration of Conformity: Commercial products require technical documentation (Annex VII) and a signed declaration before market placement.
Understanding Product Classifications
The CRA uses a risk-based system to categorize digital products:
- Default Category: Most commercial libraries and developer utilities fall here, allowing for self-assessment conformity procedures.
- Important Products (Annex III): SDKs handling sensitive operations like identity or network configuration may require more stringent audits.
- Critical Products (Annex IV): High-risk software requiring formal European cybersecurity certificates or mandatory third-party assessments.
Enforcement and Compliance Deadlines
The CRA mandates two critical milestones for vendors:
- 11 September 2026: Mandatory reporting of actively exploited vulnerabilities to ENISA and national CSIRTs within 24 hours.
- 11 December 2027: Full compliance, including CE marking, technical documentation (Annex VII), and supply chain controls.
Non-compliance risks fines up to EUR 15 million or 2.5% of global turnover, alongside potential market withdrawal of components.
Check Your SDK Repository Against CRA Expectations
Connect your GitHub repository to generate a CycloneDX SBOM, audit dependency vulnerabilities, and calculate your compliance readiness score.
Preparing Your Library or SDK for the CRA
- 1
1. Connect Your Codebase
Link your GitHub repository to analyze your dependency tree across major ecosystems like npm, PyPI, Go, and Rust.
- 2
2. Generate a Complete SBOM
Export a verified CycloneDX Software Bill of Materials that your downstream commercial integrators can immediately ingest.
- 3
3. Evaluate Your Compliance Score
Receive an objective readiness score assessing vulnerability hygiene, dependency posture, and mandatory documentation baselines.
- 4
4. Export Technical Documentation
Generate pre-filled Annex VII technical files, SECURITY.md policies, and an EU declaration of conformity.
A Practical Self-Assessment Platform
CRAcheck is designed for developers, startups, and vendors to simplify compliance. While it does not provide official government certification, it removes the operational friction of mapping dependencies, managing security policies, and tracking regulatory benchmarks.
By prioritizing SBOM transparency and vulnerability workflows, maintainers can meet corporate procurement standards and protect their libraries from becoming supply-chain risks.
Frequently Asked Questions
Does a free, open-source library hosted on GitHub fall under the CRA?+
No, provided it is developed outside of commercial activity. Volunteer-maintained open-source software is exempt under Recital 18. However, commercial entities using your library must conduct due diligence, which may lead them to request SBOMs and security data from you.
What makes an SDK commercial under the CRA?+
An SDK is considered commercial if it is provided for payment, distributed with paid enterprise support, offered with integration consulting, or marketed as a proprietary toolkit.
What are the mandatory reporting deadlines for security flaws?+
Starting 11 September 2026, manufacturers must report actively exploited vulnerabilities to ENISA and CSIRTs within 24 hours, followed by a 72-hour notification and a 14-day final technical report.
Does CRAcheck certify my library as officially compliant?+
No. CRAcheck is a self-assessment tool. It provides automated SBOM generation, scanning, and templates to help you organize evidence, but it does not constitute official legal certification.
Which dependency ecosystems does CRAcheck support?+
CRAcheck supports 9 major ecosystems: npm, PyPI, Go, Rust, .NET, PHP, Ruby, Java, and raw CycloneDX exports.
Align Your SDK with EU Cyber Resilience Requirements
Scan your GitHub repo, generate standardized SBOMs, and prepare your technical documentation before mandatory deadlines take effect.
Same topic — Par type de produit
New to the Cyber Resilience Act? Start with the complete guide.
The CRA guideFrom the blog
Check your CRA compliance in 1 minute
Free, no sign-up. Scan your repo and get your compliance score + pre-filled documents.