Non-Human Identity Risks Your Cloud Review Misses

A Terraform state file sits in a Google Cloud storage bucket. One service account can read it. That account’s key has not rotated in eighteen months. From that single credential, an attacker lists every IAM binding, assumes a role in an adjacent project, and walks out with the secrets vault.

A non-human identity cloud security review exists to find that exact path before an extortion crew does. It is the one check most point-in-time scanners cannot run on their own, and it is where CTDefense’s cloud security work spends most of its time.

The scenario above mirrors the technique a real cloud-native extortion crew ran across GCP, AWS, and Azure environments in the first half of 2026. Most organisations now run cloud posture scanners that flag stale keys and over-permissive policies. Far fewer run an adversarial walk-through of the full chain from a leaked credential to full secrets exfiltration. The gap between the two is the gap this post is about.

What Non-Human Identities Are (and Why They Accumulate)

Service accounts, API keys, OAuth tokens, CI/CD pipeline credentials, and workload identity bindings are all non-human identities. In cloud-native environments they outnumber human users by a wide margin, and they rarely have defined owners or expiry dates.

The accumulation pattern is familiar. A developer stands up a microservice; it needs to read a storage bucket, so it gets a service account. A CI/CD pipeline needs to deploy a Terraform plan; it gets another one. A SaaS integration needs read-only access to a project; a third. Three years in, the sum is a sprawl of accounts no one owns, with permissions no one has reviewed since they were issued.

Datadog’s 2025 State of Cloud Security measured the shape of the sprawl across the three major providers: “59% of AWS IAM users, 55% of Google Cloud service accounts and 40% of Microsoft Entra ID applications had an access key older than one year.” In other words, the majority of long-lived credentials in cloud environments are durable enough to survive an attacker’s reconnaissance window, and they never self-heal without an active cleanup cycle.

A conventional posture scan reports on this surface. A review has to walk it, not just count it, because the risk is not that a key is old. The risk is what the role attached to that key can do once the key is used.

The Attack Chain: From One Service Account to Full Secrets Exfil

The attack chain starts small. An attacker with read access to a Terraform state file, or with a leaked workload credential, can assume an over-privileged service account role, enumerate IAM bindings, and chain into adjacent project or subscription access without triggering a conventional perimeter alert.

Wiz’s H1 2026 cloud threat tracking of the crew tracked as JINX-0163 shows what this looks like in production. In Wiz’s words: “In some cases, they have been able to leverage a single over-privileged identity or exposed state file to pivot and obtain a full inventory of an organization’s secrets.” The pivot is the point. A single misconfigured identity is sufficient to move laterally across GCP projects, AWS accounts, or Entra ID tenants, and to exfiltrate secrets at scale.

Over-privileged service accounts are the usual root of this chain. The familiar pattern:

• A service account is created with broad permissions, often a default role, because narrowing them would mean days of trial and error against the running workload.
• The account’s key is cached in a CI runner, a container image, or a Terraform state file.
• Months later, the state file is readable to a wider audience than intended, or the key leaks through a mis-permissioned repository.
• An attacker uses the key to list IAM bindings, finds a role chain into a higher-privilege account, and assumes it.
• From the second account, the attacker reaches the secrets manager and dumps API keys for every connected system.

No single step is remarkable. The composition is the problem, and that is exactly what the team walks when CTDefense scopes a review.

What a Cloud Security Review Actually Tests on Workload Identities

Most point-in-time CSPM scans flag stale keys and overly broad roles. Fewer simulate the full role-chaining attack path. A review that includes adversarial IAM enumeration and trust-policy testing does, and that is the difference between a report that lists findings and a report that proves an attack is viable.

A CTDefense cloud security review on this surface covers:

• Over-privileged IAM roles across the three providers. The team enumerates service accounts, service principals, and workload identities, and maps the effective permissions of each. This goes beyond listing attached policies and tests what the role can actually do once assumed.
• Trust policy abuse. AWS IAM roles have trust relationships that define who or what can assume them. Misconfigured trust policies, especially those with wildcard principals or weak external ID checks, let an unintended account take over the role.
• IAM role chaining paths. When one account has permission to assume another, and that second account can assume a third, the chain can walk from a low-value service account into a privileged administrative role. The team maps these chains using the same tooling an attacker would.
• Workload identity bindings. Google Cloud workload identity federation, AWS IAM Identity Center, and Entra ID workload identities each have common misconfigurations that let a workload in one project authenticate against another. The team tests each binding.
• Exposed state files and secrets. Terraform state, Pulumi state, and CI/CD secret stores are reviewed for public exposure, over-broad read access, and plaintext credential storage.

