Fortinet SD-WAN Hub Placement Part 2: The MSSP Shift — When the Hub Becomes Customer-Centric

Part 1 described the traditional model: a single enterprise, a pair of DCs, hubs that sit in those DCs because that’s where the applications, the security stack, and the FMG/FAZ pair all lived too. Every placement decision pointed the same direction, so there wasn’t really a decision to make.

The MSSP case breaks that immediately, because the thing that anchored the decision — “the DC, where everything lives” — stops being a single place. An MSSP’s FortiManager and FortiAnalyzer don’t serve one estate. They serve dozens, sometimes hundreds, each with its own infrastructure, its own applications, its own compliance posture, and — critically — its own idea of where “the DC” even is. This post is about what that does to hub design.

ADOMs: one FMG/FAZ pair, many separate worlds

The mechanism that makes MSSP-scale management possible is the Administrative Domain (ADOM) — covered from the FortiManager-operations side in NSE5 Part 4. The short version, recapped here because the rest of this post leans on it: an ADOM is a logical partition inside FortiManager (and the equivalent construct in FortiAnalyzer) that scopes devices, policies, objects, and logs to a single customer. From inside an ADOM, an operator sees only that customer’s FortiGates, that customer’s address objects, that customer’s logs. From the platform’s perspective, one FMG/FAZ HA pair is quietly running what amounts to dozens of independent management planes.

That’s the enabling technology. It’s also the thing that quietly removes the single biggest assumption the traditional model rested on.

The assumption that breaks

Go back to Part 1’s list of reasons the hub belonged in the DC:

• That’s where the applications were — true for one company, in one set of buildings.
• That’s where the security stack was — same.
• That’s where the network team’s hands already were — same again, and now there’s a different team (the MSSP’s) whose hands are somewhere else entirely.
• That’s where good connectivity already existed — this one was always going to be the first to go, because “good connectivity” is now a property of each customer’s footprint, not the MSSP’s.

Every one of those was a statement about one organisation’s infrastructure. An MSSP, by definition, doesn’t have one organisation’s infrastructure to anchor against — it has Customer A’s three sites and one Azure tenant, Customer B’s single DC and a growing SaaS estate, Customer C’s twelve branches and a DC they’re trying to exit entirely. The FMG/FAZ pair is the MSSP’s. The applications, the DCs, the cloud tenancies, and — the part that matters most for this post — the answer to “where should the hub go” belong to the customer.

Put bluntly: in the traditional model, “where do we put the hub?” had one answer, because there was one estate. In the MSSP model, it has as many answers as there are customers, because each customer’s hub serves their topology, not the MSSP’s.

What stays centralised, and what doesn’t

It’s worth being precise about the split, because it’s easy to over-correct into “everything is now per-customer” — which isn’t true and would throw away the entire economic case for running an MSSP practice in the first place.

Stays centralised (the MSSP’s infrastructure, MSSP-operated):

• The FMG/FAZ HA pair itself — almost always hosted in the MSSP’s own DC(s) or a colo footprint they control, for the same reasons enterprises traditionally centralised their management plane: predictable connectivity, a single security posture to defend, one place for the operations team to work.
• The operational tooling around it — the ticketing integration, the monitoring of the management plane’s own health, the template libraries that get reused (with per-ADOM variation) across customers.
• The AS and addressing governance — not the per-customer plans themselves, but the rules that stop two customers’ overlapping RFC1918 ranges (and there will be overlap — everyone uses 10.0.0.0/8 and 192.168.x.x) from colliding inside a shared management plane. ADOM scoping handles the logical separation; good addressing discipline stops it from becoming a daily headache.

Becomes per-customer (the customer’s infrastructure, often customer-influenced if not customer-operated):

• Where the hub physically sits.
• The AS plan the hub participates in.
• What the hub needs to reach, and therefore what its routing and policy design has to look like.
• How — and whether — the hub talks back to the MSSP’s central FMG/FAZ.

That last point deserves its own section, because it’s the one piece of “centralised” infrastructure that every customer-centric hub still has to reach, no matter where it ends up.

The one constant: the hub still has to phone home

However far out a customer’s hub gets placed — in their DC, in their cloud VPC, at the edge of a SASE PoP — it still has to maintain a working relationship with the MSSP’s FMG/FAZ pair. That relationship doesn’t go away; if anything it matters more, because the MSSP’s entire value proposition rests on visibility and control over devices it doesn’t physically operate.

That gives every customer-centric hub design a fixed point to route around:

• FGFM (TCP/541) to the MSSP’s FortiManager, for configuration push, template sync, and the registration handshake — wherever the hub sits.
• Log forwarding to the MSSP’s FortiAnalyzer, encrypted, from wherever the hub sits, often across the open internet rather than a private circuit (more on that below).
• A routing path that makes both of those things reliable — which, per Part 1, is exactly what BGP on loopback was built to provide, and exactly why that design choice turns out to matter even more here than it did in the single-customer case. A hub whose loopback is stably reachable doesn’t care whether the path to the MSSP’s FMG runs over a customer’s MPLS, the customer’s internet circuit, or a dedicated MSSP-to-customer interconnect — the BGP relationship and the FGFM session ride on top of whatever’s there.

