Defending non-human identities from infostealers in cloud environments

At a glance

What this is: This analysis says infostealers are moving from human credentials to non-human identity credentials in cloud environments, with API keys, certificates, and tokens becoming the target.

Why it matters: It matters because IAM teams now have to treat workload identity, credential lifetime, and access verification as part of the malware threat surface, not just human login security.

Context

Infostealers are malicious software that steal credentials, secrets, and session material from compromised systems. In cloud-native environments, that no longer stops at human logins, because workloads, services, and applications rely on machine credentials that are just as exploitable when they are static or overexposed.

The governance gap is straightforward: many identity programmes still assume the primary target is a person, while cloud operations increasingly depend on non-human identities. When those identities are not verified, scoped, and rotated with the same discipline as human access, malware can turn one compromised host or supplier foothold into cloud-wide exposure.

Key questions

Q: How should security teams reduce the risk of infostealers stealing workload credentials in cloud environments?

A: Security teams should replace static, long-lived credentials with dynamic controls that shrink the attacker’s window of opportunity. The strongest approach combines workload identity verification, conditional access based on security posture, and short-lived tokens with automated rotation. That model makes stolen secrets less useful, limits lateral movement, and reduces the chance that one compromised host or service can expose broader cloud resources.

Q: Why do static API keys and tokens increase cloud app risk?

A: Static credentials increase risk because they act as bearer secrets that can be copied, reused, and replayed without proving workload intent. If they are long-lived or broadly scoped, a stolen secret can look identical to legitimate automation. That makes revocation, scoping, and ownership central to machine identity governance.

Q: What are the signs that workload identity management is failing in a large environment?

A: Common warning signs include dormant identities that have not been reviewed for months, permissions that far exceed workload requirements, and no reliable visibility into which accounts are active. Another signal is hard coded credentials inside workloads, because that usually means access is being maintained manually instead of governed through a lifecycle process. These patterns point to weak control, not just poor hygiene.

Q: What should teams do when a third-party provider device is infected by an infostealer?

A: They should review every cloud access path that provider could reach, revoke any standing credentials tied to that path, and confirm that the affected workloads cannot reuse stolen secrets from outside the approved environment. Third-party exposure turns a local infection into a shared identity problem.

Technical breakdown

Why static workload credentials are an infostealer target

Static API keys, certificates, and long-lived tokens are attractive to infostealers because they can be harvested once and reused outside the original runtime context. Unlike interactive human sessions, these credentials often sit in code, configuration, caches, or local stores where malware can extract them without defeating multi-factor prompts or session challenges. The security problem is not simply theft, but reuse: the attacker acquires an identity artifact that may still be valid across services, environments, or automation workflows. In cloud environments, that turns one compromise into a durable access path. Practical implication: treat long-lived workload credentials as harvestable assets, not as invisible infrastructure detail.

Practical implication: treat long-lived workload credentials as harvestable assets, not as invisible infrastructure detail.

How workload verification limits credential reuse

Workload identity verification is about proving that the calling service, container, or application is the expected actor before access is granted. Attestation, posture checks, and context-aware policy reduce the chance that a stolen credential alone is enough to authenticate from an untrusted runtime. This matters because infostealers exploit the gap between possession and legitimacy: if the system only checks that a token exists, the malware wins. Stronger verification binds access to the execution environment, not just the secret. Practical implication: bind workload access to runtime trust signals so a copied credential is less useful outside the approved context.

Practical implication: bind workload access to runtime trust signals so a copied credential is less useful outside the approved context.

Why short-lived tokens change the attacker’s economics

Short-lived tokens and automated rotation reduce the time window in which a stolen credential remains useful. That does not eliminate compromise, but it changes the attacker’s economics by forcing faster use, more operational risk, and lower confidence that exfiltrated credentials will still work later. In practice, this is why rotation and token lifetime are governance controls, not just operational hygiene. They shape whether malware gets a one-time key or a persistent foothold. Practical implication: push credential lifetime down to the shortest feasible period and tie renewal to controlled issuance paths.

Practical implication: push credential lifetime down to the shortest feasible period and tie renewal to controlled issuance paths.

Threat narrative

Attacker objective: The attacker wants reusable machine credentials that open cloud services, support lateral movement, and create durable access to business systems.

