What is the difference between provisioning accounts and managing authorisation in IAAM?

Why provisioning and authorisation are different controls

Provisioning is the setup step, it creates the account, roles, groups, and baseline entitlements a person or system needs to begin work. Authorisation is the control step that keeps those permissions appropriate after the account exists. One answers “should this identity be able to start?”, the other answers “should it still be able to do this now?”

This distinction matters because access that was correct on day one can become excessive after a move, role change, project end, or exception. A control design that treats provisioning as the whole job usually misses privilege drift, stale access, and unchanged entitlements that outlive the business need that justified them.

What provisioning does in an IAAM lifecycle

In IAAM, provisioning is the lifecycle action that turns an approved request, joiner event, or system need into a working account and the minimum access structure needed to perform a role. It is where identity data, account creation, role assignment, and initial access paths are established so work can begin with the right baseline.

The quality test for provisioning is not only whether the account exists, but whether it is created from a trusted source, mapped to the right owner, and aligned to a defined access model. IAM and IGA Basics is useful here because it separates identity setup from ongoing access governance and shows why provisioning alone does not close the control loop. A provisioning process without ownership, role design, or joiner-mover-leaver discipline tends to create accounts faster than it creates control.

For non-human accounts, the same idea applies to services, workloads, and automation. The account should exist because a workload needs it, not because someone manually created a reusable access path and left it in place. That is why lifecycle management, not just account creation, is the real control boundary. Joiner-Mover-Leaver (JML) Guide reinforces the point that provisioning and deprovisioning have to be treated as one lifecycle, especially when access must change as duties change.

What authorisation controls after access exists

Authorisation governs whether the access already granted remains justified, and it does so continuously. In practice, this includes access reviews, entitlement recertification, policy evaluation, SoD checks, exception handling, and removal of privileges that are no longer needed. It is the mechanism that answers whether the existing access still matches the current job, task, or operating condition.

That makes authorisation materially different from provisioning even when the same systems are involved. Provisioning is event-driven and often approval-driven; authorisation is state-driven and must keep pace with role drift, control exceptions, and business change. Authorisation Models Guide is the clearest companion for this distinction because it covers how RBAC, ABAC, ReBAC, and policy-based access control decide access at runtime, not just at onboarding.

That is also why role design matters after provisioning. If roles are too broad, the authorisation process ends up rubber-stamping inherited access instead of genuinely evaluating need. Role Mining and Role Design Guide supports this point by showing that a clean role model reduces review noise and makes reauthorisation more meaningful.

How the two controls work together in a practical IAAM design

A useful IAAM program does not choose between provisioning and authorisation, it sequences them. Provisioning gives the identity a controlled start, then authorisation keeps checking whether that access still belongs. When those steps are separated, teams can automate onboarding without losing the ability to challenge stale access later.

The practical risk is to let provisioning become the “success metric” and authorisation become a paperwork exercise. Good design ties the two together with ownership, recertification, and revocation so that changes in role, project, or employment state actually remove access. IAM and IGA Basics and the Joiner-Mover-Leaver (JML) Guide both support this lifecycle view: create access only with a clear business basis, then revalidate or remove it when that basis changes.

Risk and Threat Considerations

When provisioning and authorisation are treated as the same thing, accounts tend to remain active after the original business need disappears. That creates stale access, privilege creep, and a larger blast radius if credentials are stolen or a role is misused.

Failure mechanism: An account is provisioned correctly at the start, but no effective authorisation review or removal process follows, so permissions accumulate or persist after duty changes, project end, or offboarding.

Impact: Excess access can enable unauthorized actions, make segregation-of-duties conflicts harder to spot, and increase the damage from account compromise, especially where broad entitlements or shared access paths exist.

Practitioner Guidance

What to prioritise: Separate your controls operationally. Treat provisioning as the creation of a bounded starting state, then require periodic reauthorisation, mover-based access changes, and explicit removal paths for leavers and abandoned access.

What to verify: Check that every privileged or business-critical entitlement has an owner, a review cadence, and a revocation path. If you cannot show who reapproved it, when, and under what condition, the access is probably being managed as a one-time setup rather than a living control.

Practitioner takeaway: Provisioning answers how access begins, authorisation answers whether it still deserves to exist; the mature design is the one that makes those two decisions independent, testable, and tied to lifecycle change.

Related resources from NHI Mgmt Group

• What is the difference between managing human accounts and non-human identities?
• What is the difference between managing service accounts and managing AI agents?
• What is the difference between managing user accounts and managing NHIs?
• What is the difference between managing accounts and managing relationships?