Your Organisation Is Not One Tenant

Most secret management tooling assumes you have one Entra ID tenant. Most organisations of any size do not.

The tenant count grows with the company. An acquisition arrives with its own tenant, its own Key Vaults, its own App Registrations, and an integration deadline that is always sooner than the cleanup. A subsidiary runs in a separate tenant for legal or billing separation. A region stands up its own tenant for data residency. A platform team keeps production in a different tenant from development. None of this is unusual. It is just how real Azure estates end up.

Every one of those tenants has the same problem as your main one: secrets and certificates that expire, App Registration credentials that need rotating, Key Vaults nobody is watching closely. The difference is that your tooling is pointed at a single tenant, so every other tenant is a blind spot by default.

How Teams Handle It Today

There are two common answers, and neither is good.

The first is to deploy the tooling again for each tenant. A separate instance, a separate database, and a separate dashboard per tenant. Now you have five places to check instead of one, five sets of alerts to triage, and no single view of which credentials across the whole organisation expire next week. The operational cost scales with the number of tenants, which is the wrong direction.

The second is the spreadsheet. Someone keeps a list of the other tenants’ important certificates and tries to remember to check it. This works until that person changes roles, at which point the subsidiary tenant goes dark and you are back to learning about expiries when something breaks.

Both answers exist because the tooling forced a choice between coverage and a single view. You could see everything in one tenant, or you could see across tenants by hand.

One Deployment, Every Tenant

The Corporate Tenant Registry removes that choice. From a single CertifyClouds deployment you onboard each additional Entra ID tenant in your organisation once, and from then on it is part of the same inventory as your home tenant.

Onboarding a tenant is a registration step, not a second install. You add the tenant, grant CertifyClouds read access (and write access if you want rotation in that tenant), and it starts appearing alongside everything else. The home tenant your deployment already runs in is detected automatically, so the registry begins with the tenant you are in and grows outward to the ones you add.

The result is one place that knows about all of them. You can look at the whole organisation at once, or filter down to a single tenant, without logging into five directories or running five copies of anything.

What You Can Do Across Tenants

Once a tenant is onboarded, it is a full participant, not a read-only afterthought:

  • Discovery runs in every onboarded tenant. Secrets, certificates, keys, and App Registration credentials are pulled into one inventory with one expiry timeline that spans the organisation. The credential that expires soonest is on the same list whether it lives in the home tenant or an acquired one.
  • Rotation works in the tenant the credential actually lives in. An App Registration secret or certificate in a subsidiary tenant rotates using that tenant’s access, against that tenant’s vault.
  • Key Vault to Key Vault replication runs within a tenant for disaster recovery and environment sync.
  • Dashboards and inventory views can be scoped to a single tenant or viewed across all of them, so the platform team sees the whole estate and a subsidiary owner sees only their own.
  • Audit entries are tagged with the tenant they happened in, so the record of who rotated what is clear when more than one tenant is in play.

Routing To The Right Tenant

The real risk in any cross-tenant tool is doing the correct operation in the wrong place: rotating a credential in one tenant’s vault using a different tenant’s identity. A read in the wrong tenant returns nothing. A write in the wrong tenant is a problem.

CertifyClouds is built so this cannot happen by accident. Every operation resolves the owning tenant of its target before it acts, and runs scoped to that tenant. A rotation in the subsidiary tenant uses the subsidiary’s credentials against the subsidiary’s vault and cannot fall back to the home tenant. Each tenant’s access is kept separate, and an operation that cannot be matched to a single tenant is refused and logged rather than guessed. The convenience of one deployment does not come at the cost of one tenant’s credentials reaching into another.

What It Is, And What It Is Not

To be precise about the scope: this is multi-tenant for one organisation that spans several Entra ID tenants. Subsidiaries, acquisitions, regions, and environment boundaries that all belong to you. It gives you unified inventory, per-tenant rotation, scoped views, and tenant-tagged audit across that estate.

It is not, today, a multi-customer platform for managing unrelated clients with hard isolation between them. That is a different product with different guarantees, and it is a direction we are heading rather than a claim we are making now. If you run one organisation across many tenants, this is built for exactly that.

Availability

Multi-tenant support, the Corporate Tenant Registry, is an Enterprise feature. It sits alongside the rest of the Enterprise tier: custom contract terms, guided onboarding, and a signed support schedule for larger Azure estates.

If your organisation has grown past a single tenant, you already know the cost of the blind spots between them. Bringing every tenant into one inventory, with rotation and alerting that route to the right place, turns that sprawl back into something one team can actually see and manage.

CertifyClouds discovers, monitors, and rotates secrets and certificates across your entire Azure estate, now across every Entra ID tenant in your organisation from a single deployment. Talk to us about Enterprise or read the Corporate Tenant Registry docs.

Further Reading