Microsoft 365 Multiplexing: Wer braucht eine Lizenz?

Kurz gesagt: Microsoft 365 Multiplexing bedeutet, dass eine Zwischenschicht den Zugriff auf einen Microsoft-Dienst bündelt. Das kann ein Sammelkonto sein, eine Automatisierung, ein Portal oder ein KI-Agent. Microsofts Regel ist eindeutig: Multiplexing senkt die Zahl der nötigen Lizenzen nicht. Wer indirekt von einem Dienst profitiert, braucht eine eigene Lizenz. Seit Mai 2026 nennt Microsoft ausdrücklich auch Automatisierung als Auslöser.

Was bedeutet Multiplexing bei Microsoft 365?

Multiplexing beschreibt jede Technik, die viele Nutzer hinter einem einzigen Zugangspunkt bündelt. Das Muster stammt aus der On-Premises-Welt. Hunderte Mitarbeiter greifen über ein Webportal auf eine SQL-Datenbank zu, doch das Portal meldet sich mit nur einem Konto an. Microsoft verlangt trotzdem eine Zugriffslizenz pro Person, weil das Portal nur als Verteiler dient.

Das Prinzip dahinter formuliert Microsoft in einem Satz: Multiplexing reduziert die Zahl der erforderlichen Lizenzen nicht. Wie viele technische Schichten zwischen Mensch und Dienst liegen, spielt keine Rolle. Entscheidend ist, wer am Ende von den Daten oder Funktionen profitiert.

Die wichtigste Trennlinie verläuft zwischen automatisiert und manuell. Ein lizenzierter Mitarbeiter, der Daten von Hand exportiert und per E-Mail an Kollegen schickt, löst kein Multiplexing aus. Übernimmt dagegen eine Automatisierung diesen Transport, brauchen alle profitierenden Kollegen eine Lizenz. Genau diese Grenze wird in der Praxis am häufigsten übersehen.

Wie war die Regel früher, und was hat sich 2026 geändert?

Die Grundregel selbst ist alt. Über Jahre definierte Microsoft Multiplexing in den Lizenzbedingungen als Einsatz von „Hardware oder Software", die Verbindungen bündelt oder die Zahl der zugreifenden Nutzer verringert. Diese Formulierung stammte noch aus der Zeit klassischer Client-Server-Systeme. Automatisierte Cloud-Prozesse waren darin nicht ausdrücklich benannt.

Im Mai 2026 hat Microsoft die Definition in den Product Terms erweitert. Sie lautet jetzt: „any method (for example, hardware, software, or automation)". Aus einer geschlossenen Liste wurde eine offene Formulierung. Das Wort Automatisierung steht nun ausdrücklich als Beispiel im Text.

Konkret bedeutet das eine Verschiebung des Fokus. Robotic Process Automation, Cloud-Flows und KI-Agenten lassen sich nicht mehr mit dem Argument aus der Regel herausdefinieren, sie seien ja weder reine Hardware noch klassische Software. Zeitgleich hat Microsoft die kommerzielle Seite nachgezogen. Seit dem 1. Mai 2026 gibt es die Suite Microsoft 365 E7 sowie Agent 365 als eigene Lizenz für den Einsatz von KI-Agenten. Beide folgen demselben Grundsatz: gezahlt wird pro Nutzer, der von der Leistung profitiert.

Eine wichtige Einordnung gehört dazu. Microsoft hat den Oberbegriff Automatisierung ergänzt, nicht einzeln „RPA" oder „KI-Agent" in die Definition geschrieben. Ob ein konkreter Automatismus Multiplexing auslöst, bleibt eine Frage des Einzelfalls. Die Richtung ist aber klar: automatisierte indirekte Nutzung steht jetzt eindeutig im Regelbereich.

Wo entsteht Multiplexing in der Praxis?

Multiplexing ist selten böse Absicht. Meist entsteht es aus einem nachvollziehbaren Wunsch, teure Lizenzen zu sparen oder einen Prozess zu vereinfachen. Die folgenden Muster begegnen einem im Mittelstand am häufigsten.