1. Entry occurs when infostealer malware reaches a device through phishing, compromised software, or malware-as-a-service distribution and begins collecting stored secrets.
2. Credential access follows when the malware extracts API keys, certificates, cookies, or tokens used by workloads and services, often from configuration or local storage.
3. Escalation occurs when the stolen non-human identity is reused against cloud services, giving the attacker privileged access beyond the original infected endpoint.
4. Impact occurs when the attacker moves laterally or disrupts business operations by acting through trusted machine identities instead of human accounts.

Breaches seen in the wild

• Okta support system breach 2023: A support service account credential saved in a personal Google profile let attackers take HAR files and hijack five Okta customers' sessions.
• Schneider Electric Jira breach 2024: Credentials linked to a Lumma infostealer infection gave Hellcat access to Schneider Electric's Jira; 40GB and 400,000 user rows claimed.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Infostealers have become an NHI governance problem because machine credentials are now part of the malware kill chain. The article shows the threat has moved beyond human usernames and passwords into API keys, certificates, and tokens used by workloads and services. That changes the control plane from endpoint-only defence to identity governance for non-human actors. Practitioners should treat workload credentials as first-class identities with their own lifecycle and trust requirements.

Static credential persistence is the named failure mode here. Long-lived secrets were designed for stable, predictable execution contexts. That assumption fails when a credential can be copied by malware and reused outside the original workload boundary. The implication is not simply more rotation, but a governance model that no longer assumes possession implies legitimacy.

Workload identity verification now sits on the critical path for cloud containment. Attestation and contextual access controls matter because they reduce the value of a stolen secret by binding access to the expected runtime. This is where NHI governance meets Zero Trust: access should depend on the identity of the workload and the trustworthiness of its environment, not on a secret alone.

Credential lifetime is now an exposure window, not an administrative setting. The shorter the secret lives, the less usable it is to infostealers and downstream buyers. That means rotation policy, secret distribution, and token issuance need to be evaluated as a single control chain rather than separate tasks. Practitioners should measure how much business access can survive after a secret is stolen.

Identity blast radius: the business impact of one stolen workload secret is determined by how much privilege, reuse, and trust sits behind it. Cloud-native environments create dense identity relationships, so one exposed token can reach far beyond the initial compromise point. The practical conclusion is that NHI governance has to be designed around containment, not just authentication.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 54% of ransomware victims had credentials exposed before the attack, according to Verizon's 2025 Data Breach Investigations Report.
• Read next: Guide to NHI Rotation Challenges

What this signals

Static credential persistence is the wrong default for cloud workloads. The practical issue is not just that infostealers steal secrets, but that many environments still allow those secrets to remain valid long enough for reuse. Governance teams should look at issuance, rotation, and revocation as one lifecycle, because the attacker only needs one durable token to turn an endpoint compromise into cloud access.

Identity verification has to move closer to the workload runtime. If access decisions do not depend on attestation or context, the secret itself becomes the only proof that matters. That is a weak control model for cloud-native systems where credentials move through build pipelines, automation, and supplier environments. The right question is whether the workload can prove itself before the token is honored.

For practitioners

• Audit long-lived workload secrets Inventory API keys, certificates, and tokens embedded in code, configuration, and automation paths. Prioritise any credential that can be reused outside the original runtime context.
• Bind access to workload attestation Require proof that the caller is the expected workload and running in an approved environment before granting access to sensitive services.
• Shorten token lifetime and rotation windows Replace static credentials with short-lived tokens wherever possible and align rotation with controlled issuance so stolen secrets expire before they can be reused.
• Apply conditional access to workload posture Evaluate the security posture of the requesting system before issuing access, including endpoint protection status and runtime configuration checks.
• Review third-party provider exposure paths Map where external providers, suppliers, and managed services can reach cloud data or automation systems, then remove any standing access that infostealers could abuse.

Key takeaways

• Infostealers are no longer just a human credential problem because cloud workloads now expose API keys, certificates, and tokens that can be harvested and reused.
• The scale of the risk comes from credential durability, since static machine secrets can keep working after the original infection point is gone.
• Workload attestation, short-lived access, and tighter secret lifecycle controls are the main levers for reducing the blast radius of stolen non-human identities.

Key terms

• Infostealer: An infostealer is malware built to collect credentials, session material, tokens, and other authentication data from infected systems. In NHI programmes, the risk is not only theft but reuse, because harvested workload secrets can unlock cloud access long after the initial infection.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• 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.
• Secret Lifetime: Secret lifetime is the period during which a credential remains valid and reusable after issuance. Shorter lifetimes reduce the usefulness of stolen tokens and keys, especially in cloud-native environments where infostealers can extract secrets from automation paths and storage locations.

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 programme, it is worth exploring.