By NHI Mgmt Group Editorial TeamPublished 2023-10-24Domain: Governance & RiskSource: 1Kosmos

TL;DR: Traditional IAM that verifies passwords or OTPs but not the person behind the login still leaves organisations exposed to account takeover, phishing-driven compromise, and downstream breaches, according to 1Kosmos. The core failure is architectural: identity assurance at enrollment and authentication is too weak to support modern access decisions.


At a glance

What this is: This is a vendor analysis of why password and basic MFA IAM leave identity verification gaps that enable account takeover.

Why it matters: It matters because IAM, PAM, and identity lifecycle teams need assurance that the subject behind access is real, enrolled correctly, and still accountable across user, privileged, and federated access paths.

👉 Read 1Kosmos's analysis of why IAM identity verification gaps keep account takeover easy


Context

Identity verification is the missing control in many IAM programmes. If a system can confirm possession of a password or one-time code but cannot reliably confirm who enrolled the account and who is authenticating now, account takeover remains a live path into enterprise systems.

That gap matters across human IAM and privileged access programmes because access governance assumes the account subject is trustworthy from enrollment through login. When that assumption is weak, phishing, credential abuse, and fake enrolment can all become access problems rather than just authentication problems.

The article argues that modern IAM needs stronger identity assurance, not just stronger credential checks. That is a typical enterprise problem, not an edge case, because the same trust gap can propagate into remote access, AD, and privileged workflows.


Key questions

Q: How should security teams improve identity assurance in IAM without overcomplicating login?

A: Start by separating identity proofing from authentication. Login controls can confirm factor possession, but proofing must confirm who the subject is before credentials are issued. The safest pattern is to keep high-assurance enrollment, recovery, and privileged approval as explicit controls rather than assuming MFA covers them all.

Q: Why do passwords and basic MFA still leave organisations open to account takeover?

A: Because they verify a secret or device, not the trustworthiness of the enrolled identity. If a synthetic or stolen identity gets through registration, the account can authenticate perfectly and still belong to the wrong subject. The failure begins at onboarding, then shows up later as account takeover.

Q: What do IAM teams get wrong about biometric and passwordless authentication?

A: They often assume biometric convenience equals identity certainty. In practice, biometrics or passkeys can strengthen authentication, but they do not automatically prove that the enrolled person is the right person or that the original identity evidence was strong enough. Enrollment quality still determines downstream trust.

Q: How should organisations connect IAM assurance to privileged access governance?

A: Treat the identity record as part of the control path for privileged access approvals, recertification, and recovery. If the root identity was weakly proofed, PAM and lifecycle reviews inherit that risk. Governance should therefore evaluate proofing strength before privilege is granted, not after.


Technical breakdown

Why password and MFA checks do not prove identity

Passwords and basic MFA confirm a factor, not the full identity of the person using it. A code, token, or passkey can show that someone controls a device or secret, but it does not by itself prove the enrolled subject is the person authenticating now. That distinction matters because IAM systems often treat factor possession as identity assurance. When enrollment is weak, the problem starts before login. If an attacker gets a synthetic or stolen identity through registration, strong login checks merely preserve a bad identity record.

Practical implication: treat factor validation and identity proofing as separate control layers in IAM design.

Enrollment assurance and the risk of synthetic identity

The enrollment step creates the trust anchor for every later authentication event. If registration relies on weak checks, email handoffs, or easily spoofed identity artefacts, the system may issue valid credentials to the wrong subject. That opens the door to synthetic identity, account takeover, and downstream abuse in directories and privileged systems. Modern IAM architecture has to bind the initial proofing event to later access decisions, otherwise the organisation is authenticating a questionable record with technically sound credentials.

Practical implication: harden enrollment proofing before expanding passwordless or MFA coverage.

How identity wallets and verifiable credentials change assurance

Identity wallets and reusable verifiable credentials shift IAM from static secret checking to cryptographically verifiable claims. In this model, the user presents signed evidence from trusted sources rather than only proving knowledge of a password or possession of an OTP device. The goal is higher assurance with less reliance on shared or replayable credentials. This also supports stronger auditability because claims, updates, and access events can be tied back to a tamper-evident identity record rather than an email-based onboarding flow.

Practical implication: evaluate whether reusable credentials can replace weak onboarding and recovery paths in your IAM stack.



NHI Mgmt Group analysis

Identity verification, not MFA alone, is the control boundary IAM programmes keep blurring. Passwords, OTPs, and even some biometric workflows are often deployed as if they establish identity, when they mostly establish factor possession. That is a governance mistake because access decisions inherit whatever happened at enrollment. Practitioners should treat identity proofing as a distinct assurance layer, not as a side effect of login.

