Who is accountable for access decisions when a person has multiple affiliations at the same time?

Why This Matters for Security Teams

When a person holds multiple affiliations at once, access is rarely “one identity, one owner.” The real risk is that each affiliation may imply different business purpose, data scope, and approval authority, yet those distinctions are often collapsed into a single account review. That creates audit confusion, weakens least privilege, and makes it hard to prove why access exists under frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls.

For security teams, the accountability question matters because access decisions are only defensible when ownership is tied to the correct relationship. If a contractor is also a researcher, or an employee also serves on a governance committee, each affiliation can justify different entitlements and different offboarding triggers. NHIMG guidance on the Ultimate Guide to NHIs shows how quickly unmanaged identities become hard to explain, with only 5.7% of organisations reporting full visibility into service accounts. In practice, many teams discover access drift only after a role overlap has already expanded what someone can reach.

How It Works in Practice

Accountability should be assigned per affiliation, not per person alone. Each relationship needs an owner who can answer three questions: what business purpose does this affiliation serve, what resources does it justify, and when does it end. That means a university appointment, a consulting engagement, and an internal employee role should each have separate governance records even if they map to the same individual.

Practically, access review should follow the affiliation that granted the entitlement. If the person is acting under a research role, the research owner reviews the access; if they are acting under a vendor or project role, the corresponding sponsor or business owner does. This is consistent with the intent of OWASP Non-Human Identity Top 10, which treats identity lifecycle and authorization context as core security problems rather than administrative details.

• Define a separate authoritative source for each affiliation type, including owner, scope, and expiry.
• Bind entitlements to the affiliation that justified them, not to a generic master profile.
• Require review and reapproval when an affiliation changes, overlaps, or ends.
• Use automated deprovisioning when the end condition is reached, rather than waiting for manual cleanup.

This approach becomes easier when governance records are precise and revocation is tied to clear lifecycle events. NHIMG’s 52 NHI Breaches Analysis shows that identity failures often persist because ownership is fragmented across teams and systems. These controls tend to break down in federated organisations where each affiliation is administered by a different department and there is no single authoritative workflow for revocation.

Common Variations and Edge Cases

Tighter affiliation-based control often increases governance overhead, requiring organisations to balance precision against administrative burden. That tradeoff is real: the more roles and sponsors a person has, the more likely it is that a simple joiner-mover-leaver process will miss a relationship if it is not explicitly modeled.

Best practice is evolving for situations where affiliations overlap in time. There is no universal standard for this yet, but current guidance suggests treating each affiliation as a distinct access context with its own accountability chain. That matters when a person is both a customer of one service and an operator of another, or when a clinician, researcher, and administrator all use the same enterprise directory. In those cases, the security team should not guess which affiliation “wins.” It should require the business owner for each active relationship to confirm the access attached to that relationship.

The main exception is emergency access. Even then, the emergency grant should inherit a temporary owner, a short expiry, and a post-event review. Without that, overlapping affiliations can hide privileged access long after the business reason has disappeared. This is exactly the kind of review gap that turns a routine overlap into an explainability problem during audit or incident response.

Related resources from NHI Mgmt Group

• Who is accountable for machine access decisions when identity, support, and audit teams all need the same data?
• Who is accountable when workflow access reviews and source-of-truth decisions are inconsistent?
• Who is accountable when contractor access is not revoked on time?
• Who is accountable when physical access decisions do not match HR status or security policy?