TenantAtlas/docs/research/m365-policy-coverage-gap-analysis.md

TenantPilot – M365 Policy Coverage Gap Analysis

Date: 2026-03-07 Author: Gap Analysis (Automated Deep Research) Scope: Security, Governance & Baseline-relevante Policy-Familien über Microsoft 365 hinweg Methode: Repo-Ist-Analyse + Microsoft Graph API Research + Produktpriorisierung

---

1. Executive Summary

• Intune-Coverage ist stark: 27 Policy-Typen + 3 Foundation-Typen sind produktiv integriert mit Backup, Restore, Drift, Inventory und Baselines. Die Intune-Abdeckung gehört zu den umfangreichsten am Markt.
• Entra ID ist die größte High-Value-Lücke: Conditional Access wird bereits gesichert (Preview-Restore), aber Named Locations, Authentication Methods Policy, Authentication Strengths, Cross-Tenant Access Settings und Authorization Policy fehlen komplett — alles davon ist über Graph v1.0 produktreif adressierbar.
• Entra Admin Roles sind ein Alleinstellungsmerkmal: Die Evidence-/Findings-Integration für hochprivilegierte Rollen ist bereits implementiert und in dieser Form selten bei Wettbewerbern.
• SharePoint/OneDrive Tenant Settings sind über die Graph v1.0 admin/sharepoint/settings API sauber erreichbar und für MSPs ein sehr häufiger Audit-Punkt (External Sharing, Guest Access).
• Exchange Online Security-Policies (Anti-Phishing, Safe Links, Safe Attachments, Anti-Spam) sind nicht sauber über Graph adressierbar — sie erfordern Exchange Online PowerShell (EXO V3). Integration ist fachlich wichtig, technisch aufwändig.
• Microsoft Defender for Office 365 Policies teilen den Exchange-PowerShell-Kanal — gleiches Integrationsproblem.
• UTCM (Unified Tenant Configuration Management) ist in Preview und signalisiert langfristig einen vereinheitlichten Backup/Restore/Drift-Kanal für alle M365-Workloads. Strategisch relevant, aber noch nicht produktreif.
• Die nächsten 5 High-Impact-Kandidaten sind: Named Locations, Authentication Methods Policy, SharePoint Tenant Settings, Authentication Strengths und Cross-Tenant Access Settings — alle über Graph v1.0.
• Purview/DLP hat für MSPs begrenzten Wert (typischerweise Enterprise-Scope, selten in MSP-Baselines) und sollte nur als Roadmap-Signal behandelt werden.
• Die größte strategische Chance liegt in der Positionierung als „Unified M365 Configuration Governance" — dafür fehlt primär der Entra-ID-Block.

---

2. Current Coverage Snapshot

2.1 Was ist heute abgedeckt?

Intune / Endpoint Management — 27 Policy-Typen (Full Backup/Restore/Inventory/Drift):

Kategorie	Policy-Typen
Configuration	Device Configuration, Administrative Templates (ADMX), Settings Catalog
Compliance	Device Compliance, Custom Compliance Scripts
Update Management	Windows Update Rings, Feature Updates, Quality Updates, Driver Updates
Apps / MAM	App Protection (MAM), App Configuration (MAM), App Configuration (Device), Mobile Apps (Metadata)
Scripts	PowerShell Scripts, macOS Shell Scripts, Proactive Remediations (Health Scripts)
Enrollment	Autopilot Profiles, Enrollment Status Page, Enrollment Limits, Platform Restrictions, Enrollment Notifications, Enrollment Restrictions, Terms & Conditions
Endpoint Security	Endpoint Security Intents, Endpoint Security Policies, Security Baselines

Foundation-Typen (3): Assignment Filters, Scope Tags, Notification Message Templates

Entra ID — Teilweise:

Bereich	Status	Details
Conditional Access Policies	✅ Backup, Inventory, Versioning	Restore ist preview-only (bewusste Entscheidung wegen Risiko)
Entra Admin Roles	✅ Evidence & Findings	Rolendefinitionen, Assignments, Severity-Klassifizierung, Finding-Generierung, Alerts
Entra Groups	✅ Directory Cache	Read-only Sync für Group-Name-Resolution
Service Principals	✅ Probing	RBAC-Onboarding-Validierung

2.2 Schwerpunkt

