What should teams do when onboarding tasks fall outside IAM?

Separate onboarding work from identity administration

When onboarding tasks fall outside IAM, teams should treat them as fulfilment work with their own owner, queue and evidence trail. The useful test is whether the task changes identity, access or privilege; if it does, it belongs back in IAM. If it does not, it should stay with the operational process that can actually execute it.

That separation matters because onboarding often mixes physical, technical and access steps in one request. Device preparation, software installation, asset allocation and shipping can be managed by operational teams, while account creation, MFA enrolment and privileged access remain tied to identity controls. Keeping that boundary explicit prevents IAM from becoming a catch-all service desk.

Clear ownership also avoids control drift. If a non-IAM task is routed through an identity workflow without a real access decision, teams can lose traceability over who approved what, which evidence was captured and where exceptions were handled.

Draw the boundary around access, not around the ticket

The cleanest split is usually by decision type, not by department label. If the step issues, changes or revokes access, it is an IAM decision. If the step prepares equipment, installs software or fulfils logistics, it is an operational onboarding decision. The ticket may be shared, but the control owner should not be.

That distinction becomes easier to manage when teams use a single intake form with routing rules, rather than allowing every onboarding request to land in the IAM queue. A request can then branch into identity work, fulfilment work or both, with each branch recording its own completion evidence.

For broader identity governance, it helps to align this boundary with the lifecycle model already used for IAM and IGA Basics, so onboarding does not become a shadow process that bypasses entitlement governance.

Keep exceptions visible and reversible

Exceptions are inevitable when access is needed before the rest of onboarding is finished. The right response is not to force every out-of-band step through IAM, but to define an exception path that returns the access element to IAM review. That keeps temporary access, elevated access and provisional credentials from becoming permanent by accident.

Teams should also preserve enough evidence to reconstruct the decision later: who asked, who approved, what was provisioned, when it happened and what follow-up remains open. If the request touches accounts, roles or credentials, the evidence standard should match the level of privilege involved.

That is why lifecycle discipline matters in onboarding and offboarding alike, and why the same process lens should be applied to Joiner-Mover-Leaver (JML) Guide wherever access changes are part of the transition.

Risk and Threat Considerations

When onboarding and IAM are blended too loosely, the main risk is control ambiguity. A request can be fulfilled without anyone clearly owning the access decision, which makes it easier for excessive access, orphaned access or unreviewed exceptions to persist. That is also where audit gaps appear, because operational completion does not automatically prove that access was correctly governed.

Failure mechanism: The workflow treats fulfilment completion as evidence of secure onboarding, even when the access decision was never reviewed, recorded or reversed after a temporary exception.

Impact: Privilege can be granted or retained without proper review, creating exposure for misuse, delayed revocation and weak accountability across the onboarding lifecycle.

Practitioner Guidance

What to prioritise: Define the handoff rule first. Every onboarding step should resolve to one of three outcomes, fulfilment only, IAM only, or a split workflow with explicit ownership for each branch.

What to verify: Confirm that every exception path has a return point into IAM whenever access, credentials or privileged roles are involved, and that the evidence set is sufficient to reconstruct the decision later.

Common mistake: Treating the service desk or onboarding portal as the control owner for everything. That usually hides whether the real risk is operational delay or improper access administration.

Practitioner takeaway: The goal is not to move all onboarding into IAM, but to make sure IAM owns access decisions and other teams own everything else, with no gray zone in between.

Related resources from NHI Mgmt Group

• Who is accountable when disconnected applications fall outside IAM and IGA coverage?
• What should teams do when long-tail applications fall outside normal IAM coverage?
• Who is accountable when nonstandard applications fall outside IAM governance?
• What breaks when healthcare IAM is managed as separate onboarding, access, and offboarding tasks?