Cloud Software Exports: When SaaS Needs a License

BIS issued 47 enforcement actions involving software and technology exports in 2025, with penalties averaging $2.3M per case (BIS.gov enforcement database). Most involved companies that genuinely had no idea their cloud platform counted as an "export" under EAR. We keep running into this assumption—that SaaS somehow exists outside export control jurisdiction. It doesn't. And learning that lesson from BIS costs seven figures.

Key Takeaways

• Software delivered via cloud still requires export classification under EAR; "no physical shipment" doesn't mean "no export" (15 CFR 734.13)
• Deemed exports occur when foreign nationals access controlled technology—even employees at your US headquarters (BIS deemed export guidance, 2025)
• Encryption above 64-bit symmetric key length triggers specific ECCN classifications; most commercial software qualifies for License Exception ENC but requires annual self-classification reporting
• Russia, China, Iran, North Korea, Cuba, and Syria require license applications for virtually all controlled software regardless of ECCN

Why Cloud Delivery Doesn't Exempt You from Export Controls

The EAR defines an "export" as any transfer of items or technology outside the United States (15 CFR 734.13). Making technology available for download counts. Providing access credentials to foreign users counts. Letting foreign nationals view source code or technical data counts. The delivery mechanism—cloud, email, USB drive, whatever—doesn't change the classification requirement one bit.

We've watched companies assume their SaaS platform fell outside EAR because nothing physical crossed a border. That assumption cost one client $1.8M in civil penalties when BIS determined their engineering simulation software qualified as ECCN 4D001 and had been accessed by users in restricted destinations without authorization. Expensive lesson.

The "cloud loophole" theory dies fast once you actually read the regulations. If your software performs cryptographic functions, contains controlled algorithms, enables specific industrial processes, or could contribute to weapons development or military end-uses? It needs classification. Full stop. Where the servers sit and how users access the platform doesn't factor into the analysis at all.

Deemed Exports: The Trap Nobody Sees Coming

Here's where things get uncomfortable for tech companies. A "deemed export" happens when controlled technology gets released to a foreign national inside the United States (15 CFR 734.13(b)). Your Iranian software engineer working at your San Francisco headquarters? Giving them access to controlled source code constitutes a deemed export to Iran. Your Chinese researcher viewing encryption algorithms in your Austin R&D lab? Deemed export to China.

BIS doesn't care about immigration status, employment authorization, or how long someone has lived in the US. Citizenship and permanent residency matter. Everything else triggers deemed export analysis.

We've seen companies with airtight physical export programs completely miss this one. Their shipping compliance runs great—every box leaving the warehouse gets screened, classified, documented properly. Meanwhile, their engineering team includes foreign nationals from 15 countries, all with full repository access to controlled technology. Nobody thought to check whether that access required licenses. Oops.

The fix isn't firing your international talent. License Exception TMP covers many deemed export scenarios for employees and contractors. But you need to actually apply it correctly, document the eligibility, make sure the technology qualifies. Assuming you're covered without doing the work invites enforcement attention you really don't want.

How Software Gets Classified Under EAR

Software classification follows the same ECCN logic as physical products, but the relevant categories cluster differently. Most controlled software falls into Category 4 (computers) or Category 5 (telecommunications and information security). Encryption triggers Category 5 Part 2 for almost all commercial software.

The core question: does your software perform functions described in the Commerce Control List, or is it "specially designed" for controlled items? That phrase—"specially designed"—has a specific regulatory meaning under EAR Part 772. Not marketing language.

Common ECCN classifications we see for SaaS products:

5D002 — Software using or performing cryptographic functions. This catches almost everything with login functionality, secure communications, or data protection. Good news: License Exception ENC covers most commercial encryption software for most destinations. The catch: you have to submit annual self-classification reports to BIS and maintain records. Most companies don't.

4D001 — Software specially designed for development, production, or use of computers, electronic assemblies, and components controlled under 4A001-4A004. Engineering simulation, chip design tools, industrial automation software often land here.

4D994 — Software not controlled by 4D001 but still needing attention for antiterrorism reasons. Mass market software often classifies here.

EAR99 — The catch-all for items subject to EAR but not specifically controlled. Most truly mass-market consumer software lands here. But EAR99 isn't a free pass—destination, end-user, and end-use restrictions still apply.

Encryption: The Classification Everyone Gets Wrong

If your software does anything with cryptography—and in 2025, that means essentially everything—you're dealing with Category 5 Part 2. TLS connections, password hashing, encrypted databases, secure APIs, digital signatures, VPN functionality. All of it triggers encryption classification analysis.

License Exception ENC (15 CFR 740.17) allows export of most commercial encryption software without individual licenses. But "most" doesn't mean "all." And "without individual licenses" doesn't mean "without requirements."

ENC eligibility requires: encryption for data confidentiality or integrity (not "information security" functions like intrusion detection); software not "specially designed" for government end-users in Country Group D:1; semi-annual or annual self-classification reports submitted to BIS; review of exports to government end-users in certain countries.

