MS365 | Tenant anlegen & sicher konfigurieren

Ein neuer Microsoft 365 Tenant ist technisch in wenigen Minuten erstellt. Über signup.microsoft.com richtest du ihn ein. Vor der Registrierung legst du den Tenant-Typ fest, denn davon hängt ab, welche Lizenzmodelle, Verwaltungsrechte und Compliance-Einstellungen dir später zur Verfügung stehen. Microsoft Entra ID, das Microsoft 365 Admin Center und die gebuchten Dienste stehen danach sofort bereit.

Für den produktiven Einsatz reicht dieser Zustand nicht aus, weil die Registrierung Entscheidungen festlegt, die sich später nur schwer oder gar nicht korrigieren lassen: das Land der Organisation, die initiale onmicrosoft.com-Domäne, der SharePoint-Namensraum, die administrativen Identitäten und die Sicherheitsarchitektur.

Microsoft liefert neue Tenants mit Basisschutz aus. Dieser ersetzt keine durchdachte Konfiguration für Identitäten, E-Mail, Geräte, Datenresidenz, Compliance und Netzwerkzugriff.

Die wichtigsten Punkte vorab:

Ein Microsoft 365 Tenant ist keine einzelne Anwendung und kein klassischer Servermandant. Er bildet die gemeinsame Identitäts-, Verwaltungs- und Vertrauensgrenze deiner Organisation in der Microsoft Cloud. Dienste wie Exchange Online, SharePoint Online, Teams, Intune oder Microsoft Defender greifen auf dieses zentrale Verzeichnis zu, besitzen aber eigene Datenbestände, Konfigurationen und Berechtigungsmodelle.

Bei der Registrierung entstehen unter anderem:

Sobald SharePoint Online und OneDrive provisioniert sind, entsteht der gemeinsame SharePoint-Namensraum, etwa https://tenantname.sharepoint.com und https://tenantname-admin.sharepoint.com. Eine später hinzugefügte Unternehmensdomain wie firma.de ändert diese URLs nicht.

Die Tenant-ID ist eine GUID und der dauerhaft wichtigste Identifikator der Umgebung, weil sie das Verzeichnis bei Microsoft Graph, App-Registrierungen, OAuth-Anmeldungen, Azure-Abonnements, PowerShell-Verbindungen und B2B-Beziehungen identifiziert. Anzeigename, Fallbackdomäne und SharePoint-Namensraum lassen sich teilweise ändern. Die Tenant-ID bleibt bestehen.

Per Microsoft Graph PowerShell liest du das Organisationsobjekt aus:

Die Eigenschaft Id entspricht der Tenant-ID. VerifiedDomains zeigt die initiale onmicrosoft.com-Domäne und alle später verifizierten Unternehmensdomains samt Kennzeichnung als initiale oder standardmäßige Domain.

Was Microsoft bei der Provisionierung im Hintergrund im Einzelnen anlegt, liest du im ausführlichen Beitrag: Microsoft 365: Was passiert bei einem neuen Tenant

Bevor du einen neuen Tenant anlegst, musst du klären, ob für deine Organisation oder eine ihrer Domains bereits ein Entra-Verzeichnis existiert. Ein unbekannter Bestandstenant fällt oft erst auf, wenn sich die Unternehmensdomain im neuen Tenant nicht verifizieren lässt, denn eine verifizierte Domain kann nur einem Microsoft Entra Tenant gleichzeitig zugeordnet sein.

Solche Strukturen entstehen auch ohne frühere Microsoft-365-Verträge. Registriert sich ein Mitarbeiter mit seiner geschäftlichen E-Mail-Adresse eigenständig für einen Microsoft Cloud-Dienst, etwa Fabric oder Power BI, legt Microsoft ein nicht verwaltetes Entra-Verzeichnis an (Unmanaged, Shadow oder Viral Tenant). Dieses Verzeichnis besitzt zunächst keinen Global Administrator.

Prüfe vor der Neuanlage:

Liegt die Domain in einem verwalteten Tenant, muss sie dort vollständig entfernt werden. Dafür darf kein Benutzer, keine Gruppe, keine ProxyAddress und keine Anwendung die Domain mehr verwenden.

Bei einem nicht verwalteten Tenant führst du abhängig vom Dienst eine interne Übernahme durch (du wirst Administrator des vorhandenen Verzeichnisses) oder eine externe Übernahme (die Domain wandert in deinen verwalteten Tenant). Die externe Variante wird nicht von allen Diensten und Konstellationen unterstützt. Aus Sicherheitsgründen verlangt Microsoft dabei den Nachweis der Organisations- und Domaininhaberschaft.

Du kannst den Tenant direkt bei Microsoft registrieren oder über einen Cloud Solution Provider (CSP) beziehen. Die technische Basis bleibt identisch: Der Tenant gehört deiner Organisation und verwendet ein eigenes Entra-Verzeichnis. Der Bezugsweg beeinflusst Lizenzabrechnung, Vertragslaufzeiten, Support und administrative Partnerzugriffe.

