Examples include API keys, database credentials, private keys, signing keys, access tokens, and other bearer credentials. The practice covers secure generation, storage, distribution, use, rotation or renewal, revocation, expiration, recovery, and destruction — not merely placing values in an encrypted repository.
Effective designs minimize who and what can retrieve each secret, prefer short-lived or dynamically issued credentials where practical, and prevent values from appearing in source code, build output, logs, or support channels. Ownership, purpose, consumers, and dependencies should be recorded so a secret can be changed quickly without leaving old copies active or causing an uncontrolled outage.
Key points
Lifecycle controlsGenerate with suitable strength, provision over protected paths, scope access, set an appropriate lifetime, rotate safely, revoke promptly, and remove obsolete copies.
Operational controlsAuthenticate workloads strongly, separate environments, audit access and administration, detect exposure, test emergency recovery, and rehearse compromise response.
Design preferenceReduce shared and long-lived secrets. Where supported, use workload identity and narrowly scoped temporary credentials rather than distributing reusable static values.
Important limitationA secrets manager becomes a high-value dependency and does not prevent an authorized or compromised workload from reading a secret. Access policy, endpoint security, availability, and the initial trust path still matter.