This is also where the threat model shifts in a way worth naming plainly: in the traditional model, the path from spoke to FMG/FAZ was entirely inside one organisation’s perimeter, end to end. In the MSSP model, that path routinely crosses an organisational boundary — the hub is the customer’s (or sits in the customer’s environment), the FMG/FAZ is the MSSP’s, and the traffic between them is, from a trust perspective, inter-company traffic that happens to look like intra-company traffic. That doesn’t make it wrong — it’s the entire basis of the MSSP model — but it does mean the firewall policy, the encryption choices, and the monitoring around that specific path deserve more scrutiny than the “it’s all internal” framing from Part 1 would suggest. Treat the hub-to-FMG/FAZ path as a path that crosses a trust boundary, because it does.

So where does the hub go, per customer?

With the centralised/per-customer split established, the placement question becomes a genuinely per-customer design exercise — but it’s not an unstructured one. The same questions that drove the traditional model’s “obvious” answer still apply; they just now have to be asked about the customer’s estate, not the MSSP’s:

• Where does this customer’s traffic actually need to go? If Customer A still runs a conventional DC-centric estate, a hub that mirrors the traditional model — sitting in or near their DC — is still the right call. The MSSP model doesn’t obsolete the traditional placement; it just stops assuming it.
• Who operates the facility the hub would sit in, and what does that mean for the MSSP’s reach? A hub racked in a customer’s DC is reachable for remote management (that’s what FMG is for) but physically depends on the customer’s environment — power, cooling, physical security, even who’s allowed in the building to swap a failed unit. A hub the MSSP places in its own infrastructure (a regional PoP, a cloud VPC the MSSP controls) trades that dependency for an extra hop in the customer’s data path. Neither is universally right; it’s a conversation with the customer about what they’re optimising for.
• What does the customer’s connectivity actually look like, and where are the good on-ramps? This is the same “that’s where good connectivity already existed” logic from Part 1 — except now it has to be evaluated against the customer’s circuits, the customer’s cloud connectivity, the customer’s internet posture, not the MSSP’s.
• What’s this customer’s trajectory? A customer mid-migration from DC to cloud, or DC to SASE, has a moving target — and hub placement decisions made for where they are today can become the wrong answer in eighteen months. (This is exactly the territory Part 3 covers in depth.)

None of those questions are exotic. They’re the same questions a single enterprise would ask about its own estate. The shift is that an MSSP has to ask them fresh, for every customer, rather than answering them once and reusing the answer — and has to do it while keeping the centralised half of the equation (the FMG/FAZ relationship, the addressing governance, the operational consistency) intact underneath.

A worked shape: two customers, two answers

To make this concrete, picture an MSSP running a single FMG/FAZ HA pair (in the MSSP’s own DCs, AS 64999 for the management overlay) serving two customers with very different estates:

                +-------------------------------+
                |   MSSP FMG/FAZ (HA, AS 64999) |
                +---------------+---------------+
                                |
              FGFM/log, over each customer's
                  own connectivity (per ADOM)
                 /                              \
   +------------+-----------+      +-------------+------------+
   |   Customer A — ADOM-A  |      |   Customer B — ADOM-B    |
   |   Conventional DC      |      |   Cloud-first, exiting   |
   |   estate, AS 65100     |      |   their DC, AS 65200     |
   |                        |      |                          |
   |   HUB-A: in their DC,  |      |   HUB-B: in their Azure  |
   |   next to their apps   |      |   VNet, where their      |
   |   (mirrors Part 1)     |      |   apps actually live now |
   +------------------------+      +--------------------------+

Customer A’s hub looks almost exactly like Part 1’s traditional model — because for Customer A, the traditional model is still correct. Customer B’s hub sits in Azure, because that’s genuinely where Customer B’s traffic needs to go. Both hubs run BGP on loopback (different AS per customer, scoped via ADOM on the management side, exactly as the Resilience series describes for a single estate — just replicated, cleanly separated, per customer). Both phone home to the same FMG/FAZ pair, over whatever connectivity each customer actually has. Neither design contaminates the other, because ADOM scoping keeps the logical worlds apart and good addressing discipline keeps the IP space from colliding.

That’s the MSSP model working as intended: one well-run centralised platform, many independently-correct edge designs, no customer’s topology constraining another’s.

What’s next

Part	Topic
1	The traditional model — hubs in the DC, the FMG/FAZ relationship, BGP on loopback as the connective tissue
2 (this post)	The MSSP shift — multi-tenant FMG/FAZ via ADOMs, and why hubs become customer-centric
3	Placement in practice — cloud (Azure/AWS/GCP) and the migration from DC-centric to SASE-centric designs

Customer B’s Azure-VNet hub, above, is a placeholder for a much longer conversation: what actually changes about hub design when “the DC” is a VPC, and what changes again when the customer’s destination isn’t a DC or a cloud tenancy but a SASE provider’s PoP. That’s Part 3.