BIS Year-End Self Classification Report

Disclaimer: I am not a lawyer. This is not legal advice. I am not a encryption expert. If you are in doubt, do your own due diligence. I’m confident that “I read it on the internet and they said it was OK” will not be a good defence if the NSA kicks down your door and hauls you away for cyber crimes. I am trying to keep this up to date, but this stuff changes often so it’s worth double checking. If you notice anything wrong or out of date, please let me know. Thanks!

Update January 2023: According to this document on the BIS website, the reporting requirements for mass market items have been changed. My current understanding is that if your app uses any encryption that is included with iOS, or https, then you no longer need to send a report.

Yesterday, after uploading an app for beta testing, I received this message in iTunesConnect for the first time:

If you are making use of ATS or making a call to HTTPS please note that you are required to submit a year-end self classification report to the US government.

Apple’s documentation on this is clear and helpful in determining whether or not you have to report, but unfortunately some of the links are broken and it doesn’t explicitly tell you what you need to report or how to do it.

My understanding is that you are subject to this even if you are not a US company because you upload your apps to Apple’s servers in the US and then Apple exports them to the other app stores around the world. Let me know if your understanding of this is different.

Thankfully, it’s very easy to do—get a copy of the sample CSV file from the BIS website, fill it out with your own details, and then email it to and

Update: Christoper Atlan has produced a useful report generator which validates format requirements.

These reports are due either by August 1st and then February 1st (if reporting in six monthly intervals) or by February 1st of the following year (if reporting yearly).

Once you’ve made your first report then, for subsequent years, all you need to do is email those same addresses and let them know that nothing on the previously submitted form has changed.

Filling out the Form The Easy Way

Most of the information is self explanatory but there are a couple of fields that are expecting specific entries.

If your app just connects to a web service using https, or you’re using OpenSSL purely for authentication or copyright protection (e.g. receipt validation) then, as far as I understand (see disclaimer above), you should be able to just copy the following, paste it in the spreadsheet replace the items between the <Angle Brackets> with your own info and be good to go.

<App name>, <App Sku>, SELF, 5D992.c, MMKT, Mobility and mobile applications n.e.s., <Your name>, <Your phone number>, <Your email>, <Your home address>, no, n/a

Each app that you have made available either on the App Store or via TestFlight that uses any sort of encryption requires its own row.

The 5D992.c (Update: the handy flowcharts on this post show that this is probably the classification that should be used. I now think the original classification is correct.) declares the product to only use encryption that is exempt from further scrutiny, and the MMKT declares product to be a mass market product. See this page on the BIS website for more information (Update: Seems this page has now been removed. Try the FAQ for more information).

Update: It seems there is now an official category for mobile apps now. See this page.

Filling out the Form: The Hard Way

If you use any other encryption algorithms for any other reason, you’ll need to do a deeper dive into the regulations and figure out what you need to declare. There are exemptions for lots of common things like authentication or DRM but if your app does much more than that then you’ll need to make sure you’re above board and copying and pasting probably isn’t a good idea.

The last two columns, for example, are for declaring whether or not your app uses encryption algorithms developed outside of the US and, if so, which countries they were developed in.

There’s a useful explanation right at the bottom of the regulations, and I also found this FAQ helpful.

Disclaimer. Again.

It is entirely possible that the information above is incorrect so, if you have any further insights, please let me know and I’ll update this post.