Applications often need credentials to reach databases, cloud services, payment interfaces and other systems. Secrets management keeps those passwords, tokens, API keys and related credentials out of exposed code and governs who—or what—can use them, for which purpose and for how long.
A secret represents access, not just sensitive text
An application secret may be a password, API key, access token, private certificate material or another value that lets a workload authenticate. If copied or misused, it can give an attacker the application's permissions without requiring the person who originally created it.
Secrets overlap with, but are not identical to, cryptographic keys. Banks classify them by function, sensitivity, environment and potential impact so storage, rotation and recovery requirements match the access each credential can unlock.
Inventory and ownership establish the control boundary
The bank identifies which applications and automated workloads use secrets, where the values are stored, which resources they reach and who owns the business service and technical credential. Discovery is important because old scripts, test environments and vendor integrations can retain forgotten credentials.
Each secret should have a defined purpose, approved environment, accountable owner and life-cycle rule. Shared or unnamed ownership makes it difficult to determine whether a credential is still needed, whether its permissions are appropriate or who must act after exposure.
Controlled delivery replaces embedded credentials
Hard-coding a secret in source code, a configuration file, a ticket or a deployment image can leave recoverable copies in repositories, logs and backups. A governed secret store or identity service can provide the value or access token to an authenticated workload at runtime without broadly exposing it to developers or operators.
Access follows least privilege and environment segregation. Production credentials are not reused in development, people do not receive a machine secret merely because they support the application, and an application receives only the permissions and destinations required for its approved task.
Short life and rotation limit persistent exposure
Where architecture permits, short-lived tokens and workload identities reduce reliance on long-lived static secrets. Other credentials are rotated on a defined schedule and promptly after suspected compromise, personnel or vendor changes, excessive exposure or changes in the connected service.
Rotation must be engineered rather than improvised. The bank tests how old and new values overlap, how dependent systems update and how failure is detected so a security improvement does not unexpectedly interrupt payments, customer access or another critical service.
Monitoring and response complete the life cycle
Logs can show secret creation, retrieval, failed use, privilege changes and unusual access, but the secret value itself should be redacted from ordinary telemetry. Alerts, repository scanning and data-loss controls help identify credentials used from an unexpected workload, location or pattern.
A response plan defines how to revoke or replace a credential, contain affected systems, preserve evidence and notify responsible teams and third parties. Break-glass access is tightly limited, recorded and reviewed, while backup and recovery design ensures the secret-management service does not become an unplanned single point of failure.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.