Trade Secret Protection for Software: What the Law Requires

A company that distributes commercial software has a specific legal question to answer: does the way we distribute and protect our code satisfy the standard required to claim trade secret protection if our IP is misappropriated?

The answer depends on a legal concept called "reasonable measures." Under both the federal Defend Trade Secrets Act and the state-level Uniform Trade Secrets Act, information qualifies as a trade secret only if the owner has taken reasonable measures to maintain its secrecy. A company that has taken no meaningful steps to protect the proprietary logic in its software cannot claim trade secret status for that logic when a competitor extracts it.

For companies distributing .NET applications, this creates a concrete problem. A compiled .NET assembly without obfuscation is decompilable in seconds using freely available tools. The proprietary algorithms, licensing logic, and business rules embedded in that binary are readable as structured C# source code by anyone who obtains the application. Whether distributing software in that state satisfies the reasonable measures standard is a question with real legal consequences.

The statutory framework

The Defend Trade Secrets Act (DTSA), codified at 18 U.S.C. Section 1839, provides the federal baseline. Its definition of "trade secret" expressly includes "programs" and "codes," but only if "the owner thereof has taken reasonable measures to keep such information secret" and the information derives independent economic value from not being generally known or readily ascertainable.

The Uniform Trade Secrets Act (UTSA) has been adopted in some form in nearly every US state. Its language is materially similar: a trade secret is information that "is the subject of efforts that are reasonable under the circumstances to maintain its secrecy." The standard is contextual. Courts evaluate reasonableness based on the value of the information, the nature of the threat, and the totality of the protection measures in place.

One important statutory detail: the DTSA expressly provides that reverse engineering is not "improper means" of obtaining a trade secret. If a competitor lawfully obtains your software and reverse-engineers the algorithm, the misappropriation claim depends on whether your protection measures were sufficient to keep the information from being "readily ascertainable." This is precisely why technical barriers against reverse engineering matter legally, not just commercially.

What courts look for: the layered secrecy program

US courts evaluating whether a software company took reasonable measures consistently look for a combination of controls rather than any single measure. The case law from the last three decades establishes a clear pattern.

Contractual confidentiality obligations are the single most important element. Courts repeatedly emphasize that employees, contractors, and customers who access the software should be bound by nondisclosure agreements, confidentiality clauses, or restrictive license terms. In InteliClear, LLC v. ETC Global Holdings (9th Cir., 2020), the court found that source code encryption combined with confidentiality agreements was sufficient evidence of reasonable measures. In Turret Labs USA, Inc. v. CargoSprint (2d Cir., 2022), the court reached the opposite conclusion where technical controls existed but no confidentiality obligations governed the users.

Access restriction matters as evidence that the company actually treated the software as secret. Need-to-know repository access, role-based permissions, prompt revocation on departure, and segmented source code storage all demonstrate active secrecy treatment. ISC-Bunker Ramo Corp. v. Altech (N.D. Ill., 1990) found trade secret status where the company distributed only object code, kept source code tightly controlled at headquarters, and bound employees to confidentiality agreements.

Technical barriers against reverse engineering are where obfuscation enters the legal picture. Courts treat compiled, encrypted, or otherwise hardened code as meaningful evidence that the secret is not "readily ascertainable" from the distributed product. Obfuscation, code virtualization, string encryption, and anti-tamper measures all strengthen this argument. The best directly on-point international guidance is the WIPO Guide to Trade Secrets and Innovation, Part VII, which specifically names code obfuscation, encryption, and strict access controls as techniques applied to maintain confidentiality of code and the algorithms behind it.

Specific identification of the secret is a recurring requirement that technical measures alone cannot satisfy. In MAI Systems Corp. v. Peak Computer (9th Cir., 1993), the court reversed a trade secret injunction because the company failed to identify the specific trade secrets in the software. A company must be able to articulate what implementation details, algorithms, or architectures are secret, not merely that "our software is proprietary."

Consistent treatment rounds out the picture. Proprietary legends, labeling, security training, offboarding procedures, and incident response demonstrate that the company treated the information as secret in practice, not just in principle.

The hierarchy of evidence in software cases

The relative legal weight of different protection measures can be stated cautiously based on the case law:

