Axel Lenz Wissen
Wissen

Vergleiche & Entscheidungen

Ist BlackBerry UEM BSI-zertifiziert? Was der Nachweis abdeckt

BSI-Zertifikat, VS-NfD, NATO, FIPS: welcher Nachweis bei BlackBerry UEM welche Komponente und Version abdeckt und wie du ihn für eine Ausschreibung prüfst.

Axel Lenz11 Min. Lesezeit

Vier getrennte Bausteine; nur der blaue trägt ein rotes Prüfsiegel.

Ja, für genau einen Gegenstand: Das BSI hat den BlackBerry UEM Server in Version 12.21.1 (Build 40.32.0) nach Common Criteria zertifiziert. Das Zertifikat BSI-DSZ-CC-1235-2025 hat die Prüftiefe EAL 4 erweitert um ALC_FLR.3, wurde am 08.09.2025 ausgestellt und gilt bis 07.09.2030 [1][2]. Es deckt diesen Server in der geprüften On-Premises-Konfiguration ab, nicht aber die Clients auf den Geräten, die Dynamics-Apps, UEM Cloud oder eine VS-NfD-Zulassung (Registerstand 13.10.2026) [3][4].

Für eine Ausschreibung oder Freigabe reicht das Wort „BSI-zertifiziert“ deshalb nicht. Unten stehen die Nachweise rund um BlackBerry UEM mit Gegenstand, Version und Frist, die Grenzen des Serverzertifikats und eine Prüfreihenfolge, die bei jedem Anbieter funktioniert.

Welcher Nachweis gilt wofür?

In Angeboten und Datenblättern stehen BSI, NATO, Common Criteria und FIPS oft in einer Zeile, als ergäben sie zusammen eine Plattformzulassung. Dabei hat jeder Nachweis seinen eigenen Gegenstand, seine Version und seine Frist (Stand 13.10.2026).

Nachweis Gegenstand Version / Konfiguration gültig bis / Stand Register
BSI-DSZ-CC-1235-2025, Common Criteria UEM Server (UEM Core und Management Console) 12.21.1 (40.32.0), On-Premises; EAL 4 + ALC_FLR.3; Schutzprofile BSI-CC-PP-0115 und -0116 07.09.2030 BSI [1]
BSI-Zulassung oder Einsatzerlaubnis VS-NfD BlackBerry UEM kein Eintrag Stand 13.10.2026 BSI-Schrift 7164 [4]
BSI-VSA-11057, Einsatzerlaubnis bis VS-NfD SecuVOICE für iOS und Android (Secusmart) 6.x 31.08.2027 BSI-Schrift 7164 [4]
BSI-VSA-11041, Einsatzerlaubnis bis VS-NfD SecuSUITE for Samsung Knox (Secusmart) 1.17.x 30.04.2027 BSI-Schrift 7164 [4]
BSI-VSA-11030, Einsatzerlaubnis bis VS-NfD SNS Infrastruktur (Secusmart) 3.x 31.03.2027 BSI-Schrift 7164 [4]
NIAPC-Eintrag, NATO RESTRICTED UEM Server und Android Client „v12“, ohne Bezug auf einen bestimmten Release Katalogeintrag, Last Update 06.02.2026 NATO NIAPC [8]
NIAP VID11427, Common Criteria (USA) UEM Server und Android Client „v12“ archiviert, zertifiziert am 30.05.2024 NIAP [6]
NIAP VID11634, Common Criteria (USA) SecuSUITE Server 6.0 zertifiziert, Assurance Maintenance Date 26.01.2028 NIAP [6][7]
NIST CMVP #4575, FIPS 140-2 Security Builder FIPS Java Module (Kryptomodul) 2.9 / 2.9.2 Historical NIST [9]
NIST CMVP #4267, FIPS 140-2 Security Builder FIPS Module, C-Toolkit (Kryptomodul) 6.5.0 Historical NIST [10]
FIPS 140-3 zwei Security-Builder-Module ohne Zertifikatsnummer Modules In Process NIST [11]

Für die Frage aus der Überschrift zählt die erste Zeile: der BSI-Nachweis für UEM Server 12.21.1. Die drei VS-NfD-Einsatzerlaubnisse gehören zu Secusmart-Produkten für sichere Sprach- und Datenkommunikation, nicht zum UEM-Server. Wenn dir jemand sagt, „BlackBerry hat VS-NfD“, lautet die nützliche Rückfrage: für welches Produkt, in welcher Version, bis wann?

