agentleFS
Sign inStart free
vinayaklatthevinayaklatthe/microsoft-security-skills/skills/entra-id-governance/SKILL.md

entra-id-governance

Skill179 starsChanged 5 months agoMITView on GitHub

Guidance for Microsoft Entra ID Governance — automating identity lifecycle and access with entitlement management (access packages), access reviews, lifecycle workflows for joiner-mover-leaver, separation of duties, and guest access governance. Covers when to use access packages vs direct group assignment, reviewer choice and fallback actions, and integration with PIM for privileged access. WHEN: Entra ID Governance, entitlement management, access packages, access reviews, lifecycle workflows, joiner mover leaver, JML, certify access, separation of duties, govern guest access, B2B guest expiration, identity lifecycle automation, sponsor approval, recertify access. DO NOT USE for risk-based detection (use entra-id-protection), CA policy authoring (use conditional-access-mfa), or PIM activation (use azure-pim).

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Default to "no response = remove" with reviewer escalation.

    line 79
  2. Distinctive:

    Lifecycle workflows are triggered by attributes: If HR doesn't push reliable attribute data, workflows won't fire.

    line 84
  3. Distinctive:

    Don't put PIM-eligible roles in access packages: Use PIM for Groups so activation is separate from assignment.

    line 86

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Microsoft Entra ID Governance

Entra ID Governance ensures the right identities have the right access to the right resources at the right time. It automates identity lifecycle (JML) and access governance for employees, partners, and guests. Requires the Entra ID Governance SKU (P2 + Governance add-on, or M365 E5 + Governance).

When to use

Automating access requests/approvals, recurring access certification, and joiner-mover-leaver provisioning. Use this skill to choose between access packages and direct group assignment, configure access reviews safely, and run lifecycle workflows.

Do not use this skill for risk detection (entra-id-protection), Conditional Access (conditional-access-mfa), or PIM activation (azure-pim).

Pick the right governance mechanism

If the goal is...UseNotes
Self-service access request with approvalEntitlement management - access packageIncludes guests; sponsor or manager approval
Time-bound access for a projectAccess package with expirationAuto-revokes; safer than group
Govern an existing privileged groupPIM for Groups (separate skill)Just-in-time, not lifecycle
Recertify membership of a sensitive groupAccess review on the groupManager or self-attestation
Recertify access to an appAccess review on app assignmentsCatches stale SaaS access
Auto-provision new joinersLifecycle workflow - joinerPre-hire setup, welcome email
Auto-revoke leaver accessLifecycle workflow - leaverDisable, group removal, license drop
Move to new department auto-adjust accessLifecycle workflow - mover + dynamic groupsAttribute-driven
Catch toxic role combos (e.g. AP + AR)Separation of duties on access packageHard-block incompatible packages

Rule of thumb: if humans request the access, use an access package. If the system grants the access from HR attributes, use lifecycle workflows + dynamic groups. Direct group assignment is the legacy default and rarely correct in 2026.

Approach

  1. Define the catalogue — Access packages live in a catalogue. Catalogues map to a business owner (HR, Finance, Engineering platform team). Catalogue owners are accountable; IT facilitates. Verify: each catalogue has a named non-IT owner.
  2. Build access packages with policies — Each package has resources (groups, apps, SharePoint sites), eligible requesters (internal users, specific connected orgs, all external), and an assignment policy (approval, expiration, attribute requirements). Verify: every package has expiration set; no perpetual access.
  3. Configure access reviews safely — Set reviewer (manager > self > specific user), recurrence (quarterly Tier 0, bi-annually Tier 1, annually Tier 2). Critical: choose "no response" action carefully - auto-remove on no response is safer for low-risk resources but dangerous if the reviewer is on leave. Verify: reviewer escalation enabled; "no response" defaults documented per review.
  4. Lifecycle workflows for JML — Build three core flows: Pre-hire (T-7 days), Joiner (start date), Leaver (last day). Use HR attributes as triggers (employeeType, employeeHireDate, accountEnabled). Verify: leaver flow disables account, removes from all groups, revokes sessions, within 1 hour of HR attribute change.
  5. Separation of duties on access packages — Mark incompatible packages (e.g. "Accounts Payable" + "Vendor Master Data Editor"). System blocks the second request with audit log.
  6. Guest governance — All B2B guests via access packages with expiration. Run a quarterly review of guests with no recent activity (use signInActivity filter). Remove inactive guests automatically. Verify: guests created outside an access package = 0 in monthly report.

Guardrails

  • Prioritise leaver/deprovisioning automation - orphaned access is a common breach root cause. Leaver workflow within 1 hour of HR change, hard, not negotiable.
  • Set review reviewers and fallback actions carefully so "no response" doesn't auto-approve. Default to "no response = remove" with reviewer escalation.
  • Access packages for guests, always. B2B invitations outside packages bypass expiration and reviews.
  • Separation of duties only works if both packages are governed. If one role assignment is direct (not via package), SoD won't see it.
  • Lifecycle workflows are triggered by attributes. If HR doesn't push reliable attribute data, workflows won't fire. Validate the HR sync before relying on automation.
  • Don't put PIM-eligible roles in access packages. Use PIM for Groups so activation is separate from assignment.

Common anti-patterns

  • "Provision via Active Directory groups, deprovision via ticket" - Asymmetric, leaks access. Both sides need to be automated.
  • "Access reviews once a year" - 12 months of drift. Quarterly for sensitive resources.
  • "Reviewer = the resource owner" - Owner has bias to approve. Manager of the user is better; self-review only for low-risk.
  • "Guest invitations from any user" - Untracked guests sprawl. Restrict invitations to access package requests + a small invitations team.
  • "Lifecycle workflow runs on Day 1" - Joiner needs access ready before Day 1. Pre-hire flow at T-7 days.
  • "Direct group assignment is faster than building a package" - Faster once, slower forever after (no review, no expiration, no audit).

Example prompts

  • Build an access package for guest contractors with sponsor approval and 90-day expiration.
  • Set up lifecycle workflows for pre-hire, joiner, and leaver using HR attributes.
  • Configure quarterly access reviews on our privileged group with manager review.
  • Enforce separation of duties between "Accounts Payable" and "Vendor Master" access packages.
  • Audit and remove inactive guests with no sign-in in 90 days.
  • Move from direct group assignment to access packages for self-service.

Microsoft Learn

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free