Identity Governance Lifecycle: Joiners, Movers, Leavers, Reviews, Entitlements, and Separation of Duties

 

Identity governance controls who should have access over time. Authentication and authorization enforce decisions at request time, but governance determines how entitlements are requested, approved, reviewed, changed, and removed as people move through the organization. Weak lifecycle processes leave valid accounts with unjustified access long after the original business need has disappeared.

Joiners need access from authoritative business data

Onboarding should begin with trusted attributes such as employment status, department, manager, location, and role. Those attributes can trigger baseline access while higher-risk entitlements require explicit approval.

Identity lifecycle governance starts with the same directory objects that support daily administration. identity administration connects users, groups, applications, and roles to the controls that decide when access should be created, changed, reviewed, and removed.

Movers create hidden accumulation risk

Role changes are more difficult than initial onboarding because users often need new access while old access remains. Over time, this creates privilege accumulation.

A mover process should recalculate baseline access, identify incompatible legacy entitlements, and trigger review where the system cannot determine intent automatically. “Add the new role” is not enough.

Leavers require fast and complete revocation

Termination should disable interactive sign-in, revoke active sessions where possible, remove privileged assignments, address tokens and keys, transfer owned resources, and preserve data according to policy.

Lifecycle control has to include SaaS applications and local service ownership, not just the central directory. Microsoft 365 administration shows how identity and service administration meet inside a modern productivity environment.

Entitlements should describe business capability

An entitlement can be a group, application role, cloud role, license, shared mailbox, administrative permission, or data-access package. Good governance catalogs these in terms people can understand and assigns owners who can judge whether access is appropriate.

Technical identifiers alone make reviews weak. A reviewer cannot make a meaningful decision about a role named `grp-prod-fin-07` without business context.

Access reviews need good reviewers and evidence

Periodic reviews are useful only when the reviewer knows why the user has access and what the access allows. Provide manager, resource owner, request justification, last activity where appropriate, and risk information.

Reviews and approvals are only useful when ownership and evidence are explicit. Those accountability requirements are part of information security management, not merely an identity-product feature.

Separation of duties prevents dangerous combinations

Some permissions are acceptable individually but risky together. The person who creates a payment should not necessarily approve it; the administrator who configures a security control may not be the person who approves an exception.

Model toxic combinations explicitly and check them during requests and reviews. If business constraints require an exception, document compensating controls and expiry.

Privileged entitlements need a tighter lifecycle

Administrator access should normally have stronger approval, shorter duration, better monitoring, and more frequent review than ordinary application access. Time-bound elevation reduces standing privilege.

Identity governance also affects platform risk because stale or excessive access can reach cloud resources directly. Azure security makes that connection between identity control and broader Azure security.

Workload identities also require governance

Service accounts, managed identities, automation principals, and API clients need owners, purpose, permission scope, credential lifecycle, and retirement rules. Non-human accounts are easy to forget because they do not appear in HR processes.

Human and machine identities often share policy infrastructure even though their lifecycles differ. AWS identity and access management makes that visible through users, roles, services, resource policies, and data permissions.

Exceptions should expire automatically where possible

Temporary projects, incident access, mergers, and migration work create legitimate exceptions. Make the default exception time-bounded and require explicit renewal rather than relying on someone to remember later.

Continuous review follows the logic of Zero Trust security: access remains justified only while current evidence, role, and risk still support it rather than because it was once approved.

Governance succeeds when lifecycle events change access predictably

A mature program can explain what happens when a person joins, changes job, takes leave, becomes privileged, loses device compliance, changes manager, finishes a project, or leaves the company. The system does not need to automate every edge case, but every important state change should have an owner and control path.

For Microsoft estates, identity governance maps these durable lifecycle principles onto entitlement, access-review, application, and role controls without changing the underlying governance problem.