IAM is shifting from passwords to continuous identity assurance

At a glance

What this is: This is an explainer on IAM fundamentals that argues modern identity controls need to move from static authentication toward continuous assurance, passwordless access, and standards-based governance.

Why it matters: It matters because IAM teams must align human identity controls, external access, and policy enforcement across cloud and third-party systems without widening the attack surface.

By the numbers:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read 1Kosmos's full guide to IAM, passwordless authentication, and biometrics

Context

Identity and access management is the control layer that decides who or what can authenticate, sign in, and reach protected resources. In practice, the article frames IAM as the combination of identity management, authentication, authorization, and audit logging, then extends that model to workforce and customer access across cloud and external platforms.

The governance problem is that IAM is no longer only about human users behind a login screen. As organisations adopt passwordless authentication, biometrics, OAuth, and OIDC, they need to treat access as a lifecycle issue across internal systems, third-party applications, and compliance-driven environments.

That makes IAM a policy and assurance discipline, not just a sign-in feature set. The article's starting point is typical for enterprise identity teams, but the real challenge is modernising those controls without losing visibility, portability, or revocation discipline.

Key questions

Q: How should organisations implement passwordless IAM without weakening recovery controls?

A: Treat passwordless as an assurance program, not a user-experience feature. Enrolment, device binding, biometrics, and fallback recovery must be governed together so the reset path is not easier to abuse than the primary login path. The strongest deployments define recovery thresholds, step-up checks, and auditability before rollout.

Q: Why do OAuth and OIDC create governance challenges in cloud IAM?

A: They extend identity across applications by issuing tokens and federation signals, which is useful but risky if scope, session lifetime, and revocation are inconsistent. Governance becomes harder because access is no longer controlled in one place. Teams need token policy, trust review, and monitoring across every relying application.

Q: What breaks when identity assurance is treated only as a login problem?

A: Role design, audit logging, revocation, and third-party access all become secondary, even though those controls determine whether access stays appropriate after authentication. The result is a strong front door with a weak interior. IAM programmes fail when they stop at sign-in and do not govern the full access lifecycle.

Q: How can security teams compare passwordless IAM with zero trust?

A: Passwordless answers how a subject proves identity, while zero trust answers how that identity is continuously evaluated for access. They are complementary, not interchangeable. Organisations should use passwordless to strengthen authentication and zero trust to enforce ongoing authorization, session control, and least privilege.

Technical breakdown

Identity, authentication, and authorization in IAM

IAM separates three functions that are often lumped together: identity proves who the subject is, authentication verifies that claim, and authorization decides what that subject can reach. The article also adds audit logging as the operational record that supports security, diagnostics, and compliance. That distinction matters because weak control in one layer cannot be compensated for by strength in another. A strong login flow does not fix poor role design, and clean role design does not help if authentication is easily bypassed.

Practical implication: map each access control failure to the exact layer that failed before you choose the control to fix it.

Passwordless authentication and biometrics

Passwordless IAM replaces shared secret entry with stronger factors such as biometrics, device-backed credentials, or possession-based methods. The article presents biometrics and continuous authentication as a way to reduce friction while increasing assurance. The technical trade-off is that biometric and passwordless systems still depend on proofing quality, device trust, and policy alignment. If those upstream controls are weak, a passwordless front end can still create a weak identity lifecycle underneath.

Practical implication: validate enrolment, device binding, and fallback recovery paths before treating passwordless as a governance win.

OAuth, OIDC, and zero-trust access control

OAuth delegates authorization through tokens, while OIDC adds an identity layer that lets applications rely on federated sign-in signals. In cloud and mobile environments, this makes IAM portable across services, but it also increases the importance of token scope, revocation, and session boundaries. The article ties this to zero trust by arguing that access should be evaluated on the identity and policy context, not the network location. That is the right framing for distributed systems, but only if token lifecycle and policy enforcement stay consistent.

Practical implication: review token scope, federation trust, and revocation handling as part of zero-trust design, not as separate tasks.

Threat narrative

Attacker objective: The objective is to impersonate a trusted identity and use legitimate access paths to reach protected applications, data, or administrative functions.

1. entry: The attack surface begins when password-based access, weak proofing, or exposed identity workflows let an attacker initiate authentication against a user or account.
2. credential_harvested: Once identity signals or credentials are obtained, the attacker can present themselves as a legitimate subject across cloud, mobile, or third-party services.
3. escalation: If role definitions, token scope, or fallback recovery are weak, the attacker can move from basic sign-in to broader resource access and privilege expansion.
4. impact: The result is unauthorized access, exposure of protected data, and weaker auditability across the IAM estate.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Passwordless IAM is a control redesign, not a cosmetic upgrade. The article frames passwordless access as easier and safer, but the real shift is governance: organisations move from shared secrets to stronger proofing, device binding, and recovery controls. That changes how identity assurance is established and audited. The practitioner conclusion is that passwordless only helps if the surrounding lifecycle and fallback processes are equally disciplined.