A reader asking does an annual cloud security review cover service account risks has a fair question. The honest answer: a review that explicitly includes the five items above does. One that stops at the CSPM dashboard does not. CTDefense’s earlier piece on what CSPM misses on IAM access keys covers the same gap from the key-lifecycle angle.

What Reviewers Commonly Find in Real Environments

The findings repeat across engagements. The most common ones, in rough order of frequency:

• Default compute service accounts with project editor rights. In Google Cloud, the default Compute Engine service account is often left attached to workloads, with permissions broad enough to read secrets, modify IAM, and pivot across resources.
• Access keys older than a year on human-shaped service accounts. AWS IAM users created as service accounts, then forgotten, with keys cached in environment variables and never rotated.
• Workload identity misconfiguration in federation setups. Overly broad audience or subject claim mappings in Google Cloud workload identity pools, and permissive conditional access in Entra ID workload identities, that let any workload in a connected cluster authenticate as a privileged service principal.
• Trust policies with wildcard principals. AWS cross-account roles with Principal set to a wildcard and no external ID, almost always a historical convenience that nobody dared to tighten.
• Terraform state in open or over-shared buckets. State files containing plaintext secrets, output values that enumerate every IAM role, or backend configuration that points at a bucket with a wide read ACL.
• CI/CD runners with persistent long-lived cloud credentials. GitHub Actions, GitLab CI, and self-hosted runners that still carry static keys rather than federated OIDC tokens.

None of this is novel. All of it recurs. The team’s job in a review is to confirm that the specific chain each of these creates has been walked, not just that each item has been checked off a list. The follow-on step, cloud workload vulnerability testing, takes the inventory the identity review produces and pressure-tests the workloads attached to each identity.

Remediation and Ongoing Controls

Remediation on this surface is less exciting than the attack chain, and more durable than the audit cycle. The patterns CTDefense recommends:

• Narrow service account permissions to the specific resources they touch. Replace broad roles with purpose-built custom roles. Expect this work to take iterations, because the first narrow policy will break the workload, and the diff between what the workload actually needs and what the broad role was granting is the finding.
• Rotate long-lived keys and migrate to short-lived credentials. Workload identity federation on Google Cloud, IAM Roles Anywhere on AWS, and managed identities on Azure let workloads authenticate without static keys. Where federation is not feasible, enforce rotation at a defined cadence and track key age on a dashboard the team actually reads.
• Pin trust policies. Replace wildcard principals with explicit account IDs. Require external IDs on cross-account roles. For Entra ID, use conditional access policies that scope workload identities to a specific resource or network.
• Treat state files as secrets. Encrypt Terraform state at rest. Lock backend buckets to the roles that need write access. Strip plaintext secrets from state by using secret managers for sensitive variables.
• Alert on IAM changes, not just posture drift. CloudTrail, Google Cloud audit logs, and Entra ID sign-in logs will show the trust policy edit that opens the next attack path. The alerts need to go to someone who will act, not to a dashboard no one checks.

Finance-sector buyers reading this against DORA cloud access controls will recognise the shape. DORA’s ICT risk management requirements, and the related NIS2 and ISO 27001 controls, all require evidence that privileged access is scoped, logged, and reviewed. A review that produces that evidence, mapped to specific service accounts and specific role chains, carries directly into the compliance file.

The regulators are catching up to the attack path. In September 2026, CISA and NIST published NISTIR 8587, their first formal guidance on protecting identity tokens and assertions in cloud environments. The CISA announcement framed it plainly: “Identity is the new perimeter, and the tokens and assertions behind it are attractive targets for sophisticated adversaries.” The language is now explicit in federal guidance, and the private-sector buyers CTDefense works with are already asking what their review covers against it.

Where to Take It From Here

CTDefense continues to support organisations in technology, finance, healthcare, and other regulated sectors that have expanded their cloud footprint in the last twelve months, and whose service account sprawl is now visible for the first time. Similar organisations are encouraged to look closely at the identities their workloads run as, especially the ones created out of convenience during a migration and never reviewed since. The team’s Cloud Security Assessment walks the full chain from leaked credential to secrets exfiltration, and the output is a report built around the specific service accounts and role chains that matter to the business.

By addressing these kinds of gaps early, you can help prevent the kind of pivot that turns a single stale key into a public leak-site posting.