Eén link voor alles: wat de nieuwe deelervaring van Microsoft 365 verandert

Microsoft noemt het zelf de next generation of sharing: vanaf half september tot eind oktober 2026 krijgt elk bestand en elke map in SharePoint en OneDrive één primaire deellink. Microsoft spreekt van de hero link.

Ik vind het een verstandige stap. Het huidige model is voor gebruikers lastig uit te leggen en voor beheerders lastig te overzien. Tegelijk zitten er een paar kanten aan die in de aankondiging wat onderbelicht blijven. Die licht ik in deze blog uit, samen met wat ik je zou adviseren om nu te doen.

Geschreven door: Leo van de Haar

Waarom Microsoft dit verandert

Even kort de geschiedenis. In 2011 deelde je bestanden in SharePoint Online door rechten toe te kennen aan personen. Rond 2014 kwam daar het delen via links bij: een URL die binnen een bepaald bereik toegang geeft. Dat werkte goed, maar het heeft één bekend bijeffect.

Want wat gebeurt er in de praktijk? Iemand deelt een document via de mail. Een week later plakt een collega een link in een Teams-kanaal. Weer later maakt iemand een link met verloopdatum voor een externe partij. Je hebt dan drie URL’s naar hetzelfde bestand, elk met een eigen bereik en een eigen levensduur. Microsoft noemt dat link sprawl. Herkenbaar, en behoorlijk onhandig als je achteraf wilt uitleggen wie waar precies bij kan.

De hero link moet daar een einde aan maken: één link per item, waarvan je het bereik achteraf aanpast in plaats van dat je een nieuwe link maakt en rondstuurt.

Wat verandert er precies?

• Eén primaire link. In het deelvenster zie je voortaan één hoofdlink. Of je hem nu kopieert uit het deelvenster, meestuurt via de mail of gewoon uit de adresbalk van je browser plukt: het is dezelfde link.
• Standaard geeft de link géén toegang. De standaardinstelling is Alleen personen die aan het bestand zijn toegevoegd (Only people added to the file). Het bezitten van de URL levert dus op zichzelf geen toegang op.
• Je kunt het bereik verbreden. Naar iedereen binnen de organisatie, of naar iedereen met de link (als je beleid dat toestaat).
• Rechten kies je apart. Bekijken, bewerken, of bekijken zonder downloaden, afhankelijk van wat is toegestaan.
• Bereik aanpassen maakt géén nieuwe link. Dit is de kern van de verandering: de bestaande URL blijft werken, alleen de toegang erachter wijzigt.
• Personen direct toevoegen blijft hetzelfde. Volgens Microsoft blijft dit de eenvoudigste manier om iets te delen, en dat ben ik met ze eens.
• Bestaande links blijven werken. Die verhuizen naar Overige koppelingen (Other links) in het deelvenster.
• Gebruikers krijgen eenmalig een korte uitleg bij het openen van het nieuwe deelvenster.

Wat er goed aan is

Laat ik beginnen met het positieve, want dat is er zeker. De standaardinstelling is conservatief. Een link die uit zichzelf niets openzet, is een betere uitgangspositie dan wat veel organisaties nu hebben staan. Voor omgevingen waar “Iedereen met de link” ooit als standaard is ingesteld en nooit meer is herzien, is dit een stap vooruit.

Daarnaast verdwijnt een terugkerende irritatie. Nu moet iemand die het bereik wil wijzigen een nieuwe link maken en die opnieuw verspreiden, met als gevolg dat de oude link in een Teams-bericht of een ticket blijft staan en niemand meer weet welke de juiste is. Dat scheelt straks vragen aan de servicedesk.

Waar je als beheerder op moet letten

1) Een vaste URL betekent niet automatisch vaste toegang

Dit vind ik het belangrijkste punt om te begrijpen. Stel: het projecthandboek staat met zijn hero link in een Teams-kanaal. Op maandag staat die link op Alleen personen die zijn toegevoegd. Op vrijdag zet de eigenaar hem op iedereen in de organisatie.

De URL in dat kanaal is niet veranderd. Het aantal mensen dat het document kan openen wél. Dat kan volstrekt legitiem zijn, maar het is een wijziging in je autorisaties die je moet kunnen zien en verantwoorden. Waar voorheen een nieuwe link een zichtbaar signaal was, gebeurt die wijziging nu stilletjes achter een link die er hetzelfde uitziet.

