Cyber Resilience Act · Regulation (EU) 2024/2847

The Cyber Resilience Act does not ask you to obfuscate. It asks you to know what you shipped.

If you place software on the EU market — a desktop build, an extension, an npm package, an on-premises deployment — the CRA lands on your release process, not on your source code. Its centre of gravity is a machine-readable bill of materials, a working vulnerability handling programme, security updates across a declared support period, and a short reporting clock when something is actively exploited. A protection step touches four of those obligations, ignores most of them, and can quietly work against one.

See the Evidence Model Talk to Us
The Short Version

Inventory · Updates · Disclosure

Three duties carry most of the weight for a JavaScript product, and only one of them is affected by how your code is built.

Know your componentsA machine-readable bill of materials, generated from the dependency graph rather than the bundle.
Ship fixes for a stated periodA release pipeline you can run again in a hurry, for as long as you said you would.
Make reporting easyA disclosure route that works, and an internal clock that starts the moment exploitation is known.
Why This Page Exists

A product-safety law arrived in a place that had never had one

Most software regulation until now has been sectoral: rules for cardholder data, rules for health records, rules for financial services. The Cyber Resilience Act is different in kind. It treats software the way the EU already treats a kettle or a power tool — as a product placed on a market, carrying obligations for the manufacturer that begin before it ships and continue for as long as it is supported. JavaScript teams are unused to that framing, and the instinct when a security law appears is to reach for a security feature. That instinct is wrong here. Almost nothing the CRA asks for is a feature. It asks for records, process, and the ability to answer questions about a build you shipped eighteen months ago.

It is about the product, not the language

Nothing in the regulation is JavaScript-specific. What makes it land hard on JavaScript teams is that the ecosystem’s normal practice — a deep transitive dependency tree, a bundler that erases module boundaries, a release process nobody can reproduce — is exactly what the inventory and update duties expose.

The duties outlive the release

Declaring a support period means committing to produce a fixed build later, from a tree you may no longer have checked out, with a toolchain that has moved on. That is a release-engineering problem long before it is a security one.

The clock is the sharp edge

Reporting obligations for actively exploited vulnerabilities run on hours and days rather than quarters. What that really tests is whether you can determine, quickly, which released artifacts contained the affected code.

Scope

First settle whether, and how, you are in scope

This is the question teams skip, and skipping it produces either wasted work or a nasty surprise. The regulation covers products with digital elements made available on the EU market. The interesting nuance for a JavaScript organisation is that a single codebase frequently reaches customers through several channels at once, and they are not all treated the same way.

Enumerate the channels, not the repository

One product can be a hosted service, a desktop application, a browser extension, a published npm package, a customer-installed on-premises build and an embedded SDK inside somebody else’s application. A remote service is treated differently from software supplied to a customer to run themselves. Write the list down; the answer is usually “several of these”, and the obligations attach to the ones you supply.

Being a component of someone else’s product counts

If you publish an SDK, a widget or a library that a customer integrates into a product they place on the market, your code becomes part of their bill of materials and their vulnerability handling. Expect the questions to arrive from your customers before they arrive from a regulator, phrased as procurement rather than as law.

Open source has its own treatment

The regulation carves out non-commercial open source development and treats stewards differently from manufacturers. If you publish packages that are free but exist to support a commercial offering, that boundary is worth establishing deliberately rather than by assumption.

The dates are staged

Obligations phase in rather than arriving together, with the reporting duties for actively exploited vulnerabilities landing before the full manufacturer requirements. Plan the incident path first and the documentation second. Confirm the specific dates and product category with counsel; a vendor page is not the right source for that.

The Four Points of Contact

Where a JavaScript build pipeline meets the regulation

Out of everything the CRA asks a manufacturer to do, four items are decided by how you build and release JavaScript. The rest — risk assessment, conformity, technical documentation as a whole, market surveillance cooperation — is organisational work that no toolchain performs for you.

1. A machine-readable bill of materials

The requirement is to identify and document the components contained in the product, in a commonly used machine-readable format, covering at minimum the top-level dependencies. In npm terms that is a CycloneDX or SPDX document derived from your lockfile — and the critical detail is that it must be derived from the dependency graph, not from the built bundle. Protection destroys the version fingerprints that artifact scanners rely on, which is covered in detail in does obfuscation break your SBOM.