Der klare Schwerpunkt liegt auf Intune Endpoint Management. Alle Intune-Policy-Familien haben:

• Graph Contract Definitionen mit Select/Expand/TypeFamily
• Assignment CRUD Paths
• Backup/Restore-Unterstützung
• Inventory Integration
• Drift Detection (über Baselines/Snapshots)

2.3 Erkennbare Lücken

Domäne	Gap-Einschätzung
Entra ID (Identity)	Nur CA + Admin Roles; Named Locations, Auth Methods, Auth Strengths, Cross-Tenant Access, Authorization Policy, Security Defaults fehlen komplett
SharePoint / OneDrive	Keine Unterstützung
Exchange Online	Keine Unterstützung
Defender for Office 365	Keine Unterstützung
Purview / DLP	Keine Unterstützung
Intune Policy Sets	Im Repo als Spec (025), aber nicht im supported_policy_types
Intune Device Categories	Im Repo als Spec (028), aber nicht im supported_policy_types

2.4 Im Repo vorbereitet, aber nicht vollständig produktisiert

Element	Status
conditionalAccessPolicy	Graph Contract vollständig definiert, aber Restore auf preview-only limitiert
Policy Sets (Spec 025)	Spec vorhanden, keine Implementation
Device Categories (Spec 028)	Spec vorhanden, keine Implementation
WIP Policies (Spec 029)	Spec vorhanden, keine Implementation — EOL-Thema, geringe Priorität
Intune RBAC Backup (Spec 030)	Spec vorhanden — Role Definitions/Assignments unter deviceManagement/
Cross-Tenant Compare (Spec 043)	Architektur-Spec vorhanden, Implementation läuft

---

3. Coverage & Gap Matrix

3.1 Entra ID / Identity & Access

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
Entra ID	Conditional Access Policies	identity/conditionalAccess/policies	Graph v1.0	Partial (Backup+Inventory, no full restore)	High	High	Easy	Production	P1/P2 required	Now	Restore-Ausbau ist bewusste Risikoentscheidung; Read/Backup/Versioning ist produktiv
Entra ID	Named Locations	identity/conditionalAccess/namedLocations	Graph v1.0	No	High	High	Easy	Production	P1/P2	Now	Direkte Abhängigkeit von CA Policies; MSPs brauchen dies für Baseline-Vergleiche. CRUD über Graph v1.0 vollständig.
Entra ID	Authentication Methods Policy	policies/authenticationMethodsPolicy	Graph v1.0	No	High	High	Easy	Production	Alle SKUs (Basis); einige Methods P1/P2	Now	Tenant-weite Konfiguration (FIDO2, Authenticator, SMS, etc.). Zentrales Audit-Thema für MSPs. Singleton-Resource.
Entra ID	Authentication Strengths	policies/authenticationStrengths/policies	Graph v1.0	No	High	High	Easy	Production	P1/P2 (CA dependency)	Now	Custom Auth Strength Definitions für CA. Graph v1.0 GA. MSP-Baseline-Essential.
Entra ID	Cross-Tenant Access Settings	policies/crossTenantAccessPolicy	Graph v1.0	No	High	High	Moderate	Production	P1/P2 (B2B)	Next	Partner/Default/Inbound/Outbound Settings. Komplexere Struktur (Sub-Resources), aber über Graph v1.0 GA. Kritisch für B2B-Governance.
Entra ID	Authorization Policy	policies/authorizationPolicy	Graph v1.0	No	Medium	High	Easy	Production	Alle SKUs	Next	Singleton: steuert Guest Invite, Self-Service Sign-up, User Consent, etc. Einfache Integration, hoher Audit-Wert.
Entra ID	Security Defaults	policies/identitySecurityDefaultsEnforcementPolicy	Graph v1.0	No	Medium	High	Easy	Production	Alle SKUs	Next	Singleton: ein Boolean + Metadata. Triviale Integration. Wichtig als Posture-Signal (an/aus).
Entra ID	Admin Consent Request Policy	policies/adminConsentRequestPolicy	Graph v1.0	No	Medium	Medium	Easy	Production	Alle SKUs	Next	App Consent Workflow Settings. Simple Singleton.
Entra ID	Permission Grant Policies	policies/permissionGrantPolicies	Graph v1.0	No	Medium	Medium	Moderate	Production	Alle SKUs	Later	Steuert welche Permissions User/Admins auto-consenten dürfen. Relevant, aber Nischen-Audit.
Entra ID	Conditional Access Templates	identity/conditionalAccess/templates	Graph beta	No	Low	Medium	Hard	Beta	P1/P2	Roadmap	Beta-only. Eher Reference-Daten als konfigurierbare Policies.
Entra ID	Identity Protection Policies	identityProtection/	Graph v1.0 (read) / beta (write)	No	Medium	High	Hard	Mixed	P2 required	Later	Risk-based CA (User/Sign-In Risk). Lesen über v1.0, Konfiguration nur beta. SKU-abhängig (P2).
Entra ID	Entra Admin Roles (Evidence)	roleManagement/directory/roleDefinitions + roleAssignments	Graph v1.0	Yes	High	High	—	Production	—	—	Bereits implementiert als Findings + Alerts
Entra ID	Directory Groups (Cache)	groups	Graph v1.0	Yes	Medium	Medium	—	Production	—	—	Read-only Cache für Name-Resolution

