Identity management still breaks at the authentication boundary

At a glance

What this is: This is an independent analysis of identity management, IAM, and the gap between authentication and authorization in modern environments.

Why it matters: It matters because IAM teams have to govern human access, machine access, and lifecycle controls as one programme if they want to contain credential theft and access abuse.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read 1Kosmos' full analysis of identity management, IAM, and identity proofing

Context

Identity management is the discipline of proving who or what is requesting access, then deciding what that identity can do once it is inside a system. The article argues that modern IAM problems come from treating authentication and authorization as separate concerns when they are really parts of the same control boundary.

That boundary matters because stolen credentials, weakly defined roles, and over-permissioned accounts all turn identity into an access bypass. In practice, that affects human users, service accounts, and any programme that depends on zero trust or least privilege to contain compromise.

The article also reflects a common enterprise pattern: organisations often buy separate tools for login, access, and compliance, then discover those controls do not join up cleanly across hybrid and cloud environments. That starting point is typical, not unusual, for mature-but-fragmented IAM programmes.

Key questions

Q: How should organisations separate identity proofing from access control in IAM?

A: Organisations should treat identity proofing as the point where a subject is established and access control as the point where permissions are limited. That means verifying enrollment, recovery, and step-up trust separately from role assignment, group membership, and application entitlements. If those steps blur together, attackers can exploit one weak control to bypass the rest.

Q: Why do strong logins still fail to prevent access abuse?

A: Strong logins fail when the downstream authorization model is too broad. A protected session can still reach too many systems, too many files, or too many administrative functions. The control problem shifts from authentication strength to entitlement scope, revocation discipline, and how quickly access is re-evaluated after a trust event.

Q: When should zero trust be applied in an IAM programme?

A: Zero trust should be applied at sensitive access boundaries, not only at the network edge. Re-check identity before privileged actions, high-value data access, and recovery paths that can reset trust. This reduces blast radius when credentials are stolen or a session is being abused.

Q: What is the difference between identity proofing and MFA?

A: Identity proofing establishes that a subject is who they claim to be before a trust relationship is created. MFA strengthens later authentication events by requiring more than one factor. Both matter, but they solve different problems, and neither should be treated as a substitute for tight authorization and lifecycle control.

Technical breakdown

Authentication versus authorization in IAM

Authentication proves identity. Authorization determines what that identity can access after it is proven. The article’s central technical point is that many failures happen when organisations harden one layer but leave the other weak. Strong login controls do not help if roles, groups, or policies still allow broad downstream access. Likewise, well-designed access policy does not matter if identities can be stolen or replayed easily. In modern IAM, the two controls must be designed together because the attacker only needs one weak link to turn identity into access.

Practical implication: review authentication strength and authorization scope together, not as separate programme workstreams.

Identity proofing and the problem of claimed identity

Claimed identity is what a user says they are, while actual identity is the evidence that proves they really are that person. The article points to identity proofing as the missing link between those two states. Passwords, biometrics, and MFA can improve assurance, but they do not automatically bind a request to a verified person unless the proofing process is strong enough. That distinction matters because phishing and credential theft exploit the gap between possession of credentials and proof of the true subject behind them.

Practical implication: strengthen identity proofing wherever recovery, enrollment, or step-up access can create a new trust decision.

Zero trust and least privilege as containment controls

Zero trust assumes access must be re-evaluated at each decision point, while least privilege limits the damage if an identity is misused. The article uses both concepts correctly as containment rather than as identity replacement. That means they do not solve poor authentication by themselves, but they do reduce blast radius when a credential is stolen or an account is compromised. In practice, zero trust becomes meaningful only when access rights are narrow, reviewed, and continuously enforced across systems, not just logged at the perimeter.

Practical implication: enforce re-authorization at sensitive boundaries and shrink default access before attackers can move laterally.

NHI Mgmt Group analysis

Authentication and authorization fail for different reasons, so IAM programmes must stop treating them as the same control. The article gets this right at a basic level: proving identity and deciding access are distinct functions, even if the market often bundles them under IAM. When organisations strengthen login without tightening downstream entitlements, they create a false sense of control. The practical conclusion is that identity security must be evaluated as a chain, not a single feature set.

