Notifications
Clear all
Topic starter
25/06/2026 1:30 am
TL;DR: Financial services breaches cost an average of USD 6.08 million in 2024, and credential-based incidents take 292 days to identify and contain, according to IBM’s Cost of a Data Breach Report 2024. Static secrets, hardcoded keys, and over-privileged machine identities turn banking infrastructure into a long-dwell attack surface that regulators are scrutinising more closely.
NHIMG editorial — based on content published by Akeyless: financial institution security and secrets management
By the numbers:
- The average cost of a data breach in the US financial services sector reached USD 6.08 million in 2024.
- Breaches involving stolen or compromised credentials took an average of 292 days to identify and contain.
- Stolen credentials were the initial attack vector in 24% of all breaches analyzed in the 2024 Verizon DBIR.
Questions worth separating out
Q: How should financial institutions reduce the risk from compromised machine credentials?
A: They should treat every machine credential as a lifecycle asset, not a static configuration item.
Q: Why do service account secrets create more risk than teams expect?
A: Service account secrets create risk because they often authenticate connected systems with broad privileges and little human visibility.
Q: How do security teams know whether secret governance is actually working?
A: Look for evidence that secrets are inventoried, scoped, rotated, and revoked on time, and that no secret remains active beyond its business need.
Practitioner guidance
- Map every credential to a named workload owner Create an authoritative inventory of API keys, certificates, database passwords, and tokens, and require each one to have a named owner, a purpose, and a revocation path.
- Eliminate hardcoded secrets from code and pipelines Scan repositories, CI/CD jobs, and container images for embedded credentials, then block merges and releases until the secret is replaced with a managed secret reference.
- Reduce machine privilege to one workload and one environment Scope each secret so it only authorises the specific application, system, and environment that needs it, and recertify the mapping when integrations change.
What's in the full article
Akeyless's full guide covers the operational detail this post intentionally leaves for the source:
- Regulatory mapping across GLBA, SOX, NY DFS Part 500, PCI DSS v4.0, FFIEC, and NIST CSF 2.0 for credential controls.
- Implementation detail on dynamic secrets, JIT access, and automated rotation for banking workloads.
- Multi-cloud control patterns for AWS, Azure, GCP, and on-premises environments, including environment isolation and audit logging.
- A practical walkthrough of how zero-trust access applies to banking secrets, including request approval and revocation triggers.
👉 Read Akeyless's guide to financial institution secrets management →
Financial institution credential sprawl: what IAM teams need now?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 10:58 am
Static credential persistence is the core failure mode in financial services. The article shows that banks are not dealing with isolated leaks. They are dealing with credentials that remain valid after the business process, workforce change, or vendor relationship that created them has already moved on. That is a lifecycle governance problem, not just a storage problem. Practitioners should treat every long-lived secret as an active liability until rotation, revocation, and scope reduction are proven.
A few things that frame the scale:
- 24% of all breaches analyzed in the 2024 Verizon DBIR began with stolen credentials, according to Guide to the Secret Sprawl Challenge.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection without revocation leaves an active attack surface.
A question worth separating out:
Q: Who is accountable when a leaked credential is used to access banking systems?
A: Accountability should sit with the system owner, the identity governance function, and the control owner for the secret store or vault. In regulated environments, the institution must also be able to prove to auditors that access was limited, logged, and removed when the underlying use case ended.
👉 Read our full editorial: Financial institution secrets management is now a breach control