Ein CSP lohnt sich, wenn du flexible Lizenzmengen, einen deutschsprachigen Supportweg oder eine gemeinsame Betreuung von Microsoft 365 und Azure benötigst. Kläre vorab, ob der Anbieter direkte oder indirekte CSP-Beziehungen nutzt, weil der Support bei indirekten Resellern über einen zusätzlichen Distributor laufen kann.

Eine Reseller-Beziehung rechtfertigt keinen dauerhaften Vollzugriff auf deinen Tenant. Administrative Partnerzugriffe gehören ausschließlich über Granular Delegated Admin Privileges (GDAP) abgebildet, weil GDAP klar definierte Entra-Rollen mit begrenzter Laufzeit erzwingt und von dir ausdrücklich genehmigt werden muss.

Für Exchange-Arbeiten genügt eine passende Exchange-Rolle, ein dauerhafter Global-Administrator-Zugriff ist nicht erforderlich. Dokumentiere Partner, Vertragsmodell, zugewiesene GDAP-Rollen samt Laufzeit, Ansprechpartner und den Prozess zur regelmäßigen Entfernung nicht mehr benötigter Zugriffe.

Wer bereits über einen Microsoft 365 Tenant verfügt und dort administrative Rechte besitzt, kann über das Azure Portal nicht nur zwischen bestehenden Tenants wechseln, sondern auch einen komplett neuen Tenant anlegen.

Alle anderen Wege der Ersteinrichtung, etwa Trial-Version, PowerBI-Signup oder Self-Service-Registrierung, erfordern, dass der Kunde selbst aktiv wird. Der Tenant-Name, der später bei SharePoint als tenantname.sharepoint.com und bei OneDrive als tenantname-my.sharepoint.com sichtbar wird, leitet sich bei diesen Wegen teilweise direkt von der SMTP-Domain ab. Das wird zum Problem, wenn der abgeleitete Name nicht zur gewünschten Außendarstellung passt.

Ob es für die Anlage neuer Tenants über das Azure Portal Obergrenzen gibt, etwa für neue Tenants pro Zeitraum oder Tenants insgesamt, ist bislang nicht dokumentiert oder ich fand nirgends dazu was.

Als Administrator startest du das Azure Portal über https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview und wählst dort "Manage Tenants".

Über "Create" öffnest du den Dialog zur Tenant-Anlage. Dieser zeigt dir zunächst alle Tenants, in denen du bereits als Administrator hinterlegt bist, denn ein Gast-Benutzer kann in einem fremden Tenant durchaus administrative Rechte besitzen oder dort als Mitglied arbeiten. An dieser Stelle geht es aber nicht um einen Tenant-Wechsel, sondern um die Neuanlage.

Verzeichnistyp wählen

An dieser Stelle zeigt Microsoft Entra ID inzwischen drei Konfigurationen statt der früheren Zwei-Wege-Auswahl zwischen klassischem Azure AD und B2C. Die Auswahl richtet sich danach, welche Art von Benutzern, Anwendungen und Ressourcen du verwalten willst.

Wichtig für die Planung: Ab dem 15. August 2026 lassen sich Add-On-Mitarbeitertenants nur noch über die Oberfläche "Verwaltete Mitarbeitende" anlegen. Wer jetzt einen Tenant für einen Kunden vorbereitet, sollte diese Umstellung bei der Wahl der Konfiguration bereits berücksichtigen, da ein späterer Wechsel der Konfiguration nach der Anlage nicht ohne Weiteres möglich ist.

Eine ausführliche Entscheidungshilfe zu den drei Konfigurationen liefert Microsoft unter aka.ms/ExternalID/TenantConfig.

Name und Region festlegen

Bei diesem Schritt lohnt sich Sorgfalt, denn der "Initial domain name" erscheint später unter anderem bei tenantname.sharepoint.com und lässt sich danach nicht mehr ändern. Ist der Wunschname bereits vergeben, meldet das Portal das sofort. Die Region lässt sich ebenfalls nachträglich nicht mehr anpassen. Einzig der "Organization name" bleibt später änderbar.

Ist der gewünschte Domainname bereits belegt, lohnt sich ein Blick auf den aktuellen Inhaber. Per Skript lässt sich zumindest der hinterlegte Organization Name und eventuelle Zusatzdomains ermitteln. Möglich ist auch, dass es sich um einen viralen Tenant oder einen PowerBI-Tenant handelt, den du unter Umständen übernehmen kannst, oder schlicht um eine andere Konzerngesellschaft, die bei der Registrierung schneller war.

Einstellungen bestätigen

Vor der finalen Anlage zeigt Microsoft Entra ID die gewählten Einstellungen noch einmal zur Kontrolle. Der Name ist ab diesem Zeitpunkt für mindestens 180 Tage reserviert.

Captcha-Verifikation

