DORA · Regulation (EU) 2022/2554

DORA does not ask you to obfuscate. It asks whether you would notice.

The Digital Operational Resilience Act is a resilience law, not a secrecy law. Its centre of gravity is knowing which ICT providers you depend on, detecting and reporting incidents on a short clock, testing that your systems hold up, and managing change so you can say what a release contained. A JavaScript protection step touches four of those obligations at the edges, has nothing to say about most of them, and can work against one of them if you are careless.

See the Evidence Model Talk to Us
The Short Version

Register · Detect · Report

Three duties carry most of the browser-side weight, and none of them is satisfied by a build option.

Know what executesThe third-party scripts on a live page are an ICT dependency whether or not they reached the register.
Notice quicklyReporting clocks start at awareness, so detection time is the number that matters.
Prove what shippedChange traceability means naming the exact artifact a customer received.
Why This Page Exists

A resilience regulation landed on teams who read it as a security regulation

When a new obligation arrives with the word “operational resilience” attached, the reflex in most engineering organisations is to reach for a security feature and point at it. DORA rewards that reflex badly. Almost everything it asks for is organisational: a register you maintain, a classification scheme you apply, a clock you start, a test you commission, an exit plan you write. The parts that touch code at all touch the release and the runtime, not the source. This page exists because we sell a build-time protection tool, and the honest description of where it fits in a DORA programme is “usefully, at the edges, in four specific places” rather than anywhere near the centre.

Resilience is not confidentiality

The failure modes the regulation is built around are outages, degraded service, failed changes, unavailable providers and slow detection. Code being readable is not on that list. A protection step addresses a different risk, and pretending otherwise is the fastest way to fail a review.

The browser is an ICT surface too

Front-end code is frequently absent from the ICT inventory entirely, even when it is the layer a customer actually touches to move money. The scripts a payment page loads at runtime are dependencies in every meaningful sense, whatever the procurement record says.

The clock is the sharp edge

Reporting timelines run in hours, and they begin when you become aware. That turns detection engineering into a compliance question, and detection is precisely what an obfuscated bundle does not provide on its own.

Scope

First settle how DORA reaches you

This determines whether you are answering these questions for yourself or answering them for a customer, and the two produce quite different workloads. The regulation covers a broad set of financial entities operating in the EU, and it also reaches ICT third-party service providers that serve them — both through contractual requirements that flow down and, for a designated few, through direct oversight. Most software organisations meet DORA for the first time in a customer’s renewal paperwork.

You are a financial entity

Then the front end you operate is inside your own ICT estate, and every question below is yours to answer directly: what executes on your pages, how fast you would know if it changed, what your testing programme covers, and whether your change records identify artifacts precisely.

You supply software to financial entities

Then the pressure arrives as contract terms rather than as regulation: incident notification windows, audit and access rights, support for resilience testing, subcontractor transparency, and exit or continuity planning. Being able to answer quickly is a commercial advantage well before it is a legal duty.

You embed someone else’s widget

A third-party script on your page is your dependency, not merely theirs. If a vendor’s tag is compromised and skims data from your checkout, the incident is yours to detect, classify and report. That is the single strongest argument for maintaining a runtime inventory of what loads.

You are outside the EU but serve it

Geography of incorporation is rarely the deciding factor; where the regulated entity operates and how the service is supplied usually is. Enumerate the customers and channels involved before assuming you are out of scope, and get the determination confirmed rather than inferred.

The Four Points of Contact

Where a JavaScript pipeline meets the regulation

Out of the full set of DORA duties, four are influenced by how you build, ship and monitor JavaScript. Everything else — governance, the risk management framework, business continuity, exit strategies, the register as a contractual artifact — is organisational work that no toolchain performs for you.

1. Knowing what actually executes

The register of information records ICT third-party arrangements. Its browser-side shadow is the list of scripts a real session loads, which drifts constantly as marketing tags, experimentation tools and support widgets are added by people who never see the register. A runtime inventory that snapshots every script element at load, intercepts dynamically created ones and compares them against an allowlist turns that drift into an alert instead of an archaeology exercise. This is an inventory control, and it has nothing to do with whether your own code is obfuscated.

