Zero trust, the foundation of modern IAM
The zero trust security model starts from a simple observation: the traditional network perimeter ('trust inside, suspect outside') no longer works in a cloud environment where users, devices and services communicate from anywhere.
Never trust by default
No user, device or service is considered trustworthy simply because it's inside the organization's network. Every access request is treated as if it came from an untrusted network, regardless of its origin.
Verify systematically
Every access is authenticated and authorized individually, taking context into account (identity, device, location, behavior), rather than once at the network's edge.
Assume breach
The architecture is designed on the assumption that a breach has already occurred somewhere, which drives segmenting access and limiting the lateral movement available to an attacker who has already gained an initial foothold.
Zero trust isn't a product you install, but an approach that shapes how all access is designed. Major cloud providers' IAM tools help implement it, but the access architecture itself needs to be designed with this logic from the start.
Least privilege: a continuous cycle, not a one-time state
The least privilege principle means granting each identity only the permissions strictly necessary for its actual use, no more and no less. Simple to state, it's rarely maintained over time without a dedicated process.
Analyzing actual usage rather than assumed usage
Access analysis tools offered by major providers (like IAM permission analyzers) compare granted rights against actual observed usage, consistently revealing a significant gap between what's granted and what's actually used.
Just-in-time (JIT) access, the logical evolution of least privilege
Rather than granting permanent rights ('standing access'), just-in-time access eliminates always-active permissions and grants them only for the actual duration of the need, with an explicit request and usually an approval step. This approach mechanically reduces the exposure window if an account is compromised.
RBAC and ABAC: two different logics, often complementary
Choosing between RBAC and ABAC is one of the most common trade-offs for a team structuring its access governance — and the right answer is often 'both,' not one instead of the other.
RBAC: permissions tied to a role
Role-Based Access Control attaches permissions to a predefined role (e.g. 'database administrator'), then assigns that role to the relevant identities. Simple to understand and audit, particularly well suited to stable organizational structures.
ABAC: permissions computed from attributes
Attribute-Based Access Control dynamically computes permissions from contextual attributes (department, data sensitivity level, location, time of day). More flexible than RBAC, but also more complex to design and audit.
Combining both in a mature organization
In practice, many organizations combine RBAC for the general access structure (stable, predictable) and ABAC for fine-grained contextual rules (temporary, conditional) — rather than picking a single model for the entire organization.
A concrete example
A finance team might be assigned an RBAC role 'Finance Analyst' granting access to standard reporting tools. An ABAC rule then dynamically restricts access to certain sensitive reports based on connection location or time of day — the role defines the general scope, the attribute fine-tunes the decision case by case.
Non-human identities now outnumber human identities
Service accounts, roles assigned to CI/CD pipelines, serverless functions, automated agents: in most modern cloud environments, these non-human identities (NHIs) now outnumber human user accounts — and are often less well governed.
Why non-human identities are a frequent blind spot
Unlike a user account, a non-human identity doesn't log in manually, doesn't change moods, doesn't forget its password — which makes it less visible in classic access review processes, even though it often holds very broad permissions to function correctly.
Applying the same principles as human identities
Best practice is to apply the same requirements to non-human identities as to human accounts: an explicit lifecycle (creation, review, deactivation), regular rotation of credentials and keys, and strict application of least privilege — rather than leaving them outside the usual governance scope.
In heavily automated modern cloud environments (CI/CD, container orchestration, serverless functions), it's no longer unusual for non-human identities to represent the majority of active identities — a shift in scale that quickly makes traditional manual governance unsustainable.
Global guardrails, beyond individual permissions
In a multi-cloud or large-scale environment, IAM governance can't rely solely on fine-grained configuration of each individual permission — it requires global guardrails that apply uniformly, including to the most privileged accounts.
Concrete examples at major providers
At AWS, Service Control Policies can prevent any identity, including the root account, from disabling audit logging or removing certain security controls. At Google Cloud, Organization Policies can globally disable certain risky practices, such as creating service account keys, at the organization level rather than project by project.
The challenge of consistency across providers
Each cloud provider has its own terminology and its own governance mechanisms — consistently translating the same security policy across multiple providers remains one of the most concrete challenges of multi-cloud governance, well documented as such in organizations operating across several platforms.
Toward formalized governance (IGA)
This complexity is pushing more and more organizations toward Identity Governance and Administration (IGA): a structured set of processes and tools covering the full identity lifecycle, continuous visibility into granted access, and proactive anomaly detection — an evolution toward a formalized discipline, rather than a set of scattered one-off controls.
Toward passwordless authentication for privileged accounts
Multi-factor authentication remains an essential baseline, but the most advanced organizations in IAM are now moving toward authentication methods more robust than a simple password plus one-time code.
- FIDO2 and passkeys, which eliminate the password itself as an attack vector rather than simply reinforcing it
- Certificate-based authentication for technical access and non-human identities
- Hardware security keys for the most critical privileged accounts
- Context-aware authentication, which adjusts the required verification level based on location, device and observed behavior
The most frequent IAM governance pitfalls
Three mistakes consistently show up in organizations struggling to structure their IAM governance.
Access reviews that are too rare or nonexistent
Without regular review, permissions accumulated through role changes, finished projects, and unaddressed departures create a growing gap between granted rights and actual needs — fertile ground for exploitation if a breach occurs.
Forgetting non-human identities in governance
Treating IAM governance as a topic that only concerns human user accounts leaves an increasingly large blind spot, as automation becomes more widespread across cloud environments.
RBAC roles defined too broadly for simplicity
Creating overly permissive generic roles to avoid the complexity of finer-grained roles directly undermines the least privilege principle — the short-term management simplicity comes at the cost of a larger exposure surface in the medium term.
A documented but never-audited IAM governance policy doesn't protect any better than no policy at all. Governance is proven through effective, regular controls, not through documentation alone.
A central domain in entry-level and advanced certifications
IAM and governance consistently rank among the most heavily tested domains of cloud certifications, starting at the entry level — Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner all cover identity and access management, an essential foundation before tackling more advanced certifications specifically focused on this topic.
Further reading
- ArticleShared Responsibility in the Cloud
- ArticleIaaS, PaaS, SaaS: the 3 cloud service models
- ArticleFinOps: Understanding and Managing Cloud Costs
- ArticleAWS vs Azure vs Google Cloud
- ArticleCloud Sovereignty, Portability and Reversibility
- GuideUnderstand Azure Fundamentals
- GuideAzure Architecture: trade-offs, data, AI
Frequently asked questions
What's the difference between zero trust and the shared responsibility model?
The shared responsibility model defines who — provider or customer — is responsible for each security layer. Zero trust is an architectural approach the customer applies to their own share of responsibility, particularly to identity and access management.
Is least privilege a one-time action or an ongoing process?
It's an ongoing process. Granted permissions tend to accumulate over time if not regularly reviewed, which makes an initial compliance check alone insufficient without periodic review.
Do you have to choose between RBAC and ABAC?
Not necessarily. Many mature organizations combine RBAC for the general access structure and ABAC for finer-grained contextual rules, rather than imposing a single model across all their needs.
What is a non-human identity (NHI)?
A non-human identity is an account or role used by a system rather than a person: a service account, a role assigned to a CI/CD pipeline, a serverless function's identity. They now often outnumber human accounts in automated cloud environments.
Why are non-human identities riskier to govern?
Because they often slip through classic access review processes designed for human users, while frequently holding broad permissions needed for their automated function — a blind spot that grows with the organization's level of automation.
What is just-in-time (JIT) access?
Just-in-time access grants permissions only for the actual duration of the need, rather than permanently. It eliminates always-active rights ('standing access'), reducing the exposure window if an account is compromised.
How does a global guardrail differ from an individual permission?
An individual permission applies to a specific identity. A global guardrail (like an AWS Service Control Policy or a Google Cloud Organization Policy) applies uniformly across an entire account or organization, including the most privileged identities, blocking certain actions regardless of who attempts them.
Are passwords and classic MFA outdated in 2026?
Not outdated, but increasingly supplemented or even replaced for privileged accounts by more robust methods like FIDO2 and passkeys, which remove the password itself as a vulnerability point rather than simply adding another verification layer.
Is IAM governance purely a security topic?
No. It's also a matter of regulatory compliance, operational efficiency (granting access quickly to the right people), and cost management (unused licenses and permissions). Structured IAM governance serves several goals at once.
Do you need to know these concepts for a cloud certification?
Yes, identity and access management is among the most heavily tested domains in the Azure Fundamentals, Google Cloud Digital Leader and AWS Cloud Practitioner entry-level certifications, and forms the foundation for more advanced certifications specifically focused on security.