TL;DR: Static SSH keys, shared passwords, and long-lived service account tokens create audit, rotation, and compliance problems in payment and banking infrastructure, according to Teleport’s guide. Certificate-based authentication shifts access to short-lived, centrally issued credentials, which reduces standing exposure and makes identity attribution possible across humans, machines, and pipelines.
NHIMG editorial — based on content published by Teleport: Guide to certificate-based authentication for payment and banking infrastructure
By the numbers:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
Questions worth separating out
Q: How should security teams reduce reliance on static credentials for workloads?
A: Start by identifying which workloads can authenticate with cloud identity, Kubernetes identity, OIDC, certificates, or attestation instead of carrying reusable secrets.
Q: Why do static secrets remain risky even when rotation is enabled?
A: Rotation reduces the lifetime of a credential, but it does not eliminate the window in which the secret can be copied, cached, or reused.
Q: What breaks when certificate-based controls do not include workload identity?
A: You lose the ability to distinguish a process that is actively supposed to access a resource from one that merely inherited access long ago.
Practitioner guidance
- Replace static credentials in transaction paths Identify SSH keys, shared passwords, and service account tokens embedded in production, CI/CD, and Kubernetes access paths, then map which ones can be replaced with short-lived certificates first.
- Bind workload access to runtime need Issue certificates to pipelines and service accounts only while the process is active, and stop renewal automatically when the job completes so access expires without manual cleanup.
- Require hardware attestation for privileged access Use enrolled TPM or Secure Enclave checks for sessions that can reach cardholder data environments, and reject certificate issuance when the device identity is not on record.
What's in the full article
Teleport's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how Teleport issues certificates to machines, pipelines, and service accounts across on-prem and cloud environments.
- Hardware attestation flow details for TPM, Secure Enclave, and device inventory checks during certificate issuance.
- Protocol-by-protocol implementation notes for SSH, Kubernetes, and database access using short-lived certificates.
- Operational examples showing how certificate expiry reduces the impact of compromised build servers after pipeline completion.
👉 Read Teleport's guide on certificate-based authentication for payment and banking infrastructure →
Static credentials in banking infrastructure: what changes with certificates?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Static credentials are the governance debt that certificate-based authentication is trying to retire. The article shows the operational reason static credentials survive, but the governance issue is older than the tooling. If a credential has to be remembered, copied, rotated, and revoked across dozens of systems, it is already a liability, not an access control. For regulated payment infrastructure, that liability becomes harder to justify because attribution and revocation must be provable, not assumed. Practitioners should treat static credentials as a transition state, not an operating model.
A few things that frame the scale:
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when a machine credential is abused?
A: Accountability should sit with the team that owns the workload, the identity lifecycle, and the connected business process, not with security alone. In regulated environments, that usually means engineering, platform, and IAM teams share responsibility for discovery, rotation, and offboarding while compliance verifies that the process is repeatable.
👉 Read our full editorial: Certificate-based authentication is reshaping payment infrastructure access