Most security teams treat secrets rotation as a solved problem. You've got a vault, set rotation policies, and automated the process. Box checked. But here's the uncomfortable truth: you're spending engineering time and budget on a control that doesn't actually reduce your attack surface.
The Conventional Wisdom
The standard playbook goes like this: store credentials in a vault (HashiCorp, AWS Secrets Manager, Azure Key Vault), rotate them on a schedule, audit access, and sleep better at night. PCI DSS v4.0.1 Requirement 8.3.2 mandates password changes for interactive users. SOC 2 auditors expect documented rotation policies. Your compliance checklist has a green light next to "secrets management."
Most organizations still treat credentials as something that must be protected, stored, and rotated. It's what we've always done. It's what the tools are built for.
Why We Disagree
Rotation doesn't fix the core problem: static credentials exist. Every API key, service account password, and database credential in your vault is a potential breach vector. Rotation just changes which secret is valid this week.
During a rotation cycle, both the old and new secrets work for some time. Your monitoring can't tell if a connection using the old credential is legitimate legacy traffic or an attacker who exfiltrated it weeks ago. You've doubled your exposure window, not halved it.
Rotation also creates operational debt. Someone has to update connection strings. Someone has to handle the service that didn't get the memo about the new credential and is now throwing 401 errors at 2 AM. You're paying engineers to manage a process that doesn't materially improve your security posture.
The Evidence
Look at how breaches actually happen. Attackers don't race against your rotation schedule. They use the credential immediately or establish persistence through other means. A 90-day rotation policy doesn't stop an attacker who dumps your secrets and uses them within hours.
A second model is reshaping machine authentication: eliminate static secrets altogether and authenticate workloads using identity and just-in-time access. Instead of "here's a password that's valid for the next 30 days," you get "prove you're the authorized workload right now, and here's a token valid for the next 10 minutes."
This isn't theoretical. Cloud providers have been moving this direction for years. AWS IAM roles for EC2 don't use long-lived credentials. Google Cloud's Workload Identity Federation authenticates services without storing keys. These systems use identity assertions and short-lived tokens instead of rotating static secrets.
The security difference is fundamental. With rotation, you're managing the lifecycle of a credential that could be stolen at any point. With identity-based authentication, there's no credential to steal. The workload proves who it is through platform-native mechanisms (instance metadata, service accounts, signed JWTs), gets a time-limited token, and that token expires before an attacker could meaningfully use it.
What to Do Instead
Start with your newest services. Don't retrofit your entire infrastructure overnight, but stop creating new static credentials.
For AWS workloads, use IAM roles attached to instances or ECS tasks. Your application code calls the instance metadata service to get temporary credentials. No secrets in environment variables. No rotation scripts. The credentials refresh automatically and expire in hours.
For Kubernetes, use service accounts with short-lived projected tokens instead of pulling secrets from a vault. The kubelet handles token refresh. Your pod gets a credential that's valid for the current session.
For service-to-service authentication, implement mutual TLS with short-lived certificates issued by something like SPIFFE/SPIRE or cert-manager. Services prove identity through cryptographic attestation, not shared secrets.
When you must use API keys (third-party SaaS integrations that don't support better auth), treat them as the exception they should be. Document why identity-based auth wasn't possible. Set calendar reminders to check if the vendor has added OAuth or OIDC support.
You'll still need a secrets manager for that shrinking set of static credentials, but you're not building your entire authentication strategy around it.
When the Conventional Wisdom Is Right
Secrets rotation has its place. If you're running legacy applications that can't be refactored to use identity-based auth, rotation is your best available control. If you're managing credentials for human users (not machine-to-machine auth), rotation combined with MFA makes sense.
And rotation absolutely matters when you know a credential was compromised. Immediate rotation is part of your incident response playbook.
But treating rotation as your primary machine authentication strategy is like putting a better lock on a door when you could eliminate the door entirely. You're optimizing the wrong thing.
The question isn't "how do we rotate secrets more efficiently?" It's "why do we have static secrets in the first place?" Start asking that question for every new service you build, and your attack surface shrinks faster than any rotation policy could achieve.
