NIS2 · Risk Management · Reporting Clocks

A directive about how your organisation manages risk, not about how your code is written.

NIS2 asks whether you have proportionate measures in place, whether you can handle a vulnerability and an incident, whether you know what your suppliers put into your service, and whether your management can answer for all of it. Not one of those tests looks at the shape of a delivered bundle. What the directive does create is a reporting clock that starts at awareness — and that is where a protection step can quietly work against you if nobody planned for it.

The Supply Chain Detail Symbolication
The Short Version

Scope is about you · The clock starts at awareness · Keep the map

Four findings carry nearly all the practical weight, and only one of them is about the law.

Being in scope follows sector and sizeNever the readability of anything you ship, in either direction.
Protection slows your own triageThe stack trace from a protected build is unreadable to you too, unless you kept the map.
Describe the measure accuratelyObfuscation is an anti-tamper and intellectual property measure, and a register that calls it more will not survive review.
Why This Page Exists

A directive about organisations, arriving at a team that ships a bundle

Front-end teams meet NIS2 through a questionnaire rather than through the text. Somebody in risk or legal needs a line for a register, and the question that arrives is usually whether the web application is “covered” and whether protecting it counts as a measure. Both have short answers. The longer and more useful conversation is about the four places where the way you build browser code genuinely changes how well you can meet a duty you already have.

Scope is decided before code is discussed

Whether the directive reaches you follows the sector you operate in, the size of the entity and the role your service plays. Nothing about the delivery format of your JavaScript enters that test, so a protected front end changes neither your scope nor your category.

The measures are outcomes, not techniques

Risk analysis, incident handling, continuity, supply chain security, secure development and disclosure, access control, cryptography, training. These are areas you must address proportionately. None of them is a list of approved build settings.

The clock is the part engineering feels

Reporting timelines run from the moment you become aware of a significant incident. Anything that lengthens the time between a symptom appearing and you understanding it is, in practice, working against a legal deadline.

Boundaries

How this differs from the other regimes on this site

Four European instruments turn up in the same conversations and are constantly confused with each other, usually to the cost of whoever has to fill in the register. They differ by what they regulate rather than by how strict they are, and once that is clear the engineering work stops being duplicated.

NIS2 regulates the entity

It is about how an organisation running an important service manages its cyber risk and reports incidents. The unit of obligation is you, not a particular product you sell.

The Cyber Resilience Act regulates the product

It attaches to products with digital elements placed on the market: inventory, vulnerability handling and updates across a declared support period. If you sell software, that page is the one your release process cares about. Read the CRA page.

DORA takes over for financial entities

The financial sector regime is more specific and, for the entities it names, displaces the general one on the same subject matter. If you are a financial entity or a critical provider to one, work from that page instead. Read the DORA page.

The GDPR is about personal data

Different question, different trigger, frequently the same incident. A single browser-side failure can easily create both a personal data breach and a significant incident with two separate clocks. Read the GDPR page.

The Four Points of Contact

Where the directive genuinely meets a front-end build

Out of the whole risk-management catalogue, four things are influenced by how you build and protect browser code. Everything else — governance, continuity planning, access control, cryptography policy, staff training — is decided by the organisation around the code, and no build setting moves any of it.

1. The third-party code executing on your pages

Supply chain security is named directly in the measures, and for a front end that means two inventories. One is the packages your build pulls in, taken from your lock file before anything is bundled. The other is the scripts other people execute on your live pages: tag managers, analytics, session tools, payment widgets, chat. That second list is the one nobody maintains, it changes without a deploy, and it is the route most browser-side incidents actually take. Protecting your own bundle does nothing for either list.

2. Vulnerability handling and coordinated disclosure

You are expected to handle vulnerabilities and to have a disclosure route. Both have a front-end consequence people discover late. A researcher who finds a defect in a protected bundle has a harder time producing a clear report, so what arrives is vaguer and takes longer to triage. Publish a security contact, and be prepared to work from a symbolicated trace rather than from the shipped artifact. The cost of protection here falls on your own response time, not on the researcher's patience.

