IAM implementation still fails when governance is treated as setup

At a glance

What this is: This is a practical guide to implementing identity and access management, with a strong emphasis on strategy, controls, and continuous governance.

Why it matters: It matters because IAM implementation affects human access, non-human identities, and privilege governance across the full identity surface, not just login flow.

👉 Read Zluri's guide to implementing identity and access management

Context

Identity and access management implementation is the process of turning policy into enforceable access control across users, systems, and services. The article frames it as a lifecycle problem, but the real challenge is that most organisations still treat IAM as a deployment project rather than a governance system.

That matters because access decisions do not stop at human users. The same implementation model has to govern service accounts, API-driven workflows, and privileged access, or it leaves gaps between onboarding, certification, rotation, and offboarding.

For teams building an identity programme, the useful question is not whether IAM exists, but whether it can actually maintain least privilege, auditability, and change control as the environment scales. For broader NHI context, see the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide.

Key questions

Q: How should security teams implement IAM without creating privilege creep?

A: Start with a clean identity inventory, then define narrow roles, approval paths, and recertification triggers before rollout. If access reviews do not remove stale entitlements, the programme will simply automate sprawl. The strongest implementations connect provisioning, certification, and offboarding so that privilege shrinks when business need ends.

Q: Why do IAM programmes fail when they focus only on authentication?

A: Authentication proves who or what is asking, but it does not control what that identity can do after login or token issuance. IAM fails when organisations stop at sign-in and ignore authorisation, lifecycle management, and auditability. That gap leaves privilege persistence untouched, which is where most practical risk accumulates.

Q: What breaks when access reviews are not linked to lifecycle change?

A: Reviews become paperwork instead of control. If role changes, vendor changes, and service retirement do not trigger entitlement checks, stale access stays active and teams lose visibility into privilege drift. The result is a programme that looks governed on paper while actual access remains overextended.

Q: Who should own IAM governance in practice?

A: IAM governance should sit with identity, security, and application owners together, because each owns a different part of the access lifecycle. Security defines the control standard, application teams understand entitlement need, and identity teams enforce the process. Without shared accountability, access reviews and deprovisioning lose force.

Technical breakdown

Identity and access management implementation as a control system

IAM implementation is not just about selecting a platform. It is the process of defining identities, mapping privileges, enforcing authentication and authorisation, and maintaining accountability over time. A useful implementation model separates identity management, access management, and governance so that each control can be tested independently. That distinction matters because many failures come from gaps between those layers rather than from the absence of login controls. When onboarding, role changes, and offboarding are not tied to governance, access persists longer than intended and privilege creep becomes invisible.

Practical implication: design IAM as a governed control system, not a one-time deployment.

Least privilege, JIT access, and access certification

The article correctly links IAM value to least privilege, just-in-time access, and automated access reviews. These controls only work when entitlement scope is tightly defined and certification cycles are tied to actual business change. Least privilege is a provisioning standard, JIT is a duration standard, and access certification is a verification standard. If any one of them is weak, the others become compensating theatre. In practice, overbroad roles and stale permissions turn automation into faster overexposure rather than better control.

Practical implication: enforce narrow entitlements first, then layer JIT and certification on top.

Monitoring, logging, and identity governance in daily operations

Implementation is only durable if it includes continuous monitoring, logging, and periodic review. IAM controls fail when organisations assume the job ends after rollout, because identity risk changes every time applications, vendors, or staff roles change. Governance also depends on evidence: audit trails, access change logs, and review outcomes. That evidence becomes the basis for compliance and for detecting misuse of privilege. Without it, IAM is difficult to prove, difficult to tune, and difficult to defend in audit or incident response.

Practical implication: treat monitoring and auditability as core IAM controls, not optional reporting.

Threat narrative

Attacker objective: The objective is to obtain durable, over-permissioned access that survives normal business change and creates room for misuse or lateral movement.

1. Entry begins when identities are created or connected without a complete view of the applications, users, and services that will consume access.
2. Escalation occurs when overly broad permissions, weak certification, or missing offboarding allow access to persist beyond its intended business purpose.
3. Impact is realised through unauthorized resource access, compliance failure, or a widened attack surface that adversaries can exploit later.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

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