Bei der Anlage eines PowerBI-Tenants oder Trial-Tenants verlangt Microsoft zusätzlich den Identitätsnachweis per Rufnummer, Mailadresse und SMS. Dieser Schritt entfällt beim Weg über das Azure Portal, da du durch deine bestehende Anmeldung bereits authentifiziert bist. Ein einfaches Captcha bleibt trotzdem Pflicht. Nach der Bestätigung dauert die eigentliche Anlage einige Minuten.

Abschluss

Sobald der Tenant erstellt ist, ändert sich die Anzeige im Portal, und ein Link führt direkt in das Microsoft Entra ID des neuen Tenants. Der neue Tenant ist zu diesem Zeitpunkt noch weitgehend leer und erscheint ab sofort auch in der eigenen Tenant-Liste im Portal.

Bei der Registrierung legst du das Land der Organisation fest. Diese Auswahl bestimmt die Tenant Default Geography und beeinflusst verfügbare Dienste, Besteuerung, Abrechnungswährung, Vertragsbedingungen und die geografische Bereitstellung der Workloads. Die Auswahl lässt sich später nicht ändern. Wurde das falsche Land hinterlegt, verlangt Microsoft die Erstellung eines neuen Tenants mit anschließendem Umzug der Benutzer und Daten. Für ein Unternehmen mit rechtlichem Hauptsitz in Deutschland wählst du deshalb Deutschland, nicht den Standort des CSP-Partners oder einer ausländischen Konzernzentrale.

Die Default Geography bedeutet nicht, dass sämtliche Daten in einem einzelnen deutschen Rechenzentrum liegen. Exchange Online, SharePoint, OneDrive, Teams, Entra ID, Defender, Purview und Copilot besitzen eigene Bereitstellungs- und Datenresidenzmodelle. Microsoft unterscheidet deshalb drei Begriffe:

Während einer Migration können Current und Committed Geography voneinander abweichen. Den Status prüfst du pro Workload im Admin Center.

Für strengere Anforderungen bietet Microsoft Advanced Data Residency (ADR). Das kostenpflichtige Add-on erweitert die Datenresidenzzusagen für definierte Dienste wie Exchange Online, SharePoint, OneDrive, Teams, Copilot und ausgewählte Purview-Funktionen. ADR setzt eine berechtigte Tenant-Geografie und eine vollständige Lizenzabdeckung aller relevanten kostenpflichtigen Arbeitsplätze voraus. Fehlt die Abdeckung dauerhaft, kann die zugesagte lokale Datenresidenz entfallen.

Die initiale Domäne im Format unternehmen.onmicrosoft.com wird bei der Tenant-Erstellung angelegt und kann nicht gelöscht werden. Du kannst später weitere onmicrosoft.com-Domänen hinzufügen und eine davon als Fallbackdomäne festlegen. Microsoft begrenzt die Gesamtzahl auf fünf onmicrosoft.com-Domänen pro Tenant, und auch nachträglich angelegte lassen sich nicht mehr entfernen.

Der erste Name bleibt technisch relevant, weil er initiale Anmeldenamen, Standard-E-Mail-Adressen während der Einrichtung, SharePoint- und OneDrive-URLs, administrative Endpunkte, Skripte und externe Freigabelinks prägt. Der Domänenpräfix muss global eindeutig sein.

Verwende einen kurzen, neutralen und langfristig brauchbaren Namen. Vermeide Rechtsformen, Jahreszahlen, Produktnamen, Standortbezeichnungen, Personennamen und Testkennzeichnungen im späteren Produktionstenant. Bei einer Unternehmensgruppe ist ein neutraler Holdingname oft sinnvoller als der Name einer einzelnen Tochtergesellschaft.

Geeigneter: contosogroup.onmicrosoft.com. Weniger geeignet: contoso-gmbh-hauptsitz-berlin-2026.onmicrosoft.com.

Microsoft unterstützt die nachträgliche Umbenennung der SharePoint- und OneDrive-Domäne, etwa von https://altefirma.sharepoint.com zu https://neuefirma.sharepoint.com. Die Möglichkeit ersetzt keine saubere Planung, weil die Umbenennung alle Sites und OneDrive-Konten betrifft. Sites werden nacheinander umgestellt und können währenddessen vorübergehend nicht erreichbar sein.

Die Rahmenbedingungen im Detail:

Die Domain-Umbenennung ändert keine E-Mail-Adressen. Plane den SharePoint-Namen deshalb so, als wäre er dauerhaft.

Die onmicrosoft.com-Domäne eignet sich für technische Zwecke. Für Benutzeranmeldungen und E-Mail-Adressen gehört im produktiven Betrieb eine Unternehmensdomain in den Tenant, etwa andreas.hepp@firma.de.

Füge die Domain vor dem Anlegen der produktiven Benutzer hinzu, weil du dir dadurch spätere Änderungen an UPNs, E-Mail-Adressen und Anmeldedaten ersparst. Microsoft fordert zur Verifizierung normalerweise einen TXT-Eintrag im öffentlichen DNS mit einem generierten Wert nach dem Muster MS=ms12345678.

