Export Controls for Software: Classification Screening, Encryption Rules, and Cloud Delivery (Updated for the February 14, 2026 Amendments)

Software crosses borders without a ship or a customs declaration. Attach a file to an email, upload it to cloud storage, grant an overseas office access to a repository -- any of these can constitute an "export" or a "provision of technology" under Japan's Foreign Exchange and Foreign Trade Act (FEFTA). That is precisely why classification screening for software is harder than screening physical goods, and why IT companies and SaaS providers, who never touch a pallet, are the ones most likely to miss it.

This article walks through the legal definition of a program, where software sits within the ministerial ordinance that specifies controlled items, the encryption thresholds and their exemptions, how cloud and SaaS delivery interact with the rules, and the screening workflow and internal controls that make all of this manageable. The content reflects the regulatory amendments promulgated on November 14, 2025 and in force since February 14, 2026.

Quick Reference: How Software Activities Map to the Rules

Start with the big picture. Here is how typical software-related activities map onto FEFTA.

Activity involving software	Treatment under FEFTA	Main legal basis
Sending a program overseas by email or download	Provision of technology (service transaction)	FEFTA Art. 25(1), Foreign Exchange Order Art. 17
Placing a program on a server accessible to non-residents	Provision of technology (deemed complete at upload)	FEFTA Art. 25(1), the Technology Transfer Notice
Carrying a USB drive or HDD containing a program out of Japan	Export of specified recording media	FEFTA Art. 25(3)
Providing technology in Japan to a resident who falls under a Specified Category	Deemed export (clarified rules in force since May 1, 2022)	FEFTA Art. 25(1), the Technology Transfer Notice
Exporting hardware with embedded encryption	Export of goods	FEFTA Art. 48(1), Item 9(7) of Appended Table 1
Providing publicly available programs (such as OSS)	In principle, no license required	Art. 9(2)(ix) of the Invisible Trade Ministerial Order

If you would rather begin with a health check of your overall posture, our export compliance self-assessment takes about three minutes and highlights where your gaps are likely to be. For the general screening process itself -- classification, table cross-referencing, item-by-item comparison sheets, and non-applicability certificates -- see our classification screening walkthrough. This article focuses on what is specific to software.

Software Is Regulated as a "Program"

It surprises many people, but the word "software" never appears in FEFTA or its implementing orders. The statutory term is "program." METI's Technology Transfer Notice (Notice 4-Boekikyoku No. 492 of December 21, 1992), in its section on the interpretation of terms, defines a program as a sequence of instructions to carry out a process, expressed in a form executable by an electronic device or convertible into such a form. Source code and compiled binaries both fall within that definition.

FEFTA runs on two parallel tracks. Exports of goods are governed by Article 48(1) together with the Export Trade Control Order (Cabinet Order No. 378 of 1949). Provisions of technology are governed by Article 25(1) together with the Foreign Exchange Order (Cabinet Order No. 260 of 1980). Programs belong to the technology track. "Technology" here means specific information necessary for the design, manufacture, or use of goods, provided either as technical data -- drawings, specifications, programs -- or as technical assistance such as instruction and training.

Physical media deserve a separate note. Carrying a USB drive or an external HDD containing a program out of Japan is regulated as the export of specified recording media under Article 25(3) of FEFTA. The classification of the medium itself -- the USB stick as a good -- and the classification of the program stored on it are two different questions, and in practice it is almost always the contents that matter.

One more difference from goods is easy to overlook. Exports of goods can qualify for a small-value exemption under certain conditions; provisions of technology and programs have no such exemption. Even an inexpensive business application requires a license if it falls under the control lists. Price is never a reason to skip screening.

Where to Look in the Ministerial Ordinance

The text you ultimately screen against is the ministerial ordinance formally titled the Ministerial Order Specifying Goods and Technologies Pursuant to Appended Table 1 of the Export Trade Control Order and the Appended Table of the Foreign Exchange Order (METI Ordinance No. 49 of 1991), commonly called the Goods and Technologies Ordinance. The items in the two appended tables merely say "as specified by ministerial ordinance"; all the actual thresholds live in the ordinance. Three structural points matter for programs.

First, technology and programs sit in separate subparagraphs. The technology provisions of the ordinance distinguish between "technology necessary for design or manufacture (excluding programs)" and "programs" as such. A design document and the program built from it can fall under different subparagraphs, and screening gaps almost always trace back to ignoring that distinction.

