The Entitlements as Code framework
The lifecycle of a grant, the capabilities that support it, and where the method starts and stops.
The principles say how access should be managed. The framework says what happens to one grant over its life, which capabilities a team needs for that, and what the method covers. Roles and the maturity model complete it.
The lifecycle of a grant
1. Request
A person asks for one entitlement: which group, why, and until when. The request becomes a proposed change in Git, so from the first moment it has an author, a reason and an exact content.
2. Approve
The owners of the group approve or decline it. The approval rules are written down too: who may approve which group, how many approvals a change needs, and who never counts (the requester, anyone who edited the request, the people who get the access).
3. Apply
Once approved, the change is merged and applied: the group in the identity provider changes, and every platform that maps that group to its own roles changes with it. Nobody copies the change by hand into each tool.
4. Reconcile
The platforms are compared with Git continuously. Differences are drift: reported for a person to decide, or put back to what Git says, depending on whether the organization observes or enforces.
5. Review
On a schedule, owners go through the members of their groups and confirm who keeps access. Keeping someone is recorded; removing someone is a change like any other.
6. End
Access ends on its end date, or when an owner does not keep it in a review, or when the person asks to leave. The removal is a pull request, so the record shows why and when the access ended. Needing the access again starts a new request.
Capabilities
Each capability serves one or more steps of the lifecycle. A team can build them, buy them, or mix both.
| Capability | What it does | Lifecycle steps |
|---|---|---|
| Entitlement catalogue | Every group that can be requested, with its owners, its description and the platforms that follow it, in Git | All |
| Request intake | A simple way to ask for a group with a reason and an end date, without editing files by hand | Request |
| Approval rules | Who approves which group, how many approvals a change needs, and who never counts | Approve |
| Policy checks | Automatic checks on every proposed change: naming, sensitive groups, owners present, end dates within limits | Request, Approve |
| Applying to platforms | Merged changes update the identity provider's groups; the platforms follow the groups | Apply |
| Drift detection | Continuous comparison of Git and the platforms, with a report of every difference | Reconcile |
| Enforcement | Optionally, putting hand changes back to what Git says, per organization | Reconcile |
| Access reviews | Scheduled reviews where owners keep or remove each member, with every decision recorded | Review |
| End dates | Grants that end on their own on the agreed date, through a recorded change | End |
| Audit trail | The history of every grant: author, reason, approver, dates, and what was applied | All |
Scope: what the method covers
In scope: entitlements. Group memberships and group owners in the identity provider, and through them the roles each platform gives to those groups: a project role, a team, an account, a space.
Out of scope: creating people. Accounts are created and disabled by the identity lifecycle that already exists (HR, onboarding, offboarding). Entitlements as Code reads people from the identity provider; it decides which groups they are in.
Out of scope: authorization inside applications. How an application checks a permission in its own code is the field of authorization and policy as code. Entitlements as Code decides who holds an entitlement, not how an application evaluates it. Why "entitlements" explains the difference in more detail.
Where to go next
- Roles: who requests, who approves, who runs it and who audits it.
- Maturity model: from a recorded state to a governed one, and how to measure progress.
- In practice: the lifecycle on Microsoft Entra ID and your platforms.