Because a person can have multiple valid states at once, and one relationship ending does not necessarily invalidate the others. If IAM collapses those states into a single account model, offboarding becomes overbroad or incomplete. The control challenge is to preserve valid access from one relationship while removing only the access tied to the ended one.
Why overlapping identity states create access risk
Overlapping identity relationships create risk because access is rarely tied to just one real-world context. A single person can simultaneously be an employee, contractor, approver, administrator, or customer, and each relationship may confer different entitlements. If the identity model treats those relationships as one flat account, removal becomes imprecise: too broad and valid access is broken, too narrow and residual access remains.
That is why offboarding, role change, and exception handling are where the risk becomes visible. The security problem is not the existence of multiple relationships, but the failure to represent them separately enough to revoke the right privileges without disturbing unrelated ones.
How identity overlap turns into privilege and lifecycle failure
Overlapping relationships matter most when the access model cannot distinguish the source of each entitlement. A person may hold access because of a job role, a project assignment, a vendor relationship, or a temporary elevation. When one relationship ends, the system must remove only the entitlements that came from that path. If it cannot trace provenance, teams often compensate with manual cleanup, which is slow and easy to get wrong.
This is where lifecycle discipline matters. IAM and IGA Basics is useful here because the core issue is not just provisioning, but entitlement attribution, access review, and joiner-mover-leaver handling across multiple roles and populations. The same applies to broader lifecycle management: NHI Lifecycle Management Guide reinforces the same control principle for any identity whose privileges must change independently of other relationships.
In practice, overlap creates three failure modes. First, an account is left alive after one relationship ends because another still appears valid. Second, a cleanup action removes too much and interrupts legitimate work. Third, reviewers lose confidence in recertification because they cannot tell whether a permission belongs to the current relationship or a previous one. That is a governance problem as much as an access problem.
What good control looks like when one person has many relationships
The strongest control pattern is to separate identity, relationship, and entitlement. The person may be singular, but the access paths should be explainable by context: employer, supplier, project, environment, or delegated function. That lets you revoke one context while preserving the others. It also makes reviews more accurate, because you can ask whether each entitlement still has a live business reason rather than guessing from a merged account record.
For organisations still rationalising their model, the practical question is whether each relationship has its own join, move, and leave logic. If not, overlapping access will keep leaking into exceptions, shared accounts, or manual grant lists. Third-Party, B2B and Contractor Access Guide is relevant because external relationships often expose the same problem first: sponsorship ends, but some privileges linger because the underlying identity also serves another purpose. Identity Security Posture Management (ISPM) Guide is also a useful lens when teams need continuous visibility into stale, standing, or misattributed access.
That same distinction is why authorisation design matters. When access is expressed cleanly through roles, attributes, or relationship-based policies, revocation can be targeted. When access is granted ad hoc to the account itself, the organisation has no clean way to unwind one relationship without collateral damage.
Risk and Threat Considerations
Overlapping identity relationships create a residual-access problem that adversaries and insiders can both benefit from. The longer an account accumulates unrelated entitlements, the harder it is to prove that every privilege still has a valid owner and purpose. That increases the chance of orphaned access, privilege creep, and delayed revocation after a role change or offboarding event.
Failure mechanism: The identity layer cannot cleanly separate which privileges came from which relationship, so revocation logic either misses inherited access or removes access that still needs to exist.
Impact: Sensitive systems stay reachable after the original business need ends, and defenders lose confidence that offboarding and access review are actually reducing exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Identity overlap depends on controlled credential lifecycle and revocation. |
| AC-2 — Account Management | Multiple relationships create account lifecycle and offboarding risk. | |
| AC-6 — Least Privilege | Overlapping entitlements can accumulate excess access beyond current need. | |
| Recommendation — Track and revoke credentials by relationship so old access paths do not survive. Separate account lifecycle actions from relationship changes and remove only the matching access. Limit each relationship to the minimum permissions needed for that context. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is fundamentally about preventing inappropriate access from mixed relationships. |
| A.5.18 — Access rights | Overlapping relationships require precise granting and removal of rights. | |
| Recommendation — Define access rules that distinguish one relationship from another before revocation. Review and remove rights at the relationship level, not only at the account level. | ||
Practitioner Guidance
What to verify: Confirm that every significant entitlement can be traced to a relationship, sponsor, or policy source, not just to a person record. If you cannot explain why a permission exists in one sentence, assume the model is too coarse for safe revocation.
Decision rule: If a user can hold multiple valid roles at once, treat access removal as relationship-specific, not account-wide. Account-level deletion should be reserved for cases where all relationships truly end.
What practitioners underestimate: The hardest part is not initial provisioning, it is cleanly unwinding one relationship without harming the others. That is where merged accounts, shared entitlements, and weak ownership models create the most persistent risk.
Practitioner takeaway: Overlapping relationships are safe only when the access model preserves provenance, otherwise revocation becomes guesswork and guesswork is how valid access survives past its intended life.