When would you actually choose manual credential rotation over fully automated rotation, given that automation is generally considered the more secure default?

Automated rotation wins by default for anything where the blast radius of a rotation failure is contained and recoverable — most application and service credentials. Manual (or manually-gated) rotation earns its place specifically where a failed or badly-timed automatic rotation could cause outsized damage: credentials tied to systems without good rollback, rotations that need to be coordinated across multiple dependent systems simultaneously, or credentials where a compromised automation pipeline itself becomes a single point of catastrophic failure.

The comparison isn't really "automated is more secure, manual is more convenient" — it's about where the risk of automation failing is worse than the risk of rotation happening late. Automated rotation is a program that runs unattended and changes live credentials; if that program has a bug, a bad rollout, or gets compromised itself, it can invalidate credentials across many systems simultaneously with no human in the loop to catch it before impact.

Automated rotation fits well when failure is contained and reversible: most application database credentials, API keys for internal services, and similar cases — a rotation gone wrong typically affects one service, is caught quickly by monitoring/alerting, and can be rolled back without cascading damage. This is the large majority of credentials in a typical environment, which is why automation is the right default.

Manual or manually-gated rotation fits better when a failure would cascade or be hard to reverse: credentials shared across multiple tightly-coupled systems that must be rotated in a coordinated sequence (rotating one without the others breaking the chain), or credentials for systems with weak or no rollback capability, where an automation bug rotating at the wrong moment could cause an outage that's hard to quickly undo.

The automation pipeline itself becomes a new single point of failure worth weighing: an automated rotation system with broad reach (able to rotate credentials across many systems) is itself now a high-value target — if compromised, it could be used to lock legitimate systems out of their own credentials as a denial-of-service, or worse. For your highest-value credentials, a human-gated rotation (automation prepares the rotation, a human approves the final cutover) can be a deliberate middle ground.

Rotation frequency and system maturity also matter: a credential rotated frequently (daily/hourly) essentially has to be automated, since manual rotation at that frequency isn't sustainable; conversely, a rarely-rotated credential (annual) in a legacy system without good automation hooks may simply be cheaper and safer to rotate manually with a documented runbook than to build one-off automation for.

• The real question isn't "which is more secure" in the abstract — it's where the risk of automation failing outweighs the risk of rotation happening on a slower, human-gated cadence.
• Automated rotation is the right default for contained, reversible-failure cases — the large majority of application and service credentials.
• Manual or human-gated rotation earns its place for tightly-coupled multi-system credentials, systems with weak rollback, or your highest-value credentials where the automation pipeline's own blast radius is worth limiting.
• A broadly-reaching automated rotation system is itself a high-value target — factor that into how much reach you give it.

• AWS Secrets Manager: Rotating secrets
• HashiCorp Vault: Dynamic Secrets