FIPS 140-3 · CMVP · Common Criteria · ISO/IEC 15408

Obfuscation is not cryptography, and no amount of it will make you FIPS validated.

This question arrives most often as a single line in a procurement spreadsheet, sitting next to boxes about TLS and disk encryption: is your code protection FIPS compliant? The honest answer is short, but it is worth understanding why it is short, because the reasoning also tells you which box the transform genuinely belongs in and what you can put there instead.

Security Evidence Packet Obfuscation vs Encryption
The Short Version

Module, algorithm, technique

Three distinctions that settle the question before the transform is relevant.

Validation attaches to a moduleA certificate names a specific implementation at a specific version on a tested platform, and it has a number you can look up.
The decoder ships with the dataThe packed string and the parameter that unpacks it are arguments in the same call expression, so nothing is withheld.
Out of scope beats a weak yesA build-time transform holds no runtime keys, and explaining that is a stronger answer than stretching a definition.
What Validation Means

A certificate is issued to a module, not to a technique

Almost every misunderstanding in this area comes from treating FIPS as an adjective that can be applied to a product category. It is not. It is the outcome of testing a particular implementation.

FIPS 140-3 validates an implementation

The Cryptographic Module Validation Program issues certificates after an accredited laboratory tests a module against the standard: a defined cryptographic boundary, the interfaces crossing it, the roles and services offered, power-on self-tests, and how keys enter, live and are zeroised. What comes out is a certificate naming a module, a version and the platform it was tested on. In a questionnaire the currency is that number. Either you can cite one or you cannot.

An approved algorithm is necessary but not sufficient

SHA-256 is specified in FIPS 180-4, HMAC in FIPS 198-1, and EdDSA with Ed25519 was brought into the approved set by FIPS 186-5. Choosing one of those is a sensible engineering decision and it is not validation. The standard is concerned with the implementation that computes the algorithm, which is why two programs using the identical algorithm can differ entirely in status. Reading algorithm choice as compliance is the single most common error in vendor responses.

Common Criteria asks a different question

Standardised as ISO/IEC 15408, Common Criteria evaluates a Target of Evaluation against a Protection Profile at a chosen assurance level. It is broader than cryptography and narrower than reputation: the result covers exactly what was scoped and tested, and nothing outside it. Like FIPS, it is not a status a source transform can acquire on its own, and like FIPS it is usually raised because someone wants assurance about your process.

Why A Transform Is Not Encryption

The decoder ships in the same expression as the data

There is a specific, checkable reason this is not a matter of degree or vendor modesty. It follows from what protected code has to do to keep running in a browser.

What the Encrypt Strings option emits

With the option on, the string table stops being an array of literals and becomes a call to a generated decoder. The arguments to that call are the packed literal and the numeric parameter that unpacks it. Both are written into the same expression, in the same file, delivered to the same browser. The transform is a permutation over characters with its parameter alongside it, so there is no key held anywhere else and no key lifecycle to describe.

Anything the browser decodes, the browser can decode

This is structural rather than a shortcoming of one option. Code that must execute without calling home has to carry everything it needs to execute, which includes any means of recovering its own literals. A transform that ships its own decoder is a reversible encoding by construction. That is a perfectly reasonable thing to sell and to buy, but it is not confidentiality, and the two words should not be traded for each other.

So it cannot carry a confidentiality control

If a control asks whether data is encrypted using an approved algorithm, a code transform is not the answer, and offering it as one creates a position you would later have to withdraw. The framework that does engage with the technique directly is OWASP MASVS, which treats it as a resilience measure that raises the cost of analysis and tampering. That is the honest register, and it is written up separately.

Real Cryptography In The Toolchain

There is genuine cryptography here, and it is still not a validated module

The release-integrity features do use conventional primitives, so it is worth being precise about what they are and where the validation question actually lands.

Release signatures use Ed25519

The release signer generates an Ed25519 key pair and produces an EdDSA signature, with the algorithm identifier left null because it is implied by the key type. What gets signed is a manifest listing each file with its SHA-256 digest, which is what lets a recipient check that the artefact they hold is the artefact you published rather than something substituted in between.

Watermarks use HMAC-SHA256

A watermark is a plaintext tag encoded base64url alongside an HMAC-SHA256 signature over that tag. The tag is not hidden and is not meant to be; the signature is what makes it hard to forge a marker attributing a build to someone else. Anyone holding the key can verify one, which is the property that makes it useful in a redistribution dispute.

Whose implementation computes it is your question

These features call the cryptographic library of the host runtime. Whether that library is a validated module depends on how the runtime was built and configured in the environment where you run it, which varies by platform and by how your organisation provisions it. Nothing in this toolchain ships a validated module or claims a certificate, and the distinction is worth stating in exactly those terms.

Scope

A build-time transform sits outside your cryptographic boundary

The most useful thing you can do with this question is answer the scope part first, because it usually dissolves the rest of it.

It is absent from production

The transform runs inside your pipeline, consumes source and emits a file. It does not hold keys used by the running application, does not encrypt or decrypt user data, and is not present when a request is served. For a boundary question the accurate answer is that it falls outside, and a short explanation of why lands better than a bare denial because it shows you understood what was being asked.

The exception worth declaring yourself

Turn on release signing or watermarking and a private key or shared secret now lives in your build environment. That does not change the module question at all, but it does put key storage, access and rotation into your own control set. Volunteering this is worth doing: it is the part a thorough reviewer would find anyway, and finding it themselves reads very differently from being told.

