TL;DR: IAM tools in 2026 still concentrate on authentication, directories, and reporting, while time-bound access is emerging as a core evaluation criterion for zero-trust and high-compliance environments, according to Cerbos. The practical issue is no longer whether an IAM stack can log activity, but whether it can support ephemeral entitlements and policy enforcement without standing privilege.
At a glance
What this is: This is an independent analysis of Cerbos’ roundup of IAM tools for 2026, with the key finding that modern IAM selection is shifting toward ephemeral access and policy-enforced authorization.
Why it matters: It matters because IAM teams now have to align identity, access, and authorization across human, machine, and workload contexts without leaving standing privilege behind.
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
👉 Read Cerbos' IAM tools roundup for 2026 and policy integration guidance
Context
IAM selection is no longer just a question of login experience or directory consolidation. For most enterprises, the real issue is whether identity controls can keep up with hybrid environments, time-bound access, and policy decisions that need to happen at the point of use rather than at provisioning time.
Cerbos’ article is mainly a product-facing comparison, but the underlying governance question is broader: how do organisations separate authentication from authorization while still controlling access consistently across human users, service accounts, and workload identities? That is the pressure point for modern IAM programmes, especially where zero trust and ephemeral access are becoming baseline expectations.
Key questions
Q: How should security teams evaluate IAM tools for zero-trust environments?
A: Focus on whether the tool can enforce access at request time, not just authenticate users up front. In zero trust, identity proofing is only one part of the control. The more important questions are whether access can be time-bound, context-aware, and continuously re-evaluated without leaving standing privilege behind.
Q: Why do hybrid and multi-cloud environments complicate IAM governance?
A: Because each platform expresses access differently, even when the same identity is involved. Teams end up with inconsistent entitlements, fragmented logs, and policy drift unless they standardise the decision layer. The hard problem is not authentication, but making authorization outcomes consistent across domains.
Q: What do teams get wrong about just-in-time access?
A: They often treat JIT as a shorter version of standing privilege instead of a different control model. If exceptions, manual approvals, or lingering tokens recreate permanent access in practice, the risk remains. JIT only improves security when expiry is automatic and enforcement is real.
Q: Who should own authorization decisions in modern IAM programmes?
A: Authorization should be owned as a governance function, not left as an ad hoc application detail. Identity platforms can verify who the actor is, but policy engines should decide what that actor can do under current conditions. That separation makes access review and change control far more reliable.
Technical breakdown
Why time-bound access is replacing standing privilege in IAM
Standing privilege gives users or workloads persistent rights until someone removes them. Time-bound access changes that model by issuing entitlements that expire automatically after a defined window, which reduces the period in which stolen credentials remain useful. In practice, this works best when the IAM layer can coordinate with authorization controls that evaluate duration, context, and task scope at request time. The technical shift is not just shorter sessions. It is a move from durable entitlement state to transient, policy-governed access decisions that are harder to abuse and easier to contain.
Practical implication: evaluate whether your IAM stack can issue and enforce ephemeral access without leaving persistent exceptions behind.
How identity, directory services, and authorization fit together
IAM tools often bundle identity verification, directory management, and access logging, but those functions are not the same control. Identity verification confirms who or what is requesting access. Directory services keep records of users, groups, and attributes. Authorization decides whether that identity can act on a specific resource under current conditions. The separation matters because a system can authenticate perfectly and still overgrant access if authorization is weak. In regulated or high-scale environments, fine-grained policy enforcement becomes the real control boundary, while the directory remains an identity source rather than the decision engine.
Practical implication: keep authorization logic distinct from the identity store so access rules can change without reworking the whole directory model.
Why hybrid and multi-cloud IAM becomes harder to govern
Hybrid IT and multi-cloud environments multiply identity boundaries, policy surfaces, and integration points. A single user or workload may need access across on-prem systems, SaaS, and cloud-native services, each with different entitlement models and logging behaviour. That makes consistency the technical challenge, not mere availability. When access policies drift between environments, teams lose the ability to reason about effective privilege. The article’s emphasis on scalability and federated identity points to a familiar reality: IAM tools must reconcile heterogeneous identity sources while keeping policy and audit trails coherent across domains.
Practical implication: test whether your IAM tooling can maintain consistent policy outcomes across cloud and on-prem environments before expanding its footprint.
NHI Mgmt Group analysis
IAM selection is increasingly an authorization problem, not just an authentication problem. Cerbos’ roundup still centres on identity verification, directories, and logs, but the article itself points to time-bound access and integration with authorization layers as the real decision criteria. That reflects a broader market shift: organisations no longer win by proving they can log access, they win by proving they can constrain it precisely at decision time. Practitioners should treat policy enforcement as the control that now carries the governance load.
Hybrid and multi-cloud identity sprawl exposes the limits of directory-centric thinking. A directory can describe who exists, but it cannot by itself normalise access semantics across cloud, SaaS, and on-prem systems. The article’s discussion of mixed environments makes that gap visible. Identity teams should expect policy translation, entitlement drift, and audit fragmentation whenever access decisions are scattered across platforms rather than centralised through a consistent authorization model.
Time-bound access is becoming the practical test of least privilege in enterprise IAM. The old definition of least privilege assumed entitlements could be granted durably and reviewed later. That assumption is increasingly brittle in environments where access is task-scoped, temporary, and frequently machine-mediated. The implication is that IAM maturity now depends on whether the programme can express privilege as a short-lived condition instead of a permanent state.
Policy-as-code is the boundary where IAM and application security finally meet. Cerbos’ integration examples show the direction of travel: identity systems establish who the actor is, while policy layers decide what that actor can do in context. That separation is useful because it lets governance move closer to the application without rebuilding the identity stack every time business rules change. Practitioners should treat policy-as-code as a governance interface, not just an engineering convenience.
NHI governance is now inseparable from human IAM design. The article frames IAM as a broad enterprise discipline, but the pressure points increasingly come from service accounts, workload identities, and other non-human actors that behave differently from employees. A modern IAM programme cannot optimise only for user login journeys. It has to govern human and non-human access with the same discipline while acknowledging that non-human identities often carry the most persistent risk.
From our research:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, according to NHI Lifecycle Management Guide.
- For the full governance model behind these findings, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding patterns.
What this signals
Identity programmes are moving toward decision-time governance. The next maturity jump is not better login flows. It is whether the organisation can make access decisions close to the transaction, then prove those decisions were consistent across cloud, on-prem, and SaaS environments.
Ephemeral access will expose entitlement debt faster than most teams expect. When access expires automatically, long-lived exceptions become visible immediately. That is useful operationally, but it also means gaps in policy design, approvals, and offboarding will surface in day-to-day operations rather than during annual review cycles.
NHI and human IAM can no longer be run as separate governance stories. The same policy model needs to express access for people, service accounts, and workload identities without multiplying manual exceptions. Teams that treat non-human access as a side channel will keep inheriting risk into every application rollout.
For practitioners
- Separate authentication from authorization in your target architecture. Keep the identity source, the session, and the policy decision point distinct so access rules can be changed without rewriting the directory model. This reduces coupling and makes fine-grained control easier to audit across applications and environments.
- Test ephemeral access end to end. Validate that temporary entitlements actually expire, that de-provisioning is automatic, and that exceptions do not recreate standing privilege under another name. Include human users, service accounts, and workload identities in the same test set.
- Measure policy consistency across hybrid environments. Compare the effective access result for the same identity and resource across on-prem, cloud, and SaaS systems. If the answer differs by platform, you have policy drift rather than a stable IAM model.
- Review non-human access as part of IAM selection. Use the same procurement rubric for workload identities, API tokens, and service accounts as you do for employee access. The control question is whether the platform can govern non-human access without leaving long-lived secrets or unmanaged exceptions.
Key takeaways
- Cerbos’ IAM roundup shows that authentication alone is no longer enough.
- The strongest selection criterion in modern IAM is whether access can be governed at decision time across hybrid environments.
- Practitioners should treat non-human access, ephemeral entitlements, and policy consistency as core IAM design requirements, not add-ons.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | IAM policy enforcement and access governance map directly to least-privilege control. |
| NIST Zero Trust (SP 800-207) | AC-4 | The article emphasizes request-time access decisions and zero-trust evaluation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | The post highlights standing privilege, secrets exposure, and non-human access gaps. |
Enforce access decisions at the policy layer and re-evaluate entitlements continuously.
Key terms
- Just-in-time access: Just-in-time access is a provisioning pattern that grants privileges only for the period needed to complete a task. It reduces persistent exposure by replacing standing entitlement with a short-lived, task-scoped grant that should expire automatically and be enforced consistently across systems.
- Policy-as-code: Policy-as-code is the practice of expressing authorization rules in version-controlled, testable policy logic rather than embedding them informally in applications or manual procedures. It helps teams separate identity verification from access decision-making while keeping governance auditable and repeatable.
- Non-human identity: A non-human identity is a machine or software credential used by systems, workloads, scripts, APIs, bots, or agents to authenticate and access resources. It typically includes service accounts, tokens, API keys, and certificates, and it requires lifecycle governance that differs from human user management.
- Hybrid identity governance: Hybrid identity governance is the control model used when access spans on-premises, cloud, and SaaS environments. It focuses on keeping entitlement meaning, policy enforcement, and audit evidence consistent even when identity stores and authorization points are distributed across different platforms.
Deepen your knowledge
NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or access governance, it is worth exploring.
This post draws on content published by Cerbos: Top 9 IAM tools of 2026 and Cerbos integration guidance. Read the original.
Published by the NHIMG editorial team on 2026-04-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org