What breaks when IAM stops at authentication and provisioning?

When authentication works but access control does not

Authentication proves a subject is real, but it does not answer the harder question of whether that subject should still have the permissions it holds. IAM becomes brittle when teams equate successful sign-in with effective control, because access can remain valid long after the original business need has changed. That gap is where entitlement creep, inherited privilege, and stale access accumulate.

This is why access governance has to sit alongside sign-in control. A user can authenticate cleanly through an identity provider and still retain unnecessary roles, direct grants, shared group membership, or exception-based access that no longer matches their function. If review activity only checks whether accounts exist, it misses whether the access remains justified.

As a result, teams should distinguish authentication state from authorization state. The first answers whether the actor can present acceptable proof; the second answers what that actor may do now, in this environment, for this business purpose. When those are blended together, control reports look healthy even while permissions drift away from policy.

Where entitlement drift comes from

Entitlement drift usually appears when provisioning is treated as a one-time event instead of part of a continuous lifecycle. Roles change, projects end, exceptions linger, and automation keeps old access in place because nobody closes the loop. The problem is not just excess permissions, it is the absence of a reliable mechanism to remove access when the business condition that justified it has disappeared. IAM and IGA Basics is a useful reference point for the difference between initial provisioning and ongoing access governance.

That drift is often amplified by role design. Coarse roles, shared entitlements, and fallback access paths make it easy to get work done quickly, but they also make it harder to prove least privilege later. Once permissions are inherited through groups or nested roles, reviewers often see a technically valid grant chain without a clear explanation of why the access is still necessary. Joiner-Mover-Leaver (JML) Guide covers the lifecycle controls that prevent old-role access from surviving role changes and exits.

The practical consequence is that provisioning without review creates a growing gap between policy and reality. The account may still be active, but the entitlement model no longer reflects the current job, system boundary, or risk tolerance. Once that happens at scale, the organisation loses confidence not just in access decisions, but in the evidence used to justify them.

Why audit evidence gets weaker when access is not recertified

Auditors and control owners do not just want to know that an account exists. They want a defensible answer to why a specific user or service still holds a specific permission. If IAM only records successful authentication and the original provisioning event, it leaves a weak trail for later review, especially when permissions were added through exceptions, temporary escalation, or inherited roles.

That is where access recertification matters. Reviewers need evidence that access was periodically revalidated, that exceptions were time-bounded, and that removals were actually enforced. Ultimate Guide to NHIs, Regulatory and Audit Perspectives is relevant because the same audit logic applies whether the identity is human or non-human: the control must show ownership, justification, and timely removal of stale access.

The strongest evidence is not a sign-in log. It is a record that ties access to an approved business need, a role or policy basis, a review outcome, and a removal path when that basis changes. Without that chain, IAM produces an identity inventory, but not a control story. In practice, that is why teams struggle to answer the simplest audit question: why does this access still exist?

Risk and Threat Considerations

When access outlives its justification, the risk is not theoretical. Stale or excessive permissions expand blast radius, make lateral movement easier after compromise, and increase the chance that an otherwise routine account becomes a path to sensitive systems or data. In mature environments, the attacker does not need to defeat authentication if they can abuse valid, over-retained access.

Failure mechanism: provisioning creates access, but no reliable lifecycle control removes or revalidates it, so access remains even after the job, project, or risk basis has changed. Reviewers then see a legitimate identity with permissions that are technically valid but no longer justified.

Impact: entitlement creep, privilege accumulation, weaker separation of duties, and audit evidence that cannot clearly explain why access is still held. That increases both security exposure and the cost of proving control effectiveness during review or incident response.

Practitioner Guidance

What to verify: Treat every privileged or sensitive entitlement as needing a current justification, not just a valid account. If you cannot tie a permission to a role, owner, expiry condition, or exception record, you do not have evidence of control, only evidence that provisioning happened.

Decision rule: If the control view shows authentication success but cannot explain ongoing access need, prioritise entitlement review and removal over account status checks. The question is not whether the identity can log in, but whether the permissions still match today’s operational reality.

What good looks like: Access changes are time-bound, recertified on a predictable cadence, and removed when the business need ends. Reviewers can trace each sensitive permission back to an owner, a rationale, and a removal decision if the justification no longer holds.

Practitioner takeaway: IAM is incomplete when it stops at entry control; durable assurance comes from proving that access remains justified after the identity has been authenticated and provisioned.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Where does cross-environment agent discovery fit in an IAM programme?
• When should organizations consider updating their IAM frameworks?