Etter oppkjøpet: multi-tenant er ikke en overgangsfase

Hvorfor tenant-konsolidering tar år, og hva du gjør i mellomtiden

Hvorfor konsolidering drar ut

Å slå sammen to Entra-tenanter er ikke en migrering av brukerobjekter. Det er en migrering av alt som henger i dem:

• Postkasser og OneDrive-innhold må flyttes på tvers av tenanter, med nedetid og oppfølging av delegeringer som ikke overlever flyttingen.
• Enhetene må rejoines. En Entra-joined maskin kan ikke flyttes til ny tenant uten å tørkes og rulles ut på nytt — som betyr fysisk logistikk for hver enkelt ansatt, og en Autopilot-avregistrering i riktig rekkefølge.
• SSO-integrasjoner må bygges på nytt i den nye tenanten, med nye app-registreringer, nye claims, og en avtaleeier hos hver SaaS-leverandør som skal godkjenne endringen.
• Domener kan kun være verifisert i én tenant om gangen, som gjør cutover til en hard, ikke-inkrementell hendelse.
• Compliance-historikk — retention policies, eDiscovery-hold, revisjonslogger — følger ikke med.

Legg til at det oppkjøpte selskapet vanligvis har et pågående kvartalsregnskap, en produksjon som ikke kan stanse, og en IT-avdeling på to personer som allerede er overarbeidet. Konsolideringen blir utsatt til «etter årsskiftet», hvert år.

Og så kommer neste oppkjøp.

Konklusjonen: multi-tenant er sluttilstanden

Dette er den strategiske omvurderingen mange konsern ikke har tatt: hvis konsolidering aldri blir ferdig, er multi-tenant ikke en overgangsfase som skal tåles — det er driftsmodellen, og den bør styres som en modell og ikke som et etterslep.

Microsoft har verktøy for dette, og de er verdt å kjenne grensene til.

Cross-tenant access settings styrer B2B-samarbeid mellom tenantene. Standardverdiene er åpne: inbound og outbound B2B collaboration er tillatt, ingen organisasjoner er forhåndskonfigurert, og ekstern MFA eller enhetsstatus er ikke tiltrodd som standard. Å endre det siste — trust settings — krever P1. Det er en konkret konsekvens: uten P1 og eksplisitt konfigurasjon vil et datterselskaps MFA ikke telle når brukeren jobber i morselskapets ressurser, og brukeren må autentisere på nytt.

Cross-tenant synchronization kan opprette og vedlikeholde B2B-brukere automatisk i en annen tenant. Krever P1.

B2B direct connect (for delte Teams-kanaler) er blokkert som standard og krever P1 i begge tenanter.

Ingen av disse gir deg felles administrasjon. De gir deg samarbeid. Administrasjonsarbeidet — brukeropprettelse, lisens, gruppemedlemskap, enhetsutrulling, offboarding — utføres fortsatt per tenant, i separate konsoller, med separate rolletildelinger og separate audit-logger med hver sin 30-dagers retensjon.

Regnestykket i separate konsoller

Vurder en helt vanlig ansettelse i et konsern med elleve tenanter. Den nyansatte skal ha tilgang i tre av dem — sitt eget selskap, konsernets fellestjenester, og et prosjektmiljø. Det betyr:

• Én brukeropprettelse i hjemtenanten, med lisens, gruppemedlemskap og enhetsutrulling
• To B2B-invitasjoner, hver med sitt eget gjesteobjekt uten utløpsdato
• Tre separate audit-spor, i tre separate logger, med tre separate retensjonsklokker

Ved avgang skal alle tre reverseres, i riktig rekkefølge, av tre ulike administratorer som ikke nødvendigvis vet om hverandre. Det er her «tilgang-etter-avgang» blir en systemisk tilstand og ikke en enkeltfeil: gjesteobjektet i tenant to overlever både at kontoen i tenant én deaktiveres og at inviterende ansatt selv slutter.

Due diligence-vinkelen

Ved neste oppkjøp er dette også et forhandlingsspørsmål. Hvor mange privilegerte kontoer har målselskapet? Hvor mange gjestebrukere, invitert av hvem, aktive når? Hvor mange enhetsobjekter uten eier? Hvor mange app-registreringer med Directory.ReadWrite.All og en klienthemmelighet som utløper om fire måneder?

Å svare på dette manuelt tar uker med konsulenttimer, og svaret er utdatert når det leveres. Det er også nøyaktig den typen risiko som ikke fanges i en finansiell due diligence, men som blir kjøperens problem fra dag én.

For selskaper omfattet av digitalsikkerhetsloven — energi, transport, helse, vannforsyning, bank, finansmarkedsinfrastruktur og digital infrastruktur — er kravet i forskriften § 12 om å «følge opp at personell ikke har flere tilganger enn nødvendig» ikke opphevet av at konsernet består av elleve tenanter. Kravet er det samme; kompleksiteten i å oppfylle det er elleve ganger større.

Hva dette betyr for Entra Logic

Entra Logic er multi-tenant fra grunnen, ikke påbygget i etterkant på et enkelttenant-produkt. Tenant-bytte ligger i den globale toppmenyen, hver modul har per-tenant-konfigurasjon, feltnavn og aktiverte moduler kan tilpasses per selskap, og kostnadsrapporteringen fordeles på selskap eller kunde.

Det praktiske utslaget: samme styrte modell for én tenant eller hundre. Vekst gjennom oppkjøp krever ikke en tilsvarende økning i antall privilegerte operatører — og et nylig oppkjøpt selskaps identitetslandskap kan gjøres søkbart på dager i stedet for kartlegges manuelt over måneder.

En presisering det er verdt å holde skarpt: konsern- og porteføljestyring er hovedbruksområdet. MSP-drift er et beslektet, men ikke identisk, bruksområde. De to bør ikke fremstilles som samme sak.

Kilder

• Microsoft Learn — Cross-tenant access overview
• Microsoft Learn — Configure external collaboration settings
• Microsoft Learn — Windows Autopilot registration overview
• Microsoft Learn — Data retention for Microsoft Entra monitoring and health
• Lovdata — Digitalsikkerhetsforskriften (FOR-2025-06-20-1131)