An integration engineer has resigned. Six accounts created during deployment for various applications and integrations are still active, and nobody can say which of them anything still uses. What is the professional way to clean this up?

Orphaned identities are cleaned with lifecycle discipline, not adrenaline: map each account to the application or person that owns it, verify what still authenticates with it, move dependencies onto properly owned identities, then disable first, observe across a window long enough to cover the slowest scheduled integration, and delete only after the quiet. Disable-before-delete is the craft - it reverses instantly when a forgotten Tuesday-night job surfaces - and the ownership mapping turns the archaeology into paperwork. Immediate mass disablement 'works' in the crude sense that breakage announces itself, but it announces itself by interrupting whatever business process leans on that account, converting routine hygiene into an unplanned outage with an apology attached. Leaving accounts active until formal retirement inverts the risk model: a dormant credential with no owner and unknown password history is precisely the path an attacker walks, and 'quiet network' is an assumption, never a control. Resetting and parking accounts manufactures a second generation of orphans - credentials owned by nobody whose previous use muddies future attribution. Exam caveat: the mapping exercise is also the right moment to catch over-privileged service accounts and fix both problems in one pass. Operational check: every surviving service account names an owner and an owning application in the as-built record, and the disabled batch is deleted once the observation window closes clean.