Microsoft Entra Tenant Governance - Simply Explained

0:00 There's a risk hiding in your Microsoft three hundred sixty five setup that nobody talks about, and it starts with a tenant your own team created. A tenant is one private island inside Microsoft's cloud, and companies quietly end up owning several without meaning to. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. Today we're talking about Microsoft Entra tenant governance explained in plain words for beginners. By the end, you'll understand what tenant governance is, why it exists, and how to spot the tenants your company forgot it had. What a tenant really is. Before we go any further, we should agree on one word because it carries this entire topic. A tenant is an instance of Microsoft Entra ID, which is the directory that holds one organization's users, groups, devices, and app registrations.

0:43 If that sounds like a filing cabinet, you're close enough. The plain version is this a tenant? Is your company's private space inside Microsoft's cloud and everything your people can sign into lives inside it. A tenant does two jobs at once. It proves who someone is when they sign in, and it decides what that person is allowed to reach once they're in. Both jobs sound simple, and together they shape almost everything that happens across Microsoft three hundred sixty five. One way to feel that boundary is to picture your own work account. When you sign in on a Monday morning, the sign in gets checked against your tenant, and the apps that open afterwards are the ones your tenant allows. A colleague at another company signs in the same way against their own tenant, and the two directories never mix unless somebody deliberately builds a bridge between them. That reach runs from the email. A new hire can open on day one to the files.

1:24 A contractor should never touch. The detail that matters most for beginners is that a tenant is a boundary. Treat it like a folder and you'll miss what it's actually doing when you open Teams or Outlook. You can find and work with people inside your own tenant. Everyone in every other tenant is invisible to you by default. That separation is deliberate because tenants hold the most sensitive data a company has, and keeping them apart is how Microsoft stops one organization's information from reaching another's. Some companies even place a tenant in a specific region or cloud to satisfy data residency rules. That's why two tenants belonging to the same business can look completely different on the inside. So a tenant is one private island. Your users live there, your data lives there, and the walls stay high. By design, that sounds tidy until you remember that a company isn't always one island.

2:09 Plenty of organizations end up with several without ever planning for it. Why? One company has many tenants. Start with the reasons a company ends up with more than one tenant, because the list runs longer than you might expect. When two organizations merge, the company being bought usually brings its own tenant along. Untangling that takes years rather than weeks. And until it's done, both tenants keep running side by side. When a group owns several subsidiaries that run independently, each one often keeps its own tenant, its own rules, and its own administrators. The parent company owns them all on paper and inside Microsoft three hundred sixty five, they're still separate worlds. Then there are the structural reasons, and they're just as ordinary. A company might split part of itself off and hand that part a fresh tenant. It might be required by law to keep data inside a particular region.

2:51 So it builds a tenant there and leaves the rest of the business alone. It might also stand up separate tenants for testing and staging so that a broken experiment never reaches the environment people actually work in. None of those are accidents, and each one adds another island to the map. A test tenant built for a two week project has a habit of outliving the project by years. The last reason is the one that surprises people. Departments and individual employees create their own tenants, often for a quick pilot or a product demo, and they do it without telling anyone. Microsoft calls these shadow IT tenants because central it doesn't administer them and often doesn't even know they exist. A manager with a company card can have a working tenant running by the end of the afternoon. That tenant arrives with users, mailboxes and file storage already in place.

3:32 The result is a kind of sprawl that grows quietly, and every acquisition, new region and ambitious side project can leave one behind. Nobody sets out to build that, and it happens anyway. Now picture what that adds up to across a whole organization. The company you work for might own five tenants or fifty, and no single list anywhere says which ones exist or who looks after them. The tenants you already know about are probably fine because someone is watching them. The ones nobody knows about are the interesting ones, and one of them is a problem most companies haven't noticed yet. The tenant nobody is watching. Now we reach the hard part and it has nothing to do with technology. You can't check the settings on a tenant you don't know exists. If nobody in central it has heard of a tenant, then nobody has reviewed its security settings, its guest access, or the person holding its administrator role.

4:18 The tenant keeps running quietly outside every process you build to keep things safe. It's tempting to point at the wrong danger here. Ask a room of beginners what worries them about identity, and, they'll say, an outside attacker, a stolen password, or a clever phishing email. Those threats are real, and they earn plenty of attention and budget. The quieter problem is a tenant your own people created, set up in a hurry and then forgotten. An attacker doesn't need to break down your front door when a side entrance has been standing unlocked for two years. Think about what that means in practice. The tenant nobody watches is also the tenant. Nobody patched, nobody reviewed, and nobody gave a second thought to. It's the gap between what your organisation believes it runs and what it actually runs. None of that is a small thing to shrug off because the risk lands directly on your security and compliance goals.

