Credential Rotation and MFA: The Routine That Prevents Most Incidents

The majority of cloud account compromises come down to one of two things: a credential that should not have existed, or one that should have been rotated and was not.

Neither is a technology problem. Both are process problems, and they are solvable with a routine that takes very little ongoing effort.

MFA methods are not equivalent

The distinction that matters is origin binding. A passkey or hardware key will not authenticate to a lookalike domain, because the cryptographic challenge is bound to the real origin. A TOTP code will, because the code is just six digits that anyone can relay.

For any account with administrative capability over infrastructure, use a phishing-resistant method. For the root or owner identity specifically, use a hardware key and store a backup key somewhere physically secure.

The credential hierarchy

Ranked from safest to most dangerous:

1. Short-lived, federated credentials. Issued on demand, expire automatically, bound to an identity provider. Workload identity federation and OIDC-based CI authentication belong here.
2. Assumed roles with session credentials. Temporary by construction.
3. Long-lived keys, scoped narrowly and rotated on schedule. Acceptable when nothing better exists.
4. Long-lived keys with broad permissions. The pattern behind most serious incidents.

Work upward. Every long-lived key you eliminate is a permanent reduction in risk rather than a mitigation.

Eliminating long-lived keys

Concretely, for the common cases:

• Applications on instances: attach an IAM role, a service account or a managed identity. The instance obtains short-lived credentials from the metadata service. No key exists.
• CI pipelines: use OIDC federation between your CI provider and your cloud. The pipeline presents a signed token and receives temporary credentials. No secret is stored.
• Kubernetes workloads: use workload identity to bind a service account to a cloud identity.
• Humans: single sign-on with role assumption, never per-account credentials.
• Third-party tools: a dedicated, narrowly scoped identity with its own key, inventoried and rotated.

That last category is where long-lived keys legitimately persist. Keep a register of them.

A rotation routine that survives reality

Rotation programmes fail because they are scheduled as a quarterly event nobody owns. What works:

1. Inventory. A list of every long-lived credential, what it is for, who owns it, and when it was last rotated. Without this, nothing else is possible.
2. Name an owner per credential. Not a team — a person.
3. Rotate on a schedule proportionate to blast radius. Ninety days is a reasonable default; anything with production write access deserves shorter.
4. Use dual credentials during rotation. Create the new key, deploy it, verify, then delete the old one. Never delete first.
5. Automate what you can. Most secret managers support scheduled rotation with the provider's API.
6. Rotate immediately on trigger events — someone leaves, a laptop is lost, a repository is found to contain a secret, a third party reports a breach.

Secrets in source control

Assume any secret ever committed to a repository is compromised, including in history, including in a private repository.

• Scan repositories with a secret scanner, in CI and on push.
• Rotate anything found. Removing the commit does not help; it has been cloned.
• Use a secret manager rather than environment files in the repository.
• Add pre-commit hooks so the easy path is the safe one.

What MFA does not protect

MFA protects interactive sign-in. It does nothing for:

• API keys, which bypass interactive authentication entirely.
• Session tokens, if stolen after authentication.
• Service identities, which have no human to prompt.
• Recovery paths, if the recovery email or phone is compromised.

This is why the machine-identity audit matters as much as the MFA enrolment, and why recovery options need the same protection as the primary credential. The IAM guide covers the permission side.

Frequently asked questions

How often should keys rotate? Ninety days is a common baseline. The better goal is having fewer keys to rotate.

Is TOTP good enough? It is far better than nothing and much weaker than a passkey. For administrative access, use phishing-resistant methods.

What if I lose my hardware key? Enrol two and store the backup securely offline. This is why recovery options matter, and why they must be ones you control.

Should service accounts have MFA? They cannot — there is no human to prompt. That is exactly why they should use short-lived federated credentials instead of keys.

The hardening checklist puts this into the wider sequence for a newly acquired environment.

Whichever provider an environment sits on, this routine is the same — the catalogue shows what each listing includes.