Intune Multi Admin Approval in großen Umgebungen: Wo es sinnvoll ist und wo es operativ nervt

Multi Admin Approval, kurz MAA, klingt in Intune erstmal nach einer ziemlich offensichtlichen guten Idee:

Ein einzelner kompromittierter oder unvorsichtiger Admin soll nicht einfach alleine kritische Änderungen durchdrücken können.

Genau dafür ist MAA da. Intune kann Änderungen an bestimmten geschützten Bereichen erst dann anwenden, wenn ein zweites Admin-Konto die Anfrage explizit freigibt. Microsoft unterstützt das unter anderem für Apps, Compliance Policies, Configuration Policies, Scripts, Role-based access control, Access Policies, Tenant Configuration und Device Actions wie Wipe, Retire und Delete.

Auf dem Papier ist das stark.

In der Praxis wird es aber genau dann interessant, wenn du nicht über ein kleines zentrales Admin-Team sprichst, sondern über eine globale Umgebung mit vielen Ländern, Zeitzonen, Local IT Teams und mehreren Eskalationsstufen.

Denn dann ist die eigentliche Frage nicht mehr:

„Ist MAA sicher?“

Sondern:

„Wie setzt man MAA so um, dass es nicht in Approval-Theater oder operative Blockade kippt?“

Was MAA technisch sauber löst

Die Grundidee von MAA ist absolut sinnvoll:

Wenn eine Ressource durch eine Access Policy geschützt ist, reicht die Aktion eines einzelnen Admins nicht mehr aus. Erst ein anderer Admin aus einer zugewiesenen Approver Group kann die Änderung genehmigen oder ablehnen. Der Antragsteller kann seinen eigenen Request zwar sehen, aber nicht selbst freigeben. Außerdem laufen Requests nach 30 Tagen ab, wenn sie nicht weiterbearbeitet werden. Das ist genau der richtige Gedanke für Dinge wie:

1. Änderungen an RBAC
2. Änderungen an Access Policies
3. Änderungen an Tenant Configuration
4. riskante oder weitreichende Script-Deployments

Gerade bei RBAC und Access Policies ist MAA fachlich fast schon naheliegend, weil du damit verhindern willst, dass ein einzelner Admin sich faktisch selbst den Weg freiräumt. Microsoft hat MAA inzwischen auch explizit für role-based access control ausgerollt.

Wo MAA in großen Umgebungen schwierig wird

Richtig unbequem wird es bei Device Actions:

1. Wipe
2. Retire
3. Delete

Diese Aktionen sind in Intune inzwischen ebenfalls MAA-fähig.

Und genau hier beginnt das Betriebsproblem.

Denn in vielen Unternehmen werden solche Aktionen nicht von einem globalen Architektur- oder Plattform-Team durchgeführt, sondern von:

1. Local IT
2. Regional Support
3. Service Desk
4. Onsite Support
5. L2- oder L3-Betriebsteams

Das ist logisch, weil ein Device Wipe oft kein strategisches Plattform-Thema ist, sondern ein alltäglicher operativer Vorgang:

• Gerät verloren
• Mitarbeiter ausgetreten
• Corporate Device zurückgegeben
• Gerät hängt in falschem Zustand
• Rebuild nötig
• BYOD soll sauber retired werden

Technisch kann MAA das absichern.

Organisatorisch verschiebt es aber sofort die Frage auf etwas viel Größeres:

Wer darf in einem globalen Tenant eigentlich wen freigeben und auf welcher Grundlage?

Das Kernproblem ist nicht Sicherheit, sondern Approval Routing

In kleinen Umgebungen kann man noch sagen:

Ein zweiter Intune-Admin schaut kurz drauf und genehmigt das.

In großen Umgebungen funktioniert das aber oft nicht mehr sauber.

Warum?

Weil die eigentliche Schwierigkeit nicht der zweite Klick ist, sondern die sinnvolle Freigabelogik dahinter.

