ITSAppUsesNonExemptEncryption: brauchen Sie das, und was tragen Sie ein?

Zuletzt geprüft am 24. Juli 2026.

Was App Store Connect wirklich fragt

Über den App Store verteilte Apps gelten rechtlich als aus den Vereinigten Staaten „exportiert“ und fallen damit unter die US Export Administration Regulations (EAR). Wenn Ihr Build Verschlüsselung nutzt, muss App Store Connect wissen, ob es die gewöhnliche Art ist (ausgenommen) oder die Art, die Papierkram verlangt (nicht ausgenommen). Mehr bedeutet die Frage nicht.

Der Haken: Praktisch jede App nutzt heute Verschlüsselung, denn jeder HTTPS-Aufruf tut es. „Nutzt Ihre App Verschlüsselung?“ heißt also fast immer ja — aber die Antwort, die Sie freischaltet, dreht sich darum, ob diese Verschlüsselung ausgenommen ist, und für die allermeisten Apps ist sie das.

Entscheidungsbaum: nutzen Sie nicht ausgenommene Verschlüsselung?

Gehen Sie der Reihe nach vor. Der erste Punkt, der zutrifft, entscheidet Ihre Antwort.

1. Nutzt Ihre App gar keine Verschlüsselung oder nichts über das hinaus, was iOS selbst mitbringt? → Ausgenommen. Antworten Sie NEIN (ITSAppUsesNonExemptEncryption = false).
2. Beschränkt sich Ihre Verschlüsselung auf HTTPS/TLS oder die Standard-Krypto-APIs, die Apple in iOS/macOS ausliefert (CryptoKit, Keychain, Secure Enclave usw.)? → Ausgenommen. Antworten Sie NEIN. Das deckt die überwältigende Mehrheit der Apps ab.
3. Nutzen Sie Verschlüsselung nur zur Authentifizierung — Passwörter hashen, Token signieren — und nicht, um Nutzerinhalte zu verschlüsseln? → Ausgenommen. Antworten Sie NEIN.
4. Liefern Sie Ihren EIGENEN Verschlüsselungsalgorithmus aus oder schützen Sie damit Nutzerdaten über das Obige hinaus (etwa ein eigenes Ende-zu-Ende-Verfahren, eine eigene Chiffre, Dateien mit eigener Schlüsselverwaltung)? → Möglicherweise nicht ausgenommen. Antworten Sie JA und führen Sie die Selbstklassifizierung durch (siehe unten).

Standard-Kryptografie über einen eigenen Komfort-Wrapper zu nutzen macht sie nicht zu nicht ausgenommener Verschlüsselung — es zählt der zugrunde liegende Algorithmus, nicht die Hülle. Erst einen eigenen oder nicht standardisierten Algorithmus zu erfinden oder einzubetten kippt Sie in die nicht ausgenommene Kategorie.

Die zwei Wege zu antworten — und warum die plist gewinnt

Es gibt genau zwei Orte für diese Antwort. Sie sind nicht gleichwertig: Der eine fragt Sie bei jedem Release, der andere antwortet einmal und bleibt beantwortet.

Der genaue plist-Ausschnitt

Fügen Sie das in die Info.plist Ihres App-Targets ein (oder über den Tab Info bzw. eine xcconfig). Es ist ein Boolean:

<key>ITSAppUsesNonExemptEncryption</key>
<false/>

Danach Clean Build Folder (⇧⌘K), erneut archivieren und hochladen. Den Wert auf false zu setzen ist nur richtig, wenn Ihre App nach dem Baum oben ausgenommen ist — es ist eine rechtliche Erklärung, kein Stummschalter. Eine Feinheit: Ein Build, der bereits in App Store Connect liegt, übernimmt den Schlüssel nicht nachträglich. Beantworten Sie die Frage für diesen einen Build von Hand, um ihn jetzt freizugeben, und liefern Sie den Schlüssel im nächsten Archiv mit, damit nie wieder gefragt wird.

Wann Sie die Ausnahme / Selbstklassifizierung wirklich brauchen

Wenn Schritt 4 des Baums zutraf — Sie liefern nicht standardisierte oder eigene Verschlüsselung aus — ist ein JA nicht das Ende. Sie übernehmen echte Pflichten nach der EAR:

• Selbstklassifizierung: Bestimmen Sie die ECCN Ihrer App (typischerweise 5D002) und bestätigen Sie, dass sie für die License Exception ENC nach EAR §740.17 qualifiziert.
• Jährlicher Selbstklassifizierungsbericht: Für die meisten Massenmarkt-Apps mit Verschlüsselung müssen Sie einmal jährlich einen Bericht per E-Mail an das BIS und an den ENC/NSA Encryption Request Coordinator schicken (Jahresendbericht).
• CCATS: Manche Produkte brauchen vorab eine formelle Einstufung (CCATS) durch das Bureau of Industry and Security — App Store Connect fragt dann nach dieser Genehmigung.
• Dokumentation in App Store Connect: Sie hinterlegen im Abschnitt Verschlüsselung Ihre Ausnahmegrundlage oder Ihre CCATS-/ERN-Angaben, pro Release, sofern Sie keinen Compliance-Code hinterlegt haben.

Für Consumer-Apps ist das wirklich selten. Wenn Sie CryptoKit, Keychain, TLS und nichts Exotisches nutzen, sind Sie ausgenommen und nichts davon gilt für Sie — antworten Sie NEIN und machen Sie weiter.

Unsicher, ob Ihre Kryptografie ausgenommen ist? Apple verweist auf das US Bureau of Industry and Security; der praktische Test lautet: „Habe ich einen Verschlüsselungsalgorithmus implementiert, oder rufe ich nur Apples auf bzw. nutze HTTPS?“ Letzteres ist ausgenommen.

Der häufige Fehler: der Schlüssel fehlt ganz

Am häufigsten beißt das nicht über einen falschen Wert, sondern über gar keinen. Fehlt der Schlüssel:

• Jeder TestFlight-Build landet in „Missing Compliance“, und Ihre Tester können ihn nicht installieren, bis Sie die Frage in App Store Connect beantworten — Einladungen kommen stillschweigend nicht an.
• Ein Build für die App-Store-Einreichung geht nicht in die Prüfung, solange die Compliance ungeklärt ist, und liegt herum, während Sie ihn in der Warteschlange wähnen.
• Weil die Abfrage bei jedem Upload zurückkommt, blockiert eine CI/CD-Pipeline, die Builds automatisch einreicht, bei jedem Durchlauf — das klassische „warum hängt TestFlight?“.

Die Lösung ist dieselbe wie oben: ITSAppUsesNonExemptEncryption einmal in der Info.plist setzen (sofern ausgenommen), damit kein Build je wieder in den Zustand Missing Compliance gerät.

Häufige Fragen

Passend dazu: Apple Privacy Manifest (PrivacyInfo.xcprivacy) · Checkliste für die App-Store-Einreichung

Quellen

• Apple Developer — Complying with encryption export regulations
• Apple Developer — Überblick über die Exportkontrolle
• US Bureau of Industry and Security — Verschlüsselung und Export Administration Regulations (EAR §740.17)