IEC 62304 · SOUP · Device Software

A lifecycle standard reaches your process and your records, not the form your code takes.

The software standard that governs medical device development is a standard about how you work: how you plan, how you classify by harm, how you identify what you did not write, how you control change, and how you resolve problems. None of it describes what the shipped artifact should look like. Protecting a browser front end neither discharges an obligation nor creates one — but it interacts with two of those duties in ways worth getting right before an audit rather than during one.

The Inventory Problem Reproducible Builds
The Short Version

Classification ignores your build · Secrecy is not a control · Records need a rebuild

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

Your safety class follows possible harmWhat the software can contribute to, never how readable the code that does it is.
Every scan that reads code runs firstA component inventory taken from a protected bundle is an inventory of nothing.
A release you cannot rebuild is hard to describeA fixed seed and the build manifest turn polymorphic output back into evidence.
Why This Page Exists

A lifecycle standard, arriving at a team that ships a bundle

The question usually reaches engineering in one of two forms. Either a quality lead has asked whether protecting the web interface will complicate the technical file, or somebody has hoped out loud that protecting it will help with the cybersecurity section. Both deserve a precise answer, and the answers point in opposite directions. The first is a no with two footnotes. The second is a no with a warning attached, because a secrecy claim written into a risk file is the kind of thing an assessor removes rather than accepts.

The standard describes activities, not artifacts

Planning, requirements, architecture, unit implementation, integration, release, maintenance and problem resolution. Each is a thing you do and record. None of them constrains how the delivered JavaScript is written, so no build setting satisfies or violates any of them.

Two duties do meet the build

Identifying the software you did not write, and being able to say what a given release contained. Both are inventory and record problems, and both are affected by a step that rewrites the artifact after those records are usually taken.

The safety argument has to be checkable

A risk control that a reviewer cannot verify is not a risk control. Difficulty of reading is the least verifiable property a program has, which is exactly why it belongs nowhere near a hazard analysis.

Scope

Work out which of these you are before designing anything around it

Software reaches this area by several different routes, and the route decides how much of the lifecycle standard applies to your front end at all. Teams are often asked to “make the web app compliant” without that being settled, which is an impossible brief. Settle it with your regulatory function first. The engineering habits described further down are worth adopting in every one of these cases, which is why it is safe to start on them while the question is open.

Software that is itself the device

A browser application whose output informs a clinical decision is, in many jurisdictions, the device rather than an accessory to one. Here the front end is squarely inside the lifecycle, including its third-party components and its release records.

A web interface on a physical device

An instrument with an embedded web server, or a companion application talking to hardware. The interface is a software item within the device software, and the same inventory and configuration duties reach it even though the hardware dominates the file.

A component supplied into someone else's device

You sell a viewer, a charting library or an integration that a manufacturer embeds. Their lifecycle obligations become your customer's questionnaire, and what they need from you is provenance and version information rather than protection.

Software that is not a device at all

Scheduling, billing, general documentation and administrative tooling usually sit outside the definition even inside a clinical setting. Privacy law still applies in full, which is a different question with its own page.

The Four Points of Contact

Where device software rules genuinely meet a JavaScript protection pipeline

Out of an entire lifecycle standard and the regulations that reference it, four things are influenced by how you build and protect browser code. Everything else — intended use, clinical evaluation, usability engineering, risk management process, post-market surveillance — is decided by what the software does and by the system around it, and no build setting moves any of it in either direction.

1. The inventory of software you did not write

You are expected to identify each third-party component you incorporate, with enough detail to track it: what it is, who publishes it, which version you used, and what it is doing in your design. There are two ways to produce that list and they behave completely differently under a protection step. Derive it from your dependency manifest and lock file and it is produced before bundling ever happens, so nothing downstream can affect it. Derive it by pointing a scanner at your built output and protection destroys it, because the scanner matches on library version strings, banner comments and identifier shapes, which is precisely what renaming and string handling remove.

2. The safety classification and the risk file

Your software safety class follows the harm that a failure could contribute to. That test looks at what the software can do and what happens when it does the wrong thing. No part of it references the readability of the delivered code, so a protected front end carries exactly the class an unprotected one does. The corollary is the one to write down: obfuscation cannot appear in a hazard analysis as a risk control. Risk controls must be verifiable and testable, and “an attacker would find this hard to read” is neither.

3. Configuration management and release records

