Identity threats across AWS and Azure need continuous NHI controls

At a glance

What this is: This is a practical guide arguing that identity threats across AWS and Azure require continuous NHI controls, not periodic reviews and fragmented tooling.

Why it matters: It matters because IAM, IGA, PAM, and cloud security teams need continuous visibility into service accounts, tokens, and privilege drift across multi-cloud environments.

👉 Read Unosecur's analysis of identity threats across AWS and Azure accounts

Context

Identity threats in multi-cloud environments are often governance failures before they are technical failures. When AWS and Azure accounts are managed with periodic reviews, separate IAM controls, and static credentials, the organisation can see access on paper but still miss how identities behave at runtime. The result is a control gap across non-human identities, workload credentials, and privileged access paths.

The article’s core point is that multi-cloud identity governance has to move from approval events to continuous enforcement. That applies to service accounts, tokens, and machine identities as much as it does to human access, because attackers often exploit valid credentials rather than breaking the perimeter first.

Key questions

Q: What breaks when AWS and Azure identity controls rely on periodic reviews?

A: Periodic reviews fail when attackers operate through valid credentials between certification cycles. The control can confirm that access existed at a point in time, but it cannot see token abuse, privilege escalation, or lateral movement as they happen. That leaves multi-cloud identity governance blind to the behaviours that actually create breach risk.

Q: Why do static credentials create more risk than ephemeral access for cloud admins?

A: Static credentials create standing privilege, which means one leak can remain usable until someone finds and revokes it. Ephemeral access narrows that window and makes the issuance event, not the stored string, the governance object. That is why cloud admin access should be brokered and time-limited rather than managed as a durable secret.

Q: How do you know if identity threat detection is actually working?

A: Look for shorter mean time to detect and mean time to respond, plus fewer incidents where suspicious sessions persist for hours. Successful programmes also show accurate correlation between behavioural anomalies and real misuse, not just alert volume. If detection cannot trigger containment before damage spreads, the programme is still mostly observational.

Q: What is the difference between workload identity and API keys for AI agents?

A: Workload identity binds access to the runtime and usually issues short-lived credentials automatically, which reduces secret handling and improves revocation. API keys are typically static bearer secrets that can be reused if exposed. For governed agent environments, workload identity is the better control pattern because it aligns access with infrastructure and lifecycle management.

Technical breakdown

Why static credentials become the weakest link in multi-cloud identity

Static credentials create a durable trust path across environments that were never meant to share the same access assumptions. In AWS and Azure, hard-coded keys, tokens, and service credentials can survive long after the workload, integration, or operator that created them has changed. That persistence turns a single leak into a broad access opportunity, especially when identities are reused across clouds or tied to loosely governed automation. The technical issue is not just exposure. It is the absence of lifecycle control over credentials that should be ephemeral or tightly scoped.

Practical implication: replace static shared credentials with workload identities and enforce credential lifecycle ownership across both clouds.

How periodic access reviews miss live identity abuse

Access reviews are designed to certify entitlements at a point in time, but valid-account abuse happens in real time. Once an attacker operates with a legitimate identity, the activity can look normal unless the control stack is watching for impossible travel, unusual token use, privilege escalation, or lateral movement patterns. That is why compliance-oriented review cycles are insufficient on their own in AWS and Azure. They validate the existence of access, not the behaviour of the identity after issuance.

Practical implication: pair entitlement reviews with continuous identity threat detection that watches for misuse after access is granted.

Why workload identity beats static API keys for service-to-service access

Workload identity shifts authentication away from long-lived secrets and toward platform-native trust assertions such as managed identities, IAM roles, and OIDC-based federation. That matters because service-to-service access is one of the most common places where secrets sprawl quietly accumulates. If an integration still depends on copied API keys, the blast radius expands whenever those keys are logged, reused, or left in code. The architectural goal is to make authentication short-lived, scoped, and revocable without manual hunting.

Practical implication: remove hard-coded API keys from service-to-service paths and standardise on federated workload identity.

Threat narrative

Attacker objective: The attacker’s objective is to use legitimate-looking identity access to move laterally, escalate privilege, and reach cloud resources without triggering obvious perimeter alarms.

1. Entry occurs when attackers obtain valid credentials, often through exposed keys, token abuse, or reused service account access in cloud environments.
2. Escalation follows when those valid identities inherit more privilege than the original workload or operator should have held, allowing abuse of stale roles and over-permissioned paths.
3. Impact is achieved when attackers move laterally, access cloud resources, or use the trusted identity to avoid detection until after damage has occurred.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Continuous identity enforcement is now the control boundary, not access approval. In multi-cloud environments, the critical failure is not whether access was approved once, but whether the identity remains constrained after issuance. Periodic review cycles cannot see runtime misuse, token replay, or privilege drift in the moment they occur. Practitioners should treat continuous enforcement as the operating model for AWS and Azure identity governance.

