The scenario

Ana works at ACME, a fictional company. She has asked for Contributor on the web-platform project, and her request is waiting for Marco, the group's owner. Someone decides not to wait and adds Ana to the WebPlatform Contributors group by hand in the Azure portal. Through the group, she now has the access.

Git does not list her. Entra and Git now disagree, and that difference is drift.

If the organization enforces: back to what Git says

In an organization in enforce mode, Git is the record, and anything else is a mistake by definition. The membership Ana got by hand is removed on the next check of the group, about a minute in our tests, and the audit log in Entra shows that Entitlements as Code removed it.

Ana is not stuck. The way to get the access is the one already open: her request, approved by Marco.

Owners work the same way. An owner added by hand is removed, and the group's owners go back to the ones on record. A group with no owners on record is the exception: its Entra owners are left alone, so a team can bring owners under Git one group at a time.

If the organization observes: reported, and a person decides

Observe mode is read-only. Nothing is written to Entra, so Ana keeps the access she was given by hand. What changes is that it is no longer invisible: the web app's Drift page lists it, with who added it, to which group, and when.

From there, a person decides, with one click:

• Bring into Git, if the access is right. It opens a pull request that adds Ana to the group's file, and the group's owner approves it like any request. From then on the access has a record.
• Remove, if it is not. It opens a pull request that removes her, approved the same way.

Either way, nothing is removed by a job on its own. Taking access away from someone is a decision, so it stays with the owner, made with a request and recorded like any other.

Drift is not only additions. A member removed by hand, or a group created in Entra that Git does not know about, shows up too.

Side by side

An organization can move from one to the other over time. Observe suits the period when access is still partly granted by hand and Git is catching up. Enforce suits an organization whose records are trusted.

Access that should end, ends

Drift covers access granted outside Git. The other half of keeping access clean is access that was granted properly but is no longer needed.

• End dates. A request can say until when. When the date comes, the access ends on its own. The approval already covered the end date, so nobody has to approve it again or remember it, and a pull request tidies the expired line out of Git.
• Access reviews. Owners review their groups on a schedule. For each member they choose to keep or remove, and every removal is a request with a reason, recorded like any other.

Together they answer the questions an audit asks: who has access, who approved it, until when, and who checked that it is still needed.

The examples use a fictional company, ACME, with two Azure DevOps organizations: ACME, where its product teams work, and LABS, a smaller one for experiments.

Step 1: import what already exists

Nobody should have to write the access files by hand for a directory that already exists. Entitlements as Code imports the groups you have today, with their members and owners, and writes one file per group into Git. Each file is linked to its existing group in Entra, so nothing is created twice.

From then on, the files describe the access people have today, not the access someone thinks they have. That is the right starting point: first Git has to match reality, and only then do you change reality through Git.

Read the import with the group owners. It records what exists; it does not judge it. Some memberships will look wrong. Note them, but resist fixing everything in the first change. Fixes are easier to review as separate, small requests, each with its own reason.

Step 2: observe, with nothing written

Every organization starts in observe mode. Nothing is written: no members, no owners, no groups. Users are a special case in every mode: they are read from Entra and never changed.

What you get while nothing changes:

• Requests and approvals, on real data. People ask in the web app, owners approve, and every change is reviewed and recorded as a pull request.
• Checks on your actual groups. Naming, duplicate members, circular nesting and sensitive groups with no owner are flagged before anyone has to spot them.
• A drift report. The web app lists the access granted outside Git. During observe, that is usually access still granted the old way, by hand. Each one can be brought into Git for review, or removed.

Since nothing is written, an approved request in an organization that observes is recorded but not applied. Observe is for getting Git and Entra to agree, not for granting access yet.

What to check before enforcing

Use the observe period to get three things right:

1. Drift close to zero. Each difference is either access to bring into Git or access to question. When the report is empty, Git and Entra agree.
2. Owners on every group. In enforce mode, the owners on record become the group's owners in Entra, and owners added by hand are removed. A group with no owners on record leaves its Entra owners alone, so you can bring owners in one group at a time.
3. Owners who will approve. Approvals come from the owners. Make sure each group has owners who know they now review the requests.

Step 3: enforce one organization at a time

When an organization is ready, an EaC admin switches it to enforce in the web app. The switch is itself a request: it opens a pull request, another EaC admin approves it, and it has an author and a history like every other change.

From then on, for that organization only:

• Approved requests are applied. The change reaches Entra and every platform that follows the groups, with no ticket and nobody in an admin console.
• Changes made by hand go back to what Git says. A member or owner added outside Git is removed; one removed outside Git is put back.
• Users stay read-only. They are still only read from Entra.
• Other organizations keep their own mode. One that still observes stays read-only until it is switched.

Why one organization at a time

Each organization has its own groups, owners and habits. Switching one keeps the effect small and easy to watch: you learn how the first one behaves, fix what the observe period missed, and then move to the next. An organization whose owners are not ready can wait in observe mode without holding back the others.

The order is the same for every organization: import, observe until Git matches Entra, then enforce.

One request, start to finish

Ana works at ACME, a fictional company, and needs to work on the web-platform project in its Azure DevOps organization. She opens the Entitlements as Code web app, picks the project and the access level, writes why she needs it and until when, and sends the request.

Marco owns the group that grants that access. He sees Ana's request in his Approvals page, with her reason and the end date, and approves it there. Behind the scenes the request is a pull request: Marco's approval is recorded on it, the checks pass, and it is merged. The group in Microsoft Entra ID is updated, Azure DevOps follows the group, and Ana's My access page shows the new access and when it ends.

Nobody opened an admin console, and nobody had to remember to write anything down. The pull request holds who asked, what for, why, until when, and who approved it.

Who approves what

The person who approves depends on what the change does.

In the demo, Marco owns the group and the request only adds a member, so his approval is enough.

If the same request had made Ana an owner, Marco's approval would not be enough on its own. Owners decide who gets in, so a change to the owners needs a second person: an EaC admin who is not Marco.

An owner can also say no. A rejected request is not applied, and the rejection stays on record with the request.

Who never counts

Three kinds of people never count as approvers, even when they own the group:

1. The person asking. Ana cannot approve her own request.
2. Anyone who edited the request. They helped write the change, so they are not independent of it.
3. The people getting the access. Some people can ask on behalf of a colleague. If Ana asks for Marco, Marco cannot approve his own access, even though he owns the group.

The reason is separation of duties. A record that says "Ana asked, Ana approved" answers nothing. When an auditor or a customer's security questionnaire asks who approved a grant, the answer has to be someone other than the person who asked for it, wrote it or received it.

That is also why EaC admins step in when no owner can vote. Say Marco is the only owner and he needs Contributor himself. He is the one asking, so he cannot approve, and an EaC admin approves instead. Marco still gets his access through the same flow, and the record still shows two different people.

The rules are enforced, not just suggested. The pull request cannot be merged until the right approval is there, and the owners that count are the ones already on record, so nobody can make themselves an owner in the same request and then approve it.

The same flow, for every platform

Azure DevOps is the example here, but the flow does not depend on it. Access lives in groups in Microsoft Entra ID, and the platforms you use map those groups to their own access: a project role, a team, an account, a Jira project. A module connects each platform.

So the questions never change from one platform to the next: who asked, who approved, and until when.

Taking access away

Removing access follows the same path. Leaving a group is a request like any other, approved by the group's owner. Offboarding someone from every group is a single request. Access with an end date ends on its own, and periodic access reviews let owners confirm who should keep it. Every removal has an author, a reason and an approver, like every grant.

The result is a history where every grant and every removal has an author, a reason, an approver who is not the author, and a date. That is the evidence, and it lives in your own Git.