NHI Mgmt Group analysis

IAM implementation fails when governance is treated as a project milestone instead of a continuous control. The article presents implementation as a sequence of steps, but identity control only works when inventory, policy, and review are maintained after go-live. That is why onboarding, recertification, and offboarding must be connected as one operating loop, not separate tasks. Practitioner conclusion: treat implementation success as sustained control integrity, not initial rollout.

Identity blast radius is the real measure of IAM maturity. The article stresses least privilege and access control, but the more important question is how far a single identity can move when controls are loose. Overbroad roles, weak certification, and slow deprovisioning expand the blast radius across applications and services. Practitioner conclusion: reduce the amount of access any identity can accumulate before you add more automation.

Machine identity governance belongs inside IAM implementation, not beside it. The article speaks mostly about users, but the same logic applies to service accounts, tokens, and API-driven access. Once those identities are ignored, auditability and least privilege become partial controls that cover only humans. Practitioner conclusion: if implementation excludes non-human identities, the programme is structurally incomplete.

Access review cadence only matters when it is tied to real lifecycle change. The article highlights access certification, yet review cycles that do not align with role change, vendor change, or service retirement will not catch stale privilege. That creates a false sense of control because the paper trail exists even when entitlement hygiene does not. Practitioner conclusion: align reviews to change events, not calendar convenience.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, which shows the governance gap is already material.
• Follow the lifecycle angle in the NHI Lifecycle Management Guide when IAM implementation needs to cover provisioning, rotation, and offboarding as one control loop.

What this signals

Identity programmes are moving from access administration toward access assurance. That shift matters because implementation checklists are no longer enough when identity sprawl includes users, service accounts, and delegated application access. Teams should expect their IAM roadmap to be judged by how well it reduces standing privilege and proves control effectiveness, not by how many workflows are automated.

Identity blast radius will become the most useful design metric for IAM governance. If access reviews, JIT, and monitoring do not shrink the amount of damage one identity can cause, the implementation is only cosmetically mature. The strongest programmes will connect role design, lifecycle triggers, and audit evidence so that governance works after deployment, not just during rollout.

As non-human access grows, identity teams will need to align IAM implementation with lifecycle management resources such as the Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs and standards like the NIST Cybersecurity Framework 2.0. That combination gives security leaders a practical way to move from policy intent to operational proof.

For practitioners

• Map every identity type before selecting controls Inventory human users, service accounts, application identities, API tokens, and privileged accounts separately so that control design reflects how each identity actually behaves.
• Tie access reviews to lifecycle events Trigger certification after role changes, vendor changes, system retirement, and offboarding so reviews test real entitlement drift instead of only calendar timing.
• Separate provisioning from duration control Use least privilege to narrow standing access, then use JIT access to constrain how long elevated permissions remain active.
• Treat audit evidence as a control output Keep access logs, change records, and review outcomes in a form that can support incident investigation, compliance checks, and entitlement cleanup.

Key takeaways

• IAM implementation fails when governance is treated as a one-time deployment rather than a continuous operating model.
• Least privilege, JIT access, and access certification only work together when entitlement scope and lifecycle change are tightly controlled.
• Programmes that exclude machine identities leave a structural gap in auditability, accountability, and access reduction.

Key terms

• Identity Governance: Identity governance is the discipline of making access decisions visible, reviewable, and enforceable across the full identity lifecycle. It combines policy, certification, offboarding, and audit evidence so organisations can prove that access remains aligned to business need and risk.
• Least Privilege: Least privilege means granting each identity only the minimum access needed to complete a task. In practice, it is not a slogan but a design constraint that must be reflected in roles, exceptions, certification, and expiration handling across human and machine identities.
• Just-in-Time Access: Just-in-time access is a temporary access pattern that provisions elevated privilege only when it is needed and removes it when the task ends. It reduces standing exposure, but only if duration limits, approval logic, and revocation are reliably enforced.
• Access Certification: Access certification is the process of reviewing entitlements to confirm they are still justified. It is most effective when tied to lifecycle events, because calendar-based reviews alone often miss role changes, vendor changes, and stale machine access.

Deepen your knowledge

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

This post draws on content published by Zluri: Access Management How to Implement Identity and Access Management? Read the original.