Why do flat attribute mappings fail when a person belongs to multiple organisations with different access rules?

Flat mappings fail because a single attribute cannot accurately represent multiple concurrent relationships with different entitlements and lifecycles. When access is decided per user only, one school, department, or employer can overwrite another. Association-based handling keeps each relationship distinct so provisioning and access assignment stay aligned to the source reality.

Why This Matters for Security Teams

Flat attribute mapping fails because it assumes a person has one stable security context when the real world is often many-to-many: one individual may be a student, contractor, researcher, and employee at the same time, each with different approval chains, expiry dates, and least-privilege boundaries. If the identity system collapses those relationships into a single record, access can be over-granted, silently replaced, or revoked in the wrong place.

That is why current guidance in the OWASP Non-Human Identity Top 10 and NIST control thinking around lifecycle governance matter here: the security problem is not just authentication, but whether the source of truth preserves distinct relationships and entitlements. NHIMG’s Ultimate Guide to NHIs frames the same issue for operational identities, where flattening context creates brittle access decisions that do not survive change.

In practice, many security teams discover this only after an access review, audit exception, or revocation failure has already exposed the mismatch between source reality and the IAM record.

How It Works in Practice

The practical fix is to treat each organisational relationship as a distinct association, not as a single user attribute. Instead of asking, “What does this person belong to?”, the access platform asks, “Which relationship is being used for this request, and what rules apply to that relationship right now?” That means a person can have separate memberships for a university, a research lab, and a vendor account without one overwriting the others.

This model is especially important when provisioning and deprovisioning are driven by different systems of record. One source may define academic affiliation, another may define employment status, and a third may define project-based access. If those signals are flattened too early, lifecycle events become lossy. Best practice is to preserve relationship identity through ingestion, policy evaluation, and entitlement assignment so the system can revoke only the correct association when one role ends.

• Keep each membership or affiliation as its own object with its own start, end, and authority source.
• Evaluate access at the association level, not only at the person level.
• Allow separate approval paths where organisations have different risk tolerances or compliance rules.
• Use explicit precedence only when business policy requires it, and document that rule clearly.

For teams building or reviewing controls, the NIST SP 800-53 Rev 5 Security and Privacy Controls provides useful language for access enforcement and lifecycle accountability, while NHIMG’s 52 NHI Breaches Analysis shows how identity confusion and poor lifecycle handling repeatedly turn into real compromise paths. These controls tend to break down when downstream applications only accept a single “primary role” field because the original relationship context is discarded before authorization can evaluate it.

Common Variations and Edge Cases

Tighter relationship-based access often increases integration and governance overhead, requiring organisations to balance accuracy against directory complexity and application compatibility.

One common edge case is when two organisations intentionally share the same person but enforce conflicting access rules. Current guidance suggests keeping the affiliations separate and resolving conflict through policy, not by overwriting one attribute with another. Another edge case appears in legacy applications that only understand one role per account. In those environments, the usual workaround is a mediated entitlement layer or a policy engine that converts association state into app-specific claims at request time.

There is no universal standard for precedence modelling yet. Some organisations choose “most restrictive wins,” while others select the relationship tied to the active session or business context. The right answer depends on whether the dominant risk is accidental over-provisioning, operational interruption, or regulatory non-compliance. The important point is that the decision must be explicit and reversible, not an implicit side effect of a flattened schema.

NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks is useful for understanding how fragmented identity context creates control gaps, especially where access decisions depend on source fidelity rather than a single attribute value.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they try to manage tenant access and custom roles across multiple CIAM vendors?
• What breaks when organisations rely on static access rules in fast-changing cloud and SaaS environments?
• How should organisations handle emergency lockout when a user may still retain access across multiple connected systems?
• Why do organisations struggle to apply the same access model across different industries?