How should security teams decide whether identity tooling belongs inside the tenant or in a shared cloud?

Why This Matters for Security Teams

The tenant-versus-shared-cloud decision is not really about where software is hosted. It is about who can govern identity state, who can prove segregation, and who can respond when access policy, audit evidence, or secret material changes. If a platform can read or rewrite customer identity records, the deployment model becomes part of the control boundary.

That is why the question matters for NHI operations, privileged access, and delegated administration. Identity tooling often sits closest to the records that define who or what may authenticate, what is allowed to rotate, and what evidence exists for review. The Ultimate Guide to NHIs notes that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which reflects how central custody and control have become. NIST’s NIST Cybersecurity Framework 2.0 frames this as a governance and access-control problem, not a simple infrastructure preference.

Security teams often get this wrong by starting with cost or convenience, then discovering that logs, policy history, or token issuance data cannot be cleanly separated after the fact. In practice, many security teams encounter control disputes only after an audit, breach review, or tenant exit has already exposed the weakness.

How It Works in Practice

Start by classifying the identity tooling functions that matter most. If the platform handles customer-specific policy, rotation history, signing keys, audit trails, or access approvals, tenant-local deployment is usually the stronger governance choice because it keeps custody close to the data owner. If the platform only orchestrates shared control-plane functions and never needs to inspect customer secrets or tenant-scoped policy content, a shared cloud model can still be acceptable, but only with explicit segregation and contractual control evidence.

For teams evaluating NHI platforms, the practical test is whether the product can preserve four things: data residency, administrative separation, immutable logs, and revocation authority. The Top 10 NHI Issues and Ultimate Guide to NHIs both reinforce that visibility and rotation fail first when custody is unclear. In practice, teams should ask whether the vendor can prove:

• Tenant-scoped encryption and separate key ownership
• Logical and administrative segregation between customers
• Customer-controlled retention for audit logs and evidence
• Time-bound delegated access with clear revocation paths
• Documented handling of exports, backups, and incident forensics

Where shared cloud is used, best practice is evolving toward policy-as-code, strong tenant boundaries, and explicit review of support access rather than informal trust. The NIST Cybersecurity Framework 2.0 supports this by pushing organisations to identify assets, protect access, detect misuse, and recover with evidence. These controls tend to break down when the platform must process customer identity records across multiple tenants in one operational plane because cross-tenant support, backup restoration, and forensic export become difficult to keep strictly separated.

Common Variations and Edge Cases

Tighter tenant-local control often increases operational overhead, so organisations must balance stronger custody against update speed, cost, and vendor supportability. That tradeoff is real, especially when the tool is part of a broader identity fabric rather than a standalone app.

There is no universal standard for this yet, but current guidance suggests leaning tenant-local when the tool stores or processes customer secrets, entitlement history, or privileged workflow state. Shared cloud is more defensible when the service operates on metadata only, provides strong tenant isolation, and can demonstrate that operators cannot casually traverse customer boundaries. This is especially important for third-party integrations, where identity tooling may touch external OAuth grants or federated access paths. The 52 NHI Breaches Analysis shows how often identity failures become breach paths once visibility and segmentation weaken.

One practical edge case is regulated retention. If a customer must preserve logs for an investigation or legal hold, shared-cloud operations are only safe when retention can be enforced per tenant without provider override. Another is support access: if the vendor needs emergency access, the control question is not whether access exists, but whether it is JIT, logged, approvable, and revocable. The model becomes fragile when support, backups, and tenant admin all converge into the same shared operator path.

Related resources from NHI Mgmt Group

• How should security teams govern authentication in hybrid Active Directory and cloud identity environments?
• How can security teams tell whether service desk changes are actually helping identity operations?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?