Enterprise identity is a continuing decision about who can do what

A finance manager approves an employee’s move into a new role. The new permissions arrive promptly, but the old purchasing rights remain. Nobody has failed to authenticate the employee. The organisation has failed to keep access aligned with the work it authorised.

For an IAM programme owner, that distinction defines the job. Identity is a continuing set of decisions about people, workloads and permissions. A reliable programme connects the business reason for access to the application result, including the awkward cases that sit outside the main directory.

A platform can carry a decision; it cannot invent the policy

Microsoft Entra entitlement management packages access with policies for approval, review and expiry. That is a useful mechanism for implementing a programme, but the organisation still decides who qualifies, what the package contains and when continued access is justified.

If a department cannot agree which roles should approve payments, configuring the identity platform will not resolve the disagreement. It may simply distribute an unclear policy more efficiently. Start with the applications where the consequence of excessive or missing access is easiest to explain, and give their owners an explicit role in the programme.

This is also why integration counts are an incomplete measure of progress. Connecting an application is useful when the connection makes a defined lifecycle or permission outcome more reliable. Connecting it only for login convenience addresses a narrower problem.

Choose a first improvement the business will recognise

Rather than launch every identity capability at once, select a recurring failure: contractors retaining access after project end, role changes leaving obsolete privilege, or recovery blocked by the main identity service. Map the source decision, application effect and unresolved handovers.

That creates a practical investment sequence. Fix the authority gap where policy is unclear, the integration gap where events do not propagate, or the evidence gap where nobody can confirm the result. The same platform purchase will not necessarily solve all three.

Separate the decisions hidden inside “access”

The NCSC introduction to identity and access management treats identity as a combination of policy, identity management, privileged access, architecture and ongoing operations. It is a useful foundation because it makes the programme broader than authentication alone.

For planning purposes, separate four questions: who or what is requesting access, how much confidence the organisation needs in that identity, which actions are permitted and when permission must change. Those questions may be answered by different systems, but they need a coherent owner.

Follow a person through a role change

Take a hypothetical employee moving from procurement to finance. Creating the new finance access is only half the work. The organisation must also decide which procurement permissions should end, which must remain temporarily and who can approve that exception.

A useful review traces the entire event: where the role change originates, which applications receive it, how failed updates are detected and how completion is confirmed. Do not treat a successful automation run as evidence that every downstream application removed access. Pick representative applications and inspect the resulting permissions.

The same discipline applies to contractors, temporary staff and automated workloads, but they may need different sponsors and lifecycle triggers. Avoid forcing every identity into an employee model simply because that is the model the current platform handles most conveniently.

Keep privileged access and recovery visible

Administration deserves explicit attention because its permissions can change the service itself. List the tasks that require elevated access, the people or workloads allowed to perform them and the evidence retained after use. Decide how urgent access is granted and how temporary permissions end.

Also ask what happens when the primary identity service is unavailable. A recovery procedure that requires the failed service to approve every administrator may be unusable. The answer is not an uncontrolled back door. Design and test a limited emergency process, with protected credentials or other appropriate mechanisms, named custodians and a review after use. Its exact implementation depends on the platform and threat model.

Measure the unresolved decisions

A useful IAM programme dashboard starts with unresolved work: which critical applications lack an accountable access owner, which leavers have unconfirmed revocation and which exceptions have passed their review date? These measures direct attention to work somebody can complete.

Raw login totals or the number of connected applications can provide context, but they do not establish that permissions are appropriate. Record coverage alongside any metric. A fast removal time measured across a small set of well-integrated applications should not be presented as an organisation-wide result.

Use a sampled end-to-end check to challenge the dashboard. Select a completed joiner, mover or leaver event and compare the intended outcome with application evidence. Where the two differ, repair the process and the reporting definition together.

Prepare for a platform decision

Build a short inventory of critical applications, authoritative identity sources, unusual user groups, privileged tasks and recovery requirements. This becomes the basis for a meaningful evaluation. It also exposes where a proposed replacement would reproduce the same operational gaps in a different interface.

The IAM platform evaluation guide turns that sequence into a supplier test. A clear programme gives the technology a job to do and the business a way to judge whether it has done it.