Zertifizierung, Zulassung, Einstufung, Validierung

Die vier Begriffe beantworten verschiedene Fragen. Jede Behauptung aus einem Angebot gehört zu einer Zeile der Tabelle oder zu keiner.

Common-Criteria-Zertifikat. Ein Prüflabor evaluiert eine bestimmte Produktversion gegen ihr Security Target. Das ist die Beschreibung des Prüfgegenstands (TOE, Target of Evaluation), seiner Sicherheitsfunktionen und der Annahmen an die Umgebung. Das BSI bestätigt das Ergebnis als Zertifizierungsstelle. Den Maßstab für UEM bilden zwei BSI-Schutzprofile, PP-0115 „Mobile Device Management – Trusted Server“ und PP-0116, das dieses Profil um das Modul „Trusted Communication Channel“ ergänzt, beide in Version 1.0 [3]. EAL 4 beschreibt die Prüftiefe auf einer Skala von EAL 1 bis EAL 7 [2][21], EAL4+ ist also keine Höchstnote. Das Plus steht hier für ALC_FLR.3: Der Hersteller nimmt gemeldete Sicherheitsmängel nach einem festgelegten Verfahren an, behebt sie und verteilt Fehlermeldungen samt Korrekturen zeitnah an registrierte, möglicherweise betroffene Anwender [2][22]. Über das internationale Abkommen CCRA wird das Zertifikat außerdem nur in den Komponenten bis EAL 2 und ALC_FLR anerkannt [2].

VS-NfD-Zulassung und Einsatzerlaubnis. Für Verschlusssachen bis VS-NUR FÜR DEN DIENSTGEBRAUCH entscheidet das BSI über den Einsatz eines Produkts. Die öffentliche BSI-Liste führt dazu Produkt, Version, Nachweisart, Einstufung und Befristung [4]. Die Urkunden mit den Einsatz- und Betriebsbedingungen erhalten nur berechtigte Anwender über den internen Bereich des BSI [4]. Auf derselben Liste stehen auch Geräteplattformen mit eigenen Nummern und Fristen, etwa indigo von Apple (Zulassung BSI-VSA-10900, Einsatzerlaubnis BSI-VSA-10901, beide bis 31.10.2027) und die Knox Native Solution 3.13 (BSI-VSA-11044, bis 31.08.2027) [4]. Welche Anforderungen dort an die Geräteverwaltung gestellt werden, regeln die Einsatzbedingungen, nicht die öffentliche Liste. Ein CC-Zertifikat für den MDM-Server ist also keine VS-NfD-Freigabe, und eine Einsatzerlaubnis für ein anderes Produkt ist kein Zertifikat für UEM.

NATO-Einstufung. Im NATO-Katalog NIAPC steht für UEM der Eintrag „BlackBerry UEM Server and Android Client v12“ mit NATO RESTRICTED [8]. Der Gegenstand ist hier Server plus Android Client und als „v12“ benannt, also anders geschnitten als beim BSI-Zertifikat, das jeden Client ausschließt [3]. Ein Katalogeintrag „v12“ ist kein Nachweis für einen bestimmten Release wie 12.21.1 oder 12.24. Für einen NATO-Einsatz klärt ihr Release, Status und Einsatzbedingungen über die zuständige NATO-Stelle.

