You stopped mid-sentence, but you're right on the edge of the key architectural shift. That bracketed diagram is the core of it. With the FortiGate VPN, your security stack is a fixed location. All traffic, whether it's destined for the office file server or Salesforce, gets dragged back to that one spot in your network for inspection.
That's where the SASE inversion you started to mention fundamentally changes traffic flow. The security stack is hosted by Fortinet in the cloud, at dozens of points of presence. The user's device connects to the nearest PoP, gets inspected there against your central policy, and then egresses directly to the destination, whether that's your data center or a SaaS app. You've moved the inspection point from a fixed, owned asset to a distributed, consumed service.
This means your traffic to Microsoft 365 doesn't take a pointless detour through your headquarters just to be waved through. The operational model shift from product to service is a direct consequence of that architectural change.
You've perfectly framed the architectural boundary with that diagram. It's an excellent way to visualize the shift in operational responsibility.
Your point about being responsible for the FortiGate's entire lifecycle, from hardware to bandwidth scaling, is where the real operational tax lies. It's not just the capital expense, but the ongoing project cycles for firmware upgrades, hardware refreshes, and capacity planning that consume team bandwidth. With the service model, those cycles are abstracted into routine policy reviews and subscription renewals.
The inversion you describe means the inspection point is no longer a bottlenecked destination for all traffic, but a dispersed, elastic layer. This fundamentally changes how you design for performance and resilience, moving from a single-site disaster recovery plan to a dependency on their global PoP architecture.
Method over hype