Human passwords get policy attention: complexity, expiry, multi-factor. The credentials that machines use get much less, and they are more powerful, longer-lived, and more widely known.
What accumulates
Service accounts created for an integration in 2018, with broad rights because narrowing them was fiddly, and a password that has never changed because nobody is certain what would break.
API keys and tokens embedded in scripts, in configuration files, in a CI system, in somebody’s personal automation. Often with no expiry.
Shared administrative passwords for network devices, storage arrays, hardware management controllers, and appliances. Documented somewhere that several people can read.
Certificates and SSH keys copied between systems, with private keys in places nobody has audited.
Credentials in version control history. Removed from the current files, still present in the history, still valid.
That last one is worth checking today. Tools exist that scan repository history for credential patterns, they run in minutes, and the results are routinely unpleasant.
Why it persists
Rotating a machine credential requires knowing everything that uses it. Nobody knows. So the change carries an unbounded risk of breaking something unknown, and the safe-feeling choice is to leave it.
Meanwhile every year adds another person who has seen it and another system that uses it.
The way out
Inventory before rotation. You cannot rotate what you cannot enumerate. Start by finding them: scan repositories and configuration management, review directory accounts that have not had an interactive logon but authenticate constantly, list local accounts on appliances.
Make the next one better rather than fixing all the old ones at once. Every new integration gets a credential from a secret store, scoped narrowly, with an expiry. The population of bad credentials becomes fixed and then shrinks.
Use platform identity where it exists. Cloud workload identity, Kubernetes service accounts with short-lived tokens, certificate-based machine authentication. These remove the long-lived secret entirely, which is better than managing it. Where this is available, it is the right answer.
Rotate the highest-value ones first, with a plan. The automation account, the backup service account, the hypervisor administrative credential. For each: find what uses it, change it in a window, have the old value available to roll back.
Log authentication and alert on the unexpected. A service account that has authenticated from the same three hosts for two years and suddenly authenticates from a fourth is a signal worth having.
The one that matters most
Whatever credential your automation uses to reach every server. It can change configuration everywhere. In an estate with configuration management, it is functionally equivalent to the highest privilege in the environment.
If that credential is a static password in a variable file, or a key on a laptop, or shared between people, that is the thing to fix before anything else on this list.
The test
Pick your most privileged machine credential. Ask three questions: who knows it, what uses it, and when did it last change?
If the answers are “several people who no longer work here”, “we are not sure”, and “before the pandemic”, you have found the most valuable hour of security work available to you this quarter.