Access is not an event, it is a lifespan. A person joins and needs a starting set of access, moves and needs it to change, and leaves and needs all of it gone the same day. Most identity incidents are not clever attacks; they are the residue of that lifespan being handled by hand and handled unevenly, the leaver who kept a mailbox, the mover who accumulated three jobs worth of rights. Access reviews and lifecycle workflows are the two machines that turn this lifespan into something the platform runs rather than something people remember to do.
This is the tenth article in the Entra ID series. The previous one was about granting access as a governed object. This one is about keeping it correct over time, and about automating the moments when it should change.
Reviews put access back in front of a human
An access review is a scheduled recertification: at an interval you choose, the access someone holds is put back in front of a decision-maker who confirms it or takes it away. The reach is broad and worth knowing, because it is most of what recertification in a tenant needs to cover. You can review membership of groups, assignment to applications, the eligible and active assignments of privileged roles through their integration with Privileged Identity Management, the assignments handed out by access packages, the standing of guest accounts, and, with the governance license, users who have gone inactive. The reviewer can be the resource owner, a designated person, the user’s manager, or the users themselves, and matching the reviewer to the access is half of designing a review that produces honest answers rather than reflexive approvals.
The platform will assist the reviewer with recommendations, and it is important to understand exactly what they are. One kind is based on activity, flagging access from someone who has not signed in within a recent window as a candidate for removal. A newer kind uses a machine-learned sense of how affiliated a user is with the rest of a group, based on their place in the organizational hierarchy, and suggests removal for the outliers. Both are advisory. They are inputs to a human decision, not the decision itself, and treating them as verdicts is how a review quietly rubber-stamps a model’s guess.
The setting that decides whether a review is safe
A review has to say what happens to access nobody reviewed, and this single setting is where reviews are made safe or dangerous. The options are to leave access unchanged, to remove it, to approve it, or to take the recommendations, and they combine with an auto-apply switch that either enforces the outcome automatically or leaves it for an administrator to apply. The combination to respect is removal, or taking recommendations, together with auto-apply, because if reviewers never respond, that configuration will strip access with no human ever having looked, which is occasionally exactly what you want and frequently a way to break access for people who did nothing wrong except have an inattentive reviewer. The discipline is to choose the no-response behavior consciously for each review, understanding that a review without a clear decision policy either lets stale access persist untouched or removes valid access silently, and neither is a default you should back into.
A review without a decision policy either lets stale access persist untouched or strips valid access silently. Choose which on purpose.
Workflows run the joins, moves, and departures
Where reviews keep standing access honest, lifecycle workflows automate the transitions, the joiner, the mover, and the leaver. A workflow is a set of tasks bound to a trigger, and the triggers are the interesting part because they let the directory act on the calendar of an employment rather than on someone remembering to click. A workflow can fire a set number of days before or after a person’s hire date or their leaving date, it can fire when an attribute changes, which is the basis of the mover scenario, and it can fire on demand when you need to run it by hand. The task catalog is deep: send a welcome message, generate a temporary access pass and route it to the new hire’s manager so they can authenticate on day one without a password, add and remove group and team memberships, request or remove an access package assignment, assign or strip licenses, disable the account, revoke every refresh token to end all active sessions at once, and, at the far end, delete the user. When the built-in tasks are not enough, a workflow can call out to a Logic App to do something bespoke.
Two practical truths keep these workflows from being magic. The first is timing: the automatic triggers are evaluated on a schedule rather than the instant an event occurs, so a task set for the hire date runs on the next evaluation pass, not at the stroke of midnight, and designs that assume second-level precision will be disappointed. The second, and more consequential, is that the whole apparatus runs on attributes it does not itself produce. A joiner workflow keyed to the hire date does nothing useful if the hire date is empty, and a mover workflow watching for a department change never fires if the department attribute is never updated. These attributes normally arrive from an inbound provisioning connection to a human-resources system, or they are maintained by hand, and the quality of that source is the ceiling on how well any of this works. Lifecycle automation is only ever as good as the employment data underneath it, and that data lives outside identity, which is the uncomfortable dependency at the center of the whole design.
The two machines meet entitlement management
These pieces are meant to interlock rather than stand alone, and the seams are where a mature design shows. A joiner workflow does not hard-code a pile of group memberships; it requests the access packages the person’s role warrants, handing the actual grant to the entitlement management from the previous article so that access stays governed even when a workflow initiated it. A leaver workflow does not merely disable the account; it revokes the sessions and lets the loss of assignments trigger the guest cleanup the governance layer already knows how to do. And the access reviews close the loop on everything in between, catching the access that neither a clean joiner nor a clean leaver accounted for, the grants made in the middle of an employment that no automated transition will ever revisit. The three together describe a lifecycle that provisions correctly, adjusts as people move, recertifies what persists, and deprovisions cleanly, without depending on anyone to remember the steps.
Licensing, and where this is heading
Both machines are part of the Entra ID Governance product and licensed per seat, which for reviews means a license for the people reviewing and the people being reviewed, and for workflows a license for every user a workflow processes. External guests are metered separately on monthly activity rather than counted as seats. The billing for that guest activity has moved from theoretical to enforced across these features in the current year, so a tenant that leaned on governed guest access without accounting for the meter should expect it to appear as a real cost rather than a footnote. As with the rest of this area, the newest capability, expanded attribute support for mover triggers, delegation of workflow administration through administrative units, continues to land on the governance license rather than the older premium tier, which is the throughline of where Microsoft is putting its investment.
Reviews and workflows keep internal access correct across its lifespan. They touch external identities only at the edges, through guest reviews and the cleanup that trails a lost assignment. The larger question of how you admit outside people and organizations at all, and what you choose to trust about them, is its own design with its own blast radius, and it is where the series turns next.
Entra ID
‹ Previous: [E 9] Entitlement Management: Access as a Governed Object
Next: [E 11] External Identities: B2B, Cross-Tenant Access, and Direct Connect ›
