A deployment model where the customer controls the cloud tenant and operating environment while the vendor provides the application software and support. In identity governance, this arrangement can satisfy residency and boundary requirements, but it also shifts responsibility for environment administration, evidence collection, and some control operations to the enterprise.
Expanded Definition
Tenant-owned deployment describes a model where the enterprise owns the cloud tenant, security boundaries, and often the operating controls, while the vendor supplies software, support, and product updates. In NHI governance, it is commonly used when residency, separation, or auditability requirements make shared infrastructure too risky.
Definitions vary across vendors because the label can cover anything from a fully customer-managed SaaS tenant to a semi-managed private environment. The operational question is not the branding, but who administers the environment, who holds evidence, and who can change identity-related settings, logging, and privileged workflows. That distinction matters when service accounts, API keys, and automation agents depend on tenant-local policy for access. The NIST Cybersecurity Framework 2.0 is useful here because its governance and protection functions map cleanly to shared responsibility and evidence ownership. Tenant-owned deployment also changes how teams interpret guidance from the Ultimate Guide to NHIs, especially where lifecycle control and secret handling must remain under enterprise authority. The most common misapplication is treating a vendor-hosted application as vendor-managed security, which occurs when the enterprise assumes logging, rotation, and access reviews are included in the service contract.
Examples and Use Cases
Implementing tenant-owned deployment rigorously often introduces administrative overhead, requiring organisations to weigh stronger boundary control against the cost of deeper operational ownership.
- A regulated financial services firm keeps its identity governance platform in a customer-controlled tenant so audit logs, retention rules, and regional data handling stay inside its compliance boundary.
- A healthcare provider uses a tenant-owned deployment to separate production and test environments, ensuring that NHI secrets and support access are isolated from vendor operations.
- A software company adopts the model for AI agent orchestration so that privileged tool access, JIT elevation, and RBAC policy changes remain under enterprise approval.
- A government contractor chooses the arrangement when contract terms require the customer to manage the environment, while the vendor only maintains application code and patch guidance.
For teams comparing implementation patterns, the NIST Cybersecurity Framework 2.0 provides a practical lens for deciding which control outcomes remain internal. The NHI governance guidance in the Ultimate Guide to NHIs is also relevant when the enterprise must prove who owns secret rotation, offboarding, and break-glass access after a tenant change.
Why It Matters in NHI Security
Tenant-owned deployment matters because it can reduce boundary ambiguity, but it also concentrates responsibility for tenant hygiene, evidence collection, and privileged administration inside the enterprise. If those duties are not explicitly assigned, the result is often incomplete logging, weak review cadence, and unclear ownership for service accounts and automation tokens. That is especially dangerous in environments where NHIs outnumber human identities by 25x to 50x, as documented in the Ultimate Guide to NHIs. A customer-controlled tenant can be a strong fit for Zero Trust programs, but only when the enterprise can enforce least privilege, rotation, and offboarding at the tenant layer. The NIST Cybersecurity Framework 2.0 reinforces this expectation by tying governance outcomes to repeatable access and monitoring practices. Organisations typically encounter the consequences only after an audit failure, a leaked secret, or a support incident, at which point tenant-owned deployment becomes operationally unavoidable to fix.
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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Tenant-owned deployments demand strict secret and access ownership at the tenant layer. |
| NIST Zero Trust (SP 800-207) | SP-207 | Customer-owned tenants support Zero Trust by keeping policy enforcement and trust boundaries explicit. |
| NIST CSF 2.0 | GV.OC-01 | Shared-responsibility clarity is central to governance and operational control in this model. |
Assign and review tenant-level secret controls, rotation, and privileged access as explicit enterprise duties.
Related resources from NHI Mgmt Group
- How should regulated teams decide between shared SaaS and tenant-owned identity platforms?
- What are the main reasons AI agents struggle to achieve enterprise-scale deployment?
- When should organizations reconsider the deployment of AI agents?
- Why is it necessary to address authorization challenges in AI agent deployment?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