3.2 SharePoint / OneDrive

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
SharePoint	Tenant Sharing Settings	admin/sharepoint/settings	Graph v1.0	No	High	High	Easy	Production	SPO License	Now	External Sharing Level, Guest Access Domains, Link Defaults. Häufigster SPO-Audit-Punkt. Singleton-Resource über Graph v1.0.
SharePoint	Site Creation Settings	admin/sharepoint/settings (Teil von Tenant Settings)	Graph v1.0	No	Low	Low	Easy	Production	SPO License	Later	Enthalten in demselben Endpoint wie Sharing Settings, aber geringerer Governance-Wert.
OneDrive	OneDrive Storage Settings	admin/sharepoint/settings (Subset)	Graph v1.0	No	Low	Low	Easy	Production	ODB License	Roadmap	Default Storage Limits, Sync Restrictions. Limitierter Audit-Wert.

3.3 Exchange Online

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
Exchange	Anti-Phishing Policy	EXO PowerShell: Get-AntiPhishPolicy	Non-Graph (PowerShell)	No	High	High	Hard	Production (PS)	EOP / Defender P1	Later	Kein Graph-Endpoint. Erfordert EXO V3 Remote-PowerShell oder REST-basierte EXO V3 Cmdlets. Fachlich sehr wichtig, technisch aufwändig für SaaS-Produkt.
Exchange	Safe Links Policy	EXO PowerShell: Get-SafeLinksPolicy	Non-Graph (PowerShell)	No	High	High	Hard	Production (PS)	Defender P1/P2	Later	Gleiche Situation wie Anti-Phishing. Kein Graph-Endpoint. Kritische Security-Baseline.
Exchange	Safe Attachments Policy	EXO PowerShell: Get-SafeAttachmentPolicy	Non-Graph (PowerShell)	No	High	High	Hard	Production (PS)	Defender P1/P2	Later	Gleiche Situation. Kein Graph.
Exchange	Anti-Spam Policy	EXO PowerShell: Get-HostedContentFilterPolicy	Non-Graph (PowerShell)	No	Medium	High	Hard	Production (PS)	EOP (alle SKUs)	Later	Guter Audit-Wert, aber PowerShell-Only.
Exchange	DKIM Settings	EXO PowerShell: Get-DkimSigningConfig	Non-Graph (PowerShell)	No	Medium	High	Hard	Production (PS)	Alle SKUs	Roadmap	Email-Authentifizierung. PowerShell-Only.
Exchange	Transport Rules	EXO PowerShell: Get-TransportRule; teilweise security/rules beta	Non-Graph (PowerShell) / Graph beta partial	No	Medium	Medium	Hard	Mixed	Alle SKUs	Roadmap	Komplexe Objekte. PowerShell primär. Beta-Graph sehr limitiert.
Exchange	Remote Domains	EXO PowerShell	Non-Graph (PowerShell)	No	Low	Medium	Hard	Production (PS)	Alle SKUs	Roadmap	Nischen-Governance.
Exchange	OWA Mailbox Policy	EXO PowerShell	Non-Graph (PowerShell)	No	Low	Low	Hard	Production (PS)	Alle SKUs	Roadmap	Geringer Baseline-Wert.

