How should security teams handle identity risk across AWS and Azure?

Why This Matters for Security Teams

AWS and Azure rarely fail as separate identity problems. The real risk is that service principals, IAM roles, managed identities, API keys, and temporary tokens can chain across both clouds into one attack path. If security teams only review each platform in isolation, they miss lateral movement, trust misconfiguration, and the way one compromised workload can inherit access elsewhere. The governance model has to be cross-cloud, because the attacker’s path already is.

That is why identity visibility, rotation discipline, and rapid revocation matter more than periodic reviews. NHI research shows how often secrets are left exposed in code, configs, and CI/CD systems, and the Ultimate Guide to NHIs details how excessive privilege and weak offboarding keep those paths open. NIST also frames identity as a continuous control problem in the NIST Cybersecurity Framework 2.0, not a once-a-quarter audit exercise. In practice, many security teams encounter cross-cloud identity abuse only after tokens have already been reused, rather than through intentional detection.

How It Works in Practice

The practical answer is to normalize AWS and Azure identity telemetry into one control plane, then evaluate access in real time. That means inventorying cloud roles, service accounts, managed identities, secrets, and federation paths together, not as separate dashboards. Security teams should treat each machine identity as a workload with a lifecycle: issuance, use, rotation, and offboarding. The goal is to shorten standing access, remove long-lived credentials, and flag any use that falls outside the expected workload pattern.

For day-to-day operations, this usually means combining four moves:

• Bind every workload to a named owner and purpose so unused identities can be retired quickly.
• Prefer short-lived tokens and federated access over static secrets stored in code or pipelines.
• Correlate cloud audit logs, secret access events, and privilege changes across AWS and Azure.
• Use policy checks at request time so sensitive actions are approved based on context, not just role membership.

That approach is consistent with the identity lifecycle guidance in the 52 NHI Breaches Analysis, which shows how compromised service accounts and keys repeatedly enable escalation. It also aligns with NIST’s guidance on continuous monitoring in NIST Cybersecurity Framework 2.0. Where possible, use workload identity federation, JIT access, and automated secret rotation so a stolen credential has little replay value. These controls tend to break down when legacy applications require embedded keys or when one cloud trusts the other through broad federation without condition checks.

Common Variations and Edge Cases

Tighter identity control often increases operational overhead, so organisations have to balance security against release velocity and platform complexity. That tradeoff is especially visible in hybrid estates, migration projects, and teams that inherited different operating models for AWS and Azure.

Current guidance suggests three common exceptions deserve extra scrutiny. First, managed service identities can still be over-permissioned, so “passwordless” does not mean “low risk.” Second, cross-account and cross-subscription roles often persist long after the original project ends, creating stale trust paths that standard access reviews miss. Third, some teams rely on periodic recertification, but for high-value workloads that is usually too slow; access should be evaluated at the moment it is requested, especially when the action touches secrets, deployment pipelines, or production data.

For deeper remediation patterns, the Top 10 NHI Issues and the Azure Key Vault privilege escalation exposure example show why vault access and role design must be reviewed together. The same logic applies on AWS, where the Codefinger AWS S3 ransomware attack illustrates how identity misuse and exposed storage can combine quickly. There is no universal standard for cross-cloud identity governance yet, but the direction is clear: reduce standing privilege, verify workload identity continuously, and revoke access as soon as the task is complete.

Related resources from NHI Mgmt Group

• How should security teams handle cloud secrets that are shared across applications and pipelines?
• How should security teams make NHI best practices usable across the business?
• How should security teams handle risks from AI browser extensions?
• How should security teams reduce Azure managed identity abuse risk?