Is my product in scope? / VS Code extension
CRA compliance for VS Code extensions
Commercial VS Code extensions — paid, license-gated, or free extensions that funnel into a paid service — are installable software products. Extensions run with the user's privileges inside the tool developers trust most, which makes them a prime supply-chain target and a category regulators understand well.
What this means for you specifically
- ▸Marketplace malware campaigns targeting VS Code extensions are documented and recurring — your risk assessment should cover both your npm tree and your publisher account security (2FA, token hygiene).
- ▸The extension host gives you filesystem and process access by default: document what you actually use; scoped, declared access is your secure-by-default story.
- ▸Bundlers (esbuild/webpack) hide your dependency tree in a single dist file — generate the SBOM from the lockfile at build time, not from the shipped artifact.
- ▸If the extension is a client for your SaaS (LSP server, API integration), the extension is the in-scope product even when the backend is NIS2 territory.
The pitfall that catches most teams
Auto-publish pipelines with long-lived marketplace tokens. A leaked token turns your auto-update channel into a malware distribution channel — and an Art. 14 severe incident with a 24-hour clock.
The deadlines
2026-09-11
Reporting obligations start: actively exploited vulnerabilities and severe incidents must be reported within 24h/72h via the ENISA Single Reporting Platform.
2027-12-11
Full application: essential requirements, technical documentation, EU Declaration of Conformity and CE marking required to sell in the EU.
Where does your product actually stand?
The free Risk Check gives you a readiness score and a prioritized fix list in 3 minutes — tuned to your exact situation, including the edge cases this page can't cover.
Or get CRAdar to handle it continuously:
Other product types
Educational guidance on Regulation (EU) 2024/2847 — not legal advice.