3.4 Microsoft Defender for Office 365 / XDR

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
Defender	Preset Security Policies	EXO PowerShell: Get-*Policy + Portal	Non-Graph (PowerShell + Portal)	No	High	High	Hard	Indirect	Defender P1/P2	Roadmap	Microsoft's empfohlene Baseline. Keine Graph-API. Nur über PS + Security Portal steuerbar.
Defender	Attack Simulation Training Config	security/attackSimulation/	Graph beta	No	Low	Medium	Hard	Beta	Defender P2	Roadmap	Nur Simulation-Runs über beta-API erreichbar, nicht die Konfiguration.
Defender	Quarantine Policies	EXO PowerShell: Get-QuarantinePolicy	Non-Graph (PowerShell)	No	Low	Medium	Hard	Production (PS)	EOP	Roadmap	Nischen-Governance.

3.5 Intune – Noch fehlende / teilweise fehlende Typen

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
Intune	Policy Sets	deviceAppManagement/policySets	Graph beta	No (Spec 025 exists)	Medium	Medium	Moderate	Beta	Intune P1	Next	Spec vorhanden. Beta-API. Nützlich für Gruppierung, aber nicht Kern-Security.
Intune	Device Categories	deviceManagement/deviceCategories	Graph v1.0	No (Spec 028 exists)	Low	Low	Easy	Production	Intune P1	Later	Einfache Integration, aber geringer Governance-Wert.
Intune	Intune RBAC (Role Definitions/Assignments)	deviceManagement/roleDefinitions + roleAssignments	Graph v1.0	No (Spec 030 exists)	Medium	High	Moderate	Production	Intune P1	Next	Bereits als Graph Contract definiert (rbacRoleAssignment). Spec vorhanden. Wichtig für Governance.
Intune	Apple VPP Tokens	deviceAppManagement/vppTokens	Graph beta	No	Low	Low	Moderate	Beta	Intune P1 + Apple VPP	Roadmap	Operational, nicht Security-relevant.
Intune	DEP Profiles (Apple)	deviceManagement/depOnboardingSettings	Graph beta	No	Medium	Medium	Moderate	Beta	Intune P1 + Apple DEP	Later	Relevant für Apple-heavy MSPs. Beta.
Intune	Windows Feature Update Expedite	deviceManagement/windowsQualityUpdatePolicies	Graph beta	No	Medium	Medium	Moderate	Beta	Intune P1	Later	Neuer Update-Typ. Beta. Eigenständige Policy.

3.6 Purview / Information Governance (Optional)

Policy Domain	Policy Family	API / Management Path	Access Channel	Coverage	MSP Value	Governance Relevance	Feasibility	Maturity	SKU Notes	Recommendation	Notes
Purview	Sensitivity Labels	security/informationProtection/sensitivityLabels	Graph v1.0 (read) / beta (full)	No	Medium	High	Hard	Mixed	M365 E3/E5	Roadmap	Lesen über v1.0. Aber Labels + Publishing Policies sind komplex. Enterprise-Feature, selten in MSP-Baselines.
Purview	DLP Policies	Security & Compliance PowerShell / security/ beta	Non-Graph (PowerShell) / Graph beta partial	No	Low	Medium	Hard	Beta/Indirect	M365 E3/E5/Compliance Add-on	Roadmap	Kein stabiler Graph-Kanal. Enterprise-only. Nicht MSP-Baseline-tauglich.
Purview	Retention Policies	security/ beta; PowerShell primary	Non-Graph (PowerShell) / Graph beta partial	No	Low	Medium	Hard	Beta/Indirect	M365 E3/E5	Roadmap	Ähnliches Problem wie DLP.

---

4. Top Missing High-Value Gaps

Die folgenden 10 Lücken bieten den größten kombinierten Wert aus MSP-Relevanz, Audit-Wichtigkeit und technischer Umsetzbarkeit:

Rang 1: Entra ID – Named Locations

• Warum: Direkte Abhängigkeit von CA Policies. Jeder CA-Baseline-Vergleich ist ohne Named Locations unvollständig. identity/conditionalAccess/namedLocations ist Graph v1.0 GA mit vollem CRUD.
• Aufwand: Gering. Gleicher Pattern wie CA Policies.

Rang 2: Entra ID – Authentication Methods Policy

