Join our Newsletter — 33% off our NHI Course

How should organisations manage identity records when one person has multiple contracts or affiliations?

Organisations should model each contract or affiliation explicitly and connect it to a single trusted identity lifecycle. The key is to separate person identity from relationship-based access, so onboarding, role changes, and offboarding stay accurate. That reduces orphaned access, prevents duplicated accounts, and makes governance easier across HR, partners, contractors, and academic or project-based relationships.

Why This Matters for Security Teams

When one person holds multiple contracts, affiliations, or sponsor relationships, identity management stops being a simple join between a user and a role. It becomes a lifecycle governance problem: the same person may need separate records for employee, contractor, researcher, board member, or partner access, while still sharing a single trusted identity anchor. If those relationships are collapsed into one record, offboarding and attestations become unreliable; if they are duplicated without governance, access can linger after a contract ends.

This matters because the most common failure is not initial provisioning but mismatched deprovisioning. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, a reminder that identity lifecycle gaps are usually operational, not theoretical. The same pattern shows up in human identity records when affiliations are poorly modeled. NIST’s Cybersecurity Framework 2.0 reinforces the need for governed identity and access processes that can be consistently enforced across changing conditions.

In practice, many security teams discover the problem only after a person leaves one affiliation but retains access through another record that nobody thought to retire.

How It Works in Practice

The safest approach is to treat the person as the stable identity anchor and each contract or affiliation as a distinct relationship object with its own start date, end date, sponsor, and entitlement scope. That keeps identity proofing, authorisation, and offboarding aligned to the actual reason access exists. It also supports auditability, because reviewers can see why access was granted rather than inferring intent from a single overloaded account.

Operationally, this usually means integrating HR, vendor management, campus systems, or project offices into a shared identity governance workflow. Each source should feed relationship status, not silently overwrite the person record. When a contract ends, the relationship should close automatically, triggering access review and revocation for the entitlements tied to that relationship only. NIST SP 800-53 Rev. 5 emphasises access enforcement and account lifecycle controls; in this context, that means entitlement decisions should be tied to authoritative relationship data, not manual exceptions.

  • Use one master person record and multiple affiliation records.
  • Assign access by relationship type, sponsor, and expiry date.
  • Separate permanent identity attributes from temporary access conditions.
  • Require renewal or re-approval when a contract is extended or re-scoped.
  • Log which affiliation justified each entitlement for audit and incident response.

This is especially important in environments with research collaborators, contingent labour, adjunct staff, or shared service providers, where one person can legitimately occupy several roles over time. NHI Mgmt Group’s NHI Lifecycle Management Guide highlights how lifecycle discipline reduces orphaned access, and the same principle applies to human identity records. The model breaks down when affiliation data is owned by disconnected systems with no authoritative end-date, because access then persists longer than the relationship that justified it.

Common Variations and Edge Cases

Tighter identity modeling often increases administrative overhead, so organisations must balance precision against workflow complexity. That tradeoff is worth it when affiliations create different risk levels, but current guidance suggests avoiding unnecessary fragmentation when the relationship truly behaves like a single role with one sponsor and one expiry path.

One common edge case is dual affiliation, such as an employee who is also a contractor on a separate project. Best practice is evolving, but the most defensible approach is to keep distinct relationship records while preventing entitlement collisions, especially where segregation of duties matters. Another edge case is sponsored access for guests or visiting scholars, where the primary identity may be external but the access should still expire with the sponsoring relationship. For audit and investigation, NHI Mgmt Group’s Regulatory and Audit Perspectives can help frame how lifecycle evidence should be retained and reviewed.

The hardest cases appear when identity data is replicated across HR, IAM, and SaaS platforms without a shared canonical key. In those environments, duplicate records, delayed offboarding, and manual exception handling become the norm, and the model breaks down when one affiliation ends but downstream systems still treat the person as active because no single system owns the truth.

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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 PR.AC-1 Identity records must map access to authorized relationships and roles.
NIST SP 800-63 IAL2 Multiple affiliations still require a trusted, well-verified person anchor.
OWASP Non-Human Identity Top 10 NHI-01 Duplicate or orphaned identities create lifecycle and access control risk.
NIST AI RMF Governance depends on accountable, traceable identity decisions across changing context.
NIST Zero Trust (SP 800-207) 3.1 Zero Trust requires dynamic authorization based on current trust context.

Prevent duplicate records by centralizing lifecycle ownership and relationship-based provisioning.