Identity proofing is the real trust boundary, not the password itself. The article’s distinction between claimed identity and actual identity captures a long-standing governance problem. A credential only says that something was presented, not that the right person stood behind it. That is why phishing, recovery abuse, and stolen authenticator replay keep succeeding. The implication is that identity assurance has to start before the first session, not only at authentication time.

Zero trust and least privilege are containment disciplines, not substitutes for identity assurance. The article frames them as a way to reduce fallout from compromised identities, which is the right framing. If access is broad, compromise spreads. If re-authorization is weak, access persists longer than it should. The field should read this as a reminder that zero trust only becomes credible when access scopes are narrow and continuously re-checked.

Identity governance breaks when programmes optimise for convenience without lifecycle discipline. The article repeatedly shows the tradeoff between user experience, access simplicity, and security containment. That tension is not new, but it becomes dangerous when onboarding, role assignment, and revocation are handled as isolated events. The implication for practitioners is clear: identity governance must cover the full lifecycle, not just the login step.

Named concept: identity assurance gap. This article describes the gap between a system that can authenticate a request and a system that can prove the subject behind it is genuine. That gap widens when passwords, biometrics, or MFA are treated as sufficient on their own. Practitioners should treat this as a structural trust problem, not a cosmetic login problem.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing that identity remediation often trails disclosure.
• For the lifecycle angle, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for the offboarding and revocation mechanics that close the trust gap.

What this signals

Identity assurance gap: IAM teams should expect more scrutiny of how trust is established before a session ever begins, not only how it is enforced after login. The practical shift is toward stronger proofing, narrower entitlement design, and tighter step-up controls around recovery and privileged actions.

The next maturity test is whether identity governance can handle both human and non-human subjects with the same lifecycle discipline. If access can be granted quickly but not revoked cleanly, the programme is still optimising for convenience over control.

Teams that already struggle with service-account visibility should treat this article as a warning sign, especially when hybrid estates spread identity decisions across multiple platforms. That is where the combination of least privilege and lifecycle governance becomes operational rather than theoretical.

For practitioners

• Separate authentication controls from authorization reviews Map where identity proofing ends and access policy begins, then test each boundary independently. A strong login flow does not justify broad group membership, inherited roles, or permissive application scopes. Use the review cycle to find where access remains valid long after the proofing event that created it.
• Reduce trust in claimed identity during recovery and enrolment Treat account recovery, device re-enrolment, and step-up access as high-risk events because attackers often target those paths when primary authentication is hardened. Require stronger proofing for changes that re-establish trust in a subject.
• Apply least privilege to human and machine identities together Do not let separate teams maintain different privilege standards for employees, service accounts, and API-connected workflows. The article’s core lesson is that access scope, not just login method, determines how far compromise can spread.
• Re-authorize access at sensitive boundaries Use step-up checks for sensitive actions, privileged paths, and high-impact data access instead of assuming an authenticated session should remain trusted. That is the practical expression of zero trust in an IAM programme.

Key takeaways

• Identity management fails most often at the seam between proving identity and deciding access, not at login alone.
• The scale of the problem is visible in NHI governance gaps, with service-account visibility still extremely low in many organisations.
• IAM teams should tighten identity proofing, narrow entitlements, and re-authorize sensitive actions if they want zero trust to contain real attacks.

Key terms

• Identity proofing: Identity proofing is the process of establishing that a person or subject really is who they claim to be before the system creates or renews trust. It combines evidence, verification, and policy so credentials are not treated as proof by themselves. In IAM, it is the first gate that reduces fraud and recovery abuse.
• Claimed identity: Claimed identity is the identity a subject presents to a system, usually through a username, credential, or biometric signal. It is an assertion, not a guarantee. Security programmes fail when they confuse a presented claim with verified truth and then allow that claim to drive access decisions too broadly.
• Actual identity: Actual identity is the verified person or subject behind the credential or session. It is the evidence-backed answer to whether the claimant is legitimate. In mature IAM design, actual identity matters because access should rest on proof, not on the mere possession of a password or token.
• Zero trust: Zero trust is an operating model that assumes access must be verified continuously instead of being trusted because a subject is already inside the environment. It limits implicit trust, re-checks sensitive actions, and reduces blast radius when identities are stolen or abused. In practice, it only works when access scopes are tightly bounded.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by 1Kosmos: Identity management, IAM, and future-proof authentication. Read the original.