Which is why the real subject is the build

When someone raises FIPS about a build tool they are usually probing key custody and pipeline integrity rather than expecting a certificate. Answering the question they meant, with who can trigger a release and what record each one leaves, moves the review forward. Answering the question they typed, with a flat no and nothing else, tends to generate another round of email.

Answering The Questionnaire

Three questions get merged into one box and only one is about code

Most stuck reviews are a vocabulary problem rather than a disagreement. Splitting the box into its parts is usually the whole fix.

Data in transit

TLS between your users and your service, terminated by your platform and computed by its cryptographic library. If a validated module is genuinely required, this is one of the two places the requirement actually bites, and the answer comes from your hosting and runtime configuration rather than from anything in your build.

Data at rest

Storage and backup encryption, again a property of the platform you run on and the keys you manage there. As with transit, this is answerable with concrete configuration, and it is where the effort belongs if a real cryptographic requirement is in play.

Code protection

This is the only one a transform touches, and what it offers is a tamper and analysis cost rather than confidentiality. Naming it as its own line, with its own claim, keeps the strong meaning of encryption attached to the two rows above where it belongs and stops a reviewer reading a capability into your response that is not there.

What To Say

The answer that survives a follow-up question

Three habits keep this section of a security response durable, which matters because these documents get reread months later by people who were not in the original conversation.

Say no, plainly

There is no certificate number to cite, and the validated-module list is public and searchable, so an invented claim fails on first inspection. A clear negative costs a paragraph. A stretched yes costs a correction later, in a thread that now includes people who were not copied the first time and who will reasonably wonder what else was stretched.

Offer what you can evidence

A reproducible build from a recorded seed, a manifest of source and output digests, a signature over the release, and a written process for who runs it. These are checkable, which is the quality that makes them worth more than an assurance. Assembling them once means the next questionnaire is an editing job rather than a project.

Keep the vocabulary clean in your own copy

If your datasheet says encryption where it means encoding, procurement will read the strong meaning and you will have authored the problem. This applies to how you describe your own product as much as to how you describe ours, and it is much easier to fix in a draft than in a signed response.

Frequently Asked Questions

Questions procurement and audit teams ask

Is JavaScript Obfuscator FIPS 140-3 validated?

No, and no certificate number is claimed. FIPS 140-3 validation is issued by the Cryptographic Module Validation Program to a named cryptographic module at a specific version on a specific tested platform, after an accredited laboratory has examined it. A source-to-source code transform is not a cryptographic module and has never been submitted as one. Because the programme publishes a searchable list of validated modules, a vendor claim here is checkable in about a minute, which is a good reason to answer this one plainly.

Does the Encrypt Strings option satisfy an encryption requirement?

No, and it should not be offered as an answer to one. The option packs the string table into a compact literal and emits an initializer that calls a generated decoder, but the packed literal and the numeric parameter that unpacks it are arguments in the same call expression. They travel in the same file to the same browser. Nothing is held back, so there is no key and no key management to describe, which are the first things any encryption control asks about.

You sign releases with Ed25519 and HMAC-SHA256. Does that not make the tooling FIPS compliant?

No. Those are approved algorithms, which is a different property from a validated implementation. EdDSA with Ed25519 was approved in FIPS 186-5, SHA-256 is specified in FIPS 180-4 and HMAC in FIPS 198-1, so the algorithm choices are conventional. Validation attaches to the module that computes them, which here is whatever cryptographic library the host runtime was built against in your environment. That is a property of your platform, not of a build-time tool.

Is a build-time transform in scope for our cryptographic boundary at all?

Usually not, and saying so with a reason is stronger than a bare denial. The transform runs in your pipeline, produces a file, and is absent at runtime. It holds no keys used by the running application and neither encrypts nor decrypts user data. The one thing worth declaring is that if you enable release signing or watermarking, a private key or shared secret now exists inside your build environment, which puts key custody into your own control set even though the module question is unchanged.

What about Common Criteria, which our customer asked for instead?

It is a different framework with the same bottom line for a transform. Common Criteria, standardised as ISO/IEC 15408, evaluates a defined Target of Evaluation against a Protection Profile at an assurance level, and the evaluation covers what you scoped and the laboratory tested. There is no result a code transform earns on its own. If the question is really about assurance in your development process, the productive answer is your release evidence rather than a certificate you do not hold.

What can we actually put in the response, then?

Separate the three questions that tend to collapse into one box: data in transit, data at rest, and code protection. The first two belong to your platform and its cryptographic library, and only the third is what a transform touches. For that third one you can evidence a reproducible build from a recorded seed, a manifest carrying source and output digests, a signature over the release, and a documented process. That is a concrete answer, and it is the one that survives a follow-up question.

Related Guides

Where to read next

ISO 27001 and SOC 2

The two attestations most often demanded of a vendor, and why naming a protection step creates a population an auditor samples.

Obfuscation is not encryption

The same distinction at article length, including what a product claiming to encrypt JavaScript is actually selling.

OWASP MASVS resilience

The one standard on this site that names obfuscation directly, and treats it as a resilience measure rather than a confidentiality control.

Next Step

Answer the scope question once and reuse it

Most of the cost in this area is spent rediscovering the same three distinctions under deadline. Write them down while nothing is pending, attach the evidence you do have, and the next spreadsheet becomes a short edit rather than an escalation.

Build the Evidence Packet Obfuscation vs Encryption