Die nächsten Abschnitte gehen für die wichtigsten Dienste ins Detail: wie das Muster technisch entsteht und wie es sauber lizenziert wird.

Power Automate und Power Apps: die enthaltene Lizenz und ihre Grenzen

Viele Microsoft-365-Pläne enthalten Power Apps und Power Automate bereits, allerdings nur „in context". Der enthaltene Anspruch gilt für Standard-Konnektoren und für Flows, die zur jeweiligen App gehören. Sobald ein Flow Premium- oder Custom-Konnektoren nutzt oder losgelöst von der App läuft, braucht es eine eigenständige Lizenz.

Ein Beispiel: Ein Flow, der Daten aus einer SharePoint-Liste liest und in dieselbe App zurückschreibt, bleibt im enthaltenen Rahmen. Ein Flow, der ein externes ERP über einen Premium-Konnektor anbindet, verlässt ihn. Dann wird eine Power Automate Premium Lizenz fällig oder der Prozess muss anders lizenziert werden.

Der häufigste Umgehungsversuch nutzt ein Dienstkonto mit einer Premium-Lizenz, das den teuren Teil übernimmt. Sobald mehrere Nutzer diesen Flow auslösen oder individuell von ihm profitieren, müssen alle diese Nutzer lizenziert sein. Eine beliebte Variante entkoppelt die Logik zusätzlich. Eine einfache App schreibt einen Datensatz nach SharePoint, dessen Anlage einen separaten Premium-Flow auslöst. Das ändert nichts, denn der Nutzer stößt den Premium-Prozess indirekt an und profitiert davon.

Der saubere Weg ist die Power Automate Process License. Sie wird dem Flow zugewiesen und erlaubt Standard-, Premium- und Custom-Konnektoren, genutzt von unbegrenzt vielen Nutzern unabhängig von deren eigener Lizenz. Pro Process-Lizenz sind 250.000 Aktionen pro Tag inklusive. Damit lizenzieren Sie den Prozess statt jeden einzelnen Menschen.

Zur Fairness gehört die Gegenrichtung. Läuft ein Flow rein im Kontext seines Besitzers und liefert den auslösenden Nutzern keinen individuellen Mehrwert, braucht der Auslöser keine Premium-Lizenz. Die Prüffrage bleibt immer dieselbe: Löst der Nutzer den Prozess aus und profitiert er davon?

Dataverse und Dynamics 365: Daten rein, raus und die Sonderfälle

Dynamics-365-Lizenzen sind teuer, deshalb entstehen hier die kreativsten Architekturen. Die Regel bleibt streng: Wer auf Dynamics-Daten zugreift, direkt oder indirekt, muss passend lizenziert sein. Die Zahl der Zwischensysteme ändert daran nichts.

Beim Weg nach außen spiegelt ein automatischer Export Kunden- und Auftragsdaten aus Dynamics 365 in ein Data Warehouse wie Snowflake oder einen Data Lake. Fachabteilungen lesen das über ein BI-Tool wie Tableau und berühren Dynamics nie. Trotzdem gilt: Wer Dynamics-Daten sieht, braucht eine passende Dynamics-365-Lizenz. Hier kursiert ein hartnäckiger Irrtum. Eine Team-Member-Lizenz ist nicht automatisch das Minimum. Microsoft verlangt die zur genutzten Funktion passende Lizenz, und diese Untergrenze liegt oft höher. Für reine Standard-Daten kann umgekehrt eine Power-Platform-Lizenz genügen. Der entscheidende Hebel bleibt: Ein rein manueller Export durch eine lizenzierte Person unterbricht die Kette.