2. No known exploitable vulnerabilities at release

This is a gate on your pipeline, and its placement matters. Dependency and code scanning have to run against the resolved graph and the unprotected source, before the protection step, because a scanner reading obfuscated output finds nothing and reports success. The same ordering argument applies to every code-reading control you own, and is the practical core of obfuscation will not stop a malicious dependency.

3. Security updates across the support period

You will have to rebuild an old release with one dependency changed, and ship it. That means the build must be reproducible in a meaningful sense: pinned inputs, a recorded toolchain, and a protection step that does not introduce gratuitous variation between runs. A fixed Seed makes protected output deterministic for a given input, which is what turns “we think this is the same build” into a checkable claim. See Reproducible Builds.

4. Knowing exactly what a release contained

When a vulnerability report lands, the first question is which shipped artifacts are affected. A signed release attestation records the SHA-256 of every source file and every output file in a build, so the mapping from a file in the field back to a release is a lookup rather than an investigation. Watermarking adds the reverse direction: a recovered file identifies its own build.

The Tension Worth Naming

Protection and transparency pull in opposite directions, and the regulation is on the transparency side

This is the section most vendor pages on this topic leave out, and it is the one that will matter in a review. Almost every duty in the CRA moves information outward: publish a component inventory, run a disclosure process an outsider can use, notify authorities quickly, tell users what changed and why. Obfuscation moves information inward. Both can be legitimate at the same time, but only if you are deliberate about where the boundary sits.

Your own scanners must read the plain source

Static analysis, secret scanning, dependency review and licence checking all operate by reading code. Run every one of them on the unprotected tree in CI. A pipeline that protects first and scans afterwards produces clean reports that mean nothing, which is worse than no report.

Researchers need a route in

A coordinated vulnerability disclosure policy is only real if a stranger can find it and use it. Protected code raises the effort of reporting a genuine issue, so lower every other barrier: a published contact, a security.txt, a stated response time, and an explicit commitment not to pursue good-faith research.

Obfuscating to conceal is a different act

Protecting commercially valuable logic is ordinary. Using the same technique to hide undisclosed data collection, an undocumented component or a known defect is not, and the disclosure duties are precisely what would surface it. Keep the stated reason for protection written down, because that is the question an assessor asks.

A Workable Order

Where the protection step belongs in a CRA-shaped pipeline

The ordering below is the practical resolution of the tension above. Everything that reads code runs first, on plain source. Everything that records what shipped runs last, on the real artifact. Protection sits between them, and touches neither.

  • Resolve and pin dependencies. A committed lockfile is the input to everything downstream, including the bill of materials.
  • Generate the bill of materials from the dependency graph. CycloneDX or SPDX, produced from the lockfile, stored as a release asset. This document is unaffected by anything that happens later.
  • Run every code-reading control on unprotected source. Dependency scanning, static analysis, secret scanning, licence review, your own code review. This is the gate for “no known exploitable vulnerabilities”.
  • Build and bundle. Ordinary pipeline. Keep the source maps; do not publish them.
  • Protect, with a recorded configuration. A committed config file and a fixed seed, so the step is a documented, repeatable transformation rather than an ad-hoc run.
  • Verify the protected output still works. Run the test suite against the protected bundle, not only the plain one. See testing obfuscated JavaScript.
  • Record what shipped. A signed release attestation over source and output hashes, a watermark per build, and the bill of materials attached to the same release.
  • Keep the unprotected artifacts and the symbol data. You will need them to triage a report and to rebuild a fix. Store them where the shipped bundle is not.
Honest Limits

What we will not claim

“This makes you CRA compliant”

It does not, and no product does. Conformity is an organisational determination covering risk assessment, technical documentation, vulnerability handling and the declaration you sign. Tools supply controls and evidence; process and legal judgement supply the rest.

“Obfuscation counts as a security requirement”

At best it is a contributing measure toward protecting integrity, argued on your own risk assessment. It is not a listed requirement, and presenting it as one in technical documentation invites the question of what it is standing in for.

“A protected bundle needs no dependency scanning”

The reverse is true. Protection hides a vulnerable dependency from casual inspection while leaving it exactly as exploitable, and it hides it from your scanners too if they run in the wrong order. Scan the graph, always, and scan it before the protection step.

