Why workforce IAM and CIAM no longer cover identity relationships

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Fischer Identity's blog post: Relationship-aware identity programmes should govern changing relationships, not just separate workforce and customer accounts.

Why it matters: It matters because IAM, IGA, PAM and NHI teams have to control access as relationships change across human and non-human identities, not after categories drift apart.

Context

Workforce IAM and CIAM were built for a world where identity populations looked cleaner than they do now. The problem is not just more identity types, but more relationship states, with one person or entity moving through applicant, employee, customer, contractor, partner, guest, service account or AI agent contexts over time.

That makes the real governance question less about which silo owns the account and more about what relationship currently justifies access. When lifecycle state changes, access should change with it, otherwise organisations accumulate entitlement drift, orphaned relationships and fragmented governance across human and non-human identities.

Key questions

Q: How should security teams govern access when identities move between employee, customer and partner states?

A: They should govern the relationship state, not just the account label. When a person moves between employee, contractor, customer or partner relationships, the access rules, approvals and review cadence should change with that relationship. If the programme cannot express overlapping or sequential relationships, it will drift into fragmented entitlement management.

Q: Why do separate workforce and CIAM systems create governance gaps?

A: Because separate systems often lose the enterprise view of which relationships are active, which access rights were granted for each one and which relationship actually owns the account. That fragmentation makes lifecycle changes harder to enforce and leaves organisations relying on manual reconciliation instead of policy-driven governance.

Q: What should organisations do first when identity categories no longer match business reality?

A: Start by identifying the relationship types that exist across the organisation, then map which access rights each relationship justifies and who owns each one. Once that inventory exists, lifecycle actions can be tied to relationship change instead of treated as isolated account events.

Q: What is the difference between account-centric identity and relationship-aware identity?

A: Account-centric identity treats the login or record as the thing to manage. Relationship-aware identity treats the business relationship behind the identity as the source of authority, so access is governed by purpose, duration, ownership and change state rather than by category alone.

Technical breakdown

Why account-centric identity models break down

Account-centric IAM treats the record as the object of control. Relationship-aware identity treats the relationship as the control surface. That distinction matters because access is usually granted for a purpose, a role or a sponsorship condition, then left behind when the underlying relationship changes. In practical terms, a person can carry multiple concurrent or sequential relationships, and each one can justify different access rules. When organisations split workforce, CIAM, partner, guest and NHI handling into separate systems, they make it harder to answer a basic governance question: what does this identity mean right now?

Practical implication: design governance around relationship state, not around whether an identity sits in the workforce or CIAM stack.

How lifecycle changes create entitlement drift

Lifecycle is the mechanism that turns identity from a static label into a governed state. Joiner, mover and leaver events are only part of the picture; the article also points to relationship additions, overlaps, suspensions and expirations across roles such as student, contractor, vendor, donor, service account owner or AI agent sponsor. If those lifecycle transitions do not trigger access modification, certification, ownership validation and deprovisioning, entitlement drift builds quietly across the estate. The result is not just excess access, but access that no longer matches the relationship that originally justified it.

Practical implication: map each relationship change to a required access outcome and eliminate manual exception paths.

Why non-human identities need the same relationship lens

Service accounts, workloads and AI agents are not people, but they still exist inside a relationship model. Each one has a purpose, an owner, a lifecycle and a boundary of acceptable access. That means governance cannot stop at human IAM or CIAM constructs. When an organisation treats NHI as technical plumbing rather than governed relationships, ownership becomes unclear, offboarding becomes inconsistent and accountability weakens over time. The article's core point is that lifecycle control must apply to the subject of access, whether that subject is a person or a machine.

Practical implication: require ownership, purpose and expiry for every non-human identity, then review those relationships as part of normal governance.

NHI Mgmt Group analysis

