Should organisations build multi-tenancy themselves or use a platform?

Why This Matters for Security Teams

Choosing between custom multi-tenancy and a platform is not just an engineering preference. It is a security decision about who can become a tenant, how that tenant is represented in identity, and whether access can be revoked cleanly when business conditions change. When tenant boundaries drift into application code, database filters, and ad hoc admin workflows, the control usually fails at the seams. That is why NHI governance matters here: tenant membership, invitation flow, and revocation are identity controls, not only product features. The NIST Cybersecurity Framework 2.0 treats access control and governance as core risk functions, and the same logic applies when one tenant can affect another through shared services. NHIMG research also shows how often identity controls fail in practice, especially when secrets and privilege are not tightly managed; see the Ultimate Guide to NHIs — The NHI Market. In practice, many security teams discover tenant leakage only after an incident, rather than through intentional validation of isolation.

How It Works in Practice

The practical question is whether the team can enforce tenant isolation consistently across authentication, authorisation, storage, support tooling, and automation. If building in-house, each request needs an unbroken chain from identity proof to tenant membership to role scope to object-level access. That usually means RBAC plus tenant-aware policy checks, strong invitation workflows, and immediate revocation for both human and non-human identities. If the system uses service accounts, API keys, or automation, the same tenant rules must apply to those workloads too, because shared infrastructure can widen blast radius quickly. NHI governance guidance in the Ultimate Guide to NHIs — The NHI Market is directly relevant here, especially where secrets, offboarding, and visibility are weak. The identity and access model should also align to the NIST Cybersecurity Framework 2.0, because tenant isolation depends on continuous protection, not a one-time implementation choice.

• Use tenant-scoped identities, not global users with hidden tenant flags.
• Enforce object-level checks at every access point, including APIs and admin tools.
• Make invitations time-bound and revocable, with explicit approval where needed.
• Log tenant changes, membership grants, and revocations as security events.
• Test isolation after schema changes, policy updates, and support process changes.

These controls tend to break down when multiple product teams share the same back-end services because policy drift and bypass paths appear faster than review processes can catch them.

Common Variations and Edge Cases

Tighter tenant isolation often increases delivery overhead, so organisations have to balance speed against the cost of building and proving controls. There is no universal standard for whether custom tenancy or a platform is better; the right answer depends on regulatory pressure, data sensitivity, and how often tenant boundaries change. A platform can reduce risk if it already provides tenant-aware identity, revocation, auditability, and support segmentation, but it can also create lock-in if the provider cannot explain its isolation model clearly. Current guidance suggests treating this as an assurance problem: ask how membership is enforced, how support staff are constrained, how secrets are separated, and how exceptions are detected. That is consistent with the control focus in the NIST Cybersecurity Framework 2.0, and with NHI lifecycle discipline described in the Ultimate Guide to NHIs — The NHI Market. Organisations should prefer the option that can prove revocation, isolation, and audit continuity under change, not just during a demo. Where tenancy must cross regions, subsidiaries, or shared automation layers, bespoke builds often struggle because every exception becomes a new attack path.

Related resources from NHI Mgmt Group

• What breaks when multi-tenancy is added on top of a basic auth library?
• Multi-Tenancy Boundary
• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How can organisations reduce secret leakage in ServiceNow at scale?