Entra ID Governance: Access Reviews, Entitlement Management and Lifecycle Workflows

M365 FM - Entra ID Governance - Access Reviews, Entitlement Management and Lifecycle Workflows

00:00:00 Speaker: Your entry ID. Governance isn't failing because it's missing features. The features are there. Access packages. Access reviews. Lifecycle workflows. Privileged identity management. It's failing because of the model behind it. The assumption that people will comply, that owners will actually check that someone will remember to remove access when it's no longer needed. That assumption is broken. So if you want identity governance explained as behavior, not as a feature list, subscribe to the M365 FM podcast. This episode covers access packages, access reviews, lifecycle workflows, licensing, privileged access, and how to design governance that people actually finish. But before the architecture. A short word on who makes this show possible. Sponsor segment one. This episode is brought to you by Stellar Migrator for exchange. Here's why that matters for a governance conversation. You can't govern an identity, a state you haven't cleanly moved. If your mid migration or you've just finished one, you probably have mailboxes in odd places, accounts that don't match and attributes that were copied over by hand. Governance runs on that data. Dirty move, dirty governance, stellar migrator for exchange is built for that migration work, moving mailboxes, consolidating tenants, getting the estate into a shape you can actually manage. It's the step that comes before any access review means anything if you run a product or service for IT pros and decision makers, and you want to reach this audience. Sponsorships and thought leadership slots are open on this show. The details are in the description. Now back to the problem, starting with what governance was supposed to be. The thesis governance is a behavior problem. Here's the claim for this whole episode. Enter ID governance works when it matches how people actually behave, and it fails when it assumes they'll comply. That's the thesis. Everything else is evidence. Think about what governance asks of a person. A manager gets an email that says review the access of twelve people. That manager has a calendar full of meetings, a deadline of their own, and no idea what half of those permissions even do. So what do they do? They click approve, not out of malice because it's the fastest way to make the email go away. That's not a people problem. That's a design problem. I'll argue it through three supports. First, ownership has to be real. Every package, every group, every role needs a named person with actual authority. Not a shared mailbox, not a team that no longer exists. A person who can say yes or no and be held to it. Second, defaults have to be safe. What happens when nobody acts? That single setting decides whether your governance protects you or quietly fails. If the default is approve, silence becomes permission. If the default is deny, silence can break production. You have to choose on purpose. Third, every task has to be small enough to finish four hundred names in one review isn't a task, it's a wall. Break it down and people walk through it. Leave it as a wall and they walk around it. Ownership defaults. Task size. Hold on to those three will keep coming back to them. Now the model. The old model treats access as something you clean up. Granted, when someone asks, let it pile up. Then once a year, run a review and try to dig out. The new model treats access as a life cycle. Something happens. A person joins, moves, leaves, and access changes in response. It's continuous. It's driven by events, not by the calendar. One model asks people to remember. The other doesn't need them to. Here's the road ahead. So you always know where we are. We start with why the old model breaks, then a map of what entry ID governance actually is and the identity data that fuels it. Then licensing because someone will ask what this costs from their entitlement management, access packages, policies expiry, and guests then access reviews, why they fail and how to design ones people complete then lifecycle workflows, joiners, movers and leavers, then privileged access and how to combine all of it into one system. We close with ownership metrics, rollout and the failure patterns you'll hit, but to see why the old model breaks, you have to look at what it was built on. The old model governance as a yearly event. In most organisations, governance looks like this a spreadsheet, a quarterly email, a deadline, someone in security or audit exports, a list of who has access to what it lands in a shared drive or in an inbox with a subject line like action required access recertification. There's a due date two weeks out. Everyone sees it, almost nobody feels it. And that's the whole system. It runs on memory, on goodwill, and on a calendar reminder that fires once every few months. Now look at what this model assumes. It assumes managers know what their people need. That a manager looking at a name next to a permission called finance reporting RW can say from memory whether that person still uses it, that the manager knows what the permission does, why it was granted, and whether the project behind it ended last spring, and it assumes they have time to check, not just time in theory time on a Tuesday afternoon between a budget meeting and a customer call, with their own deadlines stacked behind it. Neither assumption holds. Think about what the manager actually sees a row, a name, a system label that someone in it invented six years ago. No history, no context. Nothing that says this person hasn't touched this in eight months. So what typically happens is predictable. The manager opens the file, scrolls for a minute, sees mostly familiar names, nothing looks obviously wrong, and nothing looks obviously right either. And the cost of the two mistakes isn't equal. If they approve something they shouldn't. Nothing happens today. If they deny something that's needed. Someone's work stops and the phone rings by lunch. So they approve all of it. Not out of carelessness, out of a very rational read of the incentives. That's the first failure. The rubber stamp. The second failure is quieter. Orphaned access. An employee leaves. HR closes the record, but the person's access to a shared mailbox, a project site, an old SaaS tool. A legacy security group that lives in places HR never touches. Nobody removes it because nobody owns the removal, or a contractor finishes a six week job and their guest account is still active two years later, sitting in a team's team. Nobody has opened since. The third failure is the one that arrives with the auditor. You ask for evidence that access was reviewed, and you get a spreadsheet with a column of approved timestamps that show the whole thing was completed in eleven minutes, and no reasons attached. Technically it's evidence. Practically nobody trusts it, including the person who produced it. An auditor who sees one hundred percent approval rate doesn't see a clean environment. They see a process that doesn't ask a real question. Now step back and ask why access piles up in the first place? Because granting is easy. Someone needs something. They ask. A ticket gets opened, an admin adds them to a group. It takes minutes. There's a requester who's waiting, a person who's helped, and a closed ticket to prove it. Removing is different. Nobody asks for it. There's no requester, no ticket, no one waiting. Taking access away produces risk for the person doing it and no reward at all. So removal falls into the gap between teams and it stays there. Do that for five years across a few thousand people and you don't have a permission model anymore. You have sediment layers of old decisions, each one reasonable on the day it was made and none of them ever revisited. The annual review is meant to dig through that sediment, but one big dig a year done by people with no context and no time, can't clear what accumulates every single day. That's the structural flaw the old model treats access as a pile you clean up. But access isn't a pile. It's a flow. It changes every time a person joins, moves or leaves, and a yearly event can't keep up with a daily flow. Microsoft's answer isn't one tool that fixes this. It's a set of layers, each handling a different part of the flow. So before we judge any single feature, we need the map. What entry ID governance actually is. Entry ID governance isn't one product. It's a set of capabilities built around a single idea. Access should follow what's happening to a person, and it should end on its own. Here are the pieces. Entitlement management. This is how people request and receive access in bundles with approvals and an end date access reviews. A recurring question should this person still have this lifecycle? Workflows. Tasks that run when someone joins, moves, or leaves. Privileged identity management. PM. This is how admin roles stop being permanent. They become something you activate when you need them and terms of use. Small one, but it matters. It's the policy a person has to accept before they get in. Entry records that they did five capabilities, five different jobs. Try to remember them as five separate tools and you'll get lost fast. So here's a simpler way to hold it. Event reasoning orchestration event is the trigger. A person gets hired, a department changes. A last day arrives, a request comes in. Something happened. The system knows about it. Reasoning is the question the system asks in response. Should this person have this access? For how long? Who decides? Is it still justified six months from now? That's where access packages, policies and reviews live. orchestration is the follow through accounts get enabled, groups get updated, licenses come off, a manager gets a message. The decision turns into actual changes across the systems that matter. Event reasoning. Orchestration. Once you see it that way, each feature finds its place. Lifecycle workflows are mostly orchestration started by an event access reviews are reasoning run on a schedule. Entitlement management sits in the middle. Takes a request, applies. The reasoning carries out the result. Pim applies the same loop to the most dangerous access you have. Now, where does this sit? Next to the rest of entry. This is where people get confused. A lot of security terms sound alike. Conditional access decides whether a sign in is allowed. Right now it looks at the device, the location, the risk level, the app. Then it says yes, no or yes. But with MFA identity protection, watches for risk, a leaked credential, an impossible travel sign in a user behaving oddly, it scores that risk and feeds it into conditional access. Governance asks something different. It doesn't ask should this sign be allowed? It asks, should this person have this access at all? Governance answers who should have access conditional access answers under what conditions they can use it. Think about what that means. In practice, a user can pass every conditional access check, healthy device, trusted location, MFA, done and still hold access to a finance app they stopped needing a year ago. Conditional access did its job perfectly. Nobody asked the governance question. The reverse is true too. You can have a perfect governance model, tidy packages, clean reviews and still lose an account to a stolen token if signing conditions are weak. Two questions. Two layers. You need both. Then there's licensing. We'll cover that properly in a moment. For now, just the shape of it. Enter ID, p1 and P2 are the base tiers. P1 gives you conditional access and the core of the platform P2 adds identity protection and Pim plus some access review capability. Enter ID governance sits on top of those as an add on. It's the layer that brings in the fuller set entitlement management at scale, lifecycle workflows and the more advanced review features. So you don't get all of this by default. Some of it comes with what you already own, some of it you have to buy on purpose. That matters because plenty of teams plan a governance design around features they haven't licensed. But licensing isn't the first thing to get right. Every one of these capabilities the packages, the reviews, the workflows runs on one thing data, specifically the attributes sitting on each identity in your directory. If that data is wrong, every feature on this map works perfectly and produces the wrong result. So before features the identity data that drives all of it. Identity is the control plane. Identity data is the fuel. Identity is the control plane. Every access decision in Microsoft three hundred sixty five runs through it, but a control plane only controls what it knows and what entry knows about a person is a handful of attributes. Look at what governance actually reads. Employee hire date. Department manager. Employee type. Employee leave date time five fields. That's close to the whole engine. Employee Hiredate tells a lifecycle workflow when to start onboarding Department tells an access package policy who qualifies for a bundle manager tells the system who approves a request and who reviews it later. Employee type separates a full time employee from a contractor. A guest, an intern. An employee. Leave daytime tells the Offboarding workflow when to pull everything back. Now think about what happens when one of those fields is wrong. A new hire start date is blank. The joiner workflow never fires. Nobody gets an error. The person just shows up on day one with nothing. Someone opens a ticket. A manager field points to someone who left last year. The approval request goes to a person who can't answer it. It sits there or it escalates to a fallback. Nobody planned for. A department, says sales, because that's where the person started. Three roles ago, the access package rule built on department hands them the wrong bundle, or it never removes the old one. And here's the part that matters most. None of this announces itself. Bad data doesn't break governance loudly. It breaks it quietly. The workflow runs. The review goes out. The package gets assigned. Every dashboard says the system is working. It's just working on the wrong facts. That's why this is so hard to catch. A broken feature throws an error. Broken data produces a clean result that happens to be wrong. So where does the data come from? That's the source of truth question. In a mature setup, HR owns it. The HR system, something like workday or Successfactors holds the real record. When HR hires someone, changes a department, or sets a last day, that change flows into entra through inbound provisioning. HR is the source. Entra is the consumer. The other way is manual creation, and admin makes the account types in a title, picks a department from memory, maybe fills in the manager, maybe doesn't. Months later, nobody remembers what was entered or why. Look at the difference in behavior. In the HR driven model, a person has to do something wrong for the data to go bad. In the manual model, a person has to do something right every single time for it to stay good. That's the same pattern we keep running into. One model asks people to remember, the other doesn't. HR driven provisioning isn't free. Of course. It needs a clean HR system. First job codes that mean something. Managers recorded accurately leave dates entered before the last day, not three weeks after. If HR data is a mess, you've just moved the problem upstream and made it faster. But that's a better problem to have. It's one problem in one place with one owner, not a thousand small errors scattered across a directory. So here's the point I want you to take from this section. Attribute quality is the first architecture decision, not the last one. Most teams treat it as cleanup. Build the packages first. Design the reviews. Set up the workflows. Then near the end someone says we should probably check the data by then. Rules are written against fields that can't be trusted. Every rule inherits the flaw. Flip that order before you design a single package. Ask for questions. Where does each of these five attributes come from? Who owns it? How fast does it change each entry? And how would you know if it was wrong? If you can't answer those. No feature will save you. You'll just automate your mistakes at a larger scale with the data in place, or at least with a plan to fix it, you can start building and the first building block of access design is deciding what a unit of access even looks like. But before that, someone will ask what all of this costs. Licensing what you actually need to buy. Start with the part that surprises people. Microsoft Android Governance isn't a new tier that replaces anything. It's an add on. It sits on top of Android P1 or P2, and you need one of those underneath before it does anything. So you have two layers of spend, the base license and the governance license on top. Now here's where teams get tripped up. P2 already includes some governance. Privileged identity management comes with P2, so do basic access reviews and entitlement management has been part of the P2 story for years in its core form. So if you own P2, you're not starting from zero. But what P2 gives you is the foundation eligible admin roles just in time activation reviews of groups, apps and roles. That covers a lot of ground and plenty of tenants never use half of it. What the governance add on brings is the full asset lifecycle workflows. The more advanced entitlement management features, extra review capability like reviewer recommendations, and inactive user checks that go beyond the simple version and newer pieces Microsoft keeps adding under that umbrella. Here's the practical split in plain terms, Privileged Identity Management P2 covers it. Basic access reviews of groups and apps. P2 covers those two lifecycle workflows. That's the governance add on. This is the one that people miss. You can design a beautiful joiner mover leaver process on paper and then find out the license isn't there to run it. Entitlement management at the level most designs need with multi-stage approvals, custom extensibility, and the advanced policy options that also leans on the add on and the extras. The review features that make reviews smarter and not just recurring. Same story. I'll be honest about one thing Microsoft changes the packaging more often than anyone would like. Features move between tiers, names get adjusted. So treat what I just listed as the shape and check the current licensing page before you commit to a design that's not a hedge, it's the one step that saves you an awkward conversation. Three months in. Guests are different and they get their own model. For external users, Microsoft builds bi monthly active users, not by headcount. You get a free allowance of monthly active users per tenant, and beyond that, you pay per active user per month. Read that carefully. Active. A guest who never signs in that month doesn't count toward the bill that changes the economics of guest sprawl. A dormant guest account isn't costing you license money. It's costing you something harder to price risk. An account that sits there, valid, attached to a team nobody remembers waiting for someone to find it.

