Relationship-Based Access

Expanded Definition

Relationship-Based Access is an access model that ties entitlement to a live, recognized business relationship rather than to a static identity label. In NHI and IAM programs, that relationship can be employee, contractor, student, vendor, partner, workload owner, or service account sponsor, and it should define what the subject can access, for how long, under what approvals, and with what review cadence. The model is often discussed alongside role-based access control, but the two are not identical: RBAC groups access by role, while relationship-based access uses the current relationship as the governing justification and may change faster than an organisational role does.

Definitions vary across vendors when the subject is an AI agent or automated workload, so governance teams should treat the relationship as a policy input rather than as proof of trust. That distinction matters because a service account may still belong to a vendor, product team, or shared platform boundary, and each relationship implies different oversight. For broader context on NHI control expectations, see the OWASP Non-Human Identity Top 10 and the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls.

The most common misapplication is treating a past relationship, such as a terminated contractor or retired vendor agreement, as if it still justifies active access.

Examples and Use Cases

Implementing relationship-based access rigorously often introduces lifecycle overhead, requiring organisations to balance faster entitlement decisions against more frequent validation of who still has a legitimate business need.

• A contractor’s access to build systems is approved only while the contract is active, then automatically reviewed or removed at offboarding.
• A vendor support account is granted limited production visibility because the vendor has an active support relationship, not because the account belongs to a named person.
• A service account used by a payroll integration is scoped to the owning application team and revalidated when the system changes hands or is decommissioned.
• A student, researcher, or adjunct instructor may retain access to a specific lab environment, but only under a relationship that is time-bounded and sponsor-backed.
• An AI agent operating on behalf of a business unit may receive constrained tool access because its authority is derived from an approved operational relationship, not broad administrative trust.

For operational patterns and failure modes, the Ultimate Guide to NHIs explains why lifecycle discipline matters, while the 52 NHI Breaches Analysis shows how weak ownership and stale access combine into recurring compromise paths.

Relationship-based access is also useful when mapped to federation and control boundaries described by the OWASP Non-Human Identity Top 10, especially where a non-human subject crosses teams, tools, or environments.

Why It Matters in NHI Security

Relationship-based access matters because NHI risk is rarely caused by identity alone. It emerges when access outlives the relationship that justified it, when sponsorship is unclear, or when ownership transfers without cleanup. In practice, that creates orphaned secrets, unreviewed service accounts, and entitlement drift across CI/CD, cloud, and third-party integrations. NHIMG research shows that 97% of NHIs carry excessive privileges and only 20% have formal offboarding and revocation processes, which makes relationship validation a core security control rather than an HR formality. The same source also notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, reinforcing how quickly stale relationships can become attack paths.

Governance teams should treat relationship status as an enforceable control signal, with documented ownership, expiration, and review triggers. This is especially important in third-party access, where the relationship may be contractual but the blast radius is technical. When paired with the control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, it becomes possible to require continuous justification for access instead of one-time approval.

Organisations typically encounter the consequence only after a contractor exits, a vendor relationship ends, or an AI workflow is repurposed, at which point relationship-based access becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What do teams get wrong about RBAC, ABAC, and relationship-based access control?
• Why does relationship-based access control matter for application and NHI governance?
• How do you know if a relationship-based access model is working?
• Why do relationship-based access models need testing beyond role review?