FIPS-Validierung. FIPS 140 bewertet ein Kryptomodul, kein Produkt. Ein CMVP-Zertifikat des NIST nennt Modulname, Modulversion, getestete Betriebsumgebungen und Status [9][10]. Der UEM Server 12.21.1 nutzt als Kryptokern den Certicom Security Builder GSE-J 2.9.2 [2]. Für das Java-Modul dieser Version gibt es ein FIPS-140-2-Zertifikat (#4575), getestet allerdings in anderen Umgebungen als der BSI-Prüfkonfiguration [9]. „FIPS compliant“ in einem Datenblatt ist kein Registerstatus.

Aktive FIPS-140-2-Module durften bis 21.09.2026 in neuen Systemen eingesetzt werden, danach verschiebt NIST die Zertifikate auf die Liste „Historical“ [12]. Dort stehen am 13.10.2026 auch #4575 und #4267 [9][10]. US-Bundesbehörden setzen solche Module nur noch in bestehenden Systemen ein [12]; neue Beschaffungen sollen sie nicht mehr enthalten, der Weiterbetrieb ist eine eigene Risikoentscheidung [9][10].

Für FIPS 140-3 stehen am 13.10.2026 zwei BlackBerry-Module auf der Liste „Modules In Process“, also in einem laufenden Verfahren ohne Zertifikat [11]. Mit dem Dynamics SDK 15.x hat BlackBerry auf einen Krypto-Provider nach FIPS 140-3 umgestellt [13]. Das betrifft die Implementierung und ersetzt keine erteilte Validierung.

Was das UEM-Zertifikat konkret abdeckt

Gegenstand des BSI-Zertifikats für UEM Server 12.21.1 ist Software: UEM Core und Management Console [2][3]. Die evaluierte Konfiguration ist eine On-Premises-Installation mit Core und Console auf demselben Host unter Windows Server 2019 oder 2022 mit Java 17 [3]. Als Testsystem diente Windows Server 2022 auf VMware ESXi 8.0.2 [2]. Eine entfernte SQL-Datenbank braucht in dieser Konfiguration TLS und zusätzlich einen IPsec-Kanal, den der Windows-Host bereitstellt [3]. Hardware, Betriebssystem, Java und SQL Server gehören zur Umgebung und sind nicht mitzertifiziert [2].

Prüfgrenze des BSI-Zertifikats: UEM Core und Management Console im UEM Server 12.21.1; Clients, NOC/Router und Betriebsumgebung außerhalb.
Abbildung 1 — Das Zertifikat deckt nur UEM Server 12.21.1 ab: Core und Console auf einem Host, On-Premises.

Außerhalb dieser 12.21.1-Evaluierung liegen der UEM Client für Android und iOS, der MDM-Client von Apple und BEMS [3]. Hochverfügbarkeit mit mehreren redundanten Instanzen ist nicht Teil des geprüften Aufbaus [3]. UEM Cloud ist eine eigene Betriebsform, geprüft wurde On-Premises [3]. Die BlackBerry-Infrastruktur (NOC) und Router gehören zur Umgebung. Sie können den geschützten Kanal zwischen Server und Gerät nicht entschlüsseln, ihn aber stören oder umleiten [3]. Wie Gerät, App, Konto und Dynamics auf dem iPhone ineinandergreifen, zeigt Ein iPhone, vier Ebenen: Welche Regel greift?; das Zertifikat betrifft davon nur die Serverseite.

Dazu kommen Annahmen an deinen Betrieb: vertrauenswürdiges, geschultes Personal, Nutzer, die einen Geräteverlust sofort melden, regelmäßig gepflegte Geräte, eine verlässliche Zeitquelle, geschützte Protokolle und Plattformen mit Sicherheitsupdates [3]. Das Zertifikat setzt sie voraus, es prüft sie nicht bei dir. Maßgeblich für die Einrichtung ist die Administrationsanleitung der Evaluierung, AGD v1.14 vom 18.08.2025 [2]. Wenn ihr euch in einer Freigabe auf das Zertifikat beruft, gehören Security Target und diese Anleitung in eure Unterlagen.

Wann der Nachweis für eure Ausschreibung nicht reicht

Die Frist bis 07.09.2030 gilt für 12.21.1, nicht für jede spätere Version. Wenn ihr UEM 12.24 betreibt [14], liegt eure Version außerhalb dieses Nachweises, denn am BSI-Eintrag stehen am 13.10.2026 weder eine Maintenance noch eine Re-Zertifizierung für eine neuere Version [1]. Der Zertifizierungsreport verlangt für nicht zertifizierte Updates und Patches eine Risikobewertung, statt sie pauschal mit abzudecken [2]. Fordert eure Ausschreibung „ein gültiges BSI-Zertifikat für die angebotene Version“, erfüllt ein Angebot mit 12.24 diesen Satz wörtlich nicht.

Weitere Fälle, in denen der Nachweis nicht trägt:

  • Ihr plant UEM Cloud oder einen hochverfügbaren Aufbau mit mehreren Instanzen.
  • Die Anforderung zielt auf die Apps. Für Dynamics, Work und Access führen BSI-Liste, Common Criteria Portal und NIAP am 13.10.2026 kein aktuelles Zertifikat [5][6][19]. Das norwegische Zertifikat SERTIT-063 von 2015 für das Good Work System mit den damaligen App- und SDK-Versionen steht im Archiv [19][20].
  • Ihr braucht VS-NfD. Dann zählen Einsatzerlaubnis, Geräteplattform und Einsatzbedingungen des Gesamtsystems, und UEM steht nicht auf der BSI-Liste [4].
  • Eure Konfiguration weicht vom Security Target ab, etwa bei Datenbankanbindung oder Hostaufteilung.

Umgekehrt gilt: Verlangt ihr für den MDM-Server ein CC-Zertifikat nach den BSI-Schutzprofilen PP-0115 und PP-0116, ist BSI-DSZ-CC-1235-2025 ein passender, eng beschriebener Produktnachweis. Der EUCC-Übergang ändert daran nichts: Seit dem 27.02.2025 gilt das europäische Schema EUCC, nationale Zertifikate bleiben bis zum Ende ihrer Laufzeit gültig [15][16]. Ich würde das Kriterium deshalb so formulieren, dass Gegenstand, Schutzprofil und Versionsregel drinstehen: entweder die zertifizierte Version oder eine neuere mit Risikobewertung der Änderungen. Mit der zweiten Variante akzeptiert ihr bewusst eine Abweichung, die neuere Version wird dadurch nicht BSI-zertifiziert. Soll das Zertifikat ausdrücklich für die angebotene Version gelten, verlangt ihr dafür einen eigenen Eintrag beim BSI, etwa eine Maintenance oder Re-Zertifizierung. Dann wird aus dem Versionsabstand eine geregelte Entscheidung statt einer späteren Diskussion im Betrieb.

Was ein BSI-Nachweis in einer Souveränitätsbewertung zählt

Mit dem Cloud Sovereignty Framework der EU-Kommission (Version 1.2.1, Oktober 2025) taucht ein zweites Raster in Gesprächen auf [17]. Es ist für die Beschaffung von Cloud-Diensten durch die Kommission gemacht, nicht als Prüfschema für eine selbst betriebene UEM [17][18]. Die Kommission hat es im April 2026 in einem Vergabeverfahren mit der Mindeststufe SEAL-2 angewendet [18].

Der Rahmen bewertet acht Ziele, SOV-1 bis SOV-8, auf fünf Stufen von SEAL-0 „No Sovereignty“ bis SEAL-4 „Full Digital Sovereignty“. Die Vergabestelle legt je Ziel ein Mindestniveau fest und ergänzt einen gewichteten Score [17].

Ziel Gewicht Bewertet
SOV-1 Strategic 15 % Eigentum, Governance, Finanzierung
SOV-2 Legal & Jurisdictional 10 % Rechtsordnung, Zugriffsrechte fremder Staaten
SOV-3 Data & AI 10 % Kontrolle über Daten, Schlüssel und KI
SOV-4 Operational 15 % Betrieb, Support, Wechselbarkeit
SOV-5 Supply Chain 20 % Herkunft von Komponenten und Software
SOV-6 Technology 15 % Offenheit, Interoperabilität, Abhängigkeiten
SOV-7 Security & Compliance 10 % Zertifizierungen, EU-Rechtskonformität, Security-Betrieb, Auditierbarkeit
SOV-8 Environmental Sustainability 5 % Energie, Ressourcen, Lebenszyklus

Ein Common-Criteria-Zertifikat passt zum Faktor Zertifizierungen in SOV-7, ein bestimmtes Zertifikat nennt der Rahmen dort nicht [17]. Rechtsordnung, Lieferkette, Betrieb und Schlüsselkontrolle bewertet er eigenständig, und dazu sagt ein Produktzertifikat nichts. Eine Selbsteinstufung eines Herstellers ist keine Bewertung durch eine Vergabestelle. Nutzt ihr den Rahmen als Fragenkatalog für eine eigene Bewertung, brauchen die übrigen sieben Ziele und der Rest von SOV-7 eigene Belege.

So prüfst du den Nachweis jedes Anbieters selbst

Mit dieser Reihenfolge prüfst du jede Zertifikatsangabe, ob sie von BlackBerry, Ivanti, Microsoft oder Omnissa kommt.

  1. Nummer verlangen. Ohne Zertifikats- oder Zulassungsnummer lässt sich nichts nachschlagen. Ein Logo im Datenblatt ersetzt sie nicht.
  2. Im Register öffnen, nicht im Datenblatt. BSI-Zertifikate stehen in der BSI-Liste zertifizierter Produkte [5], internationale CC-Zertifikate im Common Criteria Portal [19], US-Prüfungen in der NIAP-Liste [6]. Lies Produkt, Version, Schutzprofil, Ausstellungsdatum, Frist und Status ab. Schau, ob Maintenance oder Re-Zertifizierung für neuere Versionen eingetragen ist.
  3. Security Target gegen euren Betrieb legen. Prüfgegenstand, ausgeschlossene Komponenten, Betriebsform und Umgebungsannahmen entscheiden, ob der Nachweis für eure Installation spricht. Die zugehörige Administrationsanleitung gehört dazu.
  4. VS-NfD getrennt prüfen. In der BSI-Liste zugelassener Produkte zählen Produkt, Nachweisart, Version, Einstufung und Befristung [4]. Die Einsatzbedingungen holt ihr als berechtigte Stelle über das BSI.
  5. FIPS am Modul prüfen. In der CMVP-Suche des NIST zählen Modulname, Modulversion, getestete Umgebung und Status [9]. Ein Eintrag unter „Modules In Process“ ist ein laufendes Verfahren [11]. Lass dir zeigen, welches Modul in welcher Produktversion steckt.

Was du jetzt entscheidest

Drei Entscheidungen stehen am Anfang. Brauchst du einen Produktnachweis für den MDM-Server oder eine Einsatzfreigabe für VS-NfD? Das sind zwei verschiedene Verfahren. Welche UEM-Version wollt ihr betreiben, und wie geht ihr mit dem Abstand zur zertifizierten Version um? Und welche Teile außerhalb des Servers, also Clients, Apps, Cloud und Hochverfügbarkeit, müssen eigene Nachweise bringen? Wenn diese drei Antworten im Kriterienkatalog stehen, prüft eure Vergabestelle Angebote an Registerdaten statt an Schlagworten.

Stand und Quellen

Geprüft am 13. Oktober 2026 · BlackBerry UEM Server 12.21.1 (zertifizierte Version) · BlackBerry UEM 12.24 (aktuelle Dokumentation) · Registerstand 13.10.2026

  1. BSI: BlackBerry UEM Server, BSI-DSZ-CC-1235-2025, Ausstellungsdatum, Frist, Prüftiefe.
  2. BSI: Zertifizierungsreport BSI-DSZ-CC-1235-2025, 08.09.2025, Abschnitte A.3–A.5 und B.1–B.10.
  3. BlackBerry: Security Target for BlackBerry UEM Server, Version 1.9 vom 18.08.2025, Abschnitte 1.3, 1.5, 2.1, 3.3 und 4.2.
  4. BSI: Liste zugelassener IT-Sicherheitsprodukte und -systeme (BSI-Schrift 7164), Registerstand 13.10.2026.
  5. BSI: Zertifizierte Produkte nach Common Criteria.
  6. NIAP: Product Compliant List und Archived Products.
  7. NIAP: SecuSUITE Server 6.0, Validation Report, VID11634, 27.01.2026.
  8. NATO NIAPC: BlackBerry UEM Server and Android Client v12.
  9. NIST CMVP: Zertifikat #4575, Security Builder FIPS Java Module.
  10. NIST CMVP: Zertifikat #4267, Security Builder FIPS Module.
  11. NIST CMVP: Modules In Process.
  12. NIST: Cryptographic Module Validation Program, Abschnitt zum Auslaufen von FIPS 140-2.
  13. BlackBerry Dynamics SDK für iOS 15.x: Release Notes, Abschnitt zum FIPS-Upgrade.
  14. BlackBerry UEM 12.24: Dokumentation.
  15. EU: Durchführungsverordnung (EU) 2024/482 (EUCC), Artikel 49 und 50.
  16. EU: Verordnung (EU) 2019/881 (Cybersecurity Act), Artikel 57 Absatz 3.
  17. Europäische Kommission: Cloud Sovereignty Framework, Version 1.2.1, Oktober 2025.
  18. Europäische Kommission: Commission advances cloud sovereignty through strategic procurement, 17.04.2026.
  19. Common Criteria Portal: Certified Products, aktuelle und archivierte Einträge.
  20. SERTIT: Good Work System, Certification Report, 09.12.2015.
  21. Common Criteria: CC:2022 Part 5, Pre-defined packages of security requirements, Abschnitt 4.4, Evaluation Assurance Levels.
  22. Common Criteria: CC:2022 Part 3, Security assurance components, Abschnitt 12.6.6, ALC_FLR.3.