3. Detection time, because the clock starts at awareness

Reporting duties run in stages from the point you become aware of a significant incident: an early warning first, a fuller notification shortly after, and a final report later. Awareness is not the moment of compromise, it is the moment you understand what you are looking at. A protected bundle with no retained symbol map turns an error report into noise, which extends exactly the interval the deadline is measured against. Keep the map, keep the manifest, and keep them keyed to the release.

4. What you write in a register somebody else reads

Management bodies approve the risk-management measures and can be held accountable for them, which means the register is read by people who will test its claims. “Client-side code is obfuscated” is a defensible line if it is filed as an anti-tampering and intellectual property measure. It is not defensible as a confidentiality control for anything the browser receives, because the browser receives all of it. Describe it accurately and put your actual control at the boundary where it belongs.

The Ordering Rule

Anything that works by reading code has to run before the protection step

This sentence is on several pages of this site for a reason. Under a regime that asks you to demonstrate vulnerability handling, getting it backwards produces the worst possible failure mode: a control that reports success while examining nothing.

Composition analysis goes quiet

A scanner pointed at a protected bundle matches nothing, because the version strings and identifier patterns it looks for have been rewritten. A vulnerable dependency stays just as exploitable while the dashboard turns green.

Secret scanning goes quiet too

The same mechanism. A credential that a pattern-matching scan would have caught in source is unrecognisable once literals have been moved into a table and encoded. It is still in the artifact, and still recoverable at run time.

Your own reviewers lose the same visibility

The sharpest version of the rule: protecting a bundle that already contains a compromised package hides the payload from the people whose job is to find it, while leaving it fully functional for whoever planted it.

What We Will Not Claim

Four things this product does not do for you

It is not a risk-management measure on its own

Protection raises the cost of reading and modifying a shipped program. It does not manage a risk in the sense the directive uses, and a register entry that treats it as the control rather than as a hardening measure invites a question you would rather not answer.

It does not shorten a reporting clock

Nothing in a build pipeline affects when a duty to report arises. What a pipeline can do is affect how long you take to understand an incident, and the default direction of that effect is unhelpful unless you retain the symbol map.

It does not inventory your third-party scripts

The tags executing on your live pages are a runtime population, not a build output. That list comes from a content security policy report endpoint, a tag governance process, or a periodic crawl of your own site — not from a protection step.

It cannot tell you whether you are in scope

Sector, size, the role of your service, and the way your member state has implemented the directive all decide that, and the implementations differ. That determination belongs with your counsel and your national authority.

Frequently Asked

NIS2 and protected JavaScript, answered

Does NIS2 require or forbid JavaScript obfuscation?

Neither, and the directive does not mention it. The risk-management obligations are written as areas you must address proportionately: risk analysis, incident handling, business continuity, supply chain security, security in development and maintenance, vulnerability handling and disclosure, access control, cryptography, and training. Those are outcomes rather than approved techniques, and no build setting satisfies or violates any of them. Protection is a legitimate hardening measure that you may adopt or not, and the choice carries no compliance weight either way.

Does protecting our front end affect whether we are in scope?

Not at all. Scope follows the sector you operate in, the size of the entity, and the role your services play, with national implementations adding their own detail. Nothing about the delivery format of your JavaScript enters that test. It is worth stating plainly because the question often arrives inside a request to make a web application compliant, which is not a thing a web application can be on its own. Determine scope with your counsel and your national authority first, then look at the engineering work.

How is this different from DORA and the Cyber Resilience Act?

They regulate different subjects, which is why the engineering work only partly overlaps. This directive regulates the entity: how an organisation running an important service manages cyber risk and reports incidents. The Cyber Resilience Act regulates the product placed on the market, with inventory, vulnerability handling and update duties across a declared support period. The financial-sector regime is more specific and, for the entities it names, takes precedence on the same subject matter, so financial entities should work from that page instead. A single incident can easily engage more than one of them plus a personal data breach.