Der Weg nach innen ist spiegelbildlich. Ein selbstgebautes Web-Frontend lässt Logistik-Subunternehmer Lieferstatus melden, eine Middleware schreibt diese Meldungen via REST-API nach Dataverse. Diese externen Akteure erzeugen Geschäftsdaten im System und gelten damit als indirekte Nutzer. Abgedeckt werden sie über Power-Pages-Kapazität für authentifizierte Nutzer oder eine passende externe Lizenzierung, nicht über ein anonymes Sammelkonto. Wie externe Gäste und Kunden lizenziert werden, zeigt der Beitrag zur Lizenzpflicht von Gastkonten.

Ein Sonderfall sind restricted entities. Manche Dataverse-Tabellen sind fest an Dynamics-Lizenzen gebunden, etwa SLA und Entitlement. Wer sie beschreibt, braucht die entsprechende Dynamics-365-Customer-Service-Lizenz. Eine Automatisierung, die Daten aus einer freien Tabelle in eine solche geschützte Tabelle überträgt, umgeht das nicht. Beim Schreiben greift die Lizenzpflicht, ein reiner Lesezugriff ist ausgenommen. Bei der Fall-Tabelle gilt eine Teilausnahme: Nutzer mit Power-Apps-Lizenz dürfen eigene Fälle anlegen und bearbeiten, aber nicht als vollwertige Service-Agenten auf fremden Fällen arbeiten.

SharePoint-Portale und SMTP-Relay: die unauffälligen Fälle

Nicht nur Premium-Systeme sind betroffen. Auch die scheinbar kostenlosen Bausteine werden zur Falle, wenn Standard-Wege umgangen werden.

Ein häufiges Muster stellt Dokumente aus SharePoint über ein eigenes Kundenportal bereit. Statt Kunden als Gast in den Tenant einzuladen, greift die Portal-App per App-Authentifizierung über die Graph-API auf SharePoint zu und zeigt die Dokumente unlizenzierten Externen an. Technisch elegant, lizenzrechtlich heikel. Inhalte aus SharePoint sollen von lizenzierten Nutzern oder offiziell eingeladenen Gästen konsumiert werden. Die reine Durchleitung an unlizenzierte Dritte gilt als indirekte Nutzung und damit als Multiplexing.

Beim SMTP-Relay kommt es auf den menschlichen Nutznießer an, nicht auf die Absenderadresse. On-Premises-Systeme und Anwendungen versenden häufig E-Mails über Exchange. Reine Systemmeldungen von einer generischen Adresse wie alert@firma.de, hinter der kein einzelner Mensch profitiert, bleiben lizenzfrei. Verschickt ein CRM aber E-Mails unter der persönlichen Adresse eines Vertrieblers, profitiert dieser Mensch aktiv von der Exchange-Infrastruktur. Dann braucht er eine Lizenz mit Exchange-Online-Postfach, auch wenn er nur im CRM arbeitet und Outlook nie öffnet. Welche technischen Konten dabei lizenzfrei bleiben und wann eine günstige Minimallizenz reicht, zeigt der Beitrag zu Service-Accounts und Microsoft-365-Lizenzen.

Bots, RPA und KI-Agenten: wenn Software die Arbeit übernimmt

Das ist der jüngste und am stärksten wachsende Bereich. Sobald Software die Arbeit eines Menschen nachbildet, greifen eigene Regeln. Eine normale Nutzerlizenz deckt eine Maschine nicht ab.

Microsoft trennt Attended Bots, die ein Mensch auf seinem eigenen Rechner auslöst, von Unattended Bots, die autark auf einer virtuellen Maschine laufen. Ein Unattended Bot, der eigenständig Outlook liest, Anhänge in Word öffnet und Daten in ein CRM überträgt, simuliert einen Angestellten. Dafür genügt keine normale Microsoft-365-Nutzerlizenz. Der Betrieb verlangt eine eigene Microsoft 365 Unattended License, die pro virtueller Maschine zugewiesen wird und die Microsoft-365-Apps für die Automatisierung berechtigt. Ohne diese Lizenz laufen die Office-Apps nur im eingeschränkten Modus. Ein Bot darf außerdem nicht die Arbeit unlizenzierter Nutzer nachbilden, um deren Lizenzen zu ersparen.

