Treat the identity as a governed set of relationships, not a single role. Keep each relationship tied to its own source of authority, duration and entitlement scope, then recertify access against the active relationship instead of the person’s broad profile. That is how you preserve legitimate overlap without creating open-ended privilege.
How to treat one person with multiple active relationships
When one individual legitimately spans more than one business relationship, the IAM model should follow the relationship, not collapse everything into a single standing profile. That means each relationship keeps its own authority, expiry and entitlement boundary, so access can be reviewed against the current context that justified it. This is the cleanest way to preserve legitimate overlap without turning it into permanent privilege.
A single-person, multi-relationship setup is common in workforce, partner and contractor environments, but it becomes risky when teams use the person’s master record as the unit of decision. The safer pattern is to model each relationship as a governed access context with its own sponsor, purpose and lifecycle, then join those contexts only where the business truly requires shared access.
That approach also makes recertification more meaningful. If the person changes role, project, supplier status or employment status, you can revalidate each active relationship independently and retire only the entitlements that no longer have a live source of authority. The result is less over-revocation, less sprawl and better accountability for why any entitlement still exists.
Why the relationship, not the person, should drive entitlement
The practical mistake is to treat a person’s identity as if it were a single container for all access. In reality, entitlement is justified by a specific relationship: employee, contractor, board member, partner, temporary assignee, or other governed context. If two relationships coexist, they may legitimately create different access scopes, approval chains and review cadences.
This is where access governance and lifecycle discipline matter most. The person may remain the same, but the security decision changes when the relationship changes. A clean model lets teams keep those decisions separate instead of forcing awkward compromises such as broad role bundling, shared exceptions or indefinite extension of the “best fit” role after the original need has ended.
For teams managing this at scale, the right control plane is usually relationship-aware identity governance with clear source-of-authority mapping and periodic attestation. NHI lifecycle and access governance patterns are useful here because they force the same discipline for non-human and human contexts: define who owns the access, what the access is for, and when it should end. See NHI Lifecycle Management Guide for the lifecycle pattern, and Identity Security Programme Guide for operating-model governance.
How to prevent overlap from turning into excess privilege
Overlap is not the problem. Unbounded overlap is. If someone holds multiple active relationships, the access model must prevent one relationship from becoming a backdoor to the other. The key is to keep entitlements scoped to the narrowest valid purpose and to avoid inheriting access from the person’s broad profile unless that inheritance is explicitly justified.
That often means separating assignments, approvals and recertification evidence. One relationship may justify access to finance systems while another justifies access to a partner portal; those should not automatically merge into a general “trusted user” state. Where the entitlements do overlap, the overlap should be explicit, documented and time-bound rather than accidental.
Practically, teams should also watch for stale access after a relationship ends. A person can remain active in one context while another context quietly expires, and that is where excess privilege usually creeps in. The safest control is to revoke by relationship end-date, not by waiting for someone to notice that the person still looks broadly eligible.
Risk and Threat Considerations
When multiple relationships are flattened into one profile, organisations can keep access alive long after the original justification has changed. That creates avoidable exposure: stale entitlements, weak accountability for approvals, and a larger blast radius if the account is misused or compromised.
Failure mechanism: Teams recertify the person rather than the live relationship, so dormant authority survives role changes, contract changes, or partial offboarding.
Impact: Excess privilege persists, reviews become less trustworthy, and an attacker or insider who gains the account can inherit access that no longer has a valid business basis.
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 and CSA Cloud Controls Matrix set 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 | Active relationships require time-bounded credential and entitlement lifecycle control. |
| AC-2 — Account Management | Separate relationships need governed provisioning, review and deprovisioning rather than one broad profile. | |
| AC-6 — Least Privilege | Multiple relationships must not merge into broader access than each relationship justifies. | |
| Recommendation — Tie each relationship to expiring credentials and revoke or rotate them when the relationship ends. Maintain distinct account lifecycle records for each governed relationship and remove access by relationship. Limit each relationship to the minimum entitlements its specific authority requires. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The subject is relationship-aware identity governance and entitlement scoping across access contexts. |
| Recommendation — Model each active relationship with its own authority, scope and review cycle. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Multiple active relationships need identity records that preserve distinct authority and lifecycle context. |
| A.5.18 — Access rights | Access rights must be reviewed against the live relationship that justifies them. | |
| Recommendation — Keep identity records aligned to each relationship’s authority and lifecycle. Review and remove rights according to the active relationship, not the person alone. | ||
Practitioner Guidance
What to prioritise: Make the relationship object the unit of governance, not the person record. If your IAM process cannot explain why a specific entitlement still exists under a specific active relationship, it is too coarse to trust.
What to verify: For each active relationship, confirm the source of authority, start and end date, sponsor, and entitlement scope. If any entitlement is still justified only by the person’s general profile, re-evaluate whether it should be re-issued under a narrower relationship context.
Decision rule: If the relationship changes, recertify the access attached to that relationship immediately, and only carry forward entitlements that remain valid under the new authority. Do not wait for a routine review cycle to clean up a relationship that has already materially changed.
Practitioner takeaway: The goal is not to eliminate overlap, it is to make overlap explicit, bounded and revocable so legitimate business exceptions do not quietly become standing privilege.