They should do it whenever device assignment, software entitlement, or offboarding decisions are automated. If asset workflows can create or remove access, the ITAM process has become part of the identity governance chain.
When ITAM Becomes Part of Identity Governance
ITAM should be evaluated as part of IGA when the asset process can change who can use a device, application, or licence in practice. If assigning hardware, provisioning software, or reclaiming assets also creates, modifies, or removes access, then the asset workflow is no longer just inventory management. It is governing entitlements and must be treated like an identity control.
That boundary matters because many organisations still separate asset ownership from access ownership, even though the same workflow often drives both. A laptop issue can trigger authenticated access, a software install can grant application capability, and decommissioning can leave behind standing access if the entitlement is not removed at the same time.
For that reason, the most useful question is not “is this ITAM or IGA?” but “does this asset event alter authority?” If the answer is yes, the workflow needs identity review points, approval rules, and an auditable handoff between asset and access states.
Where the ITAM and IGA Boundary Breaks Down
The boundary usually breaks down in joiner, mover, and leaver activity. Onboarding often couples device issuance with access grants, while offboarding must revoke both the asset and the associated access paths. If those steps are separated, the organisation can end up with orphaned software entitlements, stale device trust, or accounts that still authenticate after the asset is removed.
Entitlement packaging is another common crossover. Software licences, managed devices, VPN access, endpoint posture exceptions, and privileged tool access are often delivered together. In that setup, ITAM is not just recording what was issued, it is shaping the effective access profile of the user or service.
Good governance therefore depends on seeing asset assignment as part of the identity lifecycle, not as a downstream administrative record. That is especially true where devices are pre-approved for sensitive applications, where return-of-asset events should trigger revocation, or where licence removal should also remove the access that licence enabled.
For a practical identity-governance view of those lifecycle linkages, IAM and IGA Basics is the best starting point. Where the lifecycle is the main issue, Joiner-Mover-Leaver (JML) Guide shows how asset and access changes should stay coupled through onboarding, transfer, and exit events.
What Teams Should Evaluate Before Deciding the Control Owner
The decision point is ownership. If an ITAM control only records asset location or warranty status, it can stay with operations. If it assigns access, recertifies software eligibility, or triggers deprovisioning, then identity governance must own or co-own the control design.
Teams should also test for closed-loop removal. The right design is not just “asset returned” or “ticket closed”, but “asset returned and all entitlements linked to that asset were revoked or revalidated.” Where that closure does not exist, the asset process is incomplete from a governance perspective.
When the workflow includes reviews, use evidence that shows both sides of the chain: the asset event and the resulting access change. If you cannot show that a reclaim, transfer, or offboard action removed the relevant entitlement, the control is still fragmented.
Where entitlement review is part of the process, Access Reviews and Certification Guide is useful because it treats removal as the objective, not just review completion. Where asset actions also affect role structure and SoD outcomes, Segregation of Duties (SoD) Guide helps teams avoid creating conflicting access through asset-driven exceptions.
Risk and Threat Considerations
When ITAM drives access, weak linkage between asset state and entitlement state creates residual access risk. The usual failure is simple: a device is reissued, a licence is removed, or a user leaves, but the access path tied to that asset remains active.
Failure mechanism: Detached asset and access workflows leave stale entitlements, orphaned software access, or reused devices that still trust the previous user or environment.
Impact: Unauthorised access can persist after offboarding, privileged tools can remain reachable, and auditors may see a governance gap between the asset record and the actual access posture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Asset-driven access often depends on credential lifecycle and revocation. |
| AC-2 — Account Management | ITAM-linked workflows can create or remove access tied to accounts and entitlements. | |
| AC-6 — Least Privilege | Asset assignment should not create broader access than the task requires. | |
| Recommendation — Tie asset offboarding to credential and token revocation. Synchronize asset events with account provisioning and deprovisioning. Limit entitlements granted through asset workflows to the minimum necessary. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Asset workflows that affect access belong in identity management governance. |
| A.5.18 — Access rights | Asset issuance and recovery can alter access rights that must be controlled. | |
| Recommendation — Define ownership for asset-triggered identity and entitlement changes. Review and revoke access rights when asset status changes. | ||
| CIS Controls v8 | CIS-5 — Account Management | Asset-linked provisioning and offboarding affect account and entitlement control. |
| Recommendation — Map asset lifecycle events to account lifecycle actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Offboarding assets without removing linked access leaves residual non-human access risk. |
| NHI-05 — Overprivileged NHI | Asset workflows can create excessive access if entitlements are bundled loosely. | |
| Recommendation — Ensure asset decommissioning revokes all linked access. Audit asset-granted access for excess privilege before approval. | ||
Practitioner Guidance
What to verify: Confirm whether each asset event has a corresponding access outcome, including creation, transfer, suspension, and removal. If the workflow cannot prove that a device handoff or software change updated entitlement state, treat it as an identity control gap rather than an ITAM housekeeping issue.
Decision rule: If an asset workflow can create, modify, or remove access, move it into the IGA operating model with explicit approvals, evidence, and recertification. If it only tracks physical or financial asset attributes, keep it outside identity governance.
Practitioner takeaway: The test is not whether ITAM and IGA overlap in theory, but whether the asset process changes effective access in practice. When it does, the control must be governed as part of the identity chain.