Cloud IAM Explained: Identity, Roles and Zero Trust (2026)
Last verified: June 29, 2026 · Format: Guide · Reviewed by TechJacks Cloud Security Team, ISC2 CISSP, AWS SAP-C02
Cloud IAM (Identity and Access Management) is the permission layer between every cloud resource and every entity that wants to use it. Misconfigured IAM is consistently among the top cloud breach vectors: not because IAM is hard, but because the terminology is used loosely and the models (RBAC, ABAC, Zero Trust) are often misunderstood.
This six-step guide covers the conceptual foundations from NIST standards, the access control models, how all three major cloud providers implement IAM, and the threat patterns (MFA fatigue, SIM swapping, confused deputy, shadow access) that exploit IAM gaps. All IAM concepts are grounded in NIST SP 800-63-3, NIST SP 800-207, and official provider documentation verified June 29, 2026.
[BOTH] Practitioners + Decision-Makers
Three terms are often conflated but represent distinct concepts from NIST SP 800-63:
| Term | Definition | Example |
|---|---|---|
| Entity | Any item with a recognizably distinct existence: person, device, software application | A Lambda function, a developer, an EC2 instance |
| Identity | Set of attributes that characterize an entity in a given domain | Username, department, job title, device fingerprint |
| Identifier | Specific attribute(s) that uniquely characterize an identity within a domain | Email address, AWS ARN, Azure Object ID, GCP service account email |
Authentication (AuthN) and Authorization (AuthZ) are always two separate gates:
- Authentication (AuthN): The formalized process of verifying a claimant's identity, answering WHO or WHAT is attempting access. Produces a verified credential (token, session).
- Authorization (AuthZ): The process of verifying WHAT resources or actions an authenticated identity is permitted to execute. Happens after AuthN, never before.
OIDC token model: When you log in with Google or Azure, an ID Token (a JSON Web Token, or JWT) carries verified claims about your authenticated user profile. A separate Access Token acts as a temporary key to authorize requests to resource servers or APIs. ID Token proves who you are; Access Token grants what you can do. These are never the same token.
Human identities (interactive users) and Non-Human Identities (NHIs) are both subject to IAM policies. NHIs include service accounts, cloud workloads, CI/CD pipelines, and API keys. NHIs are often misconfigured because they are treated as less risky than human accounts. They are not.
Two access control models dominate cloud IAM:
| Dimension | RBAC (Role-Based) | ABAC (Attribute-Based) |
|---|---|---|
| How it works | Grants permissions based on static role or group membership | Evaluates dynamic real-time attributes at decision time |
| Examples | "Developer" role: read S3, no write RDS | Allow if dept=Finance AND location=US AND time < 18:00 |
| Strengths | Simple to configure, easy to audit | Granular, context-aware, captures runtime nuances |
| Weaknesses | Too rigid; frequently leads to over-privileged accounts because static roles cannot capture runtime nuances | Complex to design, harder to audit, requires attribute infrastructure |
| AWS term | IAM Roles / Groups with managed policies | Condition keys in IAM policies (e.g., aws:RequestedRegion) |
| Azure term | Azure RBAC built-in / custom roles | Conditional Access policies (Entra ID P1/P2) |
| GCP term | Predefined IAM roles | IAM Conditions (resource attributes, time, request path) |
Most cloud environments start with RBAC and layer ABAC conditions where role granularity breaks down. The danger is letting RBAC roles grow to cover edge cases: at that point, a single "Admin" role often has far more access than any individual user legitimately needs.
RBAC risk: Static role assignments are the most common source of over-privileged cloud accounts. Run access analyzer tools regularly: AWS IAM Access Analyzer, Azure Entra ID Access Reviews, and GCP IAM Recommender surface unused permissions that should be revoked.
The Principle of Least Privilege (PoLP): every identity is granted only the absolute minimum permissions needed to perform its legitimate task, and for no longer than required.
Just-in-Time (JIT) access operationalizes least privilege for privileged operations: permissions are dynamically provisioned on demand for a specific task and automatically decommissioned upon completion. JIT replaces permanent standing privileges that give attackers a persistent window if credentials are compromised.
- IAM Access Analyzer surfaces unused permissions
- Permission Boundaries cap maximum scope
- SCPs via AWS Organizations enforce org-wide guardrails
- IAM is free; CloudTrail audit logging has charges
- Azure Access Reviews identify stale role assignments
- PIM (Entra ID P2) enables JIT activation for privileged roles
- Custom RBAC roles for granular scope control
- Azure RBAC is free; PIM requires Entra ID P2 (verify current pricing at Microsoft Entra pricing)
- IAM Recommender suggests role downscopes
- Privileged Access Manager for JIT approvals
- Custom roles with exact permission sets
- Cloud IAM is free; audit log storage has charges after free tier
Zero Trust philosophy: never trust, always verify. It assumes breach is inevitable or has already occurred, and eliminates perimeter-centric trust assumptions where being "inside the network" grants implicit access to resources.
NIST SP 800-207 defines Zero Trust Architecture with three core components:
| Component | Role | What it does |
|---|---|---|
| Policy Engine (PE) | Decision brain | Evaluates real-time signals: identity assurance levels, device health, behavioral anomalies, and org policies. Produces an allow, deny, or revoke decision. |
| Policy Administrator (PA) | Command plane | Executes PE decisions by creating, modifying, or terminating session credentials and tokens. |
| Policy Enforcement Point (PEP) | Gatekeeper | Monitors and terminates physical communication paths based on PA commands; the actual gate between the subject and the resource. |
CISA's Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications/Workloads, and Data. IAM is Pillar 1. Without strong identity verification, the other pillars cannot enforce trust decisions. Reference: cisa.gov/zero-trust-maturity-model
In AWS, the Policy Engine maps to IAM policy evaluation; the Policy Enforcement Point maps to service-level authorization checks on every API call. In Azure, Entra ID Conditional Access acts as the PE, evaluating device compliance, location, and identity risk score before issuing an access token. In GCP, BeyondCorp Enterprise provides a managed Zero Trust access layer for applications.
MFA requires at least two distinct authentication factors from three categories (NIST SP 800-63):
- Something you know: password, PIN
- Something you have: hardware token, smartphone (OTP app, push notification), smart card
- Something you are: biometrics (fingerprint, face)
Not all MFA is equally strong. Two threat patterns bypass common MFA implementations:
| Threat | How it works | MFA types bypassed | Defense |
|---|---|---|---|
| MFA Fatigue Attack | Attacker bombards the user with push notification MFA prompts until the user approves one out of fatigue or confusion | Push notification MFA (Microsoft Authenticator default, Duo push) | Number matching on push prompts; FIDO2 hardware key; number-matched authentication (forces user to confirm a code displayed on screen) |
| SIM Swapping | Attacker socially engineers the mobile carrier into transferring the victim's phone number to an attacker-controlled SIM, intercepting SMS OTP codes | SMS OTP codes | Never use SMS as MFA for privileged accounts; migrate to FIDO2 or authenticator app with number matching |
FIDO2 WebAuthn: phishing-resistant MFA
FIDO2 WebAuthn (Passkeys) uses asymmetric cryptography and protocol-level origin domain binding. When registering, the hardware authenticator generates a key pair per site; the private key never leaves the device. When authenticating, the site sends a challenge; the authenticator checks the origin domain. If the domain does not match (phishing site), the authenticator refuses to sign the challenge.
This makes FIDO2 fundamentally phishing-resistant: an attacker cannot capture credentials from a phishing page because the authenticator checks the domain before signing. PKI-based smart cards (PIV/CAC) provide the same guarantee with an X.509 certificate instead of a WebAuthn key pair. Both FIDO2 and PIV are approved for NIST SP 800-63-4 AAL3 (Authenticator Assurance Level 3 — the highest assurance level in the NIST digital identity guidelines).
For all cloud console root/admin accounts and privileged IAM roles: use FIDO2 hardware keys. For standard developer accounts: use authenticator apps with number matching as a minimum. Never use SMS OTP for any cloud IAM account.
Service accounts are non-human identities used by applications, workloads, and automated processes. They are among the fastest-growing IAM attack surfaces because they often accumulate excessive permissions and their credentials are rarely rotated.
Two critical threat patterns involving service accounts:
- Shadow access: Unintended entitlements and over-permissioned service accounts that silently expand an attacker's lateral blast radius. A Lambda function with admin IAM permissions because "it was easier" is shadow access.
- Confused deputy attack: An attacker exploits cross-account or cross-service trust paths to trick a more privileged entity into executing actions on their behalf. If Service A trusts Service B unconditionally, an attacker who compromises Service B can invoke Service A's higher-privileged actions.
- Use IAM Roles for EC2/Lambda instead of long-lived access keys
- Rotate all static access keys; disable unused ones
- Add condition keys to trust policies (e.g., aws:SourceAccount) to prevent confused deputy
- IAM Identity Center for cross-account access management
- Use Managed Identities (system-assigned or user-assigned) instead of service principal credentials
- Scope Managed Identities to minimum required RBAC roles
- Audit service principal credential expiration (keys and secrets)
- Customer always owns identity configuration in all service models
- Use Workload Identity Federation instead of service account keys for external workloads
- Service account keys: rotate at least every 90 days; prefer keyless auth
- Organization to Folder to Project to Resource: IAM policies inherit downward; minimize policies at top of hierarchy
- IAM Recommender detects over-privileged service accounts
Test Your Knowledge
AWS IAM, Amazon EC2, AWS Lambda, and AWS Organizations are trademarks of Amazon Web Services, Inc. Microsoft Entra ID, Azure RBAC, and Privileged Identity Management are trademarks of Microsoft Corporation. Google Cloud IAM, Workload Identity Federation, and BeyondCorp are trademarks of Google LLC. NIST SP 800-63 and NIST SP 800-207 are U.S. government publications in the public domain. FIDO2 and WebAuthn are standards by the FIDO Alliance and W3C. All IAM configurations should be tested in non-production environments before deployment.
Set your AI security baseline. The AI Security Policy: a deploy-ready security baseline for AI systems.
Your purchase helps keep our hubs free to read.