You are expected to know exactly what was in a release, to be able to reproduce it, and to trace a reported problem back to the version it appeared in. By default this engine produces different output for the same input on every run, which is a genuine protection property and an inconvenience for anyone maintaining a device history. The seed setting resolves it: the same input, options and seed produce byte-identical output. The build manifest complements it by recording a hash of every source file and every output file, which is what ties a shipped artifact back to the inputs that produced it.

4. Where your source travels while you protect it

A supplier assessment will ask this in writing, so answer it precisely rather than generally. The hosted service receives the JavaScript you select, protects it and deletes the request file after the run. The Windows desktop application also offers local processing, where the source body stays on the device, and the command line tool has a local mode with the same property. Those local paths still perform an online entitlement check, which carries no source. Virtual machine protection remains hosted by design, so exclude it if your policy forbids source leaving the environment.

The Ordering Rule

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

This is one sentence, it applies far beyond this page, and getting it wrong is the single most expensive mistake available here. It is not a matter of preference or convenience. It follows directly from what the transformations do, and the consequences are worst in exactly the setting where they matter most.

Component detection stops working

A scanner pointed at a protected bundle finds nothing recognisable, because the version strings and identifier patterns it matches on have been rewritten. An empty result reads exactly like a clean result on a dashboard, which is the dangerous part.

Vulnerability scanning inherits the same blindness

A dependency with a known defect stays exactly as exploitable after protection as it was before. What changes is that the tool watching for it goes quiet. Run the scan against the pre-protection artifact and the lock file, and treat the protected output as a delivery format only.

Verification evidence should still cover the release

The complementary half of the rule. Anything that works by running the software — integration testing, system testing, the usability and accessibility checks — belongs on the artifact you actually ship, because the protected build is the one the user receives.

Runtime Options To Consider Carefully

Two settings deserve a deliberate decision in a clinical interface

Nothing in this product is prohibited in a device context, and nothing in it is required. Two of the runtime options are worth an explicit decision rather than a default, because their costs land on exactly the people a clinical interface exists to serve. Both are documented in full on the runtime defense reference; what follows is why they read differently here than they do on a marketing site.

The developer-tools key block cancels the context menu

The option that blocks the usual inspection shortcuts also registers an unconditional handler that cancels every context-menu event on the page. That event is produced by the dedicated context-menu key and by a keyboard shortcut as well as by a right click, so blocking it removes a keyboard-reachable route to the browser's own reading, translation and spell-checking features. In a clinical interface used under time pressure, that is a usability engineering question, not just an accessibility one.

The integrity guard fires on assistive software

The anti-tampering option fingerprints a list of built-in functions and treats replacement as hostile, re-checking on a short interval. Assistive technology, accessibility overlays and many ordinary extensions work by wrapping those same built-ins. Enabling it on a clinical surface means accepting that a legitimate user's own tooling can trip it. The option provides an exclusion list for exactly this, and that list belongs in your configuration record.

What We Will Not Claim

Four things this product does not do for you

It is not a quality management system

The lifecycle standard is satisfied by planned activities and the records they produce. A build tool contributes evidence to a few of those records. It cannot contribute the process that produces them.

It does not produce your component inventory

The build manifest records what went into a protection run, not the provenance of your dependency tree. Your component list comes from your package manager, before the build, and it is your responsibility to keep it current.

It is not a cybersecurity control you can cite

Protection raises the cost of reading and modifying a shipped program. That is a real property and a poor one to write into a risk file, because it cannot be measured or re-verified by a third party the way an authentication or integrity control can.

It cannot tell you your classification

Whether your software is a device, which class it falls into and which route to market applies are determinations for your regulatory function and, where relevant, a notified body. Nothing on this page substitutes for that.

Frequently Asked

Device software and protected JavaScript, answered

Does IEC 62304 require or forbid JavaScript obfuscation?

Neither, and the standard does not contain the word. It is written as a set of lifecycle activities and the records they produce: planning, requirements, architecture, implementation, integration and system testing, release, maintenance and problem resolution. Each of those is something you do and document. None of them constrains how the delivered code is written, so there is no obligation you discharge by protecting a bundle and none you breach by doing so. What the standard does reach, indirectly, is the inventory of components you did not write and your ability to say exactly what a given release contained.

Does protecting our front end change our software safety classification?

It does not. The class follows the harm a failure could contribute to, which is a question about what the software can do and what happens when it does the wrong thing. Readability of the delivered code appears nowhere in that test. A protected front end carries exactly the class an unprotected one does. The consequence worth writing down is the reverse direction: because obfuscation does not change the class, it also cannot be used to argue a class down, and any hazard analysis that tries to is making a claim an assessor will remove.