Het werkt overigens ook de goede kant op: je kunt het bereik versmallen zonder dat iedereen zijn bladwijzers hoeft aan te passen. Maar het maakt wijzigingshistorie belangrijker dan link-inventarisatie.

2) Je oude rommel wordt niet opgeruimd

Bestaande links blijven gewoon werken en verhuizen naar Overige koppelingen. Dat is prettig, want er breekt niets. Maar het betekent ook dat je een periode hebt waarin één bestand zowel een hero link als een aantal oudere, doelgroep-specifieke links heeft.

3) De hero link vertelt je niet wie er bij kan

Effectieve toegang blijft de meest ruime combinatie van directe rechten, overgeërfde rechten, groepslidmaatschappen en linkrechten. Iemand kan bij een bestand komen via een Microsoft 365-groep, via overerving vanuit de site, als gast, via de hero link of via een oude link.

Kortom: de hero link vinden is niet hetzelfde als aantonen wie het document kan openen. Wie dat onderscheid niet maakt, trekt bij een audit de verkeerde conclusie.

4) Er is (nog) geen tenant-brede instelling

Je kunt het standaardbereik van de hero link instellen per SharePoint-sitecollectie of per OneDrive, met de parameter DefaultMainLinkScope in SharePoint PowerShell. De opties zijn OnlyPeopleAdded, Organization en Anyone, waarbij die laatste alleen effectief kan worden als anoniem delen op tenant- en siteniveau is toegestaan. Een site mag altijd strenger zijn dan de organisatie.

Wat er op dit moment níet is: een tenant-brede equivalent. Wil je voor honderden sites een afwijkende standaard, dan wordt dat scriptwerk. Houd daar rekening mee in je planning.

5) De rapportagekant loopt nog achter

Microsoft Graph documenteert de bekende link-scopes en -rollen, maar er is in de v1.0-documentatie nog geen volledig beeld van hero-link-specifieke zaken als tenant-brede detectie, wijzigingshistorie en verloopgedrag. Bouw je automatisering of rapportage op dit onderwerp, test dan eerst in je eigen tenant in plaats van uit te gaan van aannames.

Wat zou ik nu doen?

1. Controleer je eigen uitrolmoment. Zoek berichtnummer MC1454378 op in het Microsoft 365-beheercentrum. De uitrol loopt gefaseerd en tenants krijgen dit niet gelijktijdig.
2. Loop je deelbeleid na, zowel op tenant- als op siteniveau. Is “Iedereen met de link” toegestaan, en wil je dat nog?
3. Maak een nulmeting van je belangrijkste sites, bestaande links, gasten en gevoelige mappen. Dat is straks je referentiepunt.
4. Kies een pilotsite met niet-gevoelige content en test het nieuwe deelvenster zelf, voordat je vragen krijgt.
5. Kijk hoe een wijziging zichtbaar wordt in Toegang beheer, in de auditlogs en via PowerShell. Als je dat niet kunt terugvinden, weet je dat nu in plaats van tijdens een incident.
6. Werk je interne instructies bij. Alles wat je hebt geschreven over “maak een nieuwe link voor externen” klopt straks niet meer.
7. Communiceer gericht. Vooral naar mensen die veel met externe partijen of over teams heen samenwerken.

Wat betekent dit in de praktijk?

Microsoft zegt dat er vooraf geen actie nodig is. Technisch klopt dat: er breekt niets en er hoeft niets te worden geconfigureerd.

Maar als delen onderdeel is van je informatiebeveiligingsbeleid, dan zijn je documentatie, je gebruikersinstructies en je reviewproces verouderd op de dag dat dit binnenkomt. Niet omdat de functionaliteit slechter is (hij is op punten juist beter) maar omdat het onderliggende model verandert. Van “een link is een momentopname” naar “een link is een instelling die kan meebewegen”.

Bronnen

• https://techcommunity.microsoft.com/blog/onedriveblog/simple-smart-and-secure-the-next-step-in-sharing-files-in-microsoft-365/4411655
• RM492622 – Microsoft 365: The Next Generation of File & Folder Sharing | Microsoft 365 Message Center Archive