• Warum: Tenant-weite Steuerung von MFA-Methoden (FIDO2, Authenticator, SMS, Temporary Access Pass). Top-Audit-Thema. policies/authenticationMethodsPolicy ist ein Singleton über Graph v1.0.
• Aufwand: Gering. Einzelne Resource mit Sub-Configurations pro Method.

Rang 3: SharePoint – Tenant Sharing Settings

• Warum: External Sharing Level, Guest Access Domain Allow/Block, Default Link Type. Häufigster SharePoint-Audit-Punkt. admin/sharepoint/settings ist Graph v1.0 GA.
• Aufwand: Gering. Singleton-Resource.

Rang 4: Entra ID – Authentication Strengths

• Warum: Custom Authentication Strength Policies für CA. Definiert erlaubte MFA-Kombinationen. policies/authenticationStrengths/policies ist Graph v1.0 GA.
• Aufwand: Gering. Collection mit einfacher Struktur.

Rang 5: Entra ID – Cross-Tenant Access Settings

• Warum: B2B Inbound/Outbound Policies, Default Settings, Partner Configurations. Kritisch für MSP-Governance bei Multi-Tenant-Umgebungen. Graph v1.0 GA.
• Aufwand: Moderat. Verschachtelte Struktur (Default + N Partner-Configs mit je Inbound/Outbound/Trust).

Rang 6: Entra ID – Authorization Policy

• Warum: Steuert grundlegende Tenant-Einstellungen: Wer darf Guests einladen, Self-Service Sign-up, User Consent Flow. policies/authorizationPolicy ist Graph v1.0 GA. Singleton.
• Aufwand: Gering. Ein Objekt.

Rang 7: Entra ID – Security Defaults Policy

• Warum: Ein Boolean (+ Metadata) das bestimmt ob Security Defaults aktiviert sind. Trivialer Check, aber kritisches Posture-Signal: Ein Tenant mit Security Defaults OFF und ohne CA ist ein Red Flag.
• Aufwand: Trivial. Ein GET-Request.

Rang 8: Intune – RBAC Role Definitions & Assignments

• Warum: Intune RBAC Backup/Governance. Wer hat welche Rechte im Intune-Kontext? Graph Contract bereits definiert. Spec 030 existiert.
• Aufwand: Moderat. Graph Contract Grundstruktur vorhanden.

Rang 9: Entra ID – Admin Consent Request Policy

• Warum: App Consent Workflow Settings. Einfaches Singleton. Audit-relevant (wer darf Apps genehmigen?).
• Aufwand: Gering.

Rang 10: Conditional Access – Restore-Ausbau

• Warum: CA Backup ist produktiv, Restore ist preview-only. Full Restore (mit Safeguards wie reportOnly-Modus, Dry-Run Validation) würde den CA-Workflow komplett machen.
• Aufwand: Moderat. Risiko-Management ist die eigentliche Herausforderung, nicht die API.

---

5. Not Sensible Before Launch

Die folgenden Kandidaten sind fachlich relevant, aber aktuell nicht sinnvoll für die unmittelbare Umsetzung:

Exchange Online Anti-Phishing / Safe Links / Safe Attachments

• Warum nicht: Kein Graph-Endpoint. Erfordert Exchange Online PowerShell V3 (REST-based) Integration. Das bedeutet: separater Auth-Flow (Certificate-Based Auth für EXO), separater Management-Kanal, separates Rate-Limit-Handling. Die technische Architektur von TenantPilot (Graph-Contract-basiert) müsste fundamental erweitert werden.
• Status: Wichtig, aber aktuell schlecht integrierbar. Eher Roadmap-/Marketing-Signal.

Microsoft Defender Preset Security Policies

• Warum nicht: Gleiche EXO-PowerShell-Abhängigkeit. Zusätzlich: Preset Security Policies sind ein Microsoft-eigenes Baseline-Konzept — die sinnvolle Governance-Integration erfordert Verständnis des Tiering-Modells (Standard/Strict).
• Status: Roadmap only.

Purview DLP / Retention Policies

• Warum nicht: Kein stabiler Graph-Kanal. Erfordert Security & Compliance PowerShell. SKU-abhängig (E3/E5). MSPs nutzen DLP seltener als Enterprise-Kunden. ROI für TenantPilot ist gering.
• Status: Roadmap only (ggf. Enterprise-Tier).

