Consulting Briefing · 23.04.2026 · boddenberg.de

Sharing-Link-Expirations in SharePoint und OneDrive als Governance-Kontrolle

Executive Summary

Microsoft stopft endlich ein Loch, das jeder SharePoint-Admin seit Jahren kennt: die internen "People in your organization"-Sharing-Links hatten bisher die Halbwertszeit von radioaktivem Müll. Einmal erzeugt, bleiben sie bis zum Hitzetod des Universums aktiv. Mit Roadmap-Eintrag MC1242772 bekommen wir ab Mitte März 2026 eine Ablauf-Policy, die diese Links automatisch nach einer von dir festgelegten Anzahl Tagen schließt. Konfiguriert wird das – typisch Microsoft – nicht über die hübsche Admin-UI, sondern per PowerShell.

Die Policy kennt zwei Hebel: einen empfohlenen Zeitraum (der als Default im Dialog vorgeschlagen wird) und ein hartes Maximum. Beides lässt sich getrennt für SharePoint und OneDrive einstellen, plus optional als Site-Level-Override für Spezialfälle. Der Rollout läuft bis Ende Mai 2026 weltweit, bei GCC, GCC High und DoD bis Ende Juni 2026.

Für dich heißt das: Bevor irgendjemand im Helpdesk panisch Tickets schließt, weil Vertriebslinks am Freitagabend plötzlich nicht mehr funktionieren, solltest du vorher darüber nachdenken, wie deine Governance aussehen soll – und die Nutzerkommunikation darauf abstimmen.

Worum geht es im Detail? Und warum jetzt?

Kurzer Realitätscheck: Wenn du in einer durchschnittlichen Organisation heute auf "Freigeben" klickst und den Standard "People in your organization" wählst, erzeugst du einen Link, der praktisch ewig funktioniert. Genauer: bis jemand ihn aktiv widerruft oder die Datei gelöscht wird. Das Ergebnis kennst du aus jedem Audit: In Teams-Chats von 2021 klebt noch ein Link zum Q3-Forecast, den niemand jemals deaktiviert hat. Der Kollege, der den Link damals verschickt hat, ist längst bei der Konkurrenz – der Link selbst lebt ungerührt weiter.

Die neue Policy kommt technisch als vier Tenant-Properties pro Dienst (also acht insgesamt) sowie einer Site-Override-Option. Die Namen sind zum Glück selbsterklärend: CoreOrganizationSharingLinkMaxExpirationInDays, CoreOrganizationSharingLinkRecommendedExpirationInDays – und jeweils ein OneDrive-Pendant. Werte zwischen 7 und 730 Tagen sind möglich, 0 deaktiviert den Zwang. Site-Level-Overrides brauchen zusätzlich das Flag OverrideTenantOrganizationSharingLinkExpirationPolicy = $true. Alles klassisch über Set-SPOTenant bzw. Set-SPOSite im aktuellen Microsoft.Online.SharePoint.PowerShell-Modul.

Der wichtige Twist steckt im Umgang mit bestehenden Links: Neu erzeugte Links erben sofort die konfigurierte Ablaufzeit. Altlasten werden nicht rückwirkend angefasst – aber sobald ein Empfänger nach Policy-Aktivierung auf einen alten Link klickt, wird auch der an die Policy angepasst. Microsoft nennt das "beim nächsten Zugriff". In der Praxis bedeutet das: Du siehst die Wirkung nicht an Tag eins, sondern sie schleicht sich wellenartig in dein Audit-Log.

Der Hintergrund ist übrigens nicht nur DSGVO-Hygiene. Copilot hat das Thema Oversharing in den letzten achtzehn Monaten in die Vorstandsetage getragen. Wenn dein Chat-Agent plötzlich aus einem drei Jahre alten "People in your organization"-Link die Gehaltstabelle zusammenfasst, wird aus einer lästigen Zugriffsfrage sehr schnell ein Compliance-Thema mit Namen. Link-Expirations sind damit einer der billigsten Hebel, um Copilot-Risiken zu senken, ohne gleich in Sensitivity Labels und Purview-Projekte zu investieren.