Mit Agent 365 und Copilot Studio kommt eine neue Ebene hinzu. Viele Agenten arbeiten „On Behalf Of", also unter der Identität eines Nutzers. Baut ein Abteilungsleiter mit E7-Lizenz einen leistungsstarken Agenten und teilt ihn über Teams mit zwanzig Kollegen, die nur Basis-Lizenzen haben, arbeitet der Agent für diese Kollegen. Jeder Kollege, der den Agenten für sich arbeiten lässt, braucht eine eigene Agent-365-Lizenz. Stand Mai 2026 kostet die rund 15 US-Dollar pro Nutzer und Monat als Einzellizenz oder ist in Microsoft 365 E7 für rund 99 US-Dollar enthalten. Das Zusammenlegen einer Einzellizenz für viele Nutzer senkt die Zahl der Lizenzen nicht. Wie sich die Kosten von KI-Agenten im Detail zusammensetzen, zeigt der Beitrag zu den Kosten von KI-Agenten in Microsoft 365.

Zwei Dinge gehören zur ehrlichen Einordnung. Erstens ist offen, ob auch rein passiv profitierende Nutzer je eine Lizenz brauchen. Microsoft hat die Durchsetzung der Agent-365-Lizenzierung angekündigt, aber noch nicht scharf geschaltet. Zweitens ist der Verbrauch von Copilot Credits eine andere Baustelle als Multiplexing. Wer Anfragen bündelt, um Credits zu sparen, entkommt der Lizenzpflicht seiner Nutzer trotzdem nicht. Die Credit-Abrechnung selbst ist aber kein Multiplexing-Fall, sondern wird über Kapazitätsgrenzen geregelt.

Erlaubt oder Verstoß? Die häufigsten Irrtümer

Rund um Multiplexing halten sich mehrere Mythen, die im Audit teuer werden.

Wie bleibe ich konform? Die legitimen Wege

Multiplexing zu vermeiden heißt nicht, auf Automatisierung zu verzichten. Es heißt, für jeden Prozess den passenden Lizenzweg zu wählen. Fünf Wege decken die meisten Fälle ab.

• Alle profitierenden Nutzer lizenzieren. Der direkteste Weg, sinnvoll bei kleinen, klar abgegrenzten Gruppen.
• Den Prozess statt die Nutzer lizenzieren. Eine Power Automate Process License deckt einen Flow für unbegrenzt viele Nutzer ab.
• Externe über Kapazität abdecken. Power-Pages-Kapazität für authentifizierte Nutzer lizenziert Portalzugriffe unabhängig von Einzelkonten.
• Maschinen richtig lizenzieren. Für unbeaufsichtigte Bots die Microsoft 365 Unattended License, für KI-Agenten Agent 365 pro Nutzer.
• Echte manuelle Prozesse nutzen. Ein lizenzierter Mensch, der Daten von Hand exportiert und verteilt, löst kein Multiplexing aus.

Der schwierige Teil ist nicht die Lösung, sondern die Diagnose. Man muss erst wissen, wo im Tenant überhaupt indirekte Nutzung stattfindet.

Wie prüft Microsoft indirekte Nutzung bei einem Audit?

Früher war Multiplexing ein Ehrensystem. In der On-Premises-Welt lief die Software im Rechenzentrum des Kunden, und Prüfer konnten indirekte Nutzung kaum belegen. In der Cloud liegt diese Aktivität auf Microsofts Infrastruktur. Anmeldeprotokolle, Audit-Logs, die Auswertungen im Power Platform Admin Center sowie Konnektor- und Flow-Nutzung zeichnen auf, wer wann worauf zugreift.

Wichtig zur Einordnung: Microsoft rechnet Multiplexing nicht per Algorithmus automatisch nach. Die Durchsetzung läuft über das formale Lizenz-Audit. Verändert hat sich die Beweislage. In einem Audit lässt sich mit diesen Cloud-Daten heute nachvollziehen, dass ein Sammelkonto zehntausende Datensätze aus hunderten Identitäten verarbeitet. Seit 2026 kommt die Nachvollziehbarkeit von KI-Agenten hinzu, etwa über Entra Agent ID und Microsoft Defender.