Weak enrollment creates long-lived trust debt in IAM. Once a bad or synthetic identity is issued valid credentials, every later control sits on top of a compromised trust anchor. That is why account takeover often looks like a login problem but is actually an onboarding failure. The practical conclusion is that identity lifecycle governance must start before first login and extend through every re-verification event.

Privileged access becomes materially harder to govern when the root identity is only assumed, not verified. PAM can limit blast radius, but it cannot compensate for an IAM stack that cannot establish who the subject is with high confidence. That weakens certification, approval, and audit outcomes across the entire access chain. Security teams should align authentication design with privileged identity governance, not run them as separate silos.

Reusable verifiable credentials point to a more defensible identity model for modern IAM. The article’s architecture theme is that identity should be cryptographically bound, portable, and auditable rather than stitched together from emailed secrets and static checks. That direction aligns with lifecycle-aware IAM because it makes proofing, authentication, and re-verification more consistent across onboarding, recovery, and access review. Practitioners should judge IAM roadmaps by how much they reduce identity ambiguity.

From our research:

  • 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which shows how often identity governance starts from incomplete inventory.
  • For the lifecycle side of this problem, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the natural next step.

What this signals

Identity proofing will become a more explicit design criterion in IAM roadmaps. Teams that have treated enrollment as a helpdesk flow will need to reclassify it as a control point with evidence, assurance levels, and exception handling. That shift matters most where account recovery and privileged approval depend on the same weak identity record.

The governance signal is clear: authentication modernisation without identity proofing modernisation only improves convenience. If your programme still relies on emailed secrets, low-assurance recovery, or unbound biometric checks, the risk sits upstream of login and will keep reappearing in audit findings and incident response.

Practitioners should expect stronger overlap between IAM, PAM, and lifecycle governance as organisations try to reduce identity ambiguity. The more the identity record is reused across access decisions, the more valuable tamper-evident proofing and verifiable credentials become as a programme-level design choice.


For practitioners

  • Separate identity proofing from authentication controls Map where your current stack only validates factor possession and where it actually verifies the subject. If those steps are merged today, redesign the flow so enrollment assurance is a named control with its own evidence.
  • Review enrollment and recovery paths for spoofable identity data Check whether new-account setup, reset flows, and support-assisted recovery can be completed with email-only or low-assurance artefacts. Replace those paths with stronger checks for high-risk populations and privileged users.
  • Bind privileged access approval to proofed identity records Require PAM approval and access certification to reference the identity record created at enrollment, not just the active login session. This reduces the chance that a valid but poorly proofed account can be treated as trustworthy.
  • Assess where verifiable credentials can replace shared secrets Identify onboarding, login, and re-verification scenarios where reusable credentials could remove password reuse, emailed OTPs, or other replayable controls. Focus first on use cases with the highest blast radius if identity is misbound.

Key takeaways

  • The main failure is architectural, not cosmetic: basic IAM verifies access factors without always verifying the identity behind them.
  • When identity proofing is weak, later controls inherit a bad trust anchor and account takeover becomes much easier to sustain.
  • Practitioners should harden enrollment, recovery, and privileged approval together, because identity assurance is only as strong as the weakest step in the chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-63, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST SP 800-63Identity proofing and authentication assurance are central to the article.
NIST CSF 2.0PR.AA-1Access is only as strong as identity assurance before credentials are issued.
NIST Zero Trust (SP 800-207)PR.AA-02Zero trust depends on verified identity, not assumed trust from credentials alone.

Separate enrollment proofing from authentication strength and set assurance levels for each access path.


Key terms

  • Identity Proofing: Identity proofing is the process of establishing that a person is who they claim to be before credentials are issued. In IAM, it creates the trust anchor for later authentication, recovery, and privileged approval, so weak proofing can undermine every downstream access decision.
  • Account Takeover: Account takeover is unauthorized control of a valid account by someone other than the intended user. It often follows weak enrollment, credential theft, or recovery abuse, and it is especially dangerous when the account has access to directories, remote systems, or privileged workflows.
  • Verifiable Credential: A verifiable credential is a cryptographically signed claim that can be checked against a trusted issuer without relying on shared secrets. In IAM, it can strengthen proofing and re-verification by making identity evidence portable, auditable, and less dependent on replayable credentials.
  • Identity Wallet: An identity wallet is a secure container for storing and presenting identity claims, credentials, or proofs. Used well, it can support reusable verification across onboarding and login, but its security still depends on how strongly the original identity was established and bound to the wallet.

Deepen your knowledge

NHI governance, identity lifecycle management, and secrets 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 governance in your organisation, it is worth exploring.

This post draws on content published by 1Kosmos: IAM identity verification gaps keep account takeover easy. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2023-10-24.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org