Second, program controls are paired with the controls on related goods. In the information security field, for example, encryption hardware is controlled as a good under Item 9(7) of Appended Table 1 -- Article 8(ix) of the ordinance -- while encryption programs are controlled under Item 9(1) of the Foreign Exchange Order's appended table, which corresponds to Article 21(1) of the ordinance. This pairing is why software screening always starts by identifying the related goods item.

Third, METI publishes a correspondence matrix linking the appended tables to the ordinance provisions. For program screening you only need to follow the item numbers flagged for programs in that matrix; there is no need to brute-force all fifteen categories.

The fields where software most commonly triggers controls are these.

Field	Examples of software that may be controlled	Main related items
Information security (encryption)	Cryptographic libraries, VPNs, cryptanalysis tools	Item 9(7); Item 9(1) of the FX Order table
Numerical control	Machine tool control programs, CAM software	Item 6
Computers	Software for high-performance computing	Item 8
Telecommunications	Programs for specific communications equipment, spread spectrum	Item 9
Sensors and imaging	High-precision signal and image processing	Item 10
Nuclear and fluid dynamics	Nuclear-related and CFD simulation	Items 2, 4, and others

The Four-Step Screening Workflow for Software

Screening technology, including programs, takes one more step than screening goods. Here is the four-step workflow we recommend in practice.

Step one is identifying and inventorying what you are actually providing. Screen at the level of the delivered configuration, not the product name. Break the deliverable into four buckets: code you developed in-house, commercial libraries you embedded, OSS you incorporated, and cryptographic modules. Pin down the version as well -- a minor update that adds an encryption feature can change the determination from that version onward. If your past screening records have no version field, they do not vouch for today's product.

Step two is shortlisting the related goods items. Ask which goods the program helps design, manufacture, or use, or which goods' functions it implements, and narrow the candidates in Appended Table 1. A machine tool controller points to Item 6; encryption points to Item 9.

Step three is selecting the ordinance provisions to screen against. Use METI's matrix to find the corresponding articles in the Goods and Technologies Ordinance, and check both the technology subparagraphs and the program subparagraphs, for the reason described above.

Step four is parameter comparison and documentation. Compare the ordinance thresholds against your product's specifications and record the result in an item-by-item comparison sheet or a parameter sheet. For software, base the determination on specifications, design documents, and the implemented feature list rather than marketing materials, and always record the algorithm, key length, and purpose for anything cryptographic. CISTEC's screening forms are current as of the February 14, 2026 amendments; for communications and information security, Form 9-07 covers goods and Form 9-Tech-1 covers technology and programs. Keep the record, with its reasoning, even when the conclusion is "not applicable."

For embedded commercial libraries and middleware, asking the vendor for a classification certificate is faster than reverse-engineering the answer yourself. A simple request works.

Subject: Request for export classification documentation (product name and version)

Dear Export Compliance Team,

We plan to embed your product ("Product X", version Y) in our software for
distribution outside Japan. To complete our classification screening under
Japan's FEFTA, could you kindly provide:

1. A classification certificate (item-by-item comparison sheet or parameter
   sheet, reflecting the amendments in force since February 14, 2026)
2. Documentation of any cryptographic functionality, including algorithms,
   key lengths, and purposes
3. If the product is subject to the U.S. EAR, its ECCN and any applicable
   license exceptions

We would appreciate a response by [date].

Two details keep the exchange short: set a reply deadline, and specify which amendment version of the regulations the paperwork should reflect.

Screening Software That Contains Encryption

Encryption is the hardest part of software screening, but the structure of the provisions makes it more mechanical than it first appears.

On the goods side, Item 9(7) -- Article 8(ix) of the ordinance -- controls devices with cryptographic functions designed for data confidentiality. The baseline is a symmetric algorithm with a key length exceeding 56 bits, or an equivalent asymmetric algorithm. The representative asymmetric thresholds are integer factorization above 512 bits (RSA and similar), discrete logarithms in multiplicative groups of finite fields above 512 bits (Diffie-Hellman and similar), and discrete logarithms in other groups above 112 bits (elliptic curve cryptography). The screening forms updated for the February 14, 2026 amendments also spell out post-quantum categories: lattice shortest-vector problems, isogeny search between supersingular elliptic curves, and decoding of random codes. In other words, AES-128, RSA-2048, and P-256 all exceed the thresholds on paper.

Does that make every modern application controlled? No -- Article 8(ix) layers several exemptions on top, and most commercial software lands in one of them. Check them in this order.

First, the purpose of the cryptography. Functions limited to purposes other than data confidentiality -- authentication, digital signatures, data integrity, non-repudiation, digital rights management, and the like -- are outside the control. Software that only verifies passwords or signatures exits here.

