Mover lifecycle access: remove old grants, verify new ones

A role change is a diff with two kinds of lines. Here's who owns each kind, and what proves it's done.

Illustrative role-change diff, invented for this article.

Every role change produces a diff like this one. The plus lines tend to move fast, because the employee is waiting for them. The minus lines drift, because nobody is waiting for them.

This diff belongs to Taylor Ellis, an invented support engineer moving to the security team. Taylor, the record, and everyone below are fictional, built for this article. It isn't a customer story, a product test, or a default policy.

Mover lifecycle access is finished only when both kinds of lines carry evidence. Every minus line needs a named owner and proof that the old right is gone. Every plus line needs an approver and proof that the new right works.

One record, three owners

A mover is an employee who stays at the company but changes role, team, or department, so their access needs change too. The move itself is the trigger. The diff is what follows from it, and different people own different parts.

HR starts the change, and identity operations carries out the removal. A resource owner approves the additions. Set these fields before any move happens, as decisions rather than prefilled answers.

Two actions are off-limits from the start: leaving the old support admin access in place, and granting security tooling before Ari approves. This is where the request journey from AI for IT support meets lifecycle design. For who may request or grant access at all, see AI agent authorization.

Keep this stage separate from first-day bundles. Those belong to joiner handling, not to a move.

The minus lines: removal needs an owner and a denial

Before the move, Taylor holds 3 old entitlements and 0 new ones. The decision is to remove 3, retain 3, and add 2 after approval.

Cameron checks each target system, not only the request tracker. A confirmed removal needs two things. The entitlement is gone from the target system, and a controlled test of the old action is denied.

So the first check shows 2 of 3 removals confirmed. The group was gone, yet the console kept its own role.

For the permissions check behind each step, see AI access control. That page covers the check. It doesn't make removal happen, and neither does this example.

Cameron asks the console owner to remove the admin role. Under the team's local policy, Cameron also disables Taylor's console access until the role is gone. Then the console shows no admin role, and a test admin action is denied.

Sessions need their own evidence. Removing someone from a group doesn't establish that their live sessions have ended. Identity-provider documentation, including Microsoft's guidance on revoking user access, explains that an application can keep its own session after an account change.

So Cameron records the target application's session-revocation evidence. Taylor then signs in again and confirms the old action is denied. That fresh sign-in shows the old action is denied in a new session. It doesn't prove older sessions ended, which is why the application's own record matters.

The plus lines: approved isn't usable

The additions fail differently. They're rarely forgotten. More often, they stop one step short of working.

That's 0 of 2 grants confirmed. Assigning a role is not the same as effective access, so each plus line needs a target-system entitlement and one permitted action.

Ines assigns the analyst role, and Ari's approval stays on record. Taylor runs one permitted search in the security tooling and one case read. Both succeed. The retained email, wiki, and HR self-service all still work.

This is the completed-work test from Employee self-service beyond the ticket. A closed request is not completed work. A confirmed state is.

The residual record

Taylor's move ends at 3 of 3 removals confirmed and 2 of 2 grants confirmed, with the 3 retained items intact. These outcomes are authored for the example, not test results. The useful artifact is the record that would have held anything left over.

Here's a proposed shape for it. It isn't an industry standard, and the state names are illustrative, not product fields.

Illustrative mover check – Old rights need removal and a denied-use test; new rights need approval and a working action. Session revocation needs separate evidence.

You can merge fields for readability. Don't merge "requested," "removal confirmed," and "new grant confirmed" into one status. That merge is how a lingering admin role hides behind a closed ticket.

In mover lifecycle access, residual items stay on the board until both halves are confirmed, with one owner per half. Your team sets the confirmation interval locally. This article doesn't give a number, because the right one depends on your systems and risk.

Had the console role still shown at the deadline, the change would stay open and move to Remy. An access review would then be scheduled. Recovery is a named handover, not a reminder email.

To see whether your process works, design two measures and their denominators first:

• Requested removals compared with confirmed removals, such as across moves in a quarter.
• Access held after the move compared with access the new role needs, reviewed at the point you choose.

These measures show whether your own process holds. They don't prove that any tool caused an improvement.

Who signs for the old role

With a residual record in hand, you can judge tooling on your terms. For background on how Computer, by DevRev, approaches IT help, Computer for service desk is a reasonable start. Treat it as context, not proof that your configuration supports removal or grant actions. Test any role-change workflow against your own diff.

The questions follow the diff. Can a configuration read an approved role-change record and request each line through an authorized path? Does it route minus lines and plus lines to their owners, and what confirms each one in the target system? Enterprise AI agent buying criteria helps you decide what else to require.

In Taylor's move, Cameron accepted the change only after the evidence showed 3 of 3 removals and 2 of 2 working grants. The signature doesn't revoke anything. It records who checked that the old role is gone.

So a move isn't finished when someone can do the new job. It's finished when the old rights are proven gone and someone has signed for that proof.

Who signed for the old role in your last move, and what did they check? If nobody can say, pick that move, write its diff, and talk through the cutover with DevRev, minus lines first.