Erfasse neben der aktuellen primären E-Mail-Domain auch frühere Firmennamen, Markendomains, Tochtergesellschaften, internationale Domains und Domains übernommener Unternehmen. Durch die frühzeitige Zuordnung verhinderst du, dass Benutzer mit Firmenadressen unverwaltete Microsoft-Umgebungen erzeugen. Dokumentiere jede Domain:

Der Einrichtungsassistent kann abhängig vom Registrar eine automatische Konfiguration anbieten. Für bestehende Unternehmensdomains belässt du die DNS-Zone besser beim vorhandenen Provider und trägst nur die benötigten Records ein, weil eine vollständige Nameserver-Delegation Webseite, VPN-Endpunkte, Subdomains, Zertifikatsvalidierung, Drittanbieter-Maildienste und API-Endpunkte treffen kann. Exportiere vor Änderungen die vorhandene Zone.

Für Exchange Online benötigst du mindestens MX-Record, Autodiscover-CNAME und SPF-TXT-Record. Der MX-Record zeigt auf einen Endpunkt nach dem Muster firma-de.mail.protection.outlook.com. Stelle ihn erst um, wenn alle Zielpostfächer vorhanden sind, das Mailrouting getestet ist, SPF und DKIM vorbereitet sind, Connectoren stehen, Applikationen und Multifunktionsgeräte berücksichtigt wurden und Rückfallplan samt TTL geprüft sind.

Ältere Einrichtungsanleitungen empfehlen oft noch DNS-Einträge für Skype for Business und klassische Federation. Setze solche Records nicht automatisch, weil unnötige Einträge spätere Fehleranalysen erschweren. Der Domain-Assistent zeigt die aktuell benötigten Einträge für die ausgewählten Dienste an.

Eine neue Domain braucht mehr als einen MX-Record, weil Empfängersysteme die Authentizität deiner Absenderdomain sonst nicht prüfen können und legitime Mails im Spam landen oder Angreifer deine Domain fälschen.

SPF definiert, welche Systeme im Namen deiner Domain senden dürfen. Für eine reine Exchange Online Umgebung lautet der typische Eintrag:

Pro Domain darf nur ein SPF-Record existieren. Weitere Versanddienste wie Newsletteranbieter, Ticketsysteme, ERP-Systeme oder Scanner müssen in denselben Record integriert werden. Beachte das SPF-Limit von zehn DNS-Lookups: Zu viele verschachtelte Includes führen zu PermError, und die SPF-Prüfung schlägt fehl.

DKIM versieht ausgehende Nachrichten mit einer kryptografischen Signatur, wodurch der Empfänger prüfen kann, ob die Nachricht unterwegs verändert wurde und ob ein autorisierter Dienst sie signiert hat. Für Exchange Online legst du zwei CNAME-Records an und aktivierst DKIM anschließend im Microsoft Defender Portal oder per PowerShell.

DMARC verbindet SPF und DKIM mit einer Richtlinie für fehlgeschlagene Prüfungen. Starte nicht sofort mit p=reject, solange du nicht alle legitimen Absender kennst, weil sonst gewünschte Mails abgewiesen werden. Beginne mit p=none, werte die DMARC-Berichte aus, um vergessene Absender zu finden, wechsle dann zu p=quarantine und erst am Ende zu p=reject als stärkstem Schutz gegen Domain-Spoofing.

Der Benutzer, der den Tenant erstellt, erhält weitreichende administrative Rechte. Dieses Konto darf nicht dauerhaft als persönliches Produktivkonto dienen, weil sonst jede Phishing-Mail im Alltagspostfach direkt privilegierte Rechte gefährdet. Erstelle für jeden Administrator getrennte Identitäten, zum Beispiel andreas.hepp@firma.de für Outlook, Teams und Dokumente sowie adm.andreas.hepp@tenantname.onmicrosoft.com für Admin Center, Defender, Purview, PowerShell und Microsoft Graph.

Das Administratorkonto sollte Cloud-only sein und die onmicrosoft.com-Domäne verwenden. Dadurch bleibt es unabhängig vom lokalen Active Directory, von Microsoft Entra Connect, von Föderationsdiensten und von On-Premises-Kompromittierungen. Genau diese Unabhängigkeit brauchst du, wenn die hybride Identitätskette ausfällt oder angegriffen wird.

Die Rolle Global Administrator besitzt nahezu vollständige Kontrolle über den Tenant. Microsoft empfiehlt, sie weniger als fünf Personen zuzuweisen. In der Praxis bewähren sich maximal zwei permanente Zuweisungen, der Rest läuft über spezialisierte Rollen wie Exchange Administrator, SharePoint Administrator, Intune Administrator, Security Administrator, User Administrator oder Conditional Access Administrator. Mit Entra ID P2 setzt du Privileged Identity Management ein: Rollen sind berechtigt, werden aber erst bei Bedarf zeitlich begrenzt aktiviert. Eine PIM-Aktivierung sollte abhängig vom Schutzbedarf MFA, eine Begründung, eine Ticketnummer, eine Genehmigung und eine begrenzte Aktivierungsdauer verlangen und im Audit-Protokoll landen.