00:15:44 Speaker: And one more detail governance features applied to guests like running access reviews on them or putting them into access packages fall under that same external billing model. So the cost of governing guests scales with how many of them are actually in use, which, if you think about it, is a reasonable place to spend. Now, how do you frame this for an executive? The wrong pitch is we need to license the whole tenant. Nobody wants to approve that. And in many cases you don't have to. The better pitch is this license. The people being governed where the licensing model allows it, you scope the spend to the identities that actually use the governance features, the employees and lifecycle workflows, the users and access packages, the reviewers and the people being reviewed. Not every mailbox, every shared account, every service identity in the directory that reframes the question, it stops being what does governance cost and becomes which populations carry enough risk to justify it? Admins and privileged users first, then guests, then high turnover groups where movers and leavers pile up fast. And that's a cost conversation. An executive can actually say yes to a defined group, a defined price, a defined risk. It removes one caution. licensing rules here have edges, and scoping by group doesn't always work the way you'd expect for every feature. Verify it for the specific capability before you promise a number. Nothing damages trust faster than a budget that doubles at renewal. So that's the bill. What you own, what you add, and who you pay for. Now, the first capability worth paying for how access gets packaged entitlement management packaging access around context. Here's how access usually gets granted. Someone needs to do a job. They ask for a permission. An admin adds them to a group, then another group, then a site, then an app for requests for decisions, for separate pieces of access that nobody ever ties together. Six months later, nobody can say why that person has any of it. That's the flaw in granting individual permissions. A permission has no reason attached to it. It's just a fact in a directory. The reason lived in someone's head or in a ticket nobody will ever search for. Entitlement management starts from a different idea. Stop granting permissions. Start granting bundles tied to a business. Need not add Maria to the finance reporting group. Instead, Maria is joining the finance analyst team. So she gets the finance analyst package. One request, one decision. And the reason is built into the thing itself. To work with this you only need three nouns catalogs resources access packages. Start with resources because they're the easy one. A resource is something a person can be given access to and an entry. That list is wider than most people expect. A resource can be a security group. A Microsoft three hundred sixty five. Group A teams team. An enterprise application, a SharePoint site. These are the real things people need to get work done. Next. The catalog. A catalog is a container. It holds a set of resources that belong together, and it holds the packages built from them. Think of it as the boundary of a business area. One catalog for finance, one for engineering, one for a specific project or partner program. And the catalog does something more important than organizing. It decides who is allowed to build catalog owners and managers control which resources can go into packages. So the person designing finance packages can't quietly pull in an engineering application. The boundary holds, then the access package. This is the thing a person actually asks for. It's a bundle of resources from one catalog with the rules attached. Who can request it? Who approves it, how long it lasts. Catalog holds the pieces. Package combines them. Resources are the pieces themselves. Now why does bundling matter so much? Count the decisions. A new analyst needs a team, two groups, a reporting app, and a SharePoint site. In the old way. That's five requests, and each one lands in front of a different approver who sees a single name and a single label. Five chances to approve without thinking. Five chances to miss something and leave the person stuck in a package. That's one request. One approver looking at one clear description. Finance analyst access for new members of the finance team. Everything the role needs is inside it. Everything is granted together and it all leaves together. When the package ends. That's fewer decisions and fewer decisions is the whole point. Because every decision is a place where a tired person can get it wrong. There's a second effect, and it's quieter. Bundles make access explainable. When someone holds a package, you can ask a simple question why do they have this? The answer is the package. A business reason with the name. Compare that to a person sitting in thirty groups with no story behind any of them. That story is also what makes later steps work. A review can ask, does this person still need the finance analyst package instead of does this person still need group number nineteen? A manager can answer the first question. Almost nobody can answer the second. So a bundle isn't just convenient, it carries the context with it. But notice what I haven't said. I haven't said packages. Fix anything by existing. You can build one hundred of them, name them badly, scatter resources across them and give them to nobody in particular. Then you've recreated the same sediment just with nicer labels. A package is only as good as its design, and that design is where most of the real work sits. Designing access packages that match real work. Start with the first design decision. What is this package for? Most teams answer with an application the Salesforce package, the SAP package. It feels natural because that's how it thinks. Systems are the things it runs. So systems become the unit. But nobody gets hired to use Salesforce. They get hired to be an account executive, or to staff a project or to run payroll. The job needs Salesforce plus a team plus two groups, plus a shared site. The application is a piece of the work, not the work itself. So package by role or by project, not by application. A role package says this is everything. A regional account executive needs a project. Package says this is everything the migration team needs until the migration ends. Both carry a reason a manager can read in five seconds. An application package says here's a login, and then someone still has to ask for the other four things separately. That's the same fragmentation we started with just wearing a new label. Now a practical detail that saves real pain. Entitlement management lets one package hold several resources, and for each resource you pick a specific role. Member of this group, owner of that team. Contributor on this site, visitor on that one. So you can put the whole bundle in a single package. The analyst gets member access to the finance group member access to the reporting team, and read access to the budget site. One request, one approval, one end date. The alternative is fragmentation. Three small packages, each with its own policy, its own approver, its own expiry. Now the person holds three assignments that expire on three different days, and the manager approves three separate requests for what is in their head. One thing the rule I'd use is simple if the resources are always needed together, they belong in one package. If they are sometimes needed together and sometimes not split them, an optional extra like admin rights on a site deserves its own package with a stricter policy because it carries more risk than the baseline. But don't split by habit, split by risk, and by who decides next. Findability. A package nobody can find is a package nobody requests. They ask a colleague instead who points them at whatever they have, and the person ends up with a copy of someone else's access. That's the original problem. Back again. So naming matters more than it sounds. Pick a convention and hold it. Something like business area, then role or project, then level finance analyst. Standard engineering platform team elevated, short, sortable and readable by a person who has never seen it before and write the description for the requestor, not for the admin. One plain sentence. Who this is for and what it includes. If a new hire can't tell which package they need from the name and description alone. The name has failed. Catalog ownership works the same way. Every catalog needs a named owner who decides what goes in it and keeps it tidy. Not an inbox a person. When a package gets created in a catalog nobody owns. It stays forever because nobody has the authority or the reason to delete it. Which brings us to the failure mode. In most organizations, the first year of entitlement management goes well. A few clean packages, clear owners. Then the requests start. Can you make one just for my team? Can we have a variation with one extra site? Each request is reasonable. Each one takes ten minutes. Two years later, there are four hundred packages. Nobody understands them. Three of them look identical and differ by one group. Several are named after projects that ended requesters can't choose, so they pick the biggest one just to be safe. Owners can't review because they can't remember what half of their packages were meant to do. That's where it breaks. You've rebuilt the sediment one tidy package at a time. The fix is discipline at creation before anyone builds a new package. Ask whether an existing one already covers the need. Retire packages when the project ends and treat the package list itself as something you review, not just the people inside it. A short list of packages people understand beats a long list nobody trusts. So say the packages are clean and findable. Two questions are still open. Who is allowed to ask for one and who gets to say yes? Policies. Approvers and the request experience. A package is a bundle. A policy is the rule book attached to it. Every package needs at least one policy and a policy answers for questions. Who can request this? Who has to approve it? How long does it last and what happens to it later? Start with the first one who can request this sounds like a small setting. It's actually the front door. You can open a package to everyone in the directory, to members of specific groups, or to a named list of people. Narrow is almost always better for a roll package. If only finance staff need the finance analyst package, only finance staff should see it. Nobody browsing the catalog should have to guess which ones apply to them. Then there's the split between internal and external requesters. And this is where a lot of designs get muddy. Internal people are already in your directory. You know, their manager, their department, their employee type. External people aren't. They sit outside your tenant and you know almost nothing about them. For those users entry users, connected organizations, a connected organization is a partner you've declared on purpose a supplier, a customer, a contractor firm. You define it once by domain or by identity provider. And then a package policy can say, people from this organization may request this package. That's a very different posture from the usual one. The usual posture is that someone on your side sends an invitation and hopes for the best. Here the partner is known first, and the access request comes second through a policy. Anyone outside a connected organization can't even ask. Now the second question who approves? This is where behavior shows up fast, because an approval is only worth something if the approver can actually judge it. Take the manager. It's the default choice. And for roll packages it often makes sense. The manager knows the job, but a manager can't judge a request for a specialist tool in another department, and they definitely can't judge a request from a partner they've never met. For external users, use a sponsor. A sponsor is an internal person who vouches for the guest. Someone who invited them, works with them, and will notice when the work ends. That gives the approval. A human who actually knows the context for a sensitive resource use the resource owner, the person who runs the application or the site, and who answers for what happens inside it and always set a fallback, a group or a named person who gets the request. When the first approver doesn't act or has left, or has no manager on record. Remember what we said about stale manager fields? Without a fallback, a request can sit in someone's queue for weeks and the requester has no idea why nothing's happening. Policies also support stages one approver first, then a second one. For higher risk access. Use that sparingly. Every extra stage is another place a request can stall and another person who might click approve without reading. Now the part most teams treat as decoration the request form itself. When someone asks for a package, you can make them answer a justification prompt. You can add custom questions and you can decide which ones are required. Most organizations leave this blank or they add one question why? Why do you need this and get back for work one hundred times in a row? That's not evidence. That's noise. A better question is specific to the package for a project package. Which project? And who asked you to join for an elevated package? What task requires this level and for how long? For a partner package, which contract is this under specific questions produce specific answers and a specific answer has a second life. Months later, when an auditor asks why this person had this access, the reason is sitting in the record in their own words, timestamped. It also gives the approver something real to judge instead of a name and a label. But keep it short. Two or three questions, no more. A form that feels like a tax return gets abandoned, and then people go back to emailing admins. So a policy decides who, asks who answers, and what gets written down. But there's another half to every policy. It's the part that decides when the access ends, and it's the part most teams leave at the default expiry by default access that ends on its own. Here's the shift. The old model says access is permanent unless someone remembers to kill it. This model says access is temporary unless someone renews it. Same access opposite default. And that one flip changes who does the work under the old way, removal needs a person to notice, decide and act under the new way. Removal happens on its own and a person only acts if they want to keep something. Silence stops, meaning keep it. Silence means it ends. That's the safe default from the thesis, and it's built right into the policy. So let's look at how you set it. Every policy has an assignment duration. You choose how long a person holds the package. Once it's approved, thirty days, ninety a year, or a fixed end date, which works well for a project with a known finish line. You can also pick no expiry. And I treat that as a setting that needs a reason. If you can't say why a package should never end, it should end. Match the length to the risk and the rhythm of the work. A project package should last as long as the project, plus a little. A partner package should track the contract. An elevated access package should be short weeks, not years. The riskier the access, the shorter the leash. Then you decide what happens at the end. And this is where the design gets practical. When an assignment expires, the person's access is removed, the group memberships go, the app role goes, the site and team permissions go. Everything that package granted comes off together because it was granted together. That's another quiet benefit of bundling. Nobody has to hunt through thirty groups to find what belonged to this assignment. The package knows what it gave so it knows what to take back. Licenses follow the same logic. If a package assigned a license through a group, the license leaves. When the group membership leaves, a person who finishes a project stops consuming a seat and you stop paying for it. That's not a side effect worth ignoring for expensive licenses. Expiry is a cost control as much as a security one. One thing to plan for, though? Removal is real, if the person still needed that access, work stops. That's not a flaw in the design. It's the reason the next feature exists, because you don't want every renewal to become a full review. Entitlement management lets a person ask for an extension before the access ends. They get a notice. They open it, say, I still need this. Add a short reason and the request goes to the approver. Same as before. If it's approved, the end date moves. Think about how light that is. One question asked at the moment. It matters to the person who knows best whether they still use the thing. Not a spreadsheet with four hundred rows, not a manager guessing from a name. That's why I think of extensions as a lightweight alternative to a full review. The access still gets questioned. Someone still has to say yes, but the effort is tiny and the person asking has every reason to be honest because they're the one who loses access. If they don't, and it produces signals you can use. If most people extend every time, the duration is probably too short or the package is a baseline everyone needs and shouldn't expire at all if almost nobody extends. You've learned that a lot of access was never really in use. Either answer is more than the old spreadsheet ever told you. Set the notices so people actually see them early enough to act, but not so early that they forget a reminder a few weeks ahead. Then another close to the end is usually plenty. Now everything I've described works cleanly for your own employees. They have a manager, a department, a place in the directory and someone who notices when they're gone. External users have none of that. A guest can finish a contract and simply vanish from everyone's attention while the account stays valid. Expiry helps, but guests carry their own problems and they need their own treatment. External identities and the guest sprawl problem. Ask any admin how many guest accounts their tenant has. Then ask how many of those people still work with the company. The gap between those two numbers is the guest sprawl problem, and it grows for a simple reason. Inviting someone takes about 30s to type an email address, click send, and a person from outside the company can open a team's channel or a shared site. Nobody has to approve anything. Nobody has to write a reason. Offboarding a guest takes far more than that. And the worst part? Nobody sees it happening. When an employee leaves, HR closes a record and a dozen people notice when a guest's project ends. Nothing closes. No record, no event. No last day. The contract finishes, the consultant moves on, and the account stays exactly as it was valid and quiet. So guests pile up. Not because anyone decided to keep them, because nothing ever asked them to leave.