Relationship, not account, is the correct unit of identity governance. Workforce IAM and CIAM are useful categories, but they are too coarse to describe how modern access actually behaves. A person or system can hold multiple roles over time, and each role changes the meaning of the identity record. The governance consequence is that access must be evaluated against current relationship state, not the presence of an account.

Identity silos create lifecycle blind spots that look like operational complexity but behave like control failure. When employee, customer, partner, guest, privileged access and NHI workflows are managed in separate platforms, organisations lose the ability to answer who owns the relationship, when it ends and what access remains justified. That fragmentation turns routine lifecycle change into manual work and leaves stale access in place.

Every non-human identity should be governed as a relationship with an owner, purpose and expiry. Service accounts, workloads and AI agents do not become less important because they are not human. They become more dangerous when ownership and lifecycle context are unclear. The practical implication is that NHI governance should follow the same relationship logic as human IAM, not a separate exception model.

Relationship-aware identity is the right operating model for continuous governance across human and non-human estates. The article's real contribution is not a new category, but a better abstraction for control. It gives IAM, IGA and NHI programmes a common way to reason about provisioning, certification and removal without collapsing every use case into a separate silo. That is the model practitioners need to scale governance without creating more identity fragmentation.

Code-free lifecycle logic becomes strategic when relationship complexity is the norm. The more business rules are embedded in custom scripts and connector logic, the harder it becomes to keep relationship state aligned with access state. Configuration-led governance matters because identity programmes need to adapt to changing relationships faster than bespoke workflow code can reliably support.

What this signals

Relationship-aware identity: Identity governance needs a common model for people, services and AI agents because lifecycle change is now the normal state, not the exception. That means programmes should stop optimising for category boundaries and start optimising for relationship state, ownership and expiry across the full identity estate.

As identity estates become more fluid, the old split between workforce IAM and CIAM becomes less useful as an operating model and more useful only as a procurement label. Practitioners should expect governance pressure to move toward continuous lifecycle control, because periodic reviews do not describe how access changes when relationships overlap or end.

For practitioners

• Map identities by relationship state Inventory the relationship types your organisation actually governs, such as employee, customer, contractor, vendor, service account and AI agent, then define the access rules tied to each state.
• Tie lifecycle events to access outcomes Require provisioning, deprovisioning, access modification and certification triggers when a relationship starts, changes, pauses or ends, rather than relying on periodic cleanup.
• Assign an accountable owner to every identity For each human and non-human identity, record who sponsors it, who approves it and who is responsible when the relationship changes or expires.
• Remove custom workflow dependence where possible Replace brittle scripts and ticket-driven exceptions with configurable identity logic so relationship changes can be governed consistently across systems.

Key takeaways

• Modern identity programmes fail when they treat workforce, customer and non-human accounts as separate governance problems instead of as changing relationships.
• The article's central warning is that lifecycle state, ownership and expiry now matter more than the legacy category attached to an identity.
• Practitioners should align provisioning, review and offboarding to relationship change, or they will keep creating access that outlives its justification.

Key terms

• Relationship-Aware Identity: Relationship-aware identity is an identity model that treats each identity as part of a governed relationship with an owner, source, purpose, lifecycle state, and access boundary. It is especially useful in complex environments where employees, contractors, workloads, service accounts, and AI agents need different control patterns.
• Lifecycle State Management: Lifecycle state management is the process of moving an identity through defined statuses such as approved, active, suspended, and retired. For AI agents, the state determines whether the agent can act, and every transition should be tracked so access and accountability stay aligned over time.
• Entitlement Drift: Entitlement drift is the slow accumulation of permissions that no longer match the original purpose, role, or workload. In cloud-native and NHI-heavy environments, it usually happens because access changes faster than review cycles, leaving organizations with more privilege than they intended.
• Identity Fragmentation: Identity fragmentation is the condition where different parts of an infrastructure estate use separate trust models, credentials, and policy systems. In hybrid environments, this breaks unified governance because access, logging, and revocation no longer line up across cloud, data center, and colocated resources.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.