Direkt nach der Anlage gehören auch die Organisationseinstellungen auf den Prüfstand, weil viele Defaults für Komfort statt Sicherheit optimiert sind. Deaktiviere den User Consent für Apps, unterbinde App-Registrierungen durch Standardbenutzer, schränke die Gruppenerstellung ein und kontrolliere Self-Service-Registrierungen. Jede offene Standardeinstellung vergrößert die Angriffsfläche für OAuth-Consent-Phishing.

Microsoft empfiehlt mindestens zwei Emergency-Access-Konten, weil eine fehlerhafte Conditional-Access-Richtlinie, ein MFA-Ausfall oder eine defekte Föderation sonst den gesamten Tenant sperren kann. Diese Konten müssen Cloud-only sein, die onmicrosoft.com-Domäne verwenden, dauerhaft aktiv als Global Administrator zugewiesen sein (in PIM aktiv statt berechtigt), keiner einzelnen Person zugeordnet werden und dürfen nicht für die tägliche Administration dienen.

Ein langes Kennwort ohne weitere Schutzmaßnahme reicht als Zielbild nicht mehr aus. Microsoft empfiehlt phishing-resistente Methoden, konkret FIDO2-Sicherheitsschlüssel oder zertifikatbasierte Authentifizierung, und zwar mit anderen Methoden als bei den normalen Administratorkonten. Der Grund: Auch Emergency-Access-Konten werden von der verpflichtenden MFA-Durchsetzung für Microsoft-Verwaltungszugriffe erfasst, und Passkey (FIDO2) sowie zertifikatbasierte Authentifizierung erfüllen diese Anforderung zuverlässig.

Aus dem Ausschluss aus blockierenden Conditional-Access-Richtlinien folgt nicht, dass die Konten ungeschützt bleiben. Ein sinnvoller Aufbau kombiniert den Ausschluss aus blockierenden Richtlinien (Richtlinien im Modus Nur Bericht benötigen keinen Ausschluss) mit phishing-resistenter Authentifizierung direkt am Konto, sofortiger Alarmierung bei jeder Anmeldung und bei jeder Änderung an Kennwort oder Authentifizierungsmethoden, ohne produktive Lizenz, ohne Postfach und ohne App-Zustimmungen.

Die Zugangsmittel lagerst du getrennt und brandsicher. Beide Konten dürfen nicht vom selben Gerät, demselben Tresor und derselben verantwortlichen Person abhängen, weil sonst ein einzelner Ausfall beide Notfallzugänge blockiert. Teste die Konten regelmäßig, bewährt hat sich ein Intervall von höchstens 90 Tagen, und dokumentiere jede Prüfung mit Datum, prüfendem Administrator, getesteter Methode, Rollenstatus und ausgelöster Alarmierung.

Security Defaults stellen einen kostenfreien Basisschutz in Microsoft Entra ID bereit. Sie erzwingen die Registrierung einer MFA-Methode, MFA für Administratoren, MFA für Benutzer bei Bedarf, die Blockierung älterer Authentifizierungsprotokolle und den Schutz privilegierter Verwaltungszugriffe. Die frühere 14-tägige Karenzfrist für die MFA-Registrierung hat Microsoft zum 29. Juli 2024 entfernt: Benutzer müssen die Registrierung abschließen, sobald sie dazu aufgefordert werden. Seit dem 1. Juli 2026 blockieren neue Tenants über Security Defaults zusätzlich den Device Code Flow, weil dieser Anmeldeweg ein beliebtes Werkzeug für Phishing-Kampagnen ist.

Security Defaults eignen sich für kleine Organisationen ohne Entra ID P1 und ohne komplexe Ausnahmen. Sie stoßen an Grenzen, sobald du Dienstkonten differenziert behandeln, Geräte-Compliance voraussetzen, Authentication Strengths einsetzen, risikobasierte Regeln nutzen oder Ausnahmen kontrolliert abbilden musst.

Mit Entra ID P1 steuerst du den Schutz über Conditional Access. Beide Modelle schließen sich gegenseitig aus. Wechselst du, musst du den Basisschutz vollständig durch eigene Richtlinien abbilden, und zwar in dieser Reihenfolge: erst die Conditional-Access-Richtlinien produktiv schalten, dann Security Defaults deaktivieren. Ein Mindestset enthält die Blockierung von Legacy Authentication, MFA für administrative Rollen, MFA für alle Benutzer, den Schutz der Sicherheitsinformationen, die Absicherung der Adminportale, Geräte-Compliance für sensible Anwendungen, den sauberen Ausschluss der Notfallkonten und die getrennte Behandlung von Servicekonten und Workloadidentitäten. Aktiviere neue Richtlinien zuerst im Modus Nur Bericht und prüfe die Anmeldeprotokolle, bevor du sie scharf schaltest.