5:00 A tenant that nobody administers can be misconfigured in ways that expose data, and because it sits outside your normal processes, it won't show up in the review you run every quarter. An auditor asking who can reach a particular set of files won't be satisfied by a shrug. You can only fix what you can see, and right now, the list you're working from is incomplete. The good news is that Microsoft built a way to find these tenants, and it leans on clues your environment has been giving off all along. Finding the tenants you forgot about. This is the job Microsoft Entra Tenant Governance was built to do, and it starts with something called related tenants. The idea is simple instead of asking you to list every tenant your company owns, Microsoft studies the connections your tenant already has. Then it shows you the other tenants sitting on the far end of them.

5:40 It leans on three signals to do that. The first is business to business activity, which covers guest sign ins, guest registrations, and administrative access flowing in and out between your tenant and other ones. The second signal is multi-tenant applications that covers apps registered in your tenant that reach into other tenants and apps from other tenants that hold permissions inside yours. The third signal is billing, and that's the one that catches people off guard. Two tenants can be connected for no reason other than a shared billing account. Nobody has to invite anyone and nobody has to sign in anywhere. If another tenant is paying for services through your billing account or yours is paying through theirs, the connection already exists for the system to find. It surfaces on the list without you doing a thing. The beauty of discovery is that it asks nothing of you. You don't have to remember the tenant's name, and you don't have to track down the person who set it up.

6:24 Those connections do the work, and the list builds itself from evidence that was sitting there the whole time. One correction matters most here, though. A related tenant isn't the same thing as a tenant you own. It simply means there's a live or historical connection worth examining. Plenty of related tenants will turn out to be a partner, or a vendor, or a project from years ago that quietly wrapped up. Seeing them on the list is the whole point, because you can't make a sensible decision about a connection you never knew you had. Knowing which tenants you're dealing with is step one, and acting on that list turns out to be simpler than it sounds. Bringing tenants under one roof. Once you can see the tenants, the next step is deciding what to do with the ones you want to keep. That's where governance relationships come in, and the name makes them sound heavier than they are.

7:05 A governance relationship is a directional link between two tenants. One tenant governs, the other is governed. And this isn't a merger because the governed tenant keeps its own users and its own data the whole time. Setting one up takes a three step handshake. The tenant that will be governed sends the other one an invitation. The other tenant replies with a request, and that request carries a policy template spelling out exactly what it wants to be allowed to do. The governance tenant then reviews it and accepts and the link goes live. What you get out of that is administrative access from a single place, using accounts in the governing tenant. That beats building and maintaining separate admin accounts in every tenant you manage. And it means fewer sets of credentials to lose track of. That matters because the alternative is grim.

7:46 Without a relationship, managing several tenants means holding a separate set of administrator credentials for each one. Every extra set is another thing to protect, rotate and eventually lose. There are limits worth knowing before you plan anything. One tenant can govern many, and several tenants can govern one. But a tenant can't be both a governing tenant and a govern tenant. So you won't build a chain where tenant A governs tenant B, and tenant B governs tenant C. That might sound one sided, and it isn't because a governed tenant can always walk away. It can end the relationship whenever it chooses, and the governing tenant receives an email telling them it happened. Two more pieces. Finish the picture. Configuration monitoring lets you write down the settings you expect and take a snapshot of what you actually have.

8:26 A monitor then compares the two every six hours across more than two hundred resource types. Those types span six Microsoft services, including Intra Intune, Exchange, Online Teams, Purview and Defender. Secure tenant creation then lets you control who's allowed to spin up a new tenant, and it sets up a governance relationship with that tenant automatically, so it never starts life unmanaged who gets in and who gets out. Tenant governance covers the tenants your company owns. Cross tenant access settings cover the ones you don't, which usually means partners, customers, and vendors. These settings decide how your tenant works with other Microsoft Entra organizations, and they come down to two directions. Inbound is who from the outside can reach your stuff. Outbound is what your own people can reach on the outside.

9:08 You can set both for everyone or narrow them to specific users, groups, and applications. There's also a trust setting that lets you accept another organization's multifactor authentication and device checks. A partner who already signed in securely at home then doesn't have to repeat the whole process inside your tenant. The default here is worth remembering because it catches people by default. Any external Microsoft Entra organization can collaborate with yours through business to business collaboration, while a more direct form of connection stays blocked. That default is friendly and open, and it's exactly why so many organizations tighten it later on. Those defaults exist to make collaboration easy and easy is exactly the problem when nobody revisits the settings. A rule that was perfect for a three week project can quietly become the way your company talks to the outside world, three ways exist for tenants to work together.

