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.
At a glance
What this is: This guide argues that certificate-based authentication can replace static credentials across payment and banking infrastructure while preserving operational continuity and improving auditability.
Why it matters: It matters because IAM, PAM, and NHI teams in regulated environments need a way to reduce credential sprawl without breaking transactions, pipelines, or compliance evidence.
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.
👉 Read Teleport's guide on certificate-based authentication for payment and banking infrastructure
Context
Certificate-based authentication replaces reusable secrets with short-lived credentials that a certificate authority can issue, validate, and expire automatically. In payment infrastructure, that model matters because static credentials are still embedded in SSH access, database authentication, Kubernetes secrets, and CI/CD configuration, even when those systems handle live transactions and regulated data.
The primary governance problem is not only theft. It is the way static credentials force teams to choose between continuity and control, especially when revocation can break pipelines or production dependencies. In that sense, this is an NHI governance problem with direct implications for IAM, PAM, and compliance evidence across on-prem, cloud, and Kubernetes estates.
Key questions
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. Then issue short-lived credentials at runtime only when access is needed. This reduces exposure, simplifies lifecycle control, and lowers the chance that leaked material can be reused across systems.
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. Static secrets still depend on trust in storage, transport, and endpoint hygiene. That is why short-lived, identity-based issuance is more resilient than timer-based rotation alone.
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. That creates hidden standing privilege in pipelines and service accounts, which is exactly the condition attackers exploit when they find a live secret after the job has ended.
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.
Technical breakdown
Short-lived certificates versus static credentials
A certificate-based model moves trust from a reusable secret to a signed assertion with an explicit expiration time. The certificate authority vouches for the identity, roles, and validity window, while the target system verifies the signature, expiry, and possession of the private key before granting access. That changes the attack surface: a stolen SSH key, password, or service account token can be replayed until revoked, but a certificate narrows that exposure to the life of the session or task. In regulated infrastructure, that difference matters because auditability depends on traceable, time-bounded identity, not just access success.
Practical implication: replace long-lived credentials with short-lived certificates wherever transaction systems can tolerate reauthentication.
Machine and workload identity in pipelines and service accounts
The article’s deeper point is that non-human access is often the dominant credential problem. CI/CD pipelines, service accounts, and automated processes usually need identity without human intervention, so a lightweight agent can request, renew, and discard certificates on behalf of the workload. When the process ends, renewal stops and the certificate expires. That gives teams a way to bind access to runtime need rather than provisioning time. For NHI governance, this is the difference between an identity that persists indefinitely and one whose authority is tied to process existence.
Practical implication: scope workload certificates to the exact runtime window of the pipeline or service process.
Hardware-backed device trust for privileged sessions
The hardware check described in the guide adds a second trust factor to certificate issuance. A certificate authority can require proof that the requesting device contains an enrolled TPM or Secure Enclave and that the device matches an approved inventory record. That prevents simple replay of a stolen certificate from an untrusted machine and reduces the value of copied credentials. For privileged access, especially to cardholder data environments, the control links identity to a physical device state instead of relying on the validity of a copied credential alone.
Practical implication: require hardware-backed attestation for the highest-risk administrative and regulated access paths.
Threat narrative
Attacker objective: The attacker aims to reuse a valid static credential to reach production systems, move through dependent infrastructure, and preserve access long enough to evade effective attribution.
- Entry occurs through static SSH keys, shared database passwords, or service account tokens that persist across hosts, pipelines, and clusters.
- Escalation occurs when those credentials are reused, copied into environment variables or images, and trusted beyond the original task or session.
- Impact comes from replayable access to production systems, where compromised credentials can outlive the incident window and undermine audit integrity.
Breaches seen in the wild
- Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
- Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Certificate-based authentication works because it redefines trust as time-bounded identity. That is a better fit for transaction infrastructure than perpetual secrets because it forces access to expire with the task, not the asset. The important shift is not just shorter lifetime, but centralised control over identity, role encoding, and revocation logic across servers, databases, and clusters. The practitioner implication is that workload access should be governed as a lifecycle, not as a static entitlement.
Machine and pipeline identities now sit in the same governance conversation as human users. The guide makes clear that service accounts and CI/CD processes are often the bigger problem than individual engineers. That means IAM teams cannot leave machine credentials to platform teams alone, and PAM cannot stop at break-glass human access. Lifecycle controls, auditability, and least privilege need to cover workloads with the same seriousness applied to people.
Hardware-bound certificate issuance is a stronger control than simple credential expiration because it narrows replay opportunities. A certificate that expires in minutes still creates risk during its validity window if it can be used from another device. Binding issuance to enrolled hardware changes the trust boundary from the token to the device state itself. For environments handling cardholder or financial data, that is the right control pattern for privileged sessions.
Named concept: credential expiry as access control. The article’s core architectural idea is that expiration is not just cleanup, it is part of authorisation. Once a certificate is the access mechanism, the validity window becomes the control boundary, which changes how teams think about rotation, revocation, and session design. Practitioners should treat expiry policy as an access decision, not a maintenance detail.
From our research:
- 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.
- From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- From our research: If static secrets persist after notification, certificate expiry and lifecycle offboarding become the practical next step, as explored in the Guide to the Secret Sprawl Challenge.
What this signals
Credential expiry will increasingly be treated as a governance control, not a hygiene task. In environments where static credentials are already hard to find and harder to revoke, short-lived certificates give identity teams a measurable boundary for access and audit. That aligns naturally with the NIST Cybersecurity Framework and the NIST Cybersecurity Framework 2.0 model of govern, protect, and recover.
Operational teams should expect certificate-based access to shift the conversation from provisioning to lifecycle ownership. Once machine and pipeline identity is certificate-driven, the question becomes who owns issuance, renewal, device trust, and revocation across workloads. For teams working through secrets sprawl, the Guide to the Secret Sprawl Challenge remains the most relevant internal reference point.
With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, per the 2026 Infrastructure Identity Survey, the same credential model that breaks for workloads will break faster when AI systems enter the access path. That is why identity programmes should align certificate strategy, workload governance, and privileged session controls now.
For practitioners
- 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.
- Unify audit evidence across identity layers Correlate IdP events, certificate issuance, and resource access logs so engineers can trace every human or workload session back to a specific identity and time window.
Key takeaways
- Static credentials remain the central weakness in payment and banking infrastructure because they persist across systems, owners, and audit boundaries.
- Short-lived certificates shift access from reusable secrets to time-bounded identity, which improves both revocation discipline and traceable attribution.
- Programmes that manage human, machine, and pipeline access as one lifecycle problem will be better positioned for regulated environments and lower standing privilege.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static secrets and rotation gaps are the core risk in this certificate-based access model. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access control are central to certificate-bound infrastructure access. |
| NIST SP 800-53 Rev 5 | IA-5 | Authenticator management applies directly to the article's credential replacement model. |
| NIST Zero Trust (SP 800-207) | Section 2.5 | The guide aligns with zero-trust verification of identity, device state, and session context. |
| PCI DSS v4.0 | 8.6.2 | The article directly addresses credential hardcoding and auditability in payment environments. |
Replace reusable secrets with short-lived credentials and enforce lifecycle ownership for every machine identity.
Key terms
- Certificate-based authentication: A method of proving identity using a cryptographic certificate and the associated private key rather than a reusable password. In identity programmes, it raises the bar for theft and replay because the secret is bound to lifecycle, issuance, and revocation control.
- Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
- Hardware Or Software Attestation: Attestation is a verification method that checks whether a workload or device is running in a trusted state before it is allowed to access systems. In NHI governance, attestation replaces human-style MFA as the assurance mechanism for machine principals.
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.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or identity security programme, it is worth exploring.
Published by the NHIMG editorial team on August 1, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org