Eine ältere Empfehlung lautet: im Büro kein MFA, außerhalb MFA. Dieses Modell reicht für privilegierte Konten nicht mehr aus, weil eine bekannte öffentliche IP-Adresse nur den Netzwerkstandort bestätigt, nicht die Identität des Benutzers, die Integrität des Geräts oder die Sitzungsintegrität. Verwende Trusted Locations nur als zusätzliches Signal. Für Administratoren gilt phishing-resistente MFA unabhängig vom Standort.

Microsoft erzwingt MFA inzwischen direkt für Verwaltungszugriffe, unabhängig von deinen eigenen Richtlinien. Die Durchsetzung läuft in Phasen:

Reine Leseoperationen über CLI, PowerShell und APIs bleiben in Phase 2 ausgenommen, Workload Identities sind nicht betroffen. Daraus folgt: Benutzerbasierte Servicekonten taugen nicht mehr für dauerhafte Automatisierung. Verwende stattdessen Managed Identities, Service Principals mit zertifikatsbasierter Authentifizierung oder Workload Identity Federation und vermeide Client Secrets mit langen Laufzeiten, weil geleakte Secrets ohne Ablauf dauerhafte Hintertüren öffnen.

Für administrative Konten sollte das Zielbild über Push-MFA hinausgehen. Geeignet sind Passkeys mit FIDO2, physische FIDO2-Sicherheitsschlüssel, Windows Hello for Business und zertifikatbasierte Authentifizierung. Erzwinge das über eine Authentication Strength in Conditional Access für privilegierte Rollen. SMS und Sprachanrufe scheiden als bevorzugte Administratormethode aus. Microsoft zieht hier die Konsequenz und rollt ab dem 1. September 2026 Passkeys als Standard-Authentifizierungsmethode in Entra ID aus, während die native Zustellung von SMS- und Sprachcodes ausläuft.

Die Kontentrennung nützt wenig, wenn beide Identitäten im selben ungesicherten Browserprofil laufen. Für privilegierte Administration gehören ein eigenes Browserprofil, ein Intune-verwaltetes Gerät mit Defender for Endpoint und im Zielbild eine dedizierte Privileged Access Workstation ohne private Software, ohne E-Mail-Nutzung und ohne allgemeines Browsing dazu. Ergänzend blockiert Microsoft Entra Password Protection schwache und häufig verwendete Kennwörter. Sperre zusätzlich organisationsspezifische Begriffe wie Firmenname, Produktnamen und Standorte, und binde bei hybriden Umgebungen die Password Protection Agents auf den Domain Controllern ein, damit die Regeln auch bei lokalen Kennwortänderungen greifen.

Die Lizenzwahl entscheidet über mehr als Office-Anwendungen, weil Conditional Access, Intune, Defender, Purview, PIM und Identity Protection an Lizenzstufen hängen. Die typischen Pakete im Überblick:

Verlasse dich nicht auf vereinfachte Vergleichstabellen aus älteren Blogartikeln, weil Microsoft Pakete, Add-ons und Bundles laufend verändert. Prüfe den aktuellen Lizenzumfang vor der Bestellung.

Vor einer Lizenzzuweisung muss beim Benutzer die Usage Location hinterlegt sein, weil sie bestimmt, welche Dienste rechtlich und technisch zugewiesen werden dürfen:

Setze die Region explizit im Provisionierungsprozess, statt dich auf die Vererbung der Tenant-Region zu verlassen. Bei hybriden Umgebungen prüfst du das Attribut-Mapping der Synchronisation, damit der Wert korrekt in Entra ID ankommt.

Die gruppenbasierte Lizenzierung verwaltest du seit dem 1. September 2024 ausschließlich über das Microsoft 365 Admin Center oder per PowerShell und Graph API, weil Microsoft die Zuweisung über das Entra Admin Center und das Azure-Portal eingestellt hat. Ältere Anleitungen nennen Entra ID P1 als zwingende Voraussetzung. Die aktuelle Dokumentation ist hier uneinheitlich, prüfe deshalb die Lizenzbedingungen der eingesetzten Produkte. Unverändert gilt: Für jedes Gruppenmitglied, das einen Dienst nutzt, muss eine ausreichende Lizenz vorhanden sein.

Verwende sprechende Gruppennamen wie LIZ-M365-BusinessPremium-DE oder LIZ-M365-E3-DE, weil ein Name wie Lizenz1 weder Produkt noch Zielgruppe erkennen lässt. Aktiviere Servicepläne bewusst statt pauschal: Exchange Online bleibt bei hybriden Benutzern zunächst deaktiviert, Teams startet in einer Pilotgruppe, Power BI Pro erhalten nur Fachanwender.

