Ein Satz, den ich in Beratungsgesprächen immer wieder höre: „Wir wollen eigene Schlüssel für Microsoft 365.“ Das klingt zunächst eindeutig. Aber wenn ich dann nachfrage, was genau damit gemeint ist, zeigt sich schnell, dass drei verschiedene Konzepte hinter dieser Aussage stecken können – und dass die Unterschiede erheblich sind.

BYOK, Customer Key und Double Key Encryption (DKE) werden in Projekten, Ausschreibungen und Compliance-Gesprächen oft in einen Topf geworfen. Alle drei haben mit Verschlüsselung und Schlüsselkontrolle zu tun – aber sie greifen an unterschiedlichen Stellen in die Plattform ein, lösen unterschiedliche Probleme und bringen unterschiedliche Betriebslasten mit sich. Wer sie als austauschbar behandelt, trifft möglicherweise die falsche Architekturentscheidung.

BYOK: der eigene Root Key für Azure Rights Management

BYOK steht in diesem Kontext für das Modell, bei dem eine Organisation ihren eigenen Mandantenstammschlüssel für den Azure Rights Management-Dienst von Microsoft Purview Information Protection bereitstellt – statt den von Microsoft generierten Standardschlüssel zu verwenden. Microsoft dokumentiert BYOK ausdrücklich für diesen Root Key des Azure Rights Management Service.^[1]

Es geht also nicht pauschal um „den ganzen Tenant“, sondern um den kryptografischen Schlüssel, der für Rights-Management-basierte Schutzfunktionen verwendet wird. Schlüssel werden aus einer externen Umgebung in Azure Key Vault eingebracht – On-Premises-HSM ist heute nur noch als Quelle bei Migrationen relevant.

Der Nutzen liegt vor allem in Schlüsselkontrolle, Nachvollziehbarkeit und Compliance. Unternehmen können den Stammschlüssel selbst erzeugen und über Azure Key Vault einbringen; Microsoft dokumentiert zudem Nutzungsprotokollierung für BYOK. Für regulierte Organisationen ist das relevant, weil sich damit besser nachweisen lässt, wer die Hoheit über den Schlüssel hat.

Gleichzeitig ist BYOK kein Allheilmittel gegen technischen Plattformzugriff: Autorisierte Personen und Dienste – etwa für Suche und Indexierung – können weiterhin auf geschützte Daten zugreifen und sie verarbeiten. BYOK stärkt die Kontrolle über den Schlüssel für Rights-Management-Schutz, macht aber nicht jede Microsoft-365-Verarbeitung kryptografisch unmöglich.

Praktisch bedeutet das auch: Wer sich für BYOK entscheidet, holt sich zusätzliche Verantwortung ins Haus. Azure Key Vault, Schlüsselverwaltung und die dazugehörigen Betriebsprozesse werden relevante Abhängigkeiten. BYOK ist deshalb weniger eine Komfortfunktion als eine bewusste Entscheidung für mehr Eigenverantwortung im Schlüsselmanagement.

Customer Key: Root Keys für die Service Encryption in Microsoft 365

Customer Key geht einen anderen Weg. Hier stellt die Organisation ebenfalls eigene Schlüssel bereit – aber nicht primär für Rights-Management-Schutz einzelner Inhalte, sondern für die Service Encryption von Daten in Microsoft 365. Microsoft beschreibt Customer Key als Lösung, bei der Kunden die Root Keys bereitstellen, während Microsoft die übrigen Schlüssel innerhalb der Verschlüsselungshierarchie verwaltet.^[2]

In der aktuellen Dokumentation nennt Microsoft dafür Daten aus Exchange, SharePoint, OneDrive, Teams sowie Windows 365 Cloud PCs. Customer Key arbeitet also näher an der Datenverschlüsselung der Microsoft-365-Workloads im Rechenzentrum als BYOK für Azure Rights Management.

Der eigentliche Mehrwert liegt in der organisatorischen Hoheit über die Root Keys für ruhende Daten. Unternehmen können festlegen, welche Schlüssel bestimmte Daten in Microsoft-365-Workloads verschlüsseln; dafür werden sogenannte Data Encryption Policies eingerichtet und zugewiesen. Für viele regulierte Organisationen ist das der Punkt, an dem Microsoft 365 deutlich besser in interne Kontrollmodelle passt: Man überlässt Microsoft weiterhin den Betrieb des Dienstes, legt aber die Wurzel der Verschlüsselung bewusst in kundenkontrollierte Azure-Schlüssel.

Gleichzeitig bleibt Customer Key ein Modell innerhalb der Microsoft-Servicearchitektur. Microsoft formuliert das selbst so, dass Customer Key die vorhandene Dienstverschlüsselung ergänzt^[2] – es ist also mehr Kontrolle über „Data at Rest“, aber keine vollständige Entkopplung von der Plattformlogik oder der Dienstverarbeitung.

Gerade deshalb ist die Kehrseite besonders wichtig: Customer Key ist eine mächtige Funktion mit spürbaren betrieblichen Risiken. Microsoft warnt in der aktuellen Setup-Dokumentation, dass Fehler bei diesen Schlüsseln zu Dienstunterbrechungen oder dauerhaftem Datenverlust führen können.^[2] Wer Customer Key einführt, muss Schlüssellebenszyklus, Backup, Rotation, Berechtigungen und Notfallverfahren sehr diszipliniert beherrschen. Es ist keine Funktion, die man „nur für etwas mehr Sicherheit“ nebenbei aktiviert, sondern ein Governance- und Betriebsmodell mit echten Konsequenzen.

