Secrets rotation
The rotation worker needs carefully bounded authority
Automation that changes credentials can be more powerful than the application using them. Restrict its target and keep its own access path auditable.
In this article
List what the worker can change
Identify the secret references, target accounts and administrative operations required by the chosen rotation strategy. Grant the scope needed for those operations rather than broad access to every secret.
Some strategies require elevated target authority to create or update another identity. Review that requirement explicitly and protect the separate administrative credential where one is used.
The runtime application should not inherit the rotation worker's privileges.
Validate the target before mutation
Ensure the workflow operates on the intended service and account. A malformed or incorrectly changed secret record should not redirect privileged rotation logic to an unrelated target.
Use the provider's supported rotation implementation and validation requirements where applicable. Custom code needs equivalent review of input, identity and destination handling.
Keep network access narrow enough for the required target and secret service.
Protect outputs and history
Inspect rotation logs, exception messages and deployment artefacts for credential values. Use synthetic secrets in a safe test to verify redaction and failure handling.
Audit creation, retrieval, update and revocation with identifiers and outcomes rather than plaintext values. Limit who can read the resulting operational records.
Retain previous versions only according to the target's recovery and security policy. Availability of historical secret material needs deliberate access control.
Verify the replacement's permissions
Test the required operation and representative denied operations using the new credential. A cloned or recreated identity may not have the same effective rights as the original after later permission changes.
Review both routine rotation and urgent revocation. A compromise response can require a different overlap policy and session handling.
The review is complete when the automation can change exactly the intended authority, consumers receive only what they need and evidence remains useful without exposing the values being protected.
Primary sources
AWS Secrets Manager: rotation strategiesOWASP: secrets managementReferences checked 11 September 2026.