Prüfe dabei Abhängigkeiten zwischen Serviceplänen, weil das Deaktivieren eines scheinbar unnötigen Plans andere Funktionen beeinträchtigen kann. Direkte Lizenzzuweisungen am Benutzer bleiben dokumentierten Sonderfällen vorbehalten, weil sie schwer zu auditieren sind und beim Offboarding gern übersehen werden.

Ein neuer Exchange Online Tenant besitzt Schutzmechanismen. Daraus folgt nicht, dass jede Standardrichtlinie zu deinem Schutzbedarf passt. Vor dem Go-live prüfst du mindestens Accepted Domains, Remote Domains, Preset Security Policies, Anti-Phishing-, Anti-Spam- und Anti-Malware-Richtlinien, Safe Links und Safe Attachments (abhängig von der Defender for Office 365 Lizenz), externe Weiterleitungen, Mail Flow Rules, Connectoren, SMTP AUTH, DKIM, DMARC, Audit, Adminrollen und Delegierungen.

Automatische Weiterleitungen an externe Empfänger werden für Datenabfluss missbraucht, weil ein kompromittiertes Konto damit unbemerkt jede eingehende Mail kopieren kann. Blockiere sie tenantweit über die Outbound Spam Policy und erlaube Ausnahmen nur nach dokumentierter Prüfung. Eine einzelne Transportregel deckt nicht alle Weiterleitungswege ab: Prüfe zusätzlich Inbox Rules, Remote Domains, Power Automate, Anwendungen mit Graph-Berechtigungen und delegierte Postfachzugriffe.

SMTP AUTH benötigt eine getrennte Betrachtung, weil Legacy-Blockaden über Security Defaults oder Conditional Access diesen Weg nicht vollständig abdecken. Deaktiviere SMTP AUTH tenantweit und aktiviere es nur für technisch notwendige Postfächer, wenn keine modernere Lösung verfügbar ist. Je nach Anwendung eignen sich OAuth 2.0, Microsoft Graph, High Volume Email, Azure Communication Services, direkter Versand oder ein SMTP Relay über Connector.

Die komplette Härtung mit allen Richtlinien, Preset Security Policies und Praxisbeispielen findest du im ausführlichen Guide: Microsoft 365 Exchange Online Hardening

Ein Tenant gehört vom ersten Tag an überwacht, weil Angriffe auf frische Umgebungen oft in der Aufbauphase erfolgen, wenn Richtlinien noch lückenhaft sind. Prüfe die Aktivierung und Funktion von Unified Audit Log, Entra Sign-in Logs, Entra Audit Logs, Risky Users, Risky Sign-ins, Defender Incidents, Exchange Admin Audit, PIM Audit, App Consent Protokollen, Mailbox Audit und Partneraktivitäten.

Definiere Alarme für sicherheitskritische Ereignisse:

Jeder dieser Punkte ist ein typischer Schritt in Angriffsketten. Wer erst nach einem Vorfall ins Audit Log schaut, verliert die Reaktionszeit, die zwischen Erstzugriff und Datenabfluss liegt.

Microsoft 365 ist ein verteilter SaaS-Dienst. Der Datenverkehr sollte direkt zum nächstgelegenen Microsoft-Netzwerkeinstieg gelangen, weil ein zentraler Internet-Breakout für alle Standorte unnötige Latenz erzeugt. Microsoft empfiehlt lokalen Internet-Egress, lokale DNS-Auflösung, Split Tunneling für VPN-Benutzer und die Vermeidung von Hairpin-Routing. Der Speicherort des Tenants ist für den Netzwerkpfad nicht ausschlaggebend: Ein deutscher Benutzer wird nicht künstlich zu einem vermuteten deutschen Rechenzentrum geroutet, weil Microsofts Service Front Doors den optimalen Einstiegspunkt bestimmen.

Microsoft veröffentlicht URLs und IP-Bereiche über einen Webdienst in den Kategorien Optimize, Allow und Default. Firewall- und Proxyregeln sollten diese Daten automatisiert verarbeiten, weil manuelle Listen veralten. Die Kategorie Optimize enthält die latenz- und volumenempfindlichsten Endpunkte. Für genau diese veröffentlichten Endpunkte empfiehlt Microsoft, TLS-Entschlüsselung und Deep Packet Inspection zu umgehen, weil Certificate Pinning, moderne Protokolle wie QUIC und die Teams-Medienströme sonst Zertifikatsfehler, Verbindungsabbrüche und Performanceverluste erzeugen. Der übrige Internetverkehr bleibt davon unberührt und wird weiter geprüft.

