Defending non-human identities from infostealers in cloud environments

At a glance

What this is: This is a best-practices analysis of how infostealers are shifting from human credential theft to non-human identity compromise in cloud and DevOps environments.

Why it matters: It matters because compromised workload identities can bypass traditional user-focused controls and expose APIs, services, and automation paths that IAM teams still manage too loosely.

By the numbers:

• Data-stealing malware has increased by sevenfold since 2020, making credential theft a far broader operational risk.
• A massive breach affecting nearly 57 million accounts was traced to an infostealer that infected a third-party provider’s device.

👉 Read Aembit’s analysis of how infostealers target non-human identities

Context

Infostealers are malware designed to collect credentials, secrets, cookies, and tokens from endpoints and applications. In cloud and DevOps environments, that same technique now reaches non-human identity material, including API keys, certificates, and workload tokens that systems use to authenticate to other systems. That makes the problem an IAM issue as much as an endpoint issue.

For practitioners, the key governance gap is simple: many programmes still protect users better than workloads, even when workloads are the larger attack surface. Static credentials, weak identity verification, and inconsistent rotation create conditions where a single infostealer infection can become an environment-wide trust failure. That pattern is increasingly typical in modern cloud estates.

Key questions

Q: How should security teams protect non-human identities from infostealers?

A: Security teams should reduce the value of any stolen credential by combining secret discovery, short-lived issuance, runtime attestation, and narrow authorization scope. The goal is not to prevent every theft. It is to make stolen NHI material expire quickly and fail outside the context where it was issued.

Q: When do static secrets create unacceptable NHI risk?

A: Static secrets become unacceptable when they can be reused across systems, live for long periods, or sit in places infostealers can scrape easily. If a copied key can authenticate outside a tightly defined workload context, the organisation has turned secret storage into an exposure mechanism.

Q: What is the difference between workload identity verification and secret rotation?

A: Secret rotation replaces old credentials with new ones, while workload identity verification checks whether the requester is the right service in the right environment before access is granted. Rotation limits dwell time. Verification limits impersonation. Mature programmes need both because stolen secrets remain dangerous if the requester is never validated.

Q: Why do infostealers change the way IAM teams think about cloud security?

A: Infostealers show that the cloud attack path often begins with credential theft and ends with non-human impersonation. That means IAM teams cannot focus only on users, MFA, or login events. They must govern service accounts, tokens, certificates, and automation paths as first-class identities.

Technical breakdown

Why infostealers are effective against workload identities

Infostealers work because they target material that proves identity rather than the identity itself. For workloads, that material often lives in environment variables, config files, CI/CD logs, local caches, browser sessions, or shared secrets stores. Once harvested, an API key or token is often enough to impersonate a service until it expires or is revoked. That differs from human identity compromise, where the attacker usually needs a password, session hijack, or MFA bypass. The technical weakness is not just theft. It is the persistence of reusable credentials across multiple runtime locations.

Practical implication: Reduce exposed secret locations and treat every stored token as a potential impersonation path.

Static secrets versus dynamic workload credentials

Static secrets are durable by design, which makes them durable attack targets. Dynamic workload credentials reduce dwell time by issuing short-lived, scoped access that expires quickly and is harder to reuse outside its intended context. The security gain comes from shrinking the window between theft and revocation, not from assuming theft cannot happen. In practice, dynamic issuance only helps if identity proof, authorization policy, and rotation are all enforced at runtime. Without that chain, short-lived access becomes a weaker version of the same trust model instead of a different one.

Practical implication: Use ephemeral credentials only when issuance, scope, and revocation are automated end to end.

How workload verification limits blast radius

Workload verification adds evidence that the requesting entity is the expected service, container, or workload running in an approved context. Attestation, platform identity, and conditional policy checks can stop a stolen secret from becoming universal access. This matters because infostealers do not need to understand the application they compromise. They only need one valid token. Strong verification narrows what that token can do, which is why verification and least privilege must be designed together. Zero Trust for workloads is not a slogan here. It is a control model for reducing replay value.

Practical implication: Pair workload attestation with least privilege so a stolen credential cannot authenticate everywhere.

Threat narrative

Attacker objective: The attacker wants reusable non-human credentials that let them impersonate services and expand access inside cloud environments.

1. Entry occurs when an infostealer reaches a user or third-party device through phishing, compromised software, or malware-as-a-service delivery.
2. Escalation happens when the malware harvests API keys, certificates, or session tokens stored on the endpoint or in adjacent tooling.
3. Impact follows when the attacker reuses stolen non-human credentials to access cloud services, move laterally, or disrupt business operations.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