00:31:14 Speaker: Think about who owns the invitation to the person who sent it is often a team member who needed a vendor in a channel for a week. They have no idea. They just created a long term identity. Six months later, they've forgotten the invite entirely, and that's where it breaks. Invitations are in action. Offboarding is an absence, and systems built on people remembering to act will always lose to the pile of things nobody remembers. Entrance answer starts with structure, not cleanup. Remember connected organizations from the policy section. This is where they earn their place. When a partner is declared upfront, the question changes from who did we invite? To which partners do we work with and what can they ask for? You can look at that list. You can reason about it. Try doing that with four thousand loose invitations. Then comes the person who vouches for them. Sponsors a sponsor is an internal user, or a group of them tied to a guest account. They're the answer to the question, who is responsible for this person being here? That question matters because it gives the system someone to ask when a review comes up or an extension request arrives, or the access is about to end. There's a human with the context to respond. Without a sponsor, a guest belongs to no one, and what belongs to no one never gets cleaned up. Now here's the practical move. Make entitlement management the front door for B2B access. Instead of letting anyone invite anyone, you point external collaboration through access packages. A partner employee requests a package. The policy says who from that connected organization may ask. A sponsor approves the assignment, gets an end date, and if the person doesn't already have a guest account, entry creates one. At the moment the request is approved, not before. Look at what changed. The guest account no longer exists because someone was nice and sent an invite. It exists because a package assignment exists. The reason the approver, the sponsor and the expiry all sit in one record. When the assignment ends, there's a lifecycle setting that decides what happens to the account itself. This part gets missed more than any other inside the connected organization and tenant settings. You can say what should happen to a guest once they hold no more access block sign in so the account can't be used. Then after a set period, remove the guest account entirely. Thirty days of blocked sign in before deletion gives you a buffer in case someone realizes the person was still needed, so the sequence becomes automatic. The package ends. The guest loses access. If they hold nothing else, they can't sign in. After the waiting period, the account is gone. No one had to notice. No ticket, no quarterly email that covers the guests who come through the front door. But what about the thousands of accounts already inside and every assignment that's still running right now? Packages expire and extensions get approved, and some of that access is going to be renewed on autopilot. Access given must eventually be questioned by someone on a schedule with a real chance of hearing no. That's the job of access, reviews, access reviews, what they are and what verify. An access review asks one question on a schedule. Is this access still justified? That's it. Not. Is this person still employed? Not. Did they pass a security check? Just a recurring check on whether a specific person still needs a specific thing, and whether somebody with the right knowledge is willing to say. So. Everything else about reviews is machinery around that question. Who gets asked how often, what they see, and what happens when they answer. Now, what can you actually point a review? At? More than most teams realize, groups, both security groups and Microsoft three hundred sixty five groups, including teams. You review the membership and each member gets a decision. Applications you can review who holds an assignment to an enterprise app, which is where a lot of forgotten access hides access package assignments. This is the one that ties back to everything we've built. You review who holds a package, and the question carries the business reason with it. Does this person still need the finance analyst package and privileged roles, directory roles, Azure resource roles, even group based role assignments will spend more time on those when we get to Pim. But the point here is that the same review engine covers them, same tool, different targets, and you can aim it at guests specifically, which is usually the first place to start. Next question who answers? You pick the reviewers and the choice shapes everything that follows. There are four main options owners the person who owns the group or the resource. They know what it's for and they answer for what happens inside IT managers. The reviewed person's manager decides that works for role based access, where the manager knows the job. It works badly for specialist tools, and it fails entirely when the manager field is stale. Self review the person confirms their own access. That sounds weak and for sensitive access it is. But for low risk access, it's cheap and it gets a useful signal. A person who says I don't need this anymore is usually telling the truth. And selected users, you name specific people or a group to do the review. That's the right answer. When no single owner exists, or when you want a security team to check privileged assignments, you can also add a fallback reviewer for when the main one doesn't respond. That detail matters more than it looks and will come back to it. There's one more distinction worth getting clear. It's the difference between a review and a revocation. A review collects decisions, approve or deny. Don't know. That's all it does by itself. It's a form with answers. A revocation is the action that removes access. And those two things are not automatically connected. If you set a review to apply results, then a deny decision triggers the removal. The membership ends. The assignment is gone. If you leave that off, the review finishes the decisions, sit in a report and someone has to go act on them by hand. Think about how that plays out. The review completes on time. Everyone checks the box, the dashboard shows green and the access is all still there because nothing connected the decision to the system. That's a review that produced paperwork and no change. Auditors love the paperwork. Attackers love the access. So when you design a review, you're really designing two things. The question and the consequence. A question with no consequence is a survey which raises a harder problem. Most organizations that run access reviews already have the question and the consequence in place. They've picked reviewers, they've set a schedule, they've turned on, apply results, and the reviews still fail. Not because the feature is missing, not because the license is wrong. The cause is design. Specifically what the reviewer actually sees when they open the thing. Why access reviews fail fatigue and rubber stamps. Picture the reviewers side of the screen and email arrives. Subject line action required. Review access for sales. All staff. They click the link. A page loads and there it is. Four hundred names. Each one has a photo placeholder, a display name, maybe a job title. If the directory has one. Next to each name sits a button. Approve, deny. Don't know, no context, no hint of what the person did last month, no sign of whether they've touched the group since they joined. Just names in alphabetical order and a deadline. Now ask what a reasonable person does here. They don't know most of these people. they recognize maybe thirty. For those thirty, they're fairly sure the access is fine. For the other three hundred and seventy. They have no way to judge, and they have a real job to do with a calendar that doesn't care about this email. So they look for the fastest way out. There's a bulk option, select all, approve, submit eight seconds. Done. And here's what I want you to notice. That's not laziness. It's rational behavior. Look at the incentives from where they sit. Approving everyone costs nothing. If someone shouldn't have access, the reviewer never finds out. Denying someone, on the other hand, carries real risk if they deny a person who actually needed the access. Work stops, a ticket lands, and the reviewer gets a message asking why they broke something. So the safe move for the reviewer is approve every time the cost of a wrong approval is invisible and delayed. The cost of a wrong denial is immediate and personal. Any system that rewards one answer will get that answer. You can see it in the data. If you look. Pull the history from a tenant that's been running reviews for a year. Check how long each review took from open to submit. Check the approval rate. In many organizations, the picture is stark. Reviews finished in under a minute, covering hundreds of users approval rates in the high nineties. Sometimes a flat one hundred percent cycle after cycle, the same names, the same clicks, the same result. Think about what that number actually says. One hundred percent approval means that across every person, in every group over a full year, not one assignment was found unnecessary in an organization with joiners, movers, leavers and project turnover. That's not a cleaner state. That's a reviewer who stopped reading. Auditors rarely catch this. They ask for evidence that reviews happened and the evidence is there. Timestamps, reviewer names, decisions recorded, everything a compliance checklist wants. But look at what the checklist measures. Did the review get completed? Yes. By the deadline? Yes. By the right person. Yes. It never asks whether anyone exercised judgment. That's where it breaks. The system measures completion, not judgment. Completion is easy to count. It's a yes or a no. Judgment is hard to see. You'd have to know whether the reviewer understood what they were looking at, whether they had the information to decide, and whether a know was even possible in practice. So organizations optimize for the number they can see. They send reminders, they escalate to the reviewers manager, they shorten the window to push completion rates up. and every one of those moves makes the problem worse, because they all increase pressure to finish without adding a single piece of information. To help the reviewer decide, you end up with a process that's very good at producing evidence and very bad at changing access. Then a year later, someone does a real cleanup, an actual forensic pass, and finds hundreds of accounts with access. Nobody can explain accounts that passed review four times in a row, and the reaction is usually to blame the people. Managers don't take this seriously. Reviewers are careless, but the people behaved exactly as the design invited them to. Large list. No context. No cost for approving. A real cost for denying. Change the people and you'll get the same outcome with a new set of names. The flaw isn't the reviewer, it's what the system handed them. And Microsoft knows this. Entra has built in tools aimed squarely at that moment, the one where a tired person faces a long list. Recommendations, smarter scoping, better defaults. Most tenants have them available right now, and most of them are switched off. Designing reviews people actually complete. So let's fix the screen the reviewer sees. Start with size. A review of four hundred people is a bad review. No matter how good the reviewer is, nobody can hold that many decisions in their head in one sitting. Cut the scope until a person can actually think about each name. That means one review per package, not one review for the whole directory, one review per group with a reviewer who knows that group. A guest review split by sponsor. So each sponsor sees only the people. They brought in twelve names from. Someone who remembers why those twelve are here. Gets real answers for hundred names. Gets a bulk click. Then think about cadence. Most teams pick a yearly review because it feels thorough. But a yearly review means a huge list. And a huge list is exactly what we just watched fail. Run it quarterly or monthly for high risk access, and each list shrinks. Fewer people have changed roles since the last pass. Fewer names are unfamiliar. The reviewer sees mostly faces they know, plus a handful of changes worth a second look more often with fewer decisions each time. That sounds like more work. It's actually less because the total effort drops when each sitting takes three minutes instead of an hour you'll never find. Now give the reviewer something to judge with. This is where recommendations come in when you turn them on. Entry looks at sign in activity and flags the people who haven't used the access. The reviewer opens the review and sees a suggestion next to each name. Deny no sign in in the last thirty days or approve active recently. That changes the whole decision. Before the reviewer faced a name and had to guess. Now they face a name and a fact. And the fact is something a busy person can act on in two seconds. You choose the lookback window. Thirty days works for tools people use daily ninety suits, something quarterly, like a finance close. Set it to match how the access is actually used because a window that's too short flags people who are fine and one that's too long catches almost nobody. Recommendations don't make the decision. They move the starting point the reviewer can still override. But now the easy path is the informed one and that matters. Whatever's easiest is what people will do. So make the easy thing the right thing. Next reasons you can require a person to explain their decision. Some teams turn this on for everything, and I'd advise against it. Forcing a typed reason on every one of fifty approvals is the fastest way to bring back the bulk click, because people will type okay fifty times or skip the review altogether. Use it where it carries weight, require a reason on a denial that goes against the recommendation. Require one. When someone approves a person, the system flagged as inactive. Those are the moments where judgment is actually happening, and where a record is worth having. Routine approvals of active users don't need a paragraph. Keep justification for the exceptions. That's how you get evidence an auditor can actually read instead of a wall of identical one word answers last piece, and it's the one that decides whether any of this matters or to apply. Earlier, we saw that a review with no consequence is a survey, or to apply is the consequence. When a reviewer denies someone, the removal happens when the review ends. No follow up ticket, no admin reading a report and deciding whether to act. The decision and the change are the same event and this changes behavior in a way you can feel. Reviewers who know their answer does something take it more seriously? Reviewers who suspect nothing happens treat it as a chore. The same screen, the same names, a different weight on every click. There's a catch, though. Auto apply means a wrong decision removes real access fast. So the safety of the whole design now rests on a handful of settings most teams never touch. What happens when the reviewer doesn't answer at all? Who gets asked next and what does the system do by default when nobody responds? Tuning those defaults decides whether this works. Reviewer recommendations, defaults, and auto apply. Let's start with the recommendation setting, because it carries one number that most people guess at the lookback window when you turn on inactivity recommendations. Enter checks. Sign in activity for each person over a period you choose. If they haven't touched the resource in that time, the review suggests deny if they have, it suggests approve. The default is thirty days, and thirty days is a trap. If you leave it alone. Think about who that catches a person on parental leave. A seasonal analyst, someone who only opens the budget site during quarter close thirty days, flags all of them as inactive, and a reviewer who trusts the label will cut access that somebody needs in six weeks. So match the window to the rhythm of the work. Daily tools can use thirty a monthly process sixty or ninety. Anything tied to a year end cycle needs a much longer view, or it shouldn't get recommendations at all. Know how the thing is actually used before you pick the number. One more limit worth knowing. Recommendations read sign in data and not every resource produces it cleanly. For some, the signal is weak, A recommendation built on thin data is worse than none because it looks confident. Now the setting that matters even more. What happens when the reviewer doesn't answer? Because some won't. People are on vacation. They've left. They ignored the email, then the reminder, then the second reminder. The review window closes and the system has to do something. With all those open decisions, you get three choices approve, deny, or take the recommendations. Approve is the comfortable one. Nothing breaks, no one complains and the review closes clean. But look at what it means. Silence becomes consent. A reviewer who does nothing has now vouched for every person on the list. Do that for a few cycles, and you've built a system where the easiest way to approve access is to ignore it. That's the same floor as the bulk click, just with the click removed. Deny goes the other way and it feels strong. No answer, no access safe on paper. But think about where this is aimed. If you point default deny at a group that feeds a live application, then one absent reviewer can pull access from one hundred people. On a Monday morning. Production stops, the help desk fills up, and the lesson the organization takes from it is reviews break things, which kills your appetite for running them at all, so neither extreme works everywhere. The third option sits in the middle. Take recommendations. If the reviewer doesn't answer, the system follows the inactivity signal. People who've been active keep access. People who haven't lose it. That's a decision grounded in a fact, not in silence and not in panic. For most reviews, that's where I'd land for high risk access, like privileged roles or sensitive partner packages. Default deny is reasonable because the cost of keeping a wrong assignment is higher than the cost of a short interruption for broad, low risk access. Take recommendations. Reserve default. Approve for cases where you've decided on purpose that a missed review isn't worth a disruption. And whichever you pick, test it first. Run the review against a small group and read what the system would have done. Surprises belong in a pilot, not in a payroll week. Now, the better fix for silence isn't a smarter default. It's making sure someone else answers first. Fallback reviewers. You can name a second person or a group who gets the review when the primary doesn't respond. A different manager, a security team, a resource owner's delegate. The system routes it automatically, and the work gets done by a human who has a reason to care.