Ein paar typische Probleme:

1. Globales Approval ohne lokalen Kontext

Wenn Local IT in UK ein Gerät wipen will, warum sollte US Local IT oder ein globales Plattform-Team diese Anfrage freigeben dürfen?

Formal geht das vielleicht.

Operativ ist es schwach.

Der Approver hat oft gar nicht genug Kontext, um zu beurteilen:

• Gehört das Gerät wirklich zum richtigen Benutzer?
• Ist der Fall legitim?
• Ist Wipe wirklich nötig oder wäre Retire korrekt?
• Handelt es sich um ein VIP-Gerät, ein Shared Device oder einen Sonderfall?

Dann wird MAA schnell zu einem reinen Abnick-Prozess.

Und Abnicken ist keine echte Sicherheitskontrolle.

2. Lokale Freigabegruppen ohne saubere Trennung

Die naheliegende Idee wäre:

Dann geben sich die Local-IT-Teams eben gegenseitig frei.

Das klingt erstmal vernünftig, hat aber in globalen Tenants ein offensichtliches Problem:

Intune MAA-Access-Policies lassen sich nicht fein nach Ländern, Märkten oder Standorten für denselben Ressourcentyp segmentieren. Eine Access Policy schützt immer einen Ressourcentyp, und bei den Approvern wird schlicht eine oder mehrere Gruppen hinterlegt kompliziertere Exclusions werden laut Microsoft nicht unterstützt.

Heißt praktisch:

Wenn du Device Actions unter MAA stellst, baust du schnell eine Approver-Struktur, die tenantweit wirkt, obwohl dein operatives Modell lokal oder regional organisiert ist.

3. Kein sauberer eingebauter Eskalations- und Benachrichtigungsfluss

Microsoft empfiehlt selbst, bei dringenden Requests bekannte Approver aktiv zu kontaktieren, damit Anfragen rechtzeitig gesehen werden. Das ist schon ein ziemlich klares Zeichen, dass hier kein wirklich starker operativer Notification-Flow eingebaut ist.

Für eine große Umgebung ist das dünn.

Denn dann hängt dein Prozess plötzlich an Dingen wie:

• Teams-Message an den richtigen Menschen
• Ticket-Kommentar mit Ping
• Mail an Shared Mailbox
• manuelle Übergabe im Zeitzonenwechsel
• persönliches „Kannst du mal kurz approven?“

Das ist kein belastbares Operating Model. Das ist improvisiertes Routing.

Mein ehrlicher Blick auf MAA in Enterprise-Setups

Ich halte MAA nicht für schlecht.

Aber ich halte es für einen Fehler, MAA überall gleich zu behandeln.

Der Denkfehler ist oft:

Alles Kritische bekommt MAA.

In der Realität musst du stärker unterscheiden zwischen:

Kategorie A: High Impact, Low Frequency

Das sind Änderungen, die selten sind, aber große Wirkung haben.

Zum Beispiel:

1. RBAC-Änderungen
2. Access Policies
3. Tenant Configuration
4. sicherheitsrelevante oder breit wirkende Scripts
5. globale Konfigurationsänderungen

Hier ist MAA stark.

Warum?

Weil:

• die Zahl der Requests überschaubar bleibt
• die Approver typischerweise zentral sitzen
• die Freigabe inhaltlich sinnvoll geprüft werden kann
• der operative Overhead akzeptabel ist

Kategorie B: High Frequency, Context Heavy

Das sind Vorgänge, die oft vorkommen und stark vom lokalen Kontext abhängen.

Zum Beispiel:

1. Device Wipe
2. Device Retire
3. Device Delete

Hier wird MAA schnell problematisch.

Nicht, weil die Aktion unwichtig wäre.

Sondern weil die Freigabe nicht nur technisch, sondern vor allem organisatorisch richtig geroutet werden muss.

Und genau da ist Intune MAA heute aus meiner Sicht noch zu grob.