Double Key Encryption: wenn selbst Microsoft nicht entschlüsseln können soll

Double Key Encryption (DKE) ist schließlich die speziellste der drei Varianten. Microsoft beschreibt DKE als Schutzmechanismus für hochgradig sensible Daten, bei dem zwei Schlüssel nötig sind: ein Schlüssel unter Kontrolle des Kunden und ein zweiter Schlüssel, der in Microsoft Azure gespeichert wird. Der Zugriff auf DKE-geschützte Inhalte ist nur möglich, wenn beide Schlüssel verfügbar sind.^[3]

Genau damit unterscheidet sich DKE konzeptionell von BYOK und Customer Key: Es geht hier nicht in erster Linie um zusätzliche Kontrolle über ruhende Daten im Rechenzentrum, sondern um ein Schutzmodell für besonders schützenswerte Inhalte, bei dem Microsoft allein den Inhalt nicht entschlüsseln kann.

Gerade weil DKE stärker abschottet, ist es aber auch die Variante mit den klarsten funktionalen Einschränkungen. DKE arbeitet mit Sensitivity Labels und setzt den Azure Rights Management Service voraus. Unterstützt wird DKE für die Desktop-Versionen von Word, Excel, PowerPoint und Outlook unter Windows. Externe Anwendungen oder Dienste, die nicht über das Microsoft Information Protection SDK integriert sind, können auf DKE-verschlüsselten Daten keine Aktionen ausführen.

Und ein für viele Organisationen besonders relevanter Punkt: Copilot ist bei der Verwendung von DKE-verschlüsselten Daten in Office aktuell nicht zugänglich.^[3] Genau hier zeigt sich der Preis maximaler Schlüsselhoheit: Je stärker Inhalte kryptografisch gegen die Plattform abgeschottet werden, desto mehr moderne Cloud-Funktionen, Integrationen und Verarbeitungsdienste fallen weg oder sind nur eingeschränkt nutzbar.

Die drei Modelle im Vergleich

Um es bildlich darzustellen: Man stelle sich Microsoft 365 wie ein Gebäude vor.

• BYOK bedeutet: „Ich bringe meinen eigenen Generalschlüssel für einen bestimmten Raum mit.“
• Customer Key bedeutet: „Ich bestimme die Hauptschlüssel für das ganze Gebäude.“
• Double Key Encryption bedeutet: „Dieser Raum lässt sich nur öffnen, wenn ich persönlich dabei bin – niemand sonst kommt allein rein.“

Wenn man die drei Modelle nüchtern nebeneinanderlegt, ergibt sich ein klares Bild:

	BYOK	Customer Key	Double Key Encryption
Anwendungsbereich	Root Key für Azure RMS / Purview Information Protection	Service Encryption für M365-Workloads (Exchange, SharePoint, OneDrive, Teams)	Besonders schützenswerte Inhalte (Dokumente, E-Mails)
Schlüsselhoheit	Kundenseitig via Azure Key Vault	Kundenseitig via Azure Key Vault	Kundenseitig (externer Key Service) + Microsoft Azure
Microsoft kann entschlüsseln?	Ja, für autorisierte Dienste	Ja, im Rahmen der Servicearchitektur	Nein (beide Schlüssel erforderlich)
Funktionale Einschränkungen	Gering	Gering	Erheblich (kein Copilot, eingeschränkte App-Unterstützung)
Betriebsaufwand	Mittel	Hoch	Hoch

Die eigentliche Architekturentscheidung

Für die Praxis bedeutet das: Wer vor allem Compliance, Schlüsselkontrolle und zusätzliche Absicherung für ruhende Daten sucht, wird meist zuerst auf Customer Key schauen. Wer informationsschutzbezogene Szenarien mit eigenem Tenant Root Key für Rights Management braucht, landet bei BYOK. Und wer regulatorisch oder organisatorisch eine Grenze braucht, bei der hochsensible Inhalte nur mit einem kundenkontrollierten externen Schlüssel lesbar bleiben, muss DKE prüfen – sollte dann aber sehr bewusst akzeptieren, dass genau diese stärkere Kontrolle bestimmte Komfort- und KI-Funktionen sowie manche Integrationen ausschließt.

Die eigentliche Architekturentscheidung ist deshalb nicht: „Welche Verschlüsselung ist die sicherste?“ Sondern: „Wie viel Plattformfunktionalität bin ich bereit aufzugeben, um an welcher Stelle welche Art von Schlüsselhoheit zu gewinnen?“

BYOK und Customer Key stärken Kontrolle innerhalb des Microsoft-Betriebsmodells. DKE verschiebt die Grenze stärker gegen das Microsoft-Betriebsmodell – und nimmt dafür bewusst funktionale Einbußen in Kauf. Wer das versteht, kann eine fundierte Entscheidung treffen. Wer die drei Modelle verwechselt, riskiert entweder zu wenig Kontrolle für die eigenen Anforderungen – oder zu viele Einschränkungen für den laufenden Betrieb.

Quellen

1. Microsoft Learn: BYOK pricing and restrictions for Azure Information Protection
2. Microsoft Learn: Service encryption with Microsoft Purview Customer Key
3. Microsoft Learn: Double Key Encryption (DKE)