00:46:28 Speaker: Escalation works the same way in layers. Primary reviewer gets the first window. If nothing happens, the fallback gets a second one only after both have been given a fair chance does the default decision fire. That way, the default becomes the last resort, not the main path. It also fixes a problem we've already seen owners leave. Managers change. A review assigned to someone who left the company six months ago will never be answered, and nobody will know why. A fallback catches that without anyone having to notice. So now you have the full picture for reviews, small scopes, recommendations that give people a fact, defaults that don't punish silence or reward it, and results that actually change access. That's a solid way to question access once it exists. But look at the timing of all of it. Every review is a reaction. Something happened, access was granted, time passed, and now someone checks the question always arrives late. The harder question is what should have happened at the moment? The person changed when they joined, when they moved, when they left. That's the life cycle layer. Joiners, movers, leavers, the life cycle model. Every identity in your tenant follows the same path. Someone arrives, someone changes, someone leaves three events, and each one carries a different kind of risk. That's exactly why one control can't cover all three. Start with the joiner. The risk here is delay. A new hire shows up on Monday. The laptop is ready, but the account isn't. Or the groups aren't, or the access they need lives in a package nobody told them about. So they sit. They message a colleague. They borrow a login just for today. Every hour of waiting pushes them toward a workaround. And workarounds are where bad access starts. So joiners need speed. The right access ready before they ask. Now the mover. The risk here is leftovers. Someone moves from sales to finance the finance. Access arrives because they asked for it, but the sales access stays because nobody asked them to give it back. Nobody even thought about it. The old access was never a decision. It was just there. Movers need cleanup. The old role has to end when the new one begins. And then the lever. The risk here is the one everybody fears and it's a different shape. Again, a lever doesn't need speed. And it isn't about tidiness. A lever needs certainty when someone walks out the door. You need to know the account is disabled, the sessions are dead, the licenses are released and nothing they owned is left without a home. Probably done isn't good enough. Speed. Clean up certainty. three different jobs, which brings up an uncomfortable pattern. In most organizations, joiners get automated first. It makes sense joiners are visible. A new hire who can't log in generates a complaint within an hour, and that complaint has a name on it. The business feels the pain, so the business funds the fix. Onboarding scripts. Templates. A checklist that runs when HR enters a start date. Leavers get attention. Second, usually after something went wrong. A former employees account turned out to be active for three months. An auditor asked a pointed question. So someone builds an offboarding process, often in a hurry. Movers get nothing. Why? Because nothing announces a mover. A joiner has a start date. A leaver has a last day. Both are events with a name and a calendar entry. A mover is a quiet change in a field. A department updated, a manager swapped, no email goes out, no ticket opens and nobody on the IT side hears about it. And there's no complaint to trigger the work. The person who just moved isn't blocked since they still have all their old access, plus whatever they request next. From their point of view, nothing is broken. From a risk point of view, the damage grows with every move. Someone who has changed roles four times in six years, can end up holding the combined access of four different jobs. That's why movers sit at the bottom of nearly every project list. The pain is silent, so the funding never arrives. Now, there's a deeper reason all three are hard. In the old model, it's about when the control fires. Scheduled governance runs on a calendar every quarter. Every year a review opens, people answer access changes. The trigger is time. And time doesn't care what happened. In between. A leaver who walks out in week two of a quarter keeps their access until the next review comes around. A mover keeps their old permissions for the same stretch. Event driven governance runs on the thing that actually happened. The higher date arrives, so the onboarding steps run, the department changes. So the old package ends and the new one begins. The last day passes. So the account closes. The control fires. At the moment the risk appears not weeks later when someone happens to look scheduled governance asks has anything gone wrong since we last checked? Event driven governance acts when something changes, you need both. Reviews are still the safety net for everything the events missed, but if the lifecycle layer is doing its job, reviews have far less to catch and far less to rubber stamp. So the question becomes practical how do you wire access to those three moments using data your tenant already holds? Entra has a tool built for exactly that, and it's called lifecycle workflows. Lifecycle workflows, triggers, tasks, and scope. A lifecycle workflow has three parts a trigger, a scope, and a list of tasks. That's the whole structure. Once you see it, every workflow in the portal reads the same way. When does it fire? Who does it fire for and what does it do? In what order? Start with the trigger because it's the part that makes this event driven instead of calendar driven. Most workflows use a time based trigger, and the clock they watch isn't a date you type into the workflow. It's a date on the user object itself. For joiners, that's employee hire date. For leavers, it's employee leave date time. So the workflow doesn't say run on March first. It says run for anyone who's hire date is two days away, or run on the day someone's hire date arrives, or run seven days after their leave date passes. But you set an offset before the date, on the date or after it. That one choice decides a lot. A pre-hire task, like creating a welcome message, needs an offset before the start date. A cleanup task like removing a license usually runs after the last day, and this is where the earlier section on identity data stops being theory. If employee hire data is blank, the trigger has nothing to watch. The workflow never fires and nothing tells you. Same for the leave date. The automation is only as alive as the attribute behind it. There's also an on demand option. You can run a workflow by hand against specific users. That's useful for testing and for the odd case where HR changed a date late and you need to catch up. Don't build your process on it though. A process that needs a person to press the button is the old model with a nicer interface. Now the second part. Scope. Scope decides who the workflow applies to, and it works through rules based on user attributes. Department equals finance. Employee type equals contractor country equals Germany. You can combine them. So a workflow can say full time employees in sales in the United States. This matters more than it sounds. A contractor's first week isn't an employee's first week. A factory worker doesn't need the same welcome as an engineer without scope. You end up with one giant workflow that tries to cover everyone and fits nobody with scope. You write several small ones, each aimed at a clear population. And again, notice what the rules read from attributes. If department is spelled three different ways across your directory, your scope rule catches one spelling and misses the rest. Those people get nothing silently. Then there's an execution condition on the workflow itself. That's the combination of trigger and scope together this event for these people. Android checks it on a schedule roughly every hour and runs the workflow for anyone who matches you. Don't watch it happen. It just happens. Now the third part tasks a workflow, holds an ordered list of tasks, and they run top to bottom. Order matters because some steps depend on others. You can't add someone to a group before the account is enabled. Enter ships with a set of built in tasks for joiners. The common ones are. These enable the user account at the user to selected groups. Add them to selected teams. Send a welcome email, send an email to the manager and generate a temporary access pass which gives a new hire a short lived way to sign in for the first time. For leavers, the list flips. Disable the account, remove the user from groups, and teams. Remove their licenses. Delete the account after a set period. Each task is small and that's the design. One action, one result clearly logged. You build a process by stacking them, not by writing code. Every run leaves a record. Two you can see which users the workflow touched, which tasks succeeded, and which failed. That's the audit trail the old model never had. Not a spreadsheet someone filled in afterward, but a log written at the moment. Each step ran. So that's the structure. A trigger tied to a date on the user, a scope built from attributes and tasks in a fixed order. The easiest place to see it work is the first event in every identity's life. Let's walk through the join our path the joiner path. Day one without a ticket, a good joiner workflow starts before anyone even knows the person exists. HR enters a start date. That's the signal. And from that moment the clock is running, which means you can do real work. Days before the new hire walks through the door, take the pre-hire phase. You set the trigger a week or two ahead of the hire date. The first task sends the manager a heads up that someone's arriving. The next one pulls the new hire into groups that don't carry risk, like the all staff list or the team's shared channel. Nothing sensitive yet, just the things that make the first morning feel like someone expected them. The account stays disabled until the right moment. That's deliberate. You prepare everything, but you don't switch it on early. Then comes the day itself. A second trigger set to the higher date runs. The onboarding tasks. Enable the account, add the teams memberships, assign the baseline license through its group. Send the welcome message with the few links a person actually needs. Now here's the part that decides whether Monday goes well. How does a brand new person sign in for the first time? They have no password, or they have one that someone emailed around, which is exactly what you don't want. This is where the temporary access pass fits. It's a short lived code valid for a set window, one user a few. The workflow generates it and sends it to the new hire or to their manager, depending on how you want to hand it over. With that code, the person signs in and registers a passwordless method like the authenticator app or a security key. They never create a password at all. That's a bigger change than it looks. The weakest moment in an identity's life. The first login now happens without a secret that can be guessed, reused, or forwarded. Set the pass to expire fast. Hours, not days. If it sits unused, it dies on its own and you can issue another. A code that lives for a week is just a password with extra steps. So the person is in. What can they actually do? This is where the workflow reaches into entitlement management. One of the available tasks assigns an access package directly and you aim it by scope. So a new sales hire in Germany gets the sales baseline package and a new engineer gets the engineering one. Same trigger, different scope, different bundle. Think about what that package already contains. The groups, the app roles, the site permissions, everything someone in that role needs on day one, granted, together with an end date attached and a policy behind it, nobody files a request. Nobody waits for an approver to wake up. The access arrives because the role exists. But keep the baseline small. It should hold what every person in that role needs and nothing a few of them need. Sometimes the extras stay as packages people request. If the baseline grows into a catch all. You've rebuilt the old pile of permissions just with a nicer name on it. The last piece is the human one. The manager entra can send them a message when the onboarding runs, and that message deserves care because most managers ignore long ones. Keep it short. Your new hire starts today. Their account is ready. Here's their first sign in pass. Here are the two things you still need to do. Say, confirm their team access and book their first one on one. A list of three lines beats a page of guidance. The manager reads it between meetings, acts on it, and moves on. The workflow handled everything it could and it hands over only what needs a person. That's the full picture of a joiner, prepared ahead, enabled on the day, signed in without a password. Holding a role sized package. A manager who knows exactly what's left. No ticket, no borrowed login. And it works because a joiner announces itself. There's a date, a record, and a clear moment to act. Movers don't give you any of that, and that makes them a much harder problem. The mover path, the quiet source of privilege creep. Think about what a department change actually is. Someone spent three years in sales. They built access around that job, the CRM, the forecasting site, the pricing sheets, a handful of groups that made sense at the time. Then they moved to finance. New manager, new team, new work. That's the moment access should reset. The old job is over, so the old access should be too. It rarely does the finance access shows up because the person needs it and asks for it. The sales access stays because nobody asks for the opposite. There's no form for. Please take away what I no longer need. And the person has no reason to volunteer it. Why would they? Nothing is broken for them. So they carry both. And after the next move they carry three. This is what people mean by privilege creep. It isn't one bad decision. It's a slow stack of decisions that each made sense when they were made and that nobody ever reversed. Now here's where lifecycle workflows help, though the setup takes more thought than it does for joiners. A joiner has a higher date. A mover has no date at all. What you have is a change. A department field that used to say sales and now says finance. So the trigger is built differently. Entra supports workflows that fire on an attribute change. When a defined attribute updates the workflow runs for that user, you pick the attribute that carries the signal department is the common one. Job title works for some organizations. Manager can also work, though it changes for reasons that have nothing to do with the role change. So expect some noise and once more everything depends on the source. If the department only updates when someone remembers to fix it in the directory, the workflow fires late or never. The cleaner setup has HR. Change the record and the change flows into entra through provisioning. The mover workflow then runs because the data moved, not because anyone filed anything. Now what should the workflow actually do? Two jobs and the order matters. First, grant what the new role needs. That's the access package for finance assigned through the workflow scope. Two people whose department is now finance. Same pattern as the joiner path, which is why it feels familiar. Second, and this is the part almost everyone skips take back what the old role carried. Because entitlement management tracks assignments. The old access has an address. The person holds an assignment to the sales package. You can remove that assignment and everything the package granted comes off together. The groups, the app roles, the site permissions. No hunting, no guessing which of forty memberships belong to the old job. That's the payoff of building access as bundles. A mover workflow can say remove the sales package, add the finance package, and the whole swap is two clean steps. There's a limit, and it's worth being honest about. A workflow can only remove what it knows about access granted through a package is traceable. Access. Someone added to a group by hand three years ago outside any package isn't the workflow won't see it. That access survives the move, and it's the exact kind a review has to catch later. So treat the move workflow as the first line, not the only one. The more of your access lives in packages, the more a mover event can clean up on its own. One design choice deserves a second look. Do you remove the old access instantly or give a short overlap? Instant removal is tidy, but real moves are messy. A person might spend a month handing over accounts. Cut the sales access on day one and you'll get an angry message from a customer waiting on a quote. A short overlap, say fourteen or thirty days handles that. The old package gets an end date at the moment of the move and expiry does the removal. Same result. No scramble. And this brings us to why movers matter so much beyond the day to day. When auditors pull access data, they look for people holding more than their role justifies. And the people who top that list aren't the new hires or the ones who just left there. The long tenured movers, someone eight years in four roles deep with permissions from every job they've ever held. That's the largest hidden finding in most identity audits. It sits in plain sight, spread across hundreds of people, and no single record looks wrong. Each assignment was approved. Each one was reasonable once only the total is a problem and nobody ever looked at the total. It's also the finding a conflict of duties check catches a person who can both create vendors and approve payments, because they moved from procurement to accounting, and kept both movers fixed that quietly when they are handled at the event. But a mover still has a future. They're still here, still working, still accountable. The next event is different. Someone is leaving and whatever they hold needs to end with certainty. The leaver path offboarding with certainty. A leaver workflow runs in three phases before the last day, on the last day, and after it. Start with the phase before HR enters a leave date. And that's your signal. Same as the higher date was for joiners weeks out, you can already do the quiet work. Notify the manager that someone is leaving. Remind them that the person's files, shared mailboxes and group ownerships need a new home. Nothing gets switched off yet. This phase is about people, not permissions, because the permissions can't change until someone decides who inherits what. Then comes the last day itself a trigger set to employee leave date time runs the tasks that matter most and the order matters here to.