Which risk-management measure does a front-end team actually own?

Supply chain security, in two halves that are usually managed by different people or by nobody. The first is the packages your build pulls in, which comes from your lock file and is at least visible to your engineers. The second is the scripts other parties execute on your live pages: tag managers, analytics, session recording, payment widgets, chat. That second population changes without a deployment, is rarely inventoried, and is the route most browser-side incidents actually take. Protecting your own bundle does nothing for either half.

Does obfuscation help or hurt our incident reporting timelines?

It works against you unless you plan for it, and this is the most practical point on the page. Reporting runs in stages from the moment you become aware of a significant incident, with an early warning first, a fuller notification shortly after and a final report later. Awareness means the point at which you understand what you are looking at, not the moment of compromise. A protected bundle with no retained symbol map turns production error reports into noise, which lengthens exactly the interval your deadline is measured against. Retain the symbol map and the build manifest, keyed to the release.

What should we write in the risk register about client-side protection?

Describe it as what it is. Filed as an anti-tampering and intellectual property measure that raises the cost of reading and modifying shipped code, it is accurate and defensible. Filed as a confidentiality control for data or logic that the browser receives, it is not, because the browser receives all of it and anyone can read what arrives. Management bodies approve these measures and can be held accountable for them, which means the register is read by people who will test its claims, and an overstated entry is worse than no entry.

How does this interact with coordinated vulnerability disclosure?

In a way most teams discover only after the first report arrives. A researcher examining a protected bundle produces a vaguer report, with a stack trace nobody can read and a reproduction that takes longer to pin down, so your own triage slows down at the moment speed matters most. Publish a security contact and a disclosure route, be prepared to work from symbolicated traces rather than from the shipped artifact, and consider whether you can share an unprotected build under an agreement with researchers who ask.

Does secret scanning still work on protected output?

No, and the failure is silent. A credential that a pattern-matching scan would have caught in source becomes unrecognisable once literals have been moved into a table and encoded, while remaining fully recoverable at run time by anyone who inspects the running program. This is the same shape as composition analysis going quiet. Run every scan that works by reading code before the protection step, and remember that the sharpest version of the problem is that protecting a bundle which already contains a compromised package hides the payload from your own reviewers.

Does using a hosted protection service make us dependent on a third party?

It is a supplier relationship and it belongs in your supplier assessment like any other, which is a reasonable thing to ask about rather than a problem. The specifics that usually matter: the hosted service receives the JavaScript you select, protects it and deletes the request file after the run; the Windows desktop application and the command line tool both offer local processing where the source body stays on the device; those local paths still make an online entitlement check that carries no source; and virtual machine protection is hosted by design. Whether that fits your policy is a decision only you can make.

What is the shortest useful checklist for a front-end team?

Five items. Inventory the third-party scripts executing on your highest-value pages and identify an owner for each. Generate your dependency list from the lock file and run composition and secret scanning before the protection step. Retain the symbol map and build manifest for every release, and rehearse reading a real production error with them. Write the register entry as an anti-tampering measure rather than a confidentiality control. And publish a disclosure route, because a researcher who cannot reach you is not a risk you have avoided.

Related Guides

Other compliance and evidence guides

DORA and your JavaScript

The financial-sector regime that displaces this one for the entities it names, with its own register and testing expectations.

Symbolication reference

How to turn a stack trace from a protected build back into something your responders can act on inside a deadline.

Digital Services Act

The conduct and transparency counterpart to this directive's security duties.

Next Step

Check three things this week

List every third-party script that executes on your highest-value pages and find out who owns each one, because that list is usually shorter than people fear and older than they expect. Confirm your composition and secret scans run against the pre-protection artifact, not the bundle you ship. Then take a real error from production, try to read it, and see whether your symbol map is where you thought it was — that rehearsal is worth more than any register entry.

Open the Online Tool Ask a Question