TL;DR: IAM implementation has shifted from IT hygiene to a core business control that determines whether attackers can move freely or are stopped at the first login attempt, according to 1Kosmos. The real test is identity clarity, because access cannot be secured until organisations know who users are, what they need, and what they should never touch.
NHIMG editorial — based on content published by 1Kosmos: IAM implementation and why it matters
Questions worth separating out
Q: How should security teams implement IAM in hybrid environments?
A: Start by centralising policy while allowing enforcement to fit local system constraints.
Q: When does IAM implementation fail in practice?
A: It fails when organisations treat it as a login project instead of a governance programme.
Q: What do organisations get wrong about least privilege?
A: They often define least privilege at provisioning time and then assume it stays valid.
Practitioner guidance
- Inventory every identity class before changing controls. Map employees, contractors, service accounts, APIs, devices, and automation identities to owners, purposes, and critical systems so access rules reflect the real environment.
- Tighten assurance for high-risk access paths. Apply stronger authentication and identity proofing wherever privileged systems, sensitive data, or remote access create higher impact if compromised.
- Refactor roles before scaling federation. Review RBAC scope, remove role sprawl, and test whether ABAC inputs are reliable enough to support dynamic decisions in production.
What's in the full article
1Kosmos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step implementation sequence for identity proofing, authentication, authorisation, and lifecycle governance
- Practical guidance on choosing between cloud, on-premises, and hybrid deployment models
- Operational considerations for integrating SAML, OIDC, and FIDO into existing enterprise environments
- Measurement ideas for tracking onboarding time, password reset volume, and audit preparation effort
👉 Read 1Kosmos's guide to IAM implementation and business control →
IAM implementation: what it means for security teams now?
Explore further
IAM implementation is now a business control, not an IT hygiene exercise. The article is right to frame access as the point where attackers are either blocked or allowed to move. That makes identity governance a board-relevant control plane, especially where contractors, APIs, and non-human identities are in scope. The practitioner conclusion is simple: if access decisions are weak, every downstream security investment inherits that weakness.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
A question worth separating out:
Q: Who is accountable when IAM controls are weak?
A: Accountability sits with the business owner of the access decision, not just the identity team. IAM is a shared control plane across security, IT, application owners, and compliance functions. If access is excessive or revocation lags, the failure is usually governance, not configuration alone. Clear ownership is what turns IAM into a measurable control.
👉 Read our full editorial: IAM implementation is now a core security control