Can we list obfuscation as a risk control in the hazard analysis?

It is a poor fit and we would advise against it. A risk control has to be specified, implemented, verified and shown to be effective, and its effectiveness has to be re-checkable by somebody who is not you. Difficulty of reading is the least measurable property a program has: there is no test that passes or fails, no threshold, and no way for a reviewer to reproduce your assessment. Describe protection accurately in your design documentation as an anti-tampering and intellectual property measure, and put the controls that carry safety weight where they can be tested.

How does protection affect our SOUP inventory?

It depends entirely on how you produce the inventory, and the difference is stark. A list derived from your dependency manifest and lock file is generated before bundling, so a later protection step cannot touch it and everything in it stays accurate. A list produced by pointing a scanner at your built output is destroyed, because such tools match on library version strings, banner comments and identifier shapes, all of which renaming and string handling remove. The rule that follows is general: every control that works by reading code must run before the protection step, not after it.

What happens to vulnerability scanning of the shipped bundle?

The same mechanism produces a more dangerous outcome. A dependency with a known defect remains exactly as exploitable after protection as before, because the code still runs. What changes is that the scanner watching for it stops recognising anything, and an empty result is displayed identically to a clean result. Point composition and vulnerability analysis at the pre-protection artifact and the lock file, treat the protected output purely as a delivery format, and record in your process which artifact each check was run against.

Which artifact should our verification testing run against?

The one you release. This is the complementary half of the ordering rule and it points the other way: anything that works by executing the software, including integration testing, system testing, usability validation and accessibility checks, belongs on the protected build because that is what reaches the user. Anything that works by reading the software belongs before protection. Splitting your evidence along that line is straightforward once it is written down and awkward to reconstruct afterwards.

How do we keep release records when the output changes on every build?

Use the seed setting, which exists for this. By default the engine produces different output for the same input on each run, which is a genuine protection property and unhelpful for anyone maintaining a device history file. Supplying a fixed seed makes the same input, the same options and the same seed produce byte-identical output, so a release can be rebuilt and compared rather than merely described. The build manifest records a hash of every source file and every output file, which is what ties a shipped artifact back to the inputs that produced it.

Where does our source code go when we protect it?

That depends on which path you use, and it is worth answering precisely because a supplier assessment will ask in writing. The hosted service receives the JavaScript you select, protects it and deletes the request file after the run. The Windows desktop application also offers local processing, where the source body stays on the device, and the command line tool has a local mode with the same property. Those local paths still make an online entitlement check, which carries no source. Virtual machine protection is hosted by design, so exclude that option if your policy forbids source leaving your environment.

Are the runtime defence options appropriate in a clinical interface?

Two of them deserve an explicit decision rather than a default. The option that blocks developer-tools shortcuts also cancels every context-menu event on the page, and that event is reachable from the keyboard, so the block removes a route to the browser's own reading and translation features. The integrity guard treats replacement of built-in functions as hostile, which is exactly how assistive software and accessibility overlays work, so it can fire on a legitimate user's own tooling. Neither is prohibited. Both are choices you should be able to justify in a usability engineering file.

What is the shortest useful checklist for a device software team?

Five items. Confirm with your regulatory function whether the front end is inside the device software at all, because that decides the rest. Generate the component inventory from your lock file, before bundling. Run composition and vulnerability analysis on the pre-protection artifact, and record which artifact each check used. Adopt a fixed seed and retain the build manifest so any release can be rebuilt and compared. And read your risk file for any control whose effectiveness depends on the code being hard to read, then replace it with something a third party can verify.

Related Guides

Other compliance and evidence guides

HIPAA and your JavaScript

The privacy half of a clinical front end: what reaches the browser, what else executes on the page, and which vendors receive data.

Reproducible builds reference

The seed setting and the build manifest, which are what turn polymorphic output into a release you can rebuild and compare.

How your source is processed

The precise processing boundary for the hosted service and for the local paths, which is what a supplier assessment asks about.

Next Step

Check three things in your current pipeline

Confirm that your component inventory and your vulnerability scan both run against the pre-protection artifact and the lock file, not against the bundle you ship. Set a fixed seed and keep the build manifest, so a release can be rebuilt and compared rather than merely described. Then read your risk file and make sure no hazard control anywhere in it depends on the delivered code being hard to read — and if one does, replace it with a control somebody else can verify.

Open the Online Tool Ask a Question