Skip to content

Microsoft Entra ID Governance

Make access a managed lifecycle.

Give people a clear route to request the resources they need and remove access when the need ends.

Who should be involved: Identity teams, resource owners and service management

What does an access lifecycle cover in Microsoft Entra?

An access lifecycle connects a business need with request, approval, assignment, review and removal. Microsoft Entra entitlement management can support that lifecycle for eligible resources, but an expired package is not proof that every permission has disappeared. Amplified Pi connects the request experience with resource ownership and checks the effective access that remains through other groups or direct assignments.

When this is a good fit
Projects, partner collaboration or changing roles generate repeated access requests, and owners cannot reliably explain when access should end.
Before you invest
Map the actual resources and current access routes. Confirm ownership and relevant licence entitlements; a new request catalogue does not automatically remove unmanaged permissions.

Access starts with a need and ends when that need ends.

01

Request

State the need and requested resources.

Requester
02

Approve

An authorised owner reviews purpose and conditions.

Resource owner
03

Provide

Assign agreed resources and duration.

Identity team
04

Review

Confirm the continuing need or adjust access.

Resource owner
05

End

Remove access on expiry or when the need ends.

Identity team

The lifecycle is configured and tested through agreed policies. Access packages do not replace software licences. Agent and service identities are assessed separately.

What we work on

  • Define role-based resource bundles with owners and eligibility rules.
  • Configure request, approval, expiry and review policies for the agreed access packages.
  • Test joiner, role-change, expiry and exception scenarios with the service team.

What you take away

  • An access-package catalogue for the selected resources.
  • A tested request and approval journey with documented policies.
  • An ownership, review and exception-handling routine.

How we approach the work

Access is a business decision with a lifecycle. We help resource owners make it clear who may request access, who can approve it, how long it lasts and how removal is checked when the need ends.

  1. Map a real access scenario

    We select a project, role or collaboration need and identify its resources and owners. We inspect existing group memberships and direct permissions so the new request route does not simply sit beside unmanaged access. Internal and external identities may need different policies.

    What you receive

    A resource and access map with accountable owners.

  2. Define the request and decision

    We agree who is eligible, what reason is needed, which person approves and what happens if they are absent. Duration, renewal, separation of duties and exceptional requests are addressed in plain language. Technical administrators implement a decision model owned by the business.

    What you receive

    A catalogue and policy design that requesters and approvers understand.

  3. Test provisioning and removal

    Representative identities exercise approved, rejected, expired and withdrawn requests. We verify access at the target resource, including any delay or separate assignment. The offboarding check confirms whether another group or direct permission still provides access.

    What you receive

    End-to-end evidence for both granting and removing access.

  4. Make review a managed activity

    Resource owners receive a review calendar, usable context and a process for unresolved decisions. We agree how outcomes are applied and checked, and which access remains outside the package scope. Administrative privilege and workload identities are assessed separately where they need different controls.

    What you receive

    A review procedure, exception register and support handover.

The guidance behind the approach

Use access packages for an agreed purpose

Microsoft Entra entitlement management supports requests, assignments, reviews and expiry for supported resources. Access packages group the resources required for a task; their policies determine eligibility and approval.

Reference: Microsoft: entitlement management

Review effective access, not just one assignment

Microsoft’s external-access guidance notes that package reviews cover access granted through entitlement management. We therefore check alternative permission paths as well as the package itself before claiming that access has ended.

Reference: Microsoft: external access governance; Microsoft: planning access reviews

Illustrative example

Example: a time-limited partner project

An external collaborator needs a project Team and a shared site for an agreed period. The resource owner approves the request and later reviews the continued need. At expiry, the check covers the actual resources and any parallel membership, so a removed package assignment is not mistaken for complete revocation.

What we need to get started

  • Resource owners and an identity administrator
  • The resources, user groups and external organisations in scope
  • Current access routes, approval expectations and licence information

Questions before you begin

Does an access package replace a product licence?

No. It governs assignments to supported resources. A licensed group can be included where configured appropriately, but that does not remove the need to purchase and validate the underlying licence entitlement.

Does expiry always mean that all access has gone?

Not if another membership, direct permission or different access route remains. We include that possibility in the test and define which team must review access outside the package.

Related modules

The decision at the end

Resource owners can approve access on a clear basis, and expiry or removal works in the tested scenarios.

How progress is judged

Track request lead time, overdue reviews and access that persists beyond its approved purpose.

Scope boundary

Access packages govern entitlements to supported resources; they do not create software licences. Agent and service identities require separate authorisation design.

Choose the next step from the evidence.

The next module depends on the constraint revealed by the work. You do not need to complete every module.

Explore the other modules

Product and policy references

  • Entra entitlement management
  • Microsoft: entitlement management
  • Microsoft: external access governance
  • Microsoft: planning access reviews

Next step