I recently reviewed some old side projects and found more abandoned machine credentials than expected: CI personal access tokens, deploy tokens for hosts I no longer use, and integrations I no longer remember setting up. 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, deleting a credential and waiting to see what breaks is manageable. In a production environment, though, that approach could disrupt forgotten scheduled jobs or critical integrations. Is last-activity data the best way to identify credentials that can be retired, or should it be combined with other checks? Also, what processes have worked for making credential expiration the default without unexpectedly breaking services?
4 Answers
For small systems, checking the last-use timestamp against known activity may be enough, but in larger environments the process needs logging, alerting, ownership records, and a repeatable deactivation workflow. Schedule regular reviews, notify affected teams, disable before deleting, and record the result so the same unknown credential does not reappear later.
The basic idea is a scream test, but disabling is safer than immediately deleting. Revoke or deactivate the credential for a defined period, make sure monitoring and logs are working, and keep a rollback plan in case a delayed job or infrequent process depends on it. If nothing reports a failure during the observation window, deletion is much less risky. Document the process and communicate planned deactivations so people know how to report a legitimate dependency.
Last activity is useful, but don’t rely on a single signal. Check sign-in or audit logs, identify the application or job using the credential, confirm whether it has an owner, and review its permissions and expiration date. For credentials with no owner and no activity for roughly 90 days, a safer process is to reduce or revoke access temporarily, monitor for failures, and delete it after a quiet period. New credentials should have an expiration date by default—around 90 days is a reasonable starting point for secrets—and long-lived client secrets should be replaced with certificates or federated credentials where possible. Tagging each credential with an owner also prevents future orphaned accounts.
The bigger question is why a credential is safe to keep around. Every token should have a known owner, a documented purpose, limited permissions, and an expiration or review date. Anything that cannot meet those requirements should be treated as a candidate for retirement rather than being kept indefinitely just in case.
A short disablement window can miss monthly, quarterly, or retry-based jobs, so the observation period should match the least frequent workload that might use the credential.