The comparative point is straightforward: obfuscation is most effective legally when presented as one layer in a portfolio of secrecy measures, not as the portfolio itself. A company that obfuscates its binaries and binds its users to confidentiality has a significantly stronger position than a company that does only one or the other.

Recent decisions from the Eastern District of New York reinforce this. In Negative, Inc. v. McNamara (E.D.N.Y., 2025), the court dismissed a DTSA claim despite MFA, need-to-know access, and non-downloadable file formats, because the employer had not communicated confidentiality expectations or used NDAs. In Superb Motors Inc. v. Deo (E.D.N.Y., 2025), firewalls, passwords, and employee access limitations were held insufficient. The missing element in both cases was not more technology but enforceable secrecy obligations.

The unobfuscated .NET binary as a legal risk

Against this legal framework, distributing an unobfuscated .NET application creates a specific vulnerability in a trade secret claim.

A .NET assembly compiles to Common Intermediate Language, which is designed to be self-describing. Tools like ILSpy reconstruct the original class structure, method names, string literals, and logic flow from the compiled assembly without any special expertise. The information in the binary is not "generally known," but it is readily accessible to anyone who installs the application and opens the DLL.

In a trade secret dispute, opposing counsel's argument is straightforward: the company distributed the very information it now claims as a trade secret in a format that required no circumvention, no special tools, and no technical skill to read. The "reasonable measures" element fails not because the company had no protection at all, but because the protection it had was not proportionate to the accessibility of the information.

Obfuscation directly addresses this argument. A company that applies symbol renaming, string encryption, control flow obfuscation, and code virtualization to its distributed binaries has a documentable, technical measure that makes the protected information materially harder to extract. The measure is imperfect, but perfection is not the legal standard. Reasonableness is.

Beyond trade secret law: additional legal frameworks

Two additional legal frameworks strengthen the position of a company that applies technical protection to its software.

The DMCA's anti-circumvention provisions (17 U.S.C. Section 1201) prohibit circumventing technological measures that control access to copyrighted works. Software code is copyrightable, and obfuscation is a technological measure. Circumventing the obfuscation to access the underlying code may constitute a DMCA violation independent of any trade secret claim. This creates a secondary legal basis for protection that operates alongside trade secret law rather than depending on it.

The EU Trade Secrets Directive (2016/943) establishes a harmonized standard across EU member states that parallels the DTSA reasonable measures requirement. For companies distributing software in Europe or with European operations, the same principle applies: demonstrable technical protection of proprietary information strengthens the legal position in a misappropriation claim under EU law.

A note on export control. Some obfuscation tools incorporate strong encryption as part of their protection mechanisms. Software that includes strong cryptographic functionality may trigger export classification under the Export Administration Regulations (EAR), specifically ECCN 5D002. This is not a reason to avoid obfuscation, but companies distributing protected software internationally should consult with export control counsel to confirm their classification obligations. The question is whether the encryption in the obfuscation tool creates a reporting or licensing requirement for the protected software's export.

What a defensible protection program looks like

For a company seeking the strongest available trade secret position for its commercial software, the case law and statutory framework point toward a consistent model:

Define the secret specifically. Maintain a version-controlled inventory of the claimed trade secrets: specific source modules, algorithms, data structures, architecture decisions, and implementation details. "Our software" is not a trade secret. "The scoring algorithm in the RecommendationEngine class" may be.

Control source code access. Segmented repositories, least-privilege permissions, MFA, access logging, periodic review, and prompt revocation on role changes or departure.

Bind all recipients to confidentiality. NDAs for employees and contractors. Confidentiality provisions in customer and partner agreements. Restrictive license terms for distributed software that prohibit reverse engineering where legally enforceable.

Harden distributed binaries. Apply obfuscation, string encryption, control flow protection, and code virtualization to binaries that leave the company's control. Test the hardening by attempting decompilation of the protected output.

Label and train. Mark repositories, build artifacts, and documentation as proprietary. Train personnel on what information is secret and how to handle it.

Document everything. Retain evidence of what measures were in place at any given time: repository settings, access logs, NDA templates, onboarding materials, offboarding records. "Reasonable measures" is an intensely fact-bound determination, and contemporaneous documentation is often what decides the outcome.

Related: Defense in Depth: Where Obfuscation Fits in a Security Architecture →

Back to: .NET Obfuscation and Compliance →