Identity Protection Policies (Risk-Based CA)

• Warum nicht: Lesen über Graph v1.0 möglich, aber Konfiguration nur über beta. Harte P2-SKU-Abhängigkeit. MSPs mit M365 BP (Business Premium) haben kein P2.
• Status: Later / Roadmap.

Intune Policy Sets (beta API)

• Warum nicht: Beta-API. Policy Sets sind ein Organisations-Feature, kein Security-Feature. Der Governance-Wert (welche Policies gehören zusammen?) ist nice-to-have, nicht must-have.
• Status: Next (nach Stabilisierung der beta-API).

Sensitivity Labels

• Warum nicht: Read-API ist v1.0, aber die vollständige Konfiguration (Label Policies, Auto-Labeling, Publishing) erfordert beta oder S&C PowerShell. Enterprise-Feature. Rare im MSP-Baseline-Kontext.
• Status: Roadmap only.

---

6. UTCM Roadmap Signals

Was ist UTCM?

Unified Tenant Configuration Management (Codename: Microsoft 365 Backup & Configuration Management) ist Microsofts Ansatz, Konfigurationen über alle M365-Workloads hinweg einheitlich zu adressieren. Stand März 2026:

Strategisch interessante Signale

Signal	Bedeutung für TenantPilot	Zeitrahmen
UTCM Configuration Profiles API (Preview)	Einheitliches Read/Write/Diff für SPO, EXO, Teams, Defender Settings über Graph	Beobachten. Preview seit Mitte 2025. Keine GA-Timeline bekannt.
M365 Backup API (solutions/backupRestore/)	Graph v1.0 GA für SPO/ODB/EXO Data Backup. Nicht für Konfiguration.	Nicht relevant für TenantPilot (Data Backup ≠ Config Governance).
Multi-Tenant Management APIs (tenantRelationships/managedTenants/)	Read-only Aggregation über MSP-Managed Tenants. Baselines, Alerts, Compliance Trends.	Beobachten. Überschneidung mit TenantPilot's eigenem Multi-Tenant-Modell. Könnte als Datenquelle nützlich sein.
UTCM Drift Detection	Microsoft's eigene Drift Detection für M365 Config. Aktuell sehr begrenzt (nur wenige Workloads).	Langfristiges Wettbewerbsrisiko. TenantPilot's Drift Engine ist deutlich umfangreicher.

Bewertung

UTCM ist heute ein Beobachtungssignal, kein Umsetzungsziel:

• Die Preview-APIs sind instabil und haben sehr begrenzten Workload-Scope
• Microsoft's eigene Roadmap zeigt keine klare GA-Timeline
• TenantPilot sollte UTCM als langfristigen Integrationspartner betrachten, nicht als kurzfristiges Feature-Ziel
• Die Strategie sollte sein: Graph v1.0 APIs zuerst, UTCM als Beschleuniger wenn GA

---

7. Recommended Product Sequencing

Now (Q2 2026 – unmittelbar umsetzbar, hoher ROI)

#	Kandidat	Begründung
1	Entra: Named Locations	CA-Abhängigkeit, Graph v1.0, triviales Pattern
2	Entra: Authentication Methods Policy	Top-Audit-Thema, Graph v1.0, Singleton
3	SharePoint: Tenant Sharing Settings	Häufigster SPO-Audit-Punkt, Graph v1.0, Singleton
4	Entra: Authentication Strengths	CA-Dependency, Graph v1.0, einfach
5	Entra: Security Defaults	Trivial (1 Boolean), aber kritisches Posture-Signal

Alle 5 Kandidaten nutzen ausschließlich Graph v1.0 Stable-APIs und erfordern keinen neuen Integrationskanal.

Next (Q3-Q4 2026 – moderater Aufwand, solider Wert)

#	Kandidat	Begründung
6	Entra: Cross-Tenant Access Settings	B2B-Governance, Graph v1.0, aber verschachtelte Struktur
7	Entra: Authorization Policy	Tenant-Grundkonfiguration, Graph v1.0, Singleton
8	Intune: RBAC Role Definitions/Assignments	Spec 030 vorhanden, Graph Contract existiert, Governance-Must
9	Entra: Admin Consent Request Policy	Einfach, Graph v1.0, App-Consent-Governance
10	Conditional Access: Full Restore	Backup existiert; Restore-Workflow mit Safety-Guardrails ausbauen

