Stop machine accounts from becoming permanent orphaned access

A machine account should be a managed product object, not a username nobody dares delete. Require a human or team owner, tenant binding, documented purpose, narrow privileges, approved credential type, review date, and explicit retirement triggers. If any of those fields becomes invalid, the automation should stop receiving new credentials until ownership is restored.

Model identity separately from credentials

Create one durable identity for the workload and attach replaceable credentials to it. Do not make a long-lived API key the identity. The account record should include an opaque ID, display name, tenant, owner team, technical contact, purpose, environments, permitted audiences, privilege set, creation source, expiry or review date, and status. Credentials have their own IDs, types, issue times, expiry, last rotation, and last use.

Prefer workload federation or short-lived credentials when the execution environment can authenticate without a stored secret. Where a secret or private key is necessary, keep it in a managed secret store, scope it to one account and environment, rotate it, and support overlap so deployments do not require downtime. Never share one credential across unrelated jobs; shared use destroys attribution and complicates revocation.

NIST SP 800-63B discusses authenticator binding, issuance, maintenance, and invalidation for subscriber authentication over a network. It is written for human-centered digital identity rather than machine accounts, but that lifecycle discipline is still a useful design model for machine credentials.

Make authority tenant-aware

In a multi-tenant system, bind the account to exactly the tenants it serves and prevent a caller from selecting an arbitrary tenant in a request. Authorization should derive the tenant from the authenticated machine identity or validate membership explicitly. Give repository maintenance, billing export, and email delivery separate accounts because their audiences and failure consequences differ.

Avoid broad scopes such as admin when the job reads reports and writes one artifact. Define permissions from actual operations and add an expiry for temporary migration access. RFC 9700: OAuth 2.0 Security Best Current Practice provides current OAuth 2.0 security best current practice and updated security recommendations. If OAuth represents the workload, constrain audience and scope and use confidential-client authentication appropriate to the environment.

Treat ownership as a live dependency

Link the account to a team rather than one employee where possible, while recording an accountable approver. Offboarding events should transfer or suspend accounts the person owned. Team deletion, tenant cancellation, integration uninstall, repository archival, project end date, and prolonged inactivity are equally important triggers.

Run a periodic review that asks the owner to confirm purpose, consumers, privileges, credential inventory, and last-use evidence. Absence of traffic is a reason to investigate, not automatic proof the account is safe to delete; a quarterly disaster-recovery job may be legitimate. After a warning window, disable before deleting so recovery remains possible.

Record authentication and authorization events with account ID, credential ID, tenant, audience, action, result, and correlation ID. Never log secret values. Alert on use after retirement, a credential used from a new environment, repeated failures, and access outside the declared audience. Make last-use timestamps per credential, because an old leaked key can hide behind activity from a newer one.

Build safe retirement

Retirement should block token issuance, revoke renewable credentials, disable static credentials, stop scheduled jobs, and preserve an audit record. Self-contained access tokens may remain usable until expiry, so keep their lifetime short enough for the promised revocation window or add a current-state check for high-risk actions. Delete the identity only after retention requirements and dependency checks are satisfied.

Inventory machine accounts with eight columns: tenant, purpose, owner, privileges, credential type, last use, review date, and retirement trigger. Pick every row with a missing owner this week, suspend issuance after a defined grace period, and make ownership mandatory in the creation API. Governance becomes reliable when the system enforces it at birth.