Offboarding and Identity Lifecycle Management

Picture an electronic health record system used by a large group of clinicians. Each clinician needs to open the records of the patients in their own care, but nobody should be able to open the records of a colleague's patients simply because they happen to be logged into the same system. Deciding who may see what, and keeping that decision enforced automatically, is the job of access control.

This article follows one concrete implementation in which every clinician received a dedicated software identity that acted on their behalf. The system does not only check the human at the keyboard. It checks an agent identity created for that clinician, because the agent is the identity that acts inside the system when a request arrives.

The first design decision is that each clinician had their own identity rather than sharing one identity across the group. The identity was built with Entra Agent ID, which the source names as the identity platform used for clinician identities. Because every clinician had a separate identity, every later decision about access could be tied to one specific person.

Creating an identity is not the same as granting access. The identity exists first, and the reach is attached afterward. This separation matters because the two steps can be reasoned about, reviewed, and removed independently. An identity with no scope cannot reach anything useful, and a scope is only meaningful when it is attached to a specific identity.

An agent identity does not stay in one unchanging state. The source describes a small set of stages: the identity is created at onboarding, it is scoped through role-based access controls, it is reviewed on a recurring schedule, and it is eventually revoked when the clinician leaves. The diagram below lays these stages out as states and the events that move an identity from one to the next. It is a map of what can happen to an identity over time, not a description of any particular software screen.

Read the diagram from left to right. The identity is created when the clinician is onboarded, and scoping follows. Once the identity is in use, it returns to the review step on the customer's standard access-review cadence of ninety days, so it is checked again on that schedule rather than trusted indefinitely. The only event the source ties to ending the identity is offboarding. A review does not end the identity's life; it confirms that the identity may continue.

Scoping is the step where an abstract role becomes a concrete boundary. The source gives the example of a clinician whose agent can work with that clinician's patient panel and nothing beyond it. The scope is what the system consults when a request arrives, so it determines whether a request for a particular patient record is allowed or refused.

Creating and scoping an identity protects the system while the clinician is employed. The harder question is what happens when the clinician leaves. The implementation handled this through its offboarding process, which automatically revoked the departing clinician's agent identity. The source reports that two months after go-live, a clinician left the system, and the identity was auto-revoked within four hours. The timeline below shows the order of those events.

The four-hour figure is the window the customer's security team chose deliberately to limit misuse. The source does not describe any activity during the gap, so the honest reading is that the window is the period during which a departed clinician's identity could still exist before revocation removes it. Shortening that window reduces the time in which misuse is possible.

Scoping and revocation control who may act. A third requirement controls how actions are recorded. The audit log had to connect every agent action to a specific human clinician and to a specific timestamp. A record of activity is only useful if someone can answer which clinician's agent did something and when, and that answer depends on giving each clinician their own identity. Without individual identities, the log would point to a generic account rather than to a person.

Read the sequence from top to bottom. The clinician acts through their own agent identity. The EHR checks the action against the scope attached to that identity. The action is then written to the audit log together with the clinician it belongs to and the timestamp. Because the identity itself was dedicated to one clinician, the log entry can be traced back to that person.