Static credential dependence creates avoidable identity blast radius. The article’s strongest operational warning is that hard-coded keys between environments turn routine integration into persistent risk. That pattern widens the attack surface because compromise of one secret can cross platform boundaries and outlive the business process that needed it. The practical conclusion is that secret lifetime and access scope must be governed together, not separately.

Orphaned service accounts are a lifecycle problem, not just an inventory problem. When service identities outlive the workload, the access model has already failed even if the account is still technically valid. This is where NHI governance and lifecycle ownership intersect: unused does not mean harmless, it means unmanaged. Teams need a named owner, a revocation path, and a review trigger for every non-human identity.

Identity threat detection must be built for valid-account abuse. The article correctly shifts attention from perimeter intrusion to post-authentication behaviour such as lateral movement, token abuse, and privilege escalation. That aligns with the reality that cloud attackers often look like normal users once inside. The implication is clear: identity telemetry, not just access policy, is where detection value now sits.

Zero standing privilege changes the meaning of trust in cloud accounts. Always-on administrative access assumes the right subject will keep using the right identity at the right time, and that assumption is increasingly fragile across AWS and Azure. Just-in-time elevation narrows the exposure window, but only if entitlement, monitoring, and revocation are all continuous. Practitioners should treat standing privilege as the structural weakness, not a convenience.

What this signals

Identity threat management in cloud is now a runtime discipline. Multi-cloud programmes that still depend on quarterly certification will keep missing the activity that matters most: how identities behave after they are approved. The operational shift is toward continuous monitoring of service accounts, tokens, and access paths across both AWS and Azure.

Service-account governance is the quiet centre of multi-cloud risk. Orphaned accounts and stale privileges are not edge cases, they are the predictable by-products of cloud sprawl and fast-moving delivery pipelines. Programmes that cannot name an owner for each non-human identity will struggle to prove that their access model is under control.

For practitioners

• Replace hard-coded cloud credentials Inventory API keys, shared secrets, and copied tokens used between AWS and Azure, then eliminate them where managed identities, IAM roles, or OIDC federation can provide short-lived access.
• Centralise identity telemetry Pull sign-in, role assumption, token, and privilege events from both clouds into a SIEM so impossible travel, anomalous AssumeRole activity, and token abuse can be correlated in one place.
• Tighten non-human identity ownership Assign an explicit owner, business purpose, and revocation path to every service account, machine identity, and automation credential, including those that are currently dormant or orphaned.
• Move privileged access to JIT Replace always-on admin permissions with just-in-time elevation for cloud operators and high-risk service identities, and require automatic expiry after the task is complete.
• Use access reviews as a backstop Keep access certifications for governance evidence, but do not treat quarterly review cycles as a substitute for continuous monitoring of identity behaviour and entitlement drift.

Key takeaways

• Multi-cloud identity risk is driven less by perimeter failure than by uncontrolled credentials, stale privileges, and identities that outlive their business purpose.
• The article argues that periodic reviews are insufficient because valid-account abuse, token misuse, and lateral movement happen between certification cycles.
• The practical response is continuous enforcement through workload identity, telemetry correlation, and zero standing privilege for high-risk access paths.

Key terms

• Identity Threat Detection and Response: Identity threat detection and response is the practice of finding misuse of credentials, unusual access patterns, and compromised identities across human and machine actors. For NHIs, it relies on telemetry from code, vaults, cloud services, and pipelines to detect abuse early enough to contain it.
• Identity Security Posture Management: Identity security posture management is the continuous assessment of identity configuration, privilege, and exposure across an environment. It focuses on drift, overprivilege, and control gaps so teams can see where IAM, PAM, and NHI governance are failing before those gaps become incidents.
• 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.
• Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step controls for AWS Direct Connect, Azure ExpressRoute, and encrypted service-to-service paths
• Specific product workflows for AWS GuardDuty, Microsoft Defender for Identity, and Entra Access Reviews
• Detailed guidance on ITDR, ISPM, and Zero Standing Privilege implementation across cloud accounts
• Examples of compliance reporting for SOC 2, ISO 27001, and PCI-DSS evidence collection

👉 The full Unosecur blog covers the ITDR, ISPM, and NHI control details behind the framework.

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.