Wie ich es in großen Umgebungen eher aufziehen würde

Wenn du mich nüchtern fragst, würde ich MAA in einem großen globalen Tenant nicht überall gleichzeitig ausrollen, sondern gestuft.

1. MAA zuerst für zentrale Steuerungsebenen

Als erstes würde ich MAA für Dinge aktivieren, die tenantweit echten Hebel haben:

1. RBAC
2. Access Policies
3. Tenant Configuration
4. ggf. Scripts
5. ggf. besonders kritische App- oder Policy-Änderungen

Das ist aus meiner Sicht der sauberste Start, weil hier die Approver-Frage am wenigsten chaotisch ist.

2. Device Actions nur dann unter MAA, wenn das Betriebsmodell es wirklich trägt

Bei Wipe, Retire und Delete würde ich vor der Aktivierung erst diese Fragen klären:

1. Wer darf beantragen?
2. Wer darf genehmigen?
3. Woher kommt der betriebliche Kontext?
4. Wie wird zwischen Ländern und Regionen getrennt?
5. Wer übernimmt Off-Hours und Time-Zone-Coverage?
6. Wie wird mit Urlaubs- oder Krankheitsfällen umgegangen?
7. Wie verhindert man reines Durchwinken?

Wenn du diese Fragen nicht sauber beantworten kannst, baust du kein Sicherheitsmodell, sondern nur zusätzliche Reibung.

3. Nicht MAA als Ersatz für schwache Admin-Hygiene missverstehen

MAA ist kein Ersatz für die Grundlagen.

Wenn eure Admin-Sicherheit schwach ist, dann löst MAA das Grundproblem nicht.

Die Basis muss vorher stimmen:

1. getrennte Admin-Konten
2. starke MFA
3. PIM statt permanenter Hochprivilegierung
4. saubere Rollentrennung
5. Logging und Detection für ungewöhnliche Remote Actions
6. klare Prozesse für Incident- und Offboarding-Fälle

MAA ist eine zusätzliche Kontrollschicht, kein Rettungsboot für schlechtes Privilege Management.

Mein Fazit zu Device Wipe unter MAA

Gerade für Device Wipe in globalen Unternehmen ist MAA aus Sicherheitslogik verständlich, aber operativ heikel.

Das Problem ist nicht, dass ein zweiter Admin freigeben muss.

Das Problem ist:

Der zweite Admin muss der richtige zweite Admin sein.

Und genau das lässt sich in großen Tenants mit lokal organisierten Support-Strukturen oft nicht sauber abbilden, wenn die Policy tenantweit für den Ressourcentyp greift und der Genehmigungsprozess keinen wirklich guten Routing-Mechanismus mitbringt.

Deshalb wäre meine pragmatische Empfehlung:

1. MAA konsequent für zentrale und hochwirksame Änderungen
2. Device Actions nur nach sauberem Betriebsdesign
3. lieber ein enger, sinnvoller MAA-Scope als ein großer Scope mit blindem Abnicken

Denn ein Sicherheitsfeature bringt dir wenig, wenn es in der Praxis nur dazu führt, dass Menschen Anfragen ohne echten Kontext bestätigen.

Dann hast du formal Vier-Augen-Prinzip.

Aber faktisch nur einen zweiten Klick.

Schlussgedanke

Multi Admin Approval ist in Intune ein sinnvoller Baustein gegen einzelne kompromittierte oder unvorsichtige Admin-Konten. Für zentrale Konfigurations- und Rollenänderungen passt das sehr gut. Für lokale Device Actions in globalen Umgebungen zeigt sich aber schnell die eigentliche Schwäche:

Nicht die Freigabe selbst ist das Problem.

Sondern die fehlende organisatorische Granularität dahinter.

Und genau daran entscheidet sich am Ende, ob MAA echte Sicherheit bringt oder nur zusätzliche Prozesslast.