Abb. 1: Rollout-Zeitstrahl – plane deine Kommunikation entlang dieser Phasen.

Was sind Chancen? Was sind Risiken?

Die Chancen sind offensichtlich und werden von jedem ISO-Auditor beklatscht. Ablaufende Links reduzieren das Angriffsfenster, wenn Endgeräte kompromittiert werden, senken den Aufwand bei Mitarbeiteraustritten und erleichtern Data-Subject-Access-Requests. Wer jemals versucht hat, nach einem DSAR-Ticket alle Links auf ein konkretes Dokument zurückzuverfolgen, versteht intuitiv, warum "gar keine Links nach 180 Tagen" ein echter Fortschritt ist.

Besonders wichtig: Der zweite Hebel – Recommended – gibt dir die Möglichkeit, eine Soft-Nudge-Strategie zu fahren. Du stellst als Max einen konservativ großzügigen Wert ein (etwa 365 Tage), als Recommended aber beispielsweise 90 Tage. Die Sharing-UI zeigt 90 als Default an, die meisten Nutzer klicken das durch. Nur wer es wirklich braucht, schraubt den Wert hoch. So erreichst du den Governance-Effekt, ohne einen Sturm an Support-Tickets von Vielteilern auszulösen.

Die Risiken liegen – wie so oft – im Detail und in der Kommunikation. Erstens gibt es heute keinen "betroffene Links"-Report. Niemand kann dir verbindlich sagen, wie viele Dokumente nach der Aktivierung in welcher Zeit neu geteilt werden müssen. Du fliegst in den Nebel und hoffst, dass deine Helpdesk-Kapazität ausreicht. Zweitens: Sharing-Links in Formularen, Listen-Webparts und automatisierten Flows verhalten sich teilweise sperrig. Einen automatisch erzeugten Link in einem Power-Automate-Flow nach 90 Tagen ablaufen zu lassen, bricht dir mit Ansage Workflows – und zwar genau dann, wenn gerade niemand im Büro ist.

Drittens – der Klassiker – ist das Thema Frontline-Worker und Produktionsbereiche. Eine Schichtübergabe per OneDrive-Link, die alle zwei Monate als Routine läuft, fällt bei 30-Tage-Max-Policy krachend auf die Nase. Mach dir vor der Aktivierung klar, welche realen Prozesse in deinem Haus auf quasi-ewigen Links basieren. Und plane dafür Site-Overrides ein.

Abb. 2: Wirkmodell – vom Tenant-Setting bis zur 403-Fehlermeldung beim Empfänger.

Aus dem Feld: drei anekdotische Konstellationen

Fall 1 – Mittelständischer Maschinenbauer, 2.200 Mitarbeiter. Der Geschäftsführer teilt seit 2019 denselben OneDrive-Link zur Strategie-Präsentation an wechselnde Vertrauenspersonen. Niemand hat je nachgeschaut, wer da alles Zugriff hat. Nach Aktivierung einer 180-Tage-Max-Policy meldet sich die Assistenz im Helpdesk mit der Erkenntnis, dass auf diesem einen Link 47 Personen stehen – davon sieben ehemalige Mitarbeiter. Die Policy hat das Thema nicht verursacht, aber endlich sichtbar gemacht.

Fall 2 – Versicherer, 6.000 Mitarbeiter. Operations hat über Jahre einen Teams-Kanal mit verlinkten Schichtplänen etabliert. Die Links zeigen auf SharePoint-Dokumente, die wöchentlich aktualisiert werden. Hier ist ein 90-Tage-Default völlig harmlos – die Datei ändert sich ohnehin ständig. Aber die verlinkte Excel-Tabelle für Feiertagsplanung mit Gültigkeit zwölf Monate wird nach 90 Tagen unzugänglich. Lösung: Site-Override auf 365 Tage für genau diese eine Projektseite.