Infostealer defense is now a non-human identity governance problem, not an endpoint hardening problem. The malware trend matters because workload credentials often live outside the places security teams instrument best. When API keys, certificates, and tokens are scattered across build systems and runtime environments, theft becomes trivial and detection comes too late. Practitioners should treat every reusable secret as an identity control failure.

Ephemeral credential trust debt is the hidden risk created by static access patterns. Short-lived access only improves security if organisations also remove lingering trust in stored secrets, cached sessions, and overbroad tokens. Otherwise, teams accumulate a trust debt where compromise can be repeated faster than remediation can catch up. The practical conclusion is clear: shorten credential lifespan and narrow scope at the same time.

Workload identity controls must be measured by blast radius, not by issuance convenience. Many teams optimise for developer friction and forget that a stolen secret is only dangerous if it can be reused widely. That means runtime context, attestation, and policy enforcement matter more than whether a secret can be generated quickly. Security leaders should judge tooling by how much damage a stolen credential can still cause.

Infostealers expose the overlap between IAM, secrets management, and cloud governance. The attack path often starts at one endpoint but lands in multiple systems because access decisions were never designed around non-human actors. That overlap makes isolated controls fragile. Practitioners need one operating model for identity, secrets, and workload authorization, or they will keep closing one gap while leaving another open.

Zero Trust for workloads is becoming the minimum viable control model. The article’s core lesson is that trust must be re-evaluated every time a workload asks for access, not assumed because a secret exists. That is the correct direction for modern NHI governance. Teams should align policy, verification, and rotation so that stolen credentials stop being a durable asset for attackers.

From our research:

• 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, according to The 2024 Non-Human Identity Security Report.
• 23.7% of organisations share secrets through insecure methods such as email or messaging applications, which keeps NHI exposure tied to everyday operational habits.
• For a wider control model, review OWASP Non-Human Identity Top 10 alongside the secret-sprawl guidance in the Guide to the Secret Sprawl Challenge.

What this signals

Ephemeral credential trust debt: organisations that keep leaning on long-lived secrets are building up hidden exposure that infostealers can monetise quickly. The lesson for practitioners is to treat secret lifespan as a governance variable, not just an implementation detail. With 35.6% of organisations citing hybrid and multi-cloud consistency as their top challenge, the control problem is already structural.

Teams that are formalising workload identity should align their programme to the OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs , Static vs Dynamic Secrets. That combination helps separate credential hygiene from runtime trust decisions, which is where infostealer risk becomes operational.

The forward signal is clear: infostealer defence will converge with secrets management, CI/CD governance, and workload authorization. Security leaders should expect more scrutiny on where credentials live, how quickly they expire, and whether a copied token can still move across environments.

For practitioners

• Implement runtime secret discovery Inventory where API keys, certificates, and tokens exist in CI/CD, runtime configs, logs, and endpoint storage. Prioritise the locations most likely to be scraped by infostealers and eliminate duplicate secret copies.
• Replace long-lived credentials with short-lived issuance Move high-value service access to short-lived tokens with narrow scope and explicit expiry. Make revocation automatic so a stolen credential becomes unusable quickly after exposure.
• Add workload attestation before access is granted Require proof that a workload is running in the expected environment before it receives cloud or API access. Combine platform identity with policy checks so copied secrets do not travel freely across environments.
• Review third-party device and provider exposure paths Include contractors, external providers, and shared operational tooling in secret-hygiene reviews. The breach path in this article started outside the primary enterprise boundary, which is a common blind spot in NHI programmes.

Key takeaways

• Infostealers are now an NHI threat because they target the credentials that workloads use to prove identity, not just human logins.
• Static secrets turn a single endpoint compromise into a reusable access problem, especially when tokens and keys live in build and runtime systems.
• The practical response is to shorten credential lifespan, verify workload context, and limit what any stolen token can do.

Key terms

• Non-Human Identity: A non-human identity is any machine or software identity used by services, workloads, APIs, bots, or agents to authenticate and authorize access. It is governed like an identity, not like a generic secret, because it carries permissions that can be abused if stolen or overextended.
• 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.
• Ephemeral Credential: An ephemeral credential is a short-lived access token or secret issued for a narrow purpose and a limited time. It reduces attacker dwell time by shrinking the window in which a stolen credential remains useful, but it only works when issuance and revocation are automated.
• Workload Attestation: Workload attestation is the process of proving that a workload is running in an expected, trusted environment before granting access. It helps stop copied credentials from being treated as universally valid and is a core control for reducing impersonation risk.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers static versus dynamic secrets, workload identity, and runtime access control. If you are building controls for infostealer-resistant NHI governance, it is a strong fit.

This post draws on content published by Aembit: How to Defend Non-Human Identities from Infostealers. Read the original.