A tenant-level structure that groups users, domains, policies, and access rules for a customer inside a B2B application. It gives onboarding a stable governance boundary so provisioning, role assignment, and deprovisioning can follow the customer’s real organisational structure rather than individual accounts.
Expanded Definition
An organisation object is the tenant-scoped record that anchors a customer’s governance boundary inside a B2B application. It is not just a label for a customer account. It is the structure through which users, domains, policies, entitlements, and lifecycle rules are bound to the same administrative context, so onboarding and offboarding can follow the customer’s actual operating model.
In NHI and IAM design, the organisation object matters because machine access rarely exists in isolation. Service accounts, API keys, automation tokens, and delegated admins usually need to inherit the right boundary from the start. When that boundary is clear, teams can apply least privilege, map ownership, and separate one customer’s secrets and policy decisions from another’s. This is consistent with governance expectations in the NIST Cybersecurity Framework 2.0, where identity governance is part of operational risk control. Definitions vary across vendors on whether organisation objects also own billing, branding, or subdomain routing, but the security function is the same: create a stable container for identity policy and administrative control. The most common misapplication is treating the organisation object as a cosmetic tenant label, which occurs when provisioning rules still depend on individual user records instead of the tenant boundary.
Examples and Use Cases
Implementing an organisation object rigorously often introduces data-model and workflow constraints, requiring organisations to weigh simpler onboarding against stricter segregation of access and policy.
- A SaaS platform creates one organisation object per customer so every user, service account, and policy inherits the same offboarding path when the contract ends.
- A B2B app maps customer domains to the organisation object so invitations, login enforcement, and access reviews remain tied to the correct tenant boundary.
- An automation platform uses the organisation object to scope API keys and rotation policies, reducing the risk that one customer’s credentials can be reused elsewhere. This aligns with guidance in the Ultimate Guide to NHIs.
- A federated enterprise sets the organisation object as the anchor for SSO, then assigns machine identities to the tenant after authentication, rather than before, to avoid cross-customer entitlements.
- Audit teams use the organisation object to review whether policies, domains, and secrets are attached to the right customer boundary, not just the right username.
For implementation patterns around scoped identity and trust boundaries, the NIST Cybersecurity Framework 2.0 provides a practical governance lens, while NHIMG’s Ultimate Guide to NHIs is useful for understanding how tenant structure affects lifecycle control.
Why It Matters in NHI Security
Organisation objects become security-critical because they define where identity policy starts and stops. If the boundary is weak, machine identities can be provisioned into the wrong tenant, secrets can be attached to the wrong customer context, and deprovisioning can leave residual access behind. That creates operational confusion and expands blast radius when a service account, token, or automation workflow is compromised.
This is especially relevant in NHI-heavy environments, where NHIs outnumber human identities by 25x to 50x in modern enterprises, according to Ultimate Guide to NHIs by NHI Mgmt Group. At that scale, a poorly modelled organisation object is not a design detail. It becomes a control failure that affects onboarding, access review, rotation, and offboarding across the tenant. The same governance boundary also supports Zero Trust assumptions by ensuring identity and privilege decisions remain tenant-specific rather than global. Organisations typically encounter the impact only after a cross-tenant access incident, at which point the organisation object becomes operationally unavoidable to investigate and correct.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Tenant boundary design supports scoped NHI ownership and access separation. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access governance requires clear organisational context for authorization decisions. |
| NIST Zero Trust (SP 800-207) | Zero Trust relies on explicit, context-aware trust boundaries for each access decision. |
Bind machine identities to a tenant boundary and prevent cross-organisation entitlement bleed.
Related resources from NHI Mgmt Group
- How should an organisation respond when it discovers hundreds of unowned NHIs?
- Where should an organisation start with NHI security?
- Why do private Teams chats sometimes expose files to the whole organisation?
- What is the difference between scope-based authorization and object-level authorization in MCP?