Later (2027 H1 – requires architecture investment or beta stabilization)

#	Kandidat	Begründung
11	Entra: Permission Grant Policies	Graph v1.0, aber Nischen-Thema
12	Entra: Identity Protection Policies	SKU-abhängig (P2), Write nur beta
13	Intune: Policy Sets	Beta API, nice-to-have Governance
14	Intune: DEP Profiles (Apple)	Beta, Apple-spezifisch
15	Exchange: Anti-Phishing/Safe Links/Safe Attachments	Erfordert EXO PowerShell-Kanal — architektonische Erweiterung

Roadmap Only (strategisch, nicht kurzfristig)

Kandidat	Begründung
UTCM Integration	Preview, keine GA-Timeline
Defender Preset Security Policies	PowerShell-Only, komplexes Tiering
Purview DLP / Retention	PowerShell + beta, Enterprise-SKU, geringer MSP-ROI
Sensitivity Labels (Full)	Mixed API, Enterprise-Feature
Exchange Transport Rules	PowerShell primary, komplexe Objekte
Multi-Tenant Management API	Read-only Aggregation, Überschneidung mit eigenem Modell

---

8. Sources

Microsoft Graph API Documentation (v1.0)

• Conditional Access Policies
• Named Locations
• Authentication Methods Policy
• Authentication Strength Policy
• Cross-Tenant Access Policy
• Authorization Policy
• Identity Security Defaults
• Admin Consent Request Policy
• Permission Grant Policies
• SharePoint Settings
• Role Management (Directory)

Microsoft Graph API Documentation (beta)

• Identity Protection
• Policy Sets (Intune)
• UTCM / Multi-Tenant Management

Exchange Online / Defender (PowerShell)

• EXO V3 Module
• Anti-Phishing Policies
• Safe Links
• Safe Attachments
• Preset Security Policies

Purview

• Sensitivity Labels API
• Data Loss Prevention (Compliance)

UTCM / M365 Backup

• Microsoft 365 Backup (Data)
• Multi-Tenant Management (Lighthouse)

---

Appendix A: Architektur-Anmerkungen für die Umsetzung

"Now"-Kandidaten folgen dem bestehenden Graph-Contract-Pattern

Alle 5 „Now"-Kandidaten können in das bestehende config/graph_contracts.php + GraphContractRegistry Muster integriert werden:

// Beispiel-Contract für Named Locations
'namedLocation' => [
    'resource' => 'identity/conditionalAccess/namedLocations',
    'allowed_select' => ['id', 'displayName', '@odata.type', 'modifiedDateTime'],
    'allowed_expand' => [],
    'type_family' => [
        '#microsoft.graph.ipNamedLocation',
        '#microsoft.graph.countryNamedLocation',
    ],
    'create_method' => 'POST',
    'update_method' => 'PATCH',
    'id_field' => 'id',
    'hydration' => 'properties',
],

Singleton-Resources (neue Kategorie)

Authentication Methods Policy, Authorization Policy und Security Defaults sind Singletons (ein Objekt pro Tenant, kein Collection-CRUD). Das bestehende Pattern (Collection-basiert mit CRUD) muss um einen Singleton-Modus erweitert werden:

• GET (kein $top, kein Paging)
• PATCH (kein POST/DELETE)
• Vergleich: Vorher/Nachher eines einzelnen Objekts

Permissions-Impact

Kandidat	Benötigte Permission	Typ
Named Locations	Policy.Read.All (bereits granted)	Read
Auth Methods Policy	Policy.Read.All (bereits granted)	Read
Auth Strengths	Policy.Read.All (bereits granted)	Read
Security Defaults	Policy.Read.All (bereits granted)	Read
SharePoint Settings	SharePointTenantSettings.Read.All	Neu
Cross-Tenant Access	Policy.Read.All (bereits granted)	Read
Authorization Policy	Policy.Read.All (bereits granted)	Read

Bemerkenswert: 4 von 5 „Now"-Kandidaten erfordern keine neuen Permissions — Policy.Read.All ist bereits in config/intune_permissions.php als granted definiert. Nur SharePoint benötigt eine neue Permission.