01:01:49 Speaker: First disable the account. The person can no longer sign in, but a disabled account isn't the same as a dead session. And this is where teams get a false sense of safety. Someone already signed in on a phone or a laptop can keep working until their tokens expire. So the next task revokes their sessions, which forces every device to authenticate again. And now it fails. After that, remove them from groups and teams, strip the memberships they held so they stop receiving files, messages and channel access. If you build access through packages, the assignments end with the account. Everything else. The group someone added by hand comes off here. Then remove the licenses that releases the seat and it stops the quiet cost of paying for people who left in the spring. Four steps disable. Revoke. Remove. Release. Each is one built in task, stacked in a fixed order, and each leaves a log entry. If one fails, you see which one for which person, at what time that certainty you can point to. Now here's what the checklist hides. What did the lever own? A person who's been here a few years doesn't just hold access, they own things. Groups where they're the only owner apps. They registered a shared mailbox. Only they manage a team's channel. No one else can approve members for delete the account without handling that. And you create orphans. A group with no owner can't approve, new members can't be reviewed and can't be cleaned up. Which brings us back to a problem we've already seen. What belongs to no one never gets fixed. So reassign ownership before anything is deleted. That's the job of the pre offboarding phase. Make the manager name the new owner for each group and app, while the lever is still reachable and can answer questions after the last day you're guessing. Keep the account around for a while too. Don't delete on day one. Disable it, hold it thirty days or so and delete after that. A mailbox that someone suddenly needs or a file nobody knew was personal is recoverable during that window and gone after it. The delay costs you almost nothing and saves you one very bad Tuesday. Now the uncomfortable part. The workflow acts on the date in the record, and the date in the record isn't always the date that was real. HR enters the last day of the thirty first, then the person resigns early or gets walked out on the fifteenth or negotiates a gap with unused vacation. The record still says the thirty first. The workflow waits patiently for a day that no longer matters, and in the meantime, an unhappy employee has full access. That gap between the HR date and what actually happened is where leverage lives. Close it with a process, not a feature for immediate terminations. Don't wait for the scheduled trigger. Run the workflow on demand against that one user the moment the decision is made. Earlier, we said a process built on someone pressing the button is the old model. That's true for routine exits. For urgent ones, the button is exactly right. As long as the same tasks run in the same order and make HR and IT agree on who updates the date and how fast. A leave date that arrives after the person has left is just a record of a mistake. All of that covers what entra can do on its own disable, revoke, remove, release. But a lever also leaves behind a ticket for the laptop, a badge to deactivate, and a dozen SaaS accounts. Entra has never heard of the built in tasks. Stop at the edge of Microsoft. The workflow has to reach further, extending workflows with logic apps and custom tasks built in tasks cover the Microsoft side of a person's life. The rest lives somewhere else a ticketing system, a badge console, a CRM, an HR portal, a design tool that someone bought on a company card three years ago. Entra has no native task for any of them, so Microsoft gave workflows a way out. It's called a custom task extension, and it's simpler than the name suggests. A custom task extension is a task slot that calls an Azure Logic app. You build the logic app with whatever steps you need, then add the extension to your workflow like any other task, when the workflow reaches that step, it hands the user's details to the logic app and waits for the result. The order stays fixed. The log still records each run. The only difference is that the work happens outside entra and logic apps already speak to hundreds of services. That's why this fits so well. You don't write a connector for your ticketing tool. One probably exists. Take a few examples because they show where this pays off. Ticket creation a lever workflow fires and one task opens a ticket in your service desk with the person's name, manager, and last day facilities sees it. Nobody has to remember to send the email hardware return. The same logic app creates a shipping request for a remote employees laptop with a label sent to their personal address. When the device comes back, the ticket closes. If it doesn't, the ticket stays open and someone chases it downstream, says Deprovisioning. This is the big one. Many applications don't sit behind entrance provisioning or they sit behind it. Only partly. The logic app calls that vendors API disables the user and reports back. Without it, those accounts live on quietly, long after the entire account died. Now, where do graph API and the provisioning service fit two different jobs? Provisioning is the right answer. When an app supports it, you connect the app to enter map attributes and enter creates updates and removes accounts on its own. That's the cleanest option because the logic lives in a managed service, not in something you built. Graph API is the fallback for everything else. A logic app can call graph to read user details, change a group, or check a manager before it acts, and it can call any vendor's own API for tools that entra can't reach. So the order of preference is plain use. Built in tasks. First, use provisioning where the app supports it. Reach for a custom extension only when nothing else covers the gap, because every custom piece is something you now own. That's the risk nobody mentions in the demo. A logic app someone built in an afternoon becomes part of your onboarding process. It breaks when a vendor changes an API. It stops when the person who built it leaves and the connection they authenticated with goes dead and the workflow keeps running step after step while one of them fails without anyone noticing. So keep custom logic observable, turn on run history. Send failures to a channel a human reads, not to a mailbox. Nobody opens. Make the logic app report back to the workflow. So a failed step shows up as a failed task, not as silence and name an owner. A real person with a backup written down where the team can find it. Use a managed identity or a service account for the connections, not someone's personal login. If the logic app depends on a particular person's credentials, you've built the same fragility. We spent this whole episode removing. Treat each extension like a small product. It has a purpose, an owner, and a way to tell you when it's broken. Otherwise, you've automated the offboarding of ordinary users and left the most dangerous accounts untouched. The ones with the keys to everything. That's the privileged side of identity, and none of the automation we've covered means much. Until standing admin access is dealt with. Privileged access standing access is the real risk. Think about how admin roles get handed out in most tenants. Someone needs to manage exchange. They get the exchange administrator role. Someone else resets passwords so they get a help desk role. A project needs a global administrator for a week, and that person gets the role and keeps it three years later. The project is a memory and the role is still active. That's standing access. The role is on all day, every day, whether anyone is using it or not. And that's the problem, not who holds the role when they hold it. An admin account with permanent rights is permanent attack surface every hour of every day. That account can change tenant settings. Read mailboxes. Create new admins. An attacker doesn't need to break your best defenses. They need one Phished session, one stolen token, one reused password on one of those accounts. And the moment they land, the rights are already there. Nothing to request, nothing to approve. The door is open because it was never closed. Now count how often those rights are actually used. A person with exchange administrator might touch it twice a month, maybe less so for most of the year. That power sits idle and all it does is wait for the wrong person to find it. That's a bad trade risk every day in exchange for convenience. A few hours a month entrance answer is privileged identity management. People call it Pim, so I will. Two Pim changes one thing it separates having a role from using it. The idea sits on two words eligible and active and active. Assignment is the old way. The role is on. The person holds it right now and every token they carry reflects it. An eligible assignment is different. The person is allowed to hold the role, but they don't hold it yet. Nothing is switched on. Their account looks from the outside like an ordinary user with ordinary rights. If someone steals that session, they get an ordinary user. When the person needs the role, they activate it. They go into PM, pick the role and turn it on. Then the clock starts. A few hours later, it turns itself off. That's just in time access. The role exists for the window the work needs, and then it's gone. And activation isn't a single click. It's a small set of checks and you decide which ones apply a time limit. You set a maximum duration, say two hours. For a routine role. The person can ask for less, but not more. When time runs out, the role drops without anyone remembering to drop it. Multi-Factor authentication even if they signed in with MFA this morning, activation can demand it again right now for this role. So a stolen session that's hours old doesn't automatically become an admin and a justification. The person types a reason why do you need this and for what it takes 10s. And it produces something the old model never did. A record of why each privileged action happened. Add all three together and the picture changes. An attacker who gets into an eligible admin account has to pass a fresh MFA check, write a reason, and then work inside a window that closes on its own. Every step leaves a trace. Every step gives you a chance to notice. Now, PM isn't only about directory roles, which is where people usually picture it. It covers three areas Microsoft intro roles like Global Administrator, exchange administrator, and Security administrator. Azure resource roles like owner or contributor on a subscription or resource group, and privileged groups where membership in a group carries the access through role assignable groups or groups that grant rights in other systems. That last one matters more than it sounds. Plenty of access isn't a named role at all. It's membership in a group that happens to sit behind something sensitive. Pim lets you make that membership eligible, too. So the same just in time logic applies. Same pattern. Three places eligible by default. Active on request. Gone on a timer. So the principle is clean. Nobody carries admin power around. They pick it up when the work needs it and put it down when it's done. But here's where teams stumble. They turn on PM, convert the assignments and feel finished. Then the activation settings stay at their defaults. Eight hours, no approval. A single word is justification. An activation with no guardrails is just a standing role. With an extra click the settings behind each role. Decide whether Pim means anything. PM in practice activation, approval and reviews. Every privileged role in Pim has its own settings page. Open one and you'll see the real design work. Start with maximum duration. The default is eight hours, and that's a full workday of power for a task that often takes twenty minutes, cut it down one to two hours suits most routine roles. A person can always activate again if the work runs long, and that second activation is a useful moment because it forces one more look at whether they still need the role. Next, approval for low risk roles. Self activation is fine. The person turns it on, writes a reason, and moves on for the roles that can rewrite the tenant. Global administrator, privileged role administrator anything that touches conditional access. Add an approver. A second human sees the request before the role switches on. That one extra pair of eyes is what turns a stolen account into a stalled attack, but pick approvers who'll answer an approval that waits two days behind. An absent manager teaches people to ask for permanent access. Instead, name a small group with a backup who can respond during working hours. Then there's ticket information. You can require a ticket number at activation, not a sentence. A number that ties each privileged session to a piece of work that someone else already approved, like a change request or an incident. Months later, when someone asks why a role was active at two in the morning, the answer isn't a shrug. It's a link. Now settings drift. Assignments pile up quietly, which is why Pim raises alerts on its own. A few matter most stale assignments, meaning people who hold an eligible role and haven't activated it in a long time. If someone hasn't used exchange administrator in nine months, why do they still have the option? Another alert fires when a role has too many members, especially global administrator, where five people is a lot and fifteen is a finding and one flags roles being assigned outside Pim entirely, which means somebody went around the system, read those alerts, they're cheap, and they point at exactly the places where the model has decayed. But alerts only tell you something looks wrong, they don't ask a person to decide for that. You use the tool we covered earlier, apply it to a new target. Access reviews. Work on privileged roles to set a recurring review on your admin roles quarterly for the sensitive ones. And the question becomes narrow and clear. Does this person still need the ability to activate this role? The reviewer is usually a security lead or the role's owner, and the list is short. A dozen names, not four hundred. That's the kind of review that gets real answers here. Default deny makes sense. We said earlier that high risk access earns that setting, and this is the clearest case. If nobody confirms an admins eligibility, it should end the cost of losing a role someone can simply request. Again is small. The cost of keeping a forgotten one isn't one category sits outside all of this on purpose emergency access accounts. These are the break glass accounts. Two of them cloud only with permanent global administrator rights built for the day. Everything else fails. A conditional access policy misfires and locks out every admin. An MFA service goes down. Federation breaks on that day. Someone needs a way in that doesn't depend on any of the machinery you've built, so they can't be eligible because activation needs MFA that might be down. They can't depend on a review that might remove them. Normal governance would defeat their purpose. That doesn't mean they get ignored. They get a different kind of control. Long random passwords stored offline in separate secure places. No daily use. An alert that fires the moment either account signs in because any sign in is either a drill or a disaster, and you want to know which, and a scheduled test a couple of times a year to prove the credentials still work. Two accounts watch closely used almost never. So now you have the full set packages that end by default. Reviews that people finish, workflows that fire on events, privileged roles that exist only when needed. Each one works, but they don't live in separate rooms. A leave a workflow touches the same groups. A review checks a package, grants access that Pim may also control. If you design them one at a time, they'll collide. They need to be designed together. Designing governance as one system. Lay the pieces out in a row and you can see five layers identity data at the bottom, packages above it, lifecycle workflows, reviews and privileged access at the top. Each layer feeds the next attributes. Tell the lifecycle layer when someone joined, moved, or left, the lifecycle layer assigns and removes packages. Packages carry an end date and reviews question what's still active. Privileged access sits on top with the tightest rules because it holds the most risk. Draw it that way and you get a chain break one link and the layers above it keep running on bad input. Now which control files went. Think of it in three words event reasoning. Orchestration events come from the data. A higher date arrives, a department changes, a leave date passes. Nothing is decided. Yet a fact simply changed. Reasoning is where the system asks whether that fact matters. Packages and policies live here. Does this department get this bundle? Does this role need an approver? Does this assignment expire in ninety days? The rules were written once and they answer the same way every time. Orchestration is the part that does the work lifecycle workflows. Run the tasks in order. Disable, revoke. Remove. Release. Grant the new package. End the old one review. Sit across all three. But they're a different kind of control. They don't react to an event. They check the result later for the things the events missed. If you can say which of the three are control belongs to, you can explain why it exists. If you can't, it probably shouldn't. Here's where designs go wrong. Overlap. Someone builds a life cycle workflow that removes access. When a person moves, someone else builds a quarterly review on the same access. A third person sets package expiry to thirty days. Now three controls touch one assignment and none of them knows about the others. What does the owner see? A review request for access that already expired. A removal notice for access. They just approved an email from a workflow they've never heard of. People stop trusting a system that contradicts itself. They stop reading the emails and that's how a good design ends up ignored. So give each assignment one primary control with a clear reason events handle the predictable changes. Joining, moving leaving expiry handles the access that should be temporary. Reviews handle what's left. The long lived access where nobody can predict when it stops being justified. Write that down as a short table for each kind of access which control owns it and which ones stay out. When someone asks why a review exists, the answer should be one sentence. Now where do you start? Not with the whole tenant. That's the instinct. And it's the one that stalls, projects, twenty thousand identities, hundreds of apps, thousands of groups. Nobody can design for all of that at once. So the work drifts and nothing ships.