9:55 Business to business collaboration adds external people to your directory. As guest objects. You can track and manage business to business. Direct connect sets up a mutual trust for teams, shared channels, and those users never appear in your directory at all. Cross tenant synchronization goes furthest of the three, keeping guest accounts created, updated, and removed automatically as people join and leave the organization. Then there's a control aimed at your own users. Tenant restrictions stop people on your managed devices and networks from signing into unknown tenants or from using accounts. Another company handed them. The clean way to hold all of this in your head is three short lines. Inbound is outside people reaching your apps and outbound is your people reaching outside apps. Tenant restrictions is outside accounts reaching outside apps.

10:35 One warning before you change any of it, tightening these defaults can break real collaboration that people depend on every day. Check who currently relies on the access before you flip anything, and keep in mind that sign in logs may only reach back thirty days. Narrowing power inside one tenant. Everything so far has been about moving between tenants. There's a separate set of tools for controlling what happens inside a single one, and the first of them is the administrative unit. An administrative unit is a container that holds users, groups or devices, and it limits an administrator role to just that slice of the organization. Picture a company with support staff spread across three regions with nothing in place, giving one of them the help desk administrator role hands that person power over every user in the company. With an administrative unit, you place the regions users inside the container and scope the role to that container.

11:19 The person can then only help the people they actually support. A beginner trap hides in that setup, and it's easy to fall into if you assign a role to someone who isn't a member of the administrative unit, the scope of that role becomes the entire tenant. One missing membership turns a careful, narrow permission into a company wide one. Two smaller limits are worth filing away as well. Administrative units can't be nested, and adding a group to one brings the group into scope, but not the people inside it. The other tool in this section is guest governance, and it decides who can join your tenant from outside. Here, the default is more open than you would guess because every user in your organization, including existing guests, can invite external users. You can narrow that to member users, to specific admin roles or to nobody at all. You can also decide what a guest gets to see once they're in.

12:02 That runs from the same access as a member down to nothing but their own profile, and you can allow or block entire domains from being invited in the first place. The idea behind both tools is the same, and it's worth saying plainly, you don't hand everyone the same power and hope for the best. You decide who needs what, give them exactly that and leave the rest alone. Two settings and the difference between a tidy directory and one that slowly fills with strangers naming ownership and beginner mistakes. Before we wrap up, it helps to turn all of this into a few practical habits, and to name the mistakes that trip up. Beginners. Start with naming and ownership. Give every tenant a name that says what it's for, because a list of vague names helps nobody at two in the morning ownership matters even more. A tenant's billing asset is the record that shows who really owns it, and it's tied to one tenant.

12:46 That's the thing to check when nobody is sure where a tenant came from. The mistake Waiting here is a tenant that only one person can administer. When that person leaves, so does your access and winning it back becomes a project instead of a task. From there. A few more mistakes catch people out. Assuming one company means one tenant leaves every other tenant invisible. Ignoring the shadow tenants because they aren't on any list is the next one, even though those are the tenants most likely to be misconfigured. Scoping an administrator role, but forgetting to place the person inside the administrative unit quietly hands them the whole tenant. Leaving guest invitations open to everyone is easy to do because that's the default and it rarely gets a second look. Locking down cross tenant access in a hurry breaks collaboration that people were relying on and expecting a tenant to both govern and be governed.

13:29 Run straight into a limit the system won't let you cross. Notice what those mistakes share. None of them come from advanced technology. They come from assumptions, defaults, and loose ends, and every one of them gets easier to avoid once you can see the whole picture. None of these mistakes require a careless person either. Most of them happen because the default was left alone, or because a task was finished before anyone asked who would own it afterwards. A mistake you can spot early is just a to do item, and that's the real value of seeing the whole picture. The recap. And one question for you. So let's bring it back to one idea. A tenant is a private island inside Microsoft's cloud, and companies end up with several of them for reasons that made sense at the time. Tenant governance is the set of tools for finding those islands, connecting the ones worth keeping and keeping their settings honest.

14:10 The goal was never to lock everything down. The goal is to know what you actually have because you can't govern what you can't see. Here's the one question I want to leave you with. Of all the tenants your company is connected to, which ones do you genuinely own and which one would surprise you most if it turned up on the list tomorrow? Sit with that for a minute, because the answer usually says more about your environment than any audit report will. None of this needs to be scary, and none of it needs a huge budget. It starts with a list, a few questions, and the willingness to look at the tenants nobody has asked about in a while. If this made tenant governance feel a little less mysterious. Subscribe to M365 FM, where we keep turning Microsoft's most confusing topics into plain English. Thanks for listening.