Wie ein Microsoft-Lizenzaudit abläuft und wie Sie sich vorbereiten, behandeln wir in einem eigenen Beitrag.

Wie erkenne ich indirekte Nutzung im eigenen Tenant?

Das eigentliche Problem ist die Sichtbarkeit. Multiplexing versteckt sich in Flows, Dienstkonten, Portalen und geteilten Agenten, und kaum ein IT-Verantwortlicher hat eine vollständige Karte davon.

LessLicense verschafft Ihnen zuerst diese Transparenz. Die Analyse läuft read-only und inventarisiert unter anderem Ihre Power-Automate-Flows samt Premium-Konnektoren und Besitzern, Ihre Dienstkonten und Ihre Copilot-Studio-Agenten. Ihr Schwerpunkt liegt auf der Gegenrichtung: dem Aufspüren ungenutzter und überdimensionierter Lizenzen, also direktem Sparpotenzial. Genau dieses Inventar ist die Grundlage, auf der Sie indirekte Nutzung überhaupt erst bewerten können. Die Software läuft self-hosted in Deutschland, DSGVO-konform und ohne dass Ihre Daten das Haus verlassen. So funktioniert die read-only Tenant-Analyse.

FAQ

Braucht jeder Nutzer einer Shared Mailbox eine eigene Lizenz?

Ja. Das freigegebene Postfach selbst ist bis 50 GB kostenfrei. Jeder Mensch, der es liest oder darüber versendet, braucht laut Microsoft eine eigene lizenzierte Exchange-Online-Mailbox. Ab 50 GB kommt für das Postfach eine Exchange Online Plan 2 Lizenz hinzu.

Reicht ein manueller Freigabe-Klick, um Multiplexing zu vermeiden?

Nur bedingt. Ein echter manueller Prozess durch eine lizenzierte Person löst kein Multiplexing aus. Ein einzelner Bestätigungsklick in einer ansonsten vollautomatischen Kette ist dagegen eine riskante Auslegung. Entscheidend ist der reale manuelle Aufwand, nicht der Button.

Was ist eine Power Automate Process License?

Sie lizenziert einen einzelnen Flow statt einzelner Nutzer. Der Flow darf Standard-, Premium- und Custom-Konnektoren nutzen und von unbegrenzt vielen Personen ausgelöst werden, unabhängig von deren Lizenz. Pro Process-Lizenz sind 250.000 Aktionen pro Tag inklusive. Das ist der saubere Weg, wenn viele Nutzer einen Premium-Prozess anstoßen.

Zählen Copilot und KI-Agenten als Multiplexing?

Seit Mai 2026 nennt Microsoft Automatisierung ausdrücklich in der Definition. Teilt ein lizenzierter Nutzer einen KI-Agenten mit Kollegen ohne eigene Lizenz, und arbeitet der Agent für diese Kollegen, braucht jeder von ihnen eine eigene Agent-365-Lizenz. Der reine Zugang zu einem geteilten Agenten senkt die Zahl der Lizenzen nicht.

Muss ich für Dynamics-Daten in Snowflake Lizenzen zahlen?

Wenn die Daten automatisiert dorthin fließen, ja. Wer Dynamics-365-Daten nutzt, braucht eine passende Dynamics-Lizenz, egal durch wie viele Zwischensysteme die Daten liefen. Eine Team-Member-Lizenz ist dabei nicht automatisch das Minimum. Ein rein manueller Export durch eine lizenzierte Person unterbricht diese Kette.

Wie streng prüft Microsoft Multiplexing?

Es gibt keinen Automatismus, der Verstöße erkennt und automatisch nachberechnet. Die Durchsetzung läuft über formale Lizenz-Audits. Neu ist, dass Cloud-Protokolle indirekte Nutzung heute klar belegbar machen, was im On-Premises-Zeitalter kaum möglich war.