Continuous authentication changes the meaning of trust in IAM. Once access is evaluated beyond the login screen, identity governance has to account for session context, token lifetime, and ongoing signal quality. This is especially important in cloud and third-party application environments where access is distributed across many systems. The practitioner conclusion is that point-in-time sign-in checks are no longer enough for high-risk workflows.

IAM for workforce and customer identities is converging around the same assurance problem. The article treats workers and customers as separate use cases, but both depend on the same underlying questions: how identity is established, how access is granted, and how it is revoked. That convergence matters because teams often maintain different controls for each population. The practitioner conclusion is that identity programmes should unify assurance principles even when user experiences differ.

Standards compliance is the real interoperability test. The article's emphasis on NIST 800.63.3, FIDO2, SAML, and OIDC shows that modern IAM has to be portable across systems without weakening assurance. That aligns with NIST CSF and zero-trust thinking, where identity is a control plane, not a local feature. The practitioner conclusion is to validate whether standards support both interoperability and revocation discipline in production, not just sign-on success.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage, according to Ultimate Guide to NHIs.
• For a broader governance lens, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding shape identity assurance.

What this signals

Identity programmes are moving toward assurance orchestration. The practical shift is no longer just stronger authentication, but the ability to coordinate proofing, session control, and revocation across internal and external systems. That is where the IAM backlog will accumulate if teams keep treating passwordless, OAuth, and audit logging as separate workstreams.

Five days is too long for stale access to remain valid in a modern identity programme. Our research shows 91.6% of secrets remain valid five days after notification, which is a reminder that revocation speed is now an operational metric, not just a hygiene issue. Teams should align identity governance with the NHI Lifecycle Management Guide and the OWASP Non-Human Identity Top 10 where lifecycle drift is already measurable.

Continuous assurance will become the expected baseline for distributed identity. As organisations expand across cloud, mobile, and third-party access, identity teams should expect more pressure to prove that authentication, authorization, and recovery controls work together under real operating conditions. The programmes that adapt fastest will be the ones that treat identity as a governed control plane, not a login utility.

For practitioners

• Define assurance tiers for each identity population Separate workforce, customer, and privileged identities into distinct assurance tiers so proofing, authentication, and recovery controls match the risk level of the access path.
• Audit passwordless fallback and recovery paths Review what happens when biometrics fail, devices are lost, or users need account recovery, and make sure those paths do not become weaker than the primary login method.
• Map OAuth and OIDC token scope to business risk Treat federated token design as a governance issue, then limit scope, session duration, and revocation lag for applications that handle sensitive data or administrative functions.
• Unify IAM policies across internal and third-party access Apply the same identity assurance principles to workforce tools, external apps, and partner integrations so policy drift does not create inconsistent access controls.

Key takeaways

• IAM is no longer just about verifying a user at sign-in. It now has to sustain identity assurance across authentication, authorization, audit, and lifecycle control.
• Passwordless and biometric methods reduce friction, but they only strengthen security when enrolment, recovery, and token governance are equally mature.
• For IAM teams, the key decision is not whether to modernise authentication, but whether the surrounding governance model can support continuous trust decisions.

Key terms

• Identity Assurance: Identity assurance is the degree of confidence that an organisation has in the identity of a user or system at a given point in time. In practice, it combines proofing, authentication strength, recovery design, and auditability so access decisions can be trusted beyond a single login event.
• Passwordless Authentication: Passwordless authentication is a sign-in method that removes the shared secret as the primary credential and replaces it with stronger factors such as device binding, biometrics, or possession-based verification. It reduces phishing exposure, but only when enrolment and fallback recovery are tightly governed.
• Continuous Authentication: Continuous authentication is the practice of re-evaluating identity assurance during a session instead of only at the login boundary. It uses signals such as device state, token context, or behavioural checks to confirm that access remains appropriate as the session unfolds.
• Federated Identity: Federated identity allows one system to trust identity signals issued by another system through protocols such as OAuth and OIDC. It simplifies access across applications, but it also shifts governance to token scope, trust relationships, and revocation discipline across domains.

Deepen your knowledge

NHI governance, agentic AI identity, machine identity security, IAM, and identity lifecycle 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 governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: What is Identity and Access Management (IAM)? Read the original.