Fall 3 – Konzern mit Copilot-Pilot. Der CIO bekommt vom Datenschutz die Ansage, Oversharing zu reduzieren. Statt ein sechsmonatiges Purview-Projekt aufzusetzen, wird in drei Wochen eine Sharing-Link-Expiration von 180 Tagen empfohlen und 365 Tage Max eingeführt. Copilot-relevanter Langzeitmüll sinkt messbar – die Zahl der Copilot-Antworten aus Dokumenten über ein Jahr Alter geht nach sechs Monaten um rund 40 Prozent zurück. Kein einziges Sensitivity-Label wurde dafür angepasst.

Was müssen wir jetzt schon vorbereiten?

Erstens: Policy-Entscheidung treffen, und zwar nicht im stillen Kämmerlein des SharePoint-Admins, sondern gemeinsam mit Datenschutz, Compliance, Betriebsrat und mindestens einem Fachbereichsvertreter aus operativen Einheiten. Die Frage ist weniger "welche Zahl?" als "welche Story erzählen wir den Nutzern?".

Zweitens: Tenant- und Site-Bestandsaufnahme. Welche Site Collections haben extreme Sharing-Muster, lange Lebenszyklen, dokumentierte Ausnahmen? Genau dort brauchst du Site-Overrides. Microsoft gibt dir kein fertiges Reporting an die Hand – du musst dir das mit Purview, Microsoft Graph (sharedWithMe) und dem SharePoint-Audit-Log selbst zusammenbauen.

Drittens: Nutzerkommunikation. Erwarte mindestens zwei Fragen in jedem Fachbereich: "Warum funktioniert mein Link nicht mehr?" und "Kann ich das umgehen?". Darauf brauchst du eine klare Antwort, idealerweise als einseitiges Intranet-FAQ, und einen internen Helpdesk-Kurzleitfaden mit den drei häufigsten Szenarien (neuer Link anfordern, Empfänger erneut hinzufügen, Site-Override beantragen).

Viertens: Integrationen prüfen. Power Automate, Power Apps, SharePoint Framework Webparts, Teams Tabs, externe Wikis und Ticket-Systeme – überall wo "People in your organization"-Links kleben, musst du vor Aktivierung wissen, was passiert. Bau dir eine kurze Inventarliste und lass deine Fachbereiche pro Anwendung bewerten, ob ein Link-Ablauf tolerierbar ist.

Fünftens: Auditing scharfschalten. Aktiviere gezielt die SharePoint-Audit-Events SharingSet, SecureLinkCreated, SecureLinkUsed und SecureLinkUpdated, damit du nach Policy-Start einen klaren Vorher-Nachher-Vergleich hast. Sonst diskutierst du sechs Monate später im Lenkungskreis auf Basis von Bauchgefühl.

Sechstens: PowerShell-Runbook vorbereiten. Die Konfiguration selbst ist in fünf Minuten erledigt, die Change-Dokumentation dauert länger. Bau dir ein versioniertes Skript, das Ist- und Soll-Zustand dokumentiert, damit dein Nachfolger in zwei Jahren noch versteht, warum genau 180 Tage stehen.

Fazit aus der Kaffeeküche

Sharing-Link-Expirations sind kein revolutionäres Feature, sondern eine längst überfällige Lücke, die Microsoft jetzt schließt. Der eigentliche Gewinn steckt nicht in der Technik, sondern in der Chance, endlich eine belastbare Governance-Story für interne Kollaboration zu erzählen – ohne dafür ein halbes Jahr Purview-Projekt zu brauchen. Wer jetzt pragmatisch startet, mit Recommended-Nudge arbeitet und seine Helpdesk-Skripte sauber aufsetzt, bekommt die nächste DSGVO-Auditfrage schneller beantwortet als der Nachbar, der wieder einmal "das machen wir im nächsten Quartal" sagt. Und glaub mir: Im nächsten Quartal ist schon das nächste Roadmap-Item dran.