A contractor's workload identity still authenticates three months after their own login was removed — why?

## Two lifecycles, one of them missing A person's identity sits inside a process that exists independently of any engineering decision. Somebody is hired, an account is created. Somebody leaves, the account is removed, usually on a checklist that an administrator runs and that a manager signs. That process is imperfect, but it exists, it has an owner, and it fires on a real-world event. A workload's identity has no such process. It comes into existence because an engineer was shipping a service and the service needed to authenticate. Nothing about that creation registers it anywhere that a departure would ever look. There is no event that means "this workload should stop existing", because workloads do not resign. So the honest answer to the question is not that machine identities are exempt from removal. They can be removed at any time. It is that **nothing fires the removal**. ## Why nothing fires - **The departure checklist covers people.** It looks at accounts belonging to the person, and the workload identity belongs to a service. - **Nobody is recorded as responsible.** The engineer who created it may be the person who left. The team that inherited the service may not know it exists. - **Disabling it is risky and unrewarded.** If the workload is live, turning off its identity is an outage; if it is not, nobody is sure. The safe move is always to leave it. - **It looks healthy.** It authenticates successfully every day, which reads as evidence that it is needed rather than evidence that something is still running. - **Its rights were set once and never revisited,** usually to whatever was convenient during the first week of the project. ## The two lifecycles side by side | | The contractor's own identity | The workload identity they created | |---|---|---| | Created by | a joining process with an owner | an engineer, while shipping something | | Registered where | the organisation's record of people | often nowhere beyond the store itself | | Ends on | departure, via an existing routine | no event at all | | Who answers for it | the person, and their manager | nobody, unless assigned | | Reviewed | as part of a people process | only if somebody goes looking | ## What the contractor may still hold This is the part that turns an untidy inventory into an exposure, and it is worth stating in the order a reviewer would ask it: 1. **They set up how the workload authenticates.** Whatever the workload presents at start-up passed through their hands. 2. **If that proof is something a person can copy and keep,** they may still have it, in notes, on a machine of their own, or in a project handover folder. 3. **If they still have it, they can still authenticate as the workload** — from anywhere, at any hour, with no name of theirs in the record. 4. **Removing their own account did nothing to any of that.** It ended one path and left the other untouched, which is exactly why the departure felt complete and was not. Whether that is genuinely reachable depends on what the workload presents and whether a copy of it can exist outside the machine. Where the workload's proof is bound to the platform it runs on rather than to something typed in, the contractor keeps nothing usable. That difference is the thing to ask about first. ## Giving a machine identity an ending - **A named human owner on every workload identity.** Not a team address — a person, because ownership that belongs to a group belongs to nobody. - **A date by which somebody re-confirms it is still needed.** The value is not the date; it is that the absence of a decision becomes visible instead of silent. - **A departure question that looks past people's own accounts:** which workload identities did this person create, and did they hold what any of them presents? - **Replace what the workload presents when the person who set it up leaves,** on the same reasoning that you replace a shared credential after a departure. Removing an account and replacing a credential are different actions with different effects. - **Prefer arrangements where there is nothing for a person to keep.** Where the workload's proof is issued to the running machine rather than handed over by an engineer, the departure question mostly answers itself. ## The limit worth admitting An owner field and a review date are claims, not enforcement. They make a stale identity visible to whoever reads the list; they do not stop it authenticating. The only thing that stops it is somebody deciding to end it, which is why the review date matters more than the owner field: it creates the moment when that decision is due. An estate that records owners and never reviews has better documentation and the same exposure.