2. Detecting an incident at all

Classification and reporting duties presuppose awareness. For a front end, awareness usually arrives via a customer complaint, which is slow and unflattering in an incident report. Runtime integrity checks and third-party script violations can be beaconed to an endpoint you own and routed into existing alerting, which is what converts “we found out on Tuesday” into a defensible timeline. Build the route before you need it; a beacon nobody monitors is not detection.

3. Surviving resilience testing

Testing programmes range from routine vulnerability assessment to threat-led exercises for the most significant entities. Protected client code will be noticed in all of them. The workable arrangement is agreed in advance: production ships protected, while the tester receives unprotected source or a source map under the engagement terms so the assessment covers your real logic rather than your transformation settings.

4. Saying what a release contained

Change management and incident forensics both collapse into one question: which artifact did the customer have on the day in question? A signed release manifest recording the SHA-256 of every source file and every output file answers it in seconds, and a reproducible build path lets you regenerate the artifact to compare. This is the one place where a protection pipeline contributes something a governance process cannot produce on its own.

The Tension Worth Naming

Detection wants visibility, and protection reduces it

This is the section a reviewer will look for, and leaving it out is what makes a vendor page read as marketing. Resilience obligations push information outward and toward observability: notice quickly, classify accurately, explain clearly, let testers assess. A protection step pushes in the other direction by design. Both can be right at once, but only if you decide deliberately where the boundary sits rather than discovering it during an incident.

Your own analysis is affected first

Every control that works by reading code — dependency scanning, secret scanning, static analysis, licence review — must run on unprotected source in CI. Pointed at a protected bundle they return silence, and silence renders as a green dashboard. That failure mode costs more than it saves.

Debugging under time pressure

An incident clock is the worst moment to discover that nobody can read a production stack trace. Keep source maps generated and stored privately, and make sure the on-call path to symbolicating a protected trace is written down and has been rehearsed.

Outside reporters need a route

A researcher who cannot read your bundle also cannot tell you precisely what is wrong with it. A findable disclosure address and a willingness to share detail under agreement keeps the reporting channel usable while the shipped artifact stays protected.

A Workable Order

Where the protection step belongs in a DORA-shaped pipeline

The ordering below resolves the tension above mechanically rather than by judgement call. Everything that reads code runs first, on plain source. Everything that records or monitors runs last, on the real artifact. Protection sits between them and interferes with neither.

1
Resolve dependencies and generate the inventory

From the lockfile, before bundling. This is the document that answers component questions for the register, and it is unaffected by anything that happens later.

2
Run every code-reading control

Composition analysis, secret scanning, static analysis and licence checks, all against unprotected source. None of them should ever be pointed at a protected file.

3
Build and test normally

Unit and integration suites run against the ordinary build. Protection is not part of the inner loop and should not slow it down.

4
Protect, then re-run the end-to-end suite

Against the protected artifact, so that anything the transformation changed is caught in CI rather than in production during a reporting window.

5
Sign and record what shipped

A manifest of source and output digests per file, stored with the release. This is your change-traceability answer and your incident-scoping answer at the same time.

6
Wire the runtime signal into monitoring

Third-party script violations and integrity failures go to an endpoint you own and into the alerting rotation that a human actually reads.

Honest Limits

What we will not claim

“Obfuscation makes you DORA compliant”

No build option produces compliance with a regulation about governance, continuity and reporting. Anyone selling you that framing is describing a product rather than the law.

“This replaces your ICT risk framework”

The framework, the classification scheme, the register, the continuity and exit plans and the testing programme are organisational artifacts. A toolchain contributes evidence into them and nothing more.

“Protected code cannot be tampered with”

Code delivered to a browser can be modified by whoever controls that browser. Protection raises effort and, with runtime checks, raises the chance you find out. It does not remove the possibility.

“We can tell you your scope and your deadlines”

We can describe what the regulation asks of a build and release pipeline, which is what this page does. Whether it binds you, in which capacity, and by when, are determinations for your counsel on your own facts.

Frequently Asked

DORA and JavaScript, answered

Does DORA require JavaScript obfuscation?