Vor dem Rollout legst du den Update-Kanal der Microsoft 365 Apps fest. Für klassische Unternehmensumgebungen ist der Monthly Enterprise Channel oft ein guter Kompromiss aus Aktualität und planbarer Veröffentlichung. Kläre Bereitstellung über Office Deployment Tool oder Intune, Add-in-Kompatibilität, Makro-Richtlinien und Pilotgruppen. Shared Computer Activation brauchst du, sobald mehrere Benutzer die Apps auf demselben Gerät verwenden, etwa auf Remote Desktop Session Hosts oder in Azure Virtual Desktop. Die eingesetzte Lizenz muss Shared Computer Activation unterstützen.

Vor dem ersten produktiven Benutzer sollten diese Blöcke abgeschlossen sein:

Exportiere nach der Grundkonfiguration die zentralen Tenant-Einstellungen als reproduzierbare Baseline, weil du Konfigurationsabweichungen sonst nicht erkennst:

Speichere die Exporte in einem geschützten Repository und wiederhole sie regelmäßig. Dokumentiere zusätzlich Tenant-ID, initiale Domäne, verifizierte Domains, CSP- und GDAP-Beziehungen, Global Administrators, Notfallkonten, das Conditional-Access-Konzept und die Supportkontakte. Notfallkennwörter gehören nicht in die allgemeine Tenant-Dokumentation, sondern in den getrennt gesicherten Speicher.

Die Tenant-Anlage legt nur das Fundament. Für den produktiven Betrieb lohnt sich der Blick in die passenden Vertiefungsartikel, sortiert nach Themenblock.

Einstieg und Grundlagen

Wer die Cloud-Entscheidung selbst noch einmal gegenprüfen will, findet die Abwägung im Artikel Vor- und Nachteile von Microsoft 365. Für den Datenschutz als Ganzes bieten sich die M365 Datenschutz Checkliste und der ausführlichere M365 Datenschutz Guide als Einstieg an.

Organisationseinstellungen

Direkt im Anschluss an die Tenant-Anlage folgen die Organisationseinstellungen. Dazu gehören die Einstellungen zu Diensten, die Einstellungen zu Sicherheit und Datenschutz sowie das Organisationsprofil. Wer diese Einstellungen automatisiert und nachvollziehbar pflegen will, findet den Weg dazu im Artikel M365 Organisationseinstellungen per PowerShell.

Datenschutz je Dienst

Für die einzelnen Dienste lohnt sich eine dienstspezifische Vertiefung: Datenschutz in Microsoft Entra ID für die Identitätsarchitektur, Datenschutz in Microsoft Teams und Datenschutz in Microsoft SharePoint Online für die Kollaborationsdienste, Datenschutz in Microsoft 365 Copilot für den KI-Einsatz sowie Datenschutz mit Microsoft Purview für Compliance und Information Protection.

Ein Microsoft 365 Tenant ist nach der Registrierung erreichbar, aber nicht produktionsbereit. Der eigentliche Aufbau beginnt bei den Entscheidungen vor dem ersten Benutzer. Land, Tenant-Name, SharePoint-Domäne und Datenresidenz prägen die Umgebung langfristig. Eine falsche Länderauswahl lässt sich nicht per Portal-Schalter korrigieren, und die SharePoint-Umbenennung bleibt ein geplanter Tenant-Eingriff mit Auswirkungen auf Sites, OneDrive-Konten, Links und Integrationen.

Die Identitätsarchitektur verdient höchste Priorität. Produktivkonten und Administratorkonten bleiben getrennt, administrative Identitäten sind Cloud-only, verwenden phishing-resistente Authentifizierung und erhalten nur die benötigten Rollen. Zwei unabhängige Notfallkonten mit FIDO2 oder zertifikatbasierter Authentifizierung sichern den Zugriff, wenn Conditional Access oder die Föderation ausfallen. Die verpflichtende MFA-Durchsetzung von Microsoft erfasst inzwischen alle Verwaltungswege bis hin zu Azure PowerShell und CLI, wodurch benutzerbasierte Servicekonten für Automatisierung endgültig ausscheiden.

Security Defaults liefern kleinen Umgebungen eine brauchbare Basis, seit Juli 2026 bei neuen Tenants inklusive blockiertem Device Code Flow. Organisationen mit Entra ID P1 steuern den Schutz über Conditional Access und testen jede Richtlinie im Modus Nur Bericht, bevor sie aktiv wird. Domains und E-Mail-Sicherheit gehören vor den MX-Wechsel: SPF allein reicht nicht, DKIM und DMARC sind Grundkonfiguration, externe Weiterleitungen und SMTP AUTH werden vor dem produktiven Mailbetrieb kontrolliert.

Lizenzierung läuft gruppenbasiert und nachvollziehbar, die Usage Location gehört in den Provisionierungsprozess, Servicepläne werden bewusst aktiviert. Beim Netzwerk gilt das SaaS-Modell: direkter Weg zum Microsoft-Netzwerk, automatisierte Endpunktpflege, keine TLS Inspection auf den veröffentlichten Microsoft 365 Endpunkten. Diese Arbeit kostet am Anfang Zeit. Sie verhindert deutlich aufwendigere Korrekturen in einer bereits produktiven Umgebung.