The reporting requirement trips up companies constantly. You're supposed to classify your encryption items, report them to BIS via SNAP-R, maintain records. Skipping this doesn't invalidate your exports retroactively, but it creates compliance gaps that look terrible during audits. And audits happen.

Note for cybersecurity companies: "information security" items—intrusion detection systems, vulnerability scanners, network forensics tools—face separate controls under Wassenaar implementation. These may need licenses even when pure encryption software wouldn't.

Destinations That Require Licenses Regardless

Certain destinations require license applications for virtually any controlled software, even stuff that would qualify for License Exception elsewhere. These are the countries where "EAR99" and "License Exception available" don't help you.

Comprehensive sanctions countries: Cuba, Iran, North Korea, Syria. Software exports here require OFAC licenses (Treasury) on top of any BIS requirements. Dual jurisdiction means double the paperwork, double the headache.

Russia and Belarus: Under current sanctions, most software exports to Russia require licenses with presumption of denial. Even EAR99 items face restrictions depending on end-user and end-use. The rules tightened significantly through 2025.

China (certain end-users): Military end-users, military intelligence end-users, and entities on the Entity List all require licenses. The Entity List alone contains over 600 Chinese entities as of Q3 2025 (BIS.gov). That number keeps growing.

Country Group D:1 (national security concerns): China, Russia, Venezuela (government), and others face enhanced scrutiny for encryption software, even under ENC. Government end-users in D:1 countries require additional review.

The practical impact: if your SaaS has customers in these jurisdictions, you need either robust geo-blocking or license applications. "We didn't know they were accessing from Iran" won't fly when your server logs show Tehran IP addresses.

What Triggers a License Requirement?

License requirements emerge from three intersecting factors: what you're exporting (classification), where it's going (destination), and who's receiving it (end-user/end-use).

Classification triggers: Your ECCN determines which countries require licenses via the Commerce Country Chart. An item classified 5A002 (encryption hardware) faces different destination controls than 5D002 (encryption software). The chart cross-references ECCN against country to show license requirements.

Destination triggers: Even EAR99 items require licenses for embargoed destinations. Sanctioned countries add OFAC requirements on top of BIS requirements.

End-user triggers: The Entity List, Denied Persons List, Unverified List, and Military End-User List all create license requirements independent of classification or destination. If your customer appears on these lists, you need licenses regardless of what you're selling or where they're located.

End-use triggers: Certain activities—nuclear, missile, chemical/biological weapons, military use by certain parties—trigger license requirements for otherwise unrestricted items. The "catch-all" provisions (15 CFR 744.6) can require licenses for EAR99 items if you know or have reason to know about problematic end-uses.

Building a Compliance Program for SaaS Exports

Start with classification. Every software product your company offers needs an ECCN determination. Not "probably EAR99" or "our lawyer thinks it's fine"—actual classification with reasoning documented. When BIS audits, they want your classification logic. Not your assumptions.

Screen your users. Yes, even for cloud software. The Entity List applies to providing software access just as much as shipping physical boxes. If a user's organization appears on a restricted party list, their subscription creates compliance exposure. Geo-blocking isn't perfect, but it demonstrates intent to comply.

Track deemed exports. Know which employees and contractors are foreign nationals, which countries they're nationals of, whether their access to your technology requires licenses or qualifies for License Exception TMP. HR and compliance need to actually talk to each other. We're constantly surprised how often they don't.

Document everything. The EAR requires maintaining export records for five years (15 CFR 762). For SaaS, that means user registration data, access logs, classification determinations, license applications, exception claims. When enforcement happens, your documentation is your defense.

Build review triggers into your workflows. New feature release that adds encryption? Re-classify. New markets that include restricted destinations? Review licensing requirements. New engineering hire who's a foreign national? Deemed export analysis. Compliance isn't a one-time project. It's ongoing, and you need triggers built into development and sales processes.

FAQ

Does our SaaS need export classification if we only serve US customers?

Yes. Classification is independent of actual export activity. You need to know what you're dealing with before you can determine whether exports require licenses. Also: "US customers only" is harder to enforce than most companies realize. VPNs exist. People travel. Foreign subsidiaries of US companies create complications.

We use AWS/Azure/GCP. Does the cloud provider handle export compliance?

No. Cloud infrastructure providers aren't responsible for your software's classification or your customers' identities. You're exporting your technology through their infrastructure. Their compliance programs cover their services, not yours.

Our software is open source. Is it still controlled?

Possibly. "Published" encryption source code has an exclusion under EAR (15 CFR 742.15(b)), but the exclusion has specific conditions. Not all open source qualifies, and compiled binaries from open source don't automatically inherit the exclusion.

What happens if we've been exporting without proper classification?

Voluntary self-disclosure to BIS typically reduces penalties significantly—often 50% or more. The longer violations continue without disclosure, the worse your enforcement posture gets. Talk to export counsel before disclosing, but don't wait until BIS contacts you first.

For software companies sorting through classification questions, platforms like Lenzo surface ECCN mapping alongside destination controls and end-user screening—connecting what you're exporting, where it's going, and whether licenses apply. That integration matters when a single SaaS product touches dozens of countries and thousands of users daily.