Multi-tenant Strata Cloud Manager + Azure cross-tenant Cloud NGFW hub

The constraint

A large healthcare enterprise, several Azure tenants, and no realistic path to consolidating them. Tenants existed for reasons that outlast any network design: acquisitions that were never merged, regulatory scope that is cleaner kept separate, and workloads whose data classification made a shared tenant a non-starter.

The design question was therefore not how to collapse the tenants. It was how to inspect traffic across them without doing so.

A hub, not a mesh

Cross-tenant connectivity as a mesh scales as the square of the tenant count, and every new tenant is a change to every existing one. The design is instead hub-and-spoke, with the hub in its own isolated subscription: onboarding becomes a single attachment, and inspection policy stays in one place.

The transit VNet is addressed out of RFC 6598 carrier-grade NAT space — 100.64.0.0/22 — rather than RFC 1918. Shared transit is precisely where RFC 1918 overlap surfaces, and 100.64/10 is the one range an enterprise can reasonably assume its acquisitions and partners have not already consumed. Inspection is Cloud NGFW in its SaaS form, so the hub carries no firewall instances to patch.

Attachment and authorization

Internal workloads attach over standard VNet peering. Third-party tenants attach over cross-tenant subnet peering, where each side creates only its own half of the peering. Neither organization can complete the link unilaterally, so the attachment itself is a record of mutual consent rather than a configuration one party could have made alone.

There are no default routes pointed at the NGFW. Reachability is granted through per-engagement route lists, which makes routing the authorization mechanism: a destination an engagement has no route to is unreachable regardless of what firewall policy would have permitted. Two independent things have to be true before traffic moves, and one of them is not editable from the security policy.

Traffic is inspected without NAT at the firewall. Addresses in the logs are therefore the real ones on both sides, and a finding traces back to a host without a translation table in the middle of the investigation.

Tenancy in the management plane

The part that matters long-term is the management plane. Strata Cloud Manager's folder hierarchy has to mirror the trust boundary, not the network topology, because that hierarchy is what determines who can change what.

Rules that apply everywhere live high in the hierarchy and are not editable below. Tenant-specific rules live in that tenant's folder and cannot reach across. A tenant administrator's authority ends at their own boundary as a structural property rather than as a convention.

Boundaries that survive an org chart

The usual failure mode of a tenancy model is that it encodes the organizational structure that existed when it was drawn. A model keyed to reporting lines needs rework at every reorganization, and each rework is an opportunity to get an access boundary wrong.

This one is keyed to facts that change more slowly than org charts do — regulatory scope, data classification, acquisition boundary. Reorganizations move people between folders. They do not require redrawing the folders.