“We can tell you the dates and your scope”

We can describe what the regulation asks of a build pipeline, which is what this page does. Which dates bind you, which product category you fall into and whether a given channel is in scope are determinations for your counsel on your facts.

Frequently Asked

The Cyber Resilience Act and JavaScript, answered

Does the Cyber Resilience Act require JavaScript obfuscation?

No. Obfuscation is not named anywhere in the regulation, and no build step makes a product conformant. The CRA sets essential cybersecurity requirements for products with digital elements placed on the EU market, plus a set of vulnerability handling duties. A protection toolchain is relevant to a small number of those as a contributing measure and as evidence, and irrelevant to most of them.

Which CRA duties does a JavaScript build pipeline actually touch?

Four, in practice. Producing a machine-readable bill of materials covering at least the top-level dependencies of what you ship. Shipping without known exploitable vulnerabilities, which means your dependency scanning has to run on the real dependency graph. Distributing security updates across the support period you declare, which is a release-engineering problem. And being able to say precisely what a given released artifact contained, which is what a signed release manifest records.

Does obfuscating a bundle break the software bill of materials?

It does not break an SBOM generated from your lockfile, because that is produced from the dependency graph before any bundling or protection happens. It does break tools that infer components by scanning a built artifact for library version strings, because name mangling and string encryption remove exactly the fingerprints those scanners match on. Generate the bill of materials from the resolved dependency graph, not from the shipped bundle, and run dependency scanning before the protection step.

When does the Cyber Resilience Act start to apply?

The regulation entered into force in 2024, and its obligations phase in rather than starting together. The reporting duties for actively exploited vulnerabilities and severe incidents arrive first, and the full set of manufacturer obligations follows later. Treat the earlier date as the one that constrains your incident process and the later one as the deadline for technical documentation, conformity work and the vulnerability handling programme. Confirm the exact dates that apply to your product category with your own counsel rather than with a vendor page.

Can protecting our code conflict with the CRA transparency duties?

Yes, and this is the part worth thinking about before it becomes a finding. The regulation pushes toward disclosure: publishing a bill of materials, running a coordinated vulnerability disclosure process, and reporting exploited vulnerabilities on a short clock. Protection makes your shipped code harder to read, which is legitimate, but it also makes it harder for an outside researcher to report a real problem and harder for your own scanners to see one. The resolution is to keep every code-reading control operating on unprotected source in CI, and to make your disclosure route easy to find.

Are we in scope if we only ship a web application rather than downloadable software?

That is the scoping question to settle first, and it turns on how the product is supplied rather than on the language it is written in. A pure remote service is treated differently from software placed on the market, while a desktop build, a mobile application, a browser extension, an npm package or an on-premises deployment are all more clearly products supplied to a customer. Many organisations ship several of these at once from one codebase. Enumerate every distribution channel you actually use before assuming the answer.

What evidence can a protected build contribute to CRA technical documentation?

Artifact-level facts rather than conformity as a whole. A signed release attestation recording the SHA-256 of every source file and every output file, a per-build watermark that ties a recovered file back to a specific release, a reproducible build path so a given input produces a given output, and runtime tamper signals routed into your existing monitoring. Those are useful inputs to technical documentation and to an incident timeline. They are not a conformity assessment.

Next Step

Generate one bill of materials and check where your scanners run

Produce a CycloneDX document from the lockfile of your most widely distributed artifact, then open your CI configuration and confirm that dependency scanning, secret scanning and static analysis all execute before the protection step rather than after it. Those two checks take an afternoon and settle the two duties most likely to be wrong.

See the Evidence Model › Reproducible Builds
Related Guides

Other compliance and evidence guides

The same evidence artifacts answer questions in several frameworks. These pages cover the neighbouring ground:

PCI DSS and JavaScript · ISO 21434 and vehicle interface JavaScript · HIPAA and JavaScript · DORA and JavaScript · Security and trust · The evidence model · Does obfuscation break your SBOM? · Supply chain integrity · GDPR and JavaScript · FedRAMP, CMMC and JavaScript · The European Accessibility Act and JavaScript · The EU AI Act and your front end · Medical device software and JavaScript · NIS2 and the JavaScript you ship · IEC 62443 and industrial control