No. Obfuscation is not named in the regulation and no build step makes an entity compliant. DORA sets requirements for ICT risk management, incident handling and reporting, resilience testing, and management of ICT third-party arrangements. A protection toolchain is relevant to a few of those as a contributing control and as evidence, and irrelevant to most of them.

Which DORA duties does a JavaScript pipeline actually touch?

Four. Knowing which third-party code executes in a session, which is the browser-side half of the register of information. Detecting and escalating ICT incidents quickly, which for a front end means having a tamper or integrity signal that reaches your monitoring rather than a customer support ticket. Resilience testing, because penetration testers and threat-led exercises will encounter your protected code and need an answer prepared. And change management traceability, which is the ability to say exactly what a given released artifact contained.

How does a browser front end relate to the register of information on ICT third-party arrangements?

The register is a contractual and organisational record of your ICT third-party service providers. The browser-side reality is that a payment or banking page frequently loads scripts from vendors that nobody re-checks after go-live: tag managers, analytics, session replay, chat widgets, fraud tooling. Those scripts execute with full access to the page. Reconciling what the register says you use against what a real session actually loads is a genuinely useful exercise, and it is a code inventory question rather than an obfuscation question.

Does protecting our front end help with DORA incident reporting timelines?

Only indirectly, and only if you wire it up. Reporting clocks start when you become aware of an incident, so the useful engineering question is how quickly you would find out that something changed in a page you serve. Runtime integrity and third-party script monitoring can produce that signal and route it into the alerting you already have. Obfuscation on its own is silent and reports nothing, so it does not shorten detection time by itself.

How should we handle a penetration test or threat-led exercise finding that our JavaScript is obfuscated?

Expect the observation and prepare for it rather than arguing with it. Testers routinely record heavily transformed client code as an obstacle to review, and some frameworks require the tester be given the means to assess what they cannot read. The workable arrangement is to supply unprotected source or a source map under the engagement agreement so the test assesses your actual logic, while the production artifact stays protected. Assemble that packet before the engagement starts rather than during it.

Does DORA apply to us if we build software for financial entities rather than being one?

It reaches you through your customers, and sometimes directly. DORA covers a wide range of financial entities and also brings ICT third-party service providers into scope, with a designation regime for the most critical of them. In practice most software vendors first feel it as contractual flow-down: customers ask for stronger terms on incident notification, audit and testing support, exit planning and subcontracting transparency. Whether the regulation binds you directly is a determination for your counsel on your facts.

Can a protected build contribute evidence to a DORA ICT risk assessment?

It can contribute artifact-level facts, not an assessment. 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 yields a given output, and runtime tamper signals routed into monitoring are all useful inputs to an incident timeline or a change record. None of them is a risk assessment, and none of them substitutes for the governance work the regulation actually asks for.

How much does protecting client code reduce operational risk in a financial front end?

Less than the framing suggests, because the operational risks DORA is aimed at are largely not code-reading risks. Outages, failed changes, unavailable third parties, unrecoverable data and slow detection dominate. Protection raises the effort required to lift proprietary client-side logic and to tamper with a shipped bundle undetected, which is worth having, but the resilience questions are answered by your architecture, your monitoring and your recovery capability rather than by a build option.

Related Guides

Other compliance and evidence guides

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

ISO 27001 and SOC 2 · SEC cyber disclosure and your front end · PCI DSS and JavaScript · SOX, GLBA and financial application JavaScript · HIPAA and JavaScript · The Cyber Resilience Act · Security and trust · The evidence model · When a pentest flags your obfuscated code · Tag managers and third-party scripts · GDPR and JavaScript · FedRAMP, CMMC and JavaScript · The European Accessibility Act and JavaScript · The EU AI Act and your front end · NIS2 and the JavaScript you ship

Next Step

Load your own payment page and count the scripts

Open a real session against your production checkout or account page, list every script that executes, and compare that list to your ICT third-party register. Then open your CI configuration and confirm that dependency scanning, secret scanning and static analysis all run before the protection step. Those two checks take an afternoon and settle the two duties most likely to be wrong.

See the Evidence Model › Runtime Defense