01:17:17 Speaker: Start with the populations where one mistake costs the most privileged roles first, since they're a shortlist with a large blast radius. Then guests because they sit outside your HR data and nothing else will remove them. Then the access that touches money, customer data, or regulated records, those groups are small. You can name the owners, test the workflows, and read every result, and what you learn there carries straight over to the broader rollout with fewer surprises. A small scope done fully teaches you more than a wide one done halfway. But look at what every piece of this design needs. A package needs someone who decides what goes in it. A review needs someone who answers a workflow, needs someone who notices when it breaks a privileged role. Needs someone who says yes or no at two in the morning. All of it points at a person and that's the variable. Most designs forget to fund ownership. The variable nobody budgets for. Ask a simple question about any package in your tenant who owns it, not who created it, not who has admin rights over the catalog. Who owns it. Meaning who can say what belongs inside, who should get in and when it should end. In most tenants, the honest answer is a pause, then a name followed by, I think that pause is the real risk in your governance design. Every package, every group and every privileged role needs a named owner. One person written down with a backup and named isn't enough on its own. The owner needs real authority, which means two things. They understand what the access does and they can actually change it. An owner who can't remove a member, edit a policy or say no to a request is just a name on a form. Authority also needs time. Owning a package that feeds a payroll system might take an hour a month. If nobody told that person and nobody told their manager, the work gets squeezed out by whatever is louder. So budget it, put it in a role description, treat it as part of the job because it is. Now think about what happens to owners over time. They get promoted, they change teams. They leave. When that happens, the package doesn't announce that it's orphaned requests keep arriving and they route to someone who's gone. Approvals sit. Reviews go to an inbox. Nobody opens. Everything looks fine from the outside because nothing throws an error. The access just stops being questioned. That's why ownership needs its own life cycle. Treat an owner leaving as a mover or leaver event with a specific task attached before the account closes. Every package, group and role that person owns gets reassigned. You saw this with levers earlier here. It's the rule that protects everything else. Then add a standing check. Once a quarter, list every object with a single owner or no active owner and fix each one. A package with one owner is one resignation away from nobody. Now the easy shortcut make the manager the reviewer for everything. It sounds reasonable. The manager knows their people, so the manager can say who still needs access. That's the assumption behind most review designs, and it holds in one narrow case access that maps cleanly to a person's day to day job. Outside that case, it breaks. A manager can't tell you whether a developer still needs write access to a particular repository. They can't judge whether someone's role in a financial application is appropriate. They don't know which of fifteen groups carry risk, so they do the rational thing. They approve because the cost of being wrong is invisible, and the cost of blocking someone's work is immediate. Managers are the right reviewer for questions about people. Is this person still on my team? Do they still do this job? For questions about the resource, ask the person who understands the resource that's the owner and it's why owners matter so much. Which raises the structural question who sets the rules and who carries them out? Two models a governance council or delegated ownership. A council is central. A small group security, HR compliance and a few business leaders decides what packages exist, who approves and how long access lasts. The benefit is consistency. The cost is speed. Every new package waits for a meeting and the business learns to root around the council. Delegated ownership pushes the decisions outward. Each business area owns its own packages. Inside guardrails, the center sets finance, designs, finance packages, engineering designs, engineering ones. The benefit is that the people closest to the work make the calls. The cost is drift because without a shared standard, you get forty naming schemes and no common idea of what temporary means. Most organizations that work do both. A small central group owns the standards, naming maximum durations, review cadence, and the rules for privileged access. Everyone else owns the content inside those standards. The council sets the frame, the owners fill it. That split keeps the council small and the owners accountable. And it's the only version that scales without choking. So now you've built the system and you've named the people who run it. But a system that nobody measures only tells you it's working. Executives will ask how you know and it feels better won't survive that meeting. They'll want numbers measuring governance. What executives should ask for. Most governance reports show activity reviews, launched packages, created workflows, run those accounts of effort. They tell an executive nothing about whether risk went down. So ask for five numbers instead. Start with review completion rate of the reviews that opened, how many actually finished before they closed? Anything under ninety percent means reviewers are ignoring the system, or the system is asking too much of them next time to decision. How long does a reviewer take from the first notification to the first answer? If the median is days, people are waiting for reminders. If it's four seconds per item, that's a different problem. We'll get to it then. Denial rate of all the access put in front of reviewers. How much did they actually remove? Now here's the one that surprises executives. One hundred percent approval rate looks clean. Everyone who has access deserves it. Nothing to fix. But think about what that claims. After a year of hires, moves, reorganizations and projects that ended. Not one assignment was wrong. That's not plausible. It means reviewers clicked approve on everything. That brings us back to the rubber stamp. A healthy review program usually lands somewhere between five and fifteen percent removed, depending on how clean the access was to begin with, a near zero denial rate on a first review should trigger a question, not a celebration. The fourth number is orphaned access. That's access with no owner, no package, and no review attached groups with no active owner. Guests with no sponsor assignments that nothing will ever question. This count should fall over time. If it grows, your design has holes. The fifth is the expired versus extended ratio. When access reaches its end date, how often does it simply end and how often does someone extend it? If nearly everything gets extended, people are treating expiry as an annoyance. The end dates are decoration. If a fair share ends quietly, the model is working. Where does this data come from? Antra already keeps it access review history holds the decisions. Who reviewed what they chose, how long it took, and whether the result was applied. The audit logs record every package assignment, every removal, and every workflow run. You can send those logs to a log analytics workspace, then query them or read them through workbooks, Microsoft Ships workbooks for access, reviews, and lifecycle workflows. The first dashboard takes an afternoon, not a project. One practical point. Audit logs expire after a set retention period. Reviews you want to compare year over year need longer than that. Route the data to log analytics early because you can't query history you didn't keep. Now comes the translation step. This is where most reports die. An executive doesn't care that completion was ninety four percent. They care what it means, so say it in their terms. Forty guest accounts held access to the finance site with no sponsor. We removed them. That's business risk. Stated plainly. Every privileged role was reviewed this quarter and eleven eligibility assignments ended. That's audit readiness. An auditor asks for evidence of periodic access review. You hand over a log with names, dates and decisions. Lever tasks ran within an hour of the last day for ninety eight percent of departures. That answers the question every board eventually asks how fast do we shut the door? Numbers without a sentence like that are trivial. The sentence is what gets budgeted, renewed. But good measurement only matters if the system gets deployed in a way people can absorb. A dashboard doesn't survive a rollout that ambushes the business. The plan has to meet real teams with real calendars. Who didn't ask for any of this. Rolling it out a realistic adoption sequence. Every rollout that works has the same shape. It's narrow at the start. It widens only after something has been proven. Phase one isn't a feature, it's a cleanup of the data before you build anything. Pull a report on the attributes. Everything else will read. How many users have a higher date? How many have a manager? How many have a department spelled the way your scope rules expect you'll find gaps. Everyone does fix those first at the source. That means HR, not the directory. Then pick one population, just one. A single department or one country or one business unit with a manager who's willing to be the first. Choose people whose data is already decent and whose work you understand. You're not trying to cover the company. You're trying to learn how this behaves with real humans in it. Phase two is where access starts to take shape. Build your first access packages for that population two or three, not twenty. A baseline package for the role, and one or two that people request on top of it. Give each one an owner, an approver who answers and an end date and run a single guest review. Pick one team, one side, one group of external users. Those people sit outside your HR data. That's where unchecked access piles up fastest, and where a first review tends to find something real. Forty guests. Nobody remembers inviting as a common result. It also proves the review process on a list short enough to read line by line. Phase three is lifecycle workflows. The order here isn't arbitrary. Join us first. They're the easiest because the higher date announces itself and the payoff shows up fast. A new person signs in on day one without a ticket. People notice that early win buys you patience for the harder parts. Leave a second. The risk is higher, so you want to test them carefully, but the trigger is just as clear. Run them on a small group first. Check every log and confirm the tasks ran in order. Then widen movers last. They're the hardest because they depend on attribute changes. That data has to be trustworthy before you let it remove anything. By now you've watched your own data for weeks. You know which fields lie. That's the right time to let a department change take access away. Phase four brings privileged access in. Move your admin roles into Pim as eligible assignments. tighten the activation settings and set the recurring review on the top roles. This list is short, so it's fast and it's the one executives care about most. While if it's the highest risk because by now you have owners, a review habit and a team that's seen the system work the hardest, roles to change get the most trust. Trust takes time through all four phases. Communication does more work than the configuration does. Tell people what's coming before it arrives. A manager who gets a review request with no warning treats it as spam. A manager who heard about it in a short briefing, saw a two minute walkthrough and knows who to ask. Treats it as a task. Keep the training small. One page, one video, one name contact. Nobody reads more than that and run the first review cycle as a pilot out loud. Tell the reviewers it's the first one that you expect rough edges and that their feedback will change the next round. Then change it. If three reviewers say the list was too long, shrink the scope. If they say the questions weren't clear, rewrite them. A pilot that ignores its feedback is just a launch with a nicer name. That's the plan. Clean data one population packages one review life cycle in order. Privilege last and people told at every step. It's a good plan and it still goes wrong in predictable ways, common failure patterns and how to recover. Most governance programs that fail don't collapse. In one dramatic moment. They fade, and the fade has a few recognizable causes. The first is sprawl. Someone builds a package for every request, a review for every group, and names a reviewer for every list. It feels thorough. Within a year, there are three hundred packages, ninety recurring reviews, and a few hundred people getting emails they don't understand. Owners can't tell which package matters. Reviewers can't tell which request is real. Everyone gets the same notice, so the notices stop meaning anything. More packages don't mean more control past a certain point. They mean more places for access to hide. The second failure is quieter. A workflow runs on bad data and nothing tells. You say the higher date is blank. For a batch of contractors, the workflows trigger never fires for them. No error, no failed task. The log shows nothing because from the system's view, nothing was supposed to happen, or a department gets typed two different ways and the scope rule only matches one half. The sales team gets the baseline package and the other half doesn't. Nobody notices until someone can't open a file. That's the danger of event driven design. When the event never arrives, the silence looks identical to success. Only a person who goes looking will see the gap. The third failure is a review that works too well. Someone sets the default for unanswered reviews to deny. It sounds disciplined and for the right kind of access it is. But applied to everything. It removes access from live systems. A reviewer is on leave for the week. The review closes. Forty people lose access to the application that runs the monthly close, and the finance team finds out on the last day of the quarter. After that, nobody trusts reviews. Business leaders ask to turn auto apply off, and the control that finally had teeth gets its teeth pulled. So how do you recover? Start by shrinking, not adding. Look at your packages and retire the ones nobody has requested in six months. Merge the ones that differ by a single group. Cut the reviews that duplicate each other and keep the ones tied to real risk. A smaller set that people understand beats a larger set they ignore. Then reset the cadence. If reviewers are drowning, shorten the lists and run them more often rather than dumping everything on them once a year and for default, deny. Don't abandon it. Narrow it. Keep it for privileged roles and guests where losing access is cheap to fix for production applications, take reviewer recommendations as the default, name a fallback reviewer and let escalation handle the silence. But before any of that, fix the data, every other repair sits on top of it. Pull the same attribute report you ran in phase one. Find the blanks, the typos, the stale managers. Fix them at the source, then add a check that runs on its own. A weekly query for users missing a higher date, a manager or a valid department, and watch the workflow logs for the opposite problem, too. If a department shows zero runs last month, that's not peace. That's a gap. None of these failures comes from a missing feature. Intro. Had every setting you needed the packages, the reviews, the workflows, all of it was there. What went wrong each time was the assumption underneath that more controls means more safety, that people will keep up, that data will stay clean on its own. That's the model, and it's worth looking at it one more time. Wholly from clean up to continuous context. Go back to where we started. Governance wasn't failing because entra lacked features. It was failing because of the model behind it. A model built on a yearly event, a spreadsheet, a deadline, and an assumption that people would stop what they were doing to go check. That model treats access as something you clean up. You let it pile for twelve months, and then you sweep. The new model doesn't sweep. It changes when the question gets asked. A person joins and access arrives with them tied to their role. A person moves and the old bundle ends while the new one begins. A person leaves and the tasks run in order with a log to prove it. Access that was meant to be temporary ends on its own date, and the access that's left. The long lived kind gets a small review from someone who actually understands it. Notice what's missing. There's no big event, no annual push. Governance stops being a project that starts and ends and becomes part of how access works. So here's the thesis. In one line, access should follow context and end. By default, context decides what someone gets a role, a department, a project, a higher date, and once that context changes, the access has no reason to stay unless someone says it should. That reverses the old assumption. The old model made removal an act someone had to notice, decide, and click. The new model makes removal the default and keeping access the act. Every behavior we talked about follows from that one flip. Now the practical part, because it's tempting to hear all this and go shopping for features. Don't. Before you add a single package or workflow. Audit two things. First, your attribute data. Higher dates. Departments. Managers. Leave dates. Find the blanks and the typos and fix them at the source. Every lifecycle trigger you build will read those fields and a workflow can't act on a fact that isn't there. Second, your review defaults. Open each recurring review and read what happens when nobody answers. Does access stay? Does it go? Does the fallback reviewer step in? Those settings decide whether your reviews change anything or only produce a report. Two audits an afternoon each may be less, and they'll tell you more about your real risk than any new feature will. Because the features were never the gap. The tenant you have today probably already holds most of what you need. What it needs is a different set of assumptions underneath. Outro. Review request. LinkedIn, and topic ideas. If this changed how you think about governance, leave a review of the M365 FM podcast. It takes a minute and it helps more identity and security teams find the show, especially the ones stuck in a review cycle that nobody finishes. And if you want to keep the conversation going, connect with me on LinkedIn. Mirko Peters sent a note about what you're building or what broke. Those messages shape what I cover next. Speaking of which, tell me what you want to hear. Is it conditional access, design entry, external ID, privileged access in hybrid environments, whatever sits in your backlog and keeps getting pushed. Name it. I read every suggestion. One more word on who makes this show possible. This episode is supported by Stellar Migrator for exchange. We said earlier that you can't govern an identity estate. You haven't cleanly moved mailboxes, public folders, archives. If the migration is messy, the identity data underneath it is messy too, and every workflow you build inherits the mess. Stellar migrator for exchange is built for that work, so the foundation is solid before the governance starts. And if you run a product or a service that speaks to IT professionals and decision makers, this show reaches them. Sponsorships and thought leadership placements are open. Reach out and we'll find the right fit. Now, one last thing before you go somewhere in your tenant, there's access you granted last year a guest on a project that ended, a developer who changed teams, an admin role, switched on for a week and never switched off. It's still active today and nobody asked whether it should be.