Second, ancillary cryptography. The forms include a check for cryptographic functions used solely to support a product's primary function. Accounting software that uses TLS purely to protect its network traffic is the textbook case.

Third, equipment-type exemptions. Smart cards, mobile phone handsets, cordless phones, routers and switches, general-purpose computing devices and servers, and network-connected devices for civil industry use are all excluded under subitems (xi) through (xviii) of Article 8(ix)(i). The explicit carve-out for connected IoT equipment is a practical blessing.

Fourth, mass-market cryptography. Widely sold cryptographic devices and programs whose cryptography users cannot easily modify have their own exemption, screened on dedicated annex sheets in the CISTEC forms.

Standalone programs are screened under Item 9(1) of the Foreign Exchange Order's table, which corresponds to Article 21(1) of the ordinance, and a mass-market program exemption exists on that side too. The logic mirrors the hardware provisions, but the scope of available exemptions differs in places, so never copy a goods determination onto a program unexamined.

When in doubt, start by building a one-page inventory of the cryptography in your product: libraries, algorithms, key lengths, purposes, and activation status. That single sheet makes it far easier to see which exemption applies, and it doubles as an annex to your screening record.

Cloud, SaaS, and Classification Screening

The cloud-era principle is simple: the provision occurs the moment controlled programs or technical data become viewable or retrievable by non-residents. The physical location of the server is irrelevant. Data in a domestic region counts as provided if employees of an overseas subsidiary can open it; data in an overseas region does not, so long as access controls keep non-residents out. What matters is who can access it, not where it sits.

SaaS requires a careful distinction. If you never hand over the program itself -- no executables, no source -- and users merely operate the functionality through a browser, the prevailing view is that no provision of a program takes place. That is not the end of the analysis, though. If an on-premises edition, a resident agent, an API client, or detailed technical documentation travels alongside the service, those components must be screened in the usual way. We cover the full risk landscape for SaaS businesses in Export Controls for SaaS and Software Companies.

Transactions that look purely domestic can still be caught. The revised Technology Transfer Notice, in force since May 1, 2022, clarified deemed export controls: providing technology to a resident in Japan is treated the same as providing it to a non-resident when the recipient falls under one of three Specified Categories -- persons under the direction of, or owing duties of care to, a foreign government or foreign entity under a contract; persons receiving or promised 25 percent or more of their annual income from a foreign government or similar body; and persons acting in Japan under the instructions of a foreign government. For software companies employing international engineers this is a live issue, covered in depth in our deemed export guide.

Do not forget business travel. Taking a laptop loaded with controlled programs out of the country can constitute an export of specified recording media. Carrying data for your own use is treated as out of scope, but the analysis changes if you plan to share it with a third party at your destination. The unglamorous fix is the most effective one: put a stored-data classification check on the pre-travel checklist.

OSS and Publicly Available Technology

Open source software is handled under Article 9(2)(ix) of the Invisible Trade Ministerial Order (METI Ordinance No. 8 of 1998): providing technology that is already available to the general public, and providing technology in order to make it public, requires no license. Source code anyone can fetch from GitHub is publicly available technology, and pointing a non-resident to it needs no authorization -- even for cryptographic libraries that would otherwise be controlled, as long as the program is published.

Three traps undo that comfort. First, internal forks: the modifications you made in-house are not published, so they are not public. Second, pre-release code: even if publication is planned, handing the code to a specific party before release is simply a provision of non-public technology. Third, surrounding documents: the OSS itself may be public while your internal design documents and evaluation data remain non-public technical data subject to screening. The claim "it's OSS, so we're fine" collapses exactly where these three mix.

Building the Internal System

Export control for software is never a one-time screening, because the code changes every month and the dependency tree changes with it. Four practices keep the system honest.

• Screen per release. Re-screen on major version upgrades and whenever cryptographic functionality is added
• Manage access rights. Restrict repositories and file servers holding controlled technology to those with a business need, and stop blanket grants to overseas offices
• Approve transmission paths. Put an approval flow in front of external transmission and cloud sharing of technical data
• Keep screening records. Retain "not applicable" determinations too, with their reasoning

On the last point, the Exporter Compliance Standards under Article 55-10 of FEFTA require exporters handling list-controlled items to designate a person responsible for classification confirmation, among other duties. Record-keeping is not just internal hygiene; it is part of meeting those standards.

The law keeps moving as well. The amendments to the Export Trade Control Order that took effect on February 14, 2026 added FPGA-embedded devices and revised items agreed in the international export control regimes, and the screening forms were updated the same day. Check at least once a year that you are not still screening against an outdated form. For the details of the amendment, see our guide to the February 2026 Export Trade Control Order amendment.

Reducing the Screening Burden

Running this workflow entirely by hand consumes days of work per release, and the cryptographic inventory and item-number matching lean heavily on individual experience.

TIMEWELL's TRAFEED (formerly ZEROCK ExCHECK) is an AI agent for export control that supports exactly this screening work. It helps match product specifications against the provisions of the Goods and Technologies Ordinance and presents determinations together with their reasoning. It follows METI's standards, achieves AI screening accuracy above 95 percent (joint validation with Okayama University, based on our own research), holds Japanese patent No. 7862062, and is used by more than 20 organizations. The more frequently your screening targets change -- and with software they change constantly -- the more the automation pays off.

Frequently Asked Questions

Do we need classification screening just to email software overseas?

Yes. FEFTA's technology controls are indifferent to the means of provision. An email attachment or a download link is treated the same as any other transfer, and a controlled program requires a service transaction license either way. Conversely, if screening confirms the program is not controlled, no license is needed. The one rule that must hold: screen before you send.

Our software only uses TLS to encrypt traffic. Is it caught by the encryption controls?

Usually not, but you still have to check. Judged on key lengths alone, almost all modern cryptography exceeds the thresholds. The exemptions do the real work: purposes other than confidentiality such as authentication, the ancillary cryptography check, the equipment-type carve-outs, and the mass-market exemption. Most commercial business software lands in one of them -- and recording which exemption you relied on is part of the screening itself.

If customers only use our product as SaaS, are export controls irrelevant?

Pure SaaS use, where the program itself never changes hands, is generally viewed as not constituting a provision of a program. But an on-premises edition, distributed agents or API clients, shared technical documentation, or access rights granted to overseas offices each require screening and, where applicable, licensing. Also watch for deemed exports to domestic users who fall under the Specified Categories.

How should we screen software that incorporates OSS?

Treat the published OSS portions as publicly available technology, and screen your non-public in-house development and modifications in the normal way. For embedded commercial libraries, request classification certificates from the vendors. The product-level conclusion then aggregates the determinations for the non-public and commercial components.

Summary

Classification screening for software demands its own body of knowledge: the statutory concept of a program, the structure of the Goods and Technologies Ordinance, the layered encryption exemptions, and the operational rules for cloud delivery and deemed exports. As a first step, pick one flagship product and build the one-page cryptography inventory -- algorithms, key lengths, purposes, activation status. That single sheet makes screening, vendor requests, and audit responses dramatically easier. Then wire a re-screening rule into your release process. Classification screening is not paperwork; it is part of managing the product.

References (Primary Sources)

1. Foreign Exchange and Foreign Trade Act (Act No. 228 of 1949), Articles 25 and 48 (e-Gov) https://laws.e-gov.go.jp/law/324AC0000000228
2. Export Trade Control Order (Cabinet Order No. 378 of 1949), Appended Table 1 (e-Gov) https://laws.e-gov.go.jp/law/324CO0000000378
3. Foreign Exchange Order (Cabinet Order No. 260 of 1980), Article 17 and Appended Table (e-Gov) https://laws.e-gov.go.jp/law/355CO0000000260
4. Ministerial Order Specifying Goods and Technologies (METI Ordinance No. 49 of 1991), Article 8(ix) and Article 21(1) (e-Gov) https://laws.e-gov.go.jp/law/403M50000400049
5. METI, Technology Transfer Notice (Notice 4-Boekikyoku No. 492 of December 21, 1992) https://www.meti.go.jp/policy/anpo/law_document/tutatu/t10kaisei/ekimu_tutatu.pdf
6. METI, Clarification of Deemed Export Controls (in force May 1, 2022) https://www.meti.go.jp/policy/anpo/law_document/minashi/meikakukanitsuite2.pdf
7. Ministerial Order on Trade-Related Invisible Trade (METI Ordinance No. 8 of 1998), Article 9(2) (e-Gov) https://laws.e-gov.go.jp/law/410M50000400008
8. METI, Cabinet Decision on the Partial Amendment of the Export Trade Control Order (November 11, 2025; promulgated November 14, 2025; in force February 14, 2026) https://www.meti.go.jp/press/2025/11/20251111001/20251111001.html
9. CISTEC, Sample Parameter Sheets for Communications and Information Security, edition for the ordinances in force from February 14, 2026 https://www.cistec.or.jp/publication/shoseki/sample/b03-tuushin-kinyuurei.pdf