Secrets, Keys, and Application Credentials

Credentials have different purposes

Passwords, API keys, client secrets, encryption keys, signing keys, TLS private keys, certificates, SSH keys, database credentials, cloud access keys, and token-signing material are not interchangeable. A secret proves possession; a key may encrypt or sign; a certificate binds a public key to a subject within a trust model; a token can carry a limited authorization context. Encoding is not encryption, obscurity is not protection, and certificate validity does not prove correct trust or authorization.

Secret inventory template

Record	Questions to retain
Purpose and owner	Which application or service uses it, who approves access, and who owns lifecycle decisions?
Storage and access	Which approved secret manager, key-management system, hardware-backed store, or configuration boundary applies?
Scope and lifetime	Which environments, resources, permissions, expiry, rotation window, and dependent systems are involved?
Recovery and evidence	How are revocation, backup, audit events, emergency rotation, and decommissioning coordinated?

Lifecycle workflow

Inventory the credential without storing its value in tickets or routine documentation. Record purpose, owner, system, scope, and expiry instead.
Use least privilege and environment separation. Development, test, and production credentials should not silently share authority.
Store and deliver material through the approved mechanism for the platform. Environment variables may be useful, but they are not automatically secure because process, log, deployment, and access controls still matter.
Plan rotation with owners of every dependent service, job, integration, cache, certificate store, and rollback path. Rotation without dependency coordination can cause outages.
Monitor access and lifecycle events, review secret-scanning findings in context, revoke suspected exposure promptly through the documented emergency process, and retain evidence of action.

Rotation-readiness checklist

Confirm a current owner, purpose, inventory record, expiry, and approved replacement path.
Identify applications, build agents, runtime environments, integrations, certificate chains, and partners that use the material.
Test an approved dual-read, staged rollover, or maintenance-window approach where the dependency supports it.
Set monitoring for failed authentication, signing, decryption, or certificate validation during the change.
Remove old material only after scoped validation, retained evidence, and an agreed recovery period.

Fictional application-credential example

An application uses a service credential to reach a managed database and a signing key for outbound webhooks. An engineer rotates both during a release, but a background worker still has the prior database credential. The team restores service through the documented rollback path, separates the two lifecycle records, adds dependency checks, and schedules a tested rollover. A secret manager helped store material; it did not remove the need for least privilege, ownership, monitoring, or coordination.

Common mistakes

Common mistakes include placing credentials in source control, logs, screenshots, build configuration, or informal chat; sharing an account between services; and treating a successful rotation as proof of no prior exposure. Avoid pasting secrets, private keys, private tokens, or customer data into general tools unless handling and permission are clear. Tools can inspect bounded public or approved test data, but output does not establish authorization correctness.

Emergency revocation checklist

When exposure is suspected, identify the credential type, dependent systems, authority to revoke, replacement mechanism, current monitoring, and customer or partner coordination need. Revoke or reduce scope through the approved process, then observe authentication and service behavior for a bounded period. Preserve relevant access and deployment evidence without copying secret values into the incident record. Follow-up should include inventory correction, root-cause review, and replacement of related material where evidence and ownership justify it. A rotation event does not prove prior use was harmless.