I recently reviewed some old side projects and found more machine credentials than expected: CI access tokens for projects I abandoned years ago, deploy tokens for hosts I no longer use, and integrations whose purpose I can't remember. Unlike employee accounts, these credentials usually have no automatic lifecycle event to mark them as inactive, so they can remain valid indefinitely unless someone checks for them. For small hobby projects, I could revoke a credential and wait to see whether anything breaks, but that seems risky in a production environment. Is last-activity data the best way to identify unused credentials, or should it be combined with ownership and application logs? Also, has anyone made credential expiration the default for newly created secrets without causing operational problems?
4 Answers
The real question is whether the credential has a documented owner and purpose. Record who is responsible, what system uses it, and when it should expire or be reviewed. Communicate planned disablements, follow the same process consistently, and keep an audit trail so an old credential does not quietly become permanent infrastructure.
For low-risk personal projects, revoking an unused token and waiting to see whether anything fails can be acceptable. In shared or production environments, that ‘scream test’ is too disruptive on its own. Use access logs, ownership records, staged revocation, and a rollback plan instead.
A temporary disablement is safer than immediately deleting the credential. Turn it off for a defined window, monitor alerts and job failures, and keep a straightforward rollback available. This gives delayed jobs and infrequent processes a chance to reveal themselves without making an emergency outage permanent. The process should also include good logging and monitoring, because relying on people to complain after something breaks does not scale.
Last-use data is a good starting point, but don’t rely on a single activity signal. Check sign-in or access logs, match activity to a known application or owner, and review where the credential is used before taking action. For credentials with no owner and no activity for roughly 90 days, a staged approach works well: first disable them or reduce their permissions, then permanently delete them after a quiet period. For new credentials, enforce an expiration date at creation time—90 days is a reasonable default for secrets—and prefer certificates or federated identity over long-lived client secrets. Every credential should also have an owner or tagged responsible group.
That makes sense for credentials tied to important systems. I’ll treat deletion as the final step after an observable disablement period rather than using it as the first test.