When cloud-hosted vendor upgrades break your security configuration
Fortinet hosts and maintains their cloud EMS instances. That means they control the upgrade schedule. When Fortinet decided to update the EMS platform, they did it. There was no request for our approval. There was no convenient timing negotiated with the client. The upgrade happened, and the AD connector — the component that links EMS to the client’s Active Directory — became incompatible with the new version.
The result was that EMS lost its connection to AD entirely. The security fabric, which relies on that connection to enforce identity-based policies and user-level visibility, was now operating without the information it needed. A handful of issues followed in short order.
We jumped in, identified the incompatibility, reinstalled the AD connector at the correct version, and restored the integration. The client’s environment was back to normal. But the experience raised a question worth thinking about carefully: how many businesses understand that their cloud-hosted security platforms can change underneath them, and what that means for their configuration?
The cloud hosting assumption managed security teams must challenge
When a business moves to a cloud-hosted security platform, the immediate benefit is obvious. No on-premises infrastructure to maintain. Automatic availability. Vendor-managed uptime. These are real advantages, and they are why cloud-hosted security management has become the default for many organisations.
What is less obvious is that “vendor-managed” cuts both ways. When the vendor manages the platform, the vendor also controls when it changes. The upgrade schedule is theirs. The feature rollout timeline is theirs. And when they update a component that your configuration depends on — an AD connector, an API integration, an authentication method — you are relying on the upgrade being backwards-compatible with everything you have built on top of it.
Sometimes it is. Sometimes, as this week demonstrated, it is not.
Why the AD connector is central to Fortinet EMS security fabric integrity
The AD connector is not a peripheral component in a Fortinet EMS deployment. It is the mechanism through which EMS understands who is who. It maps device identities to user identities, which is what allows the security fabric to enforce user-aware policies rather than just device-based rules. When the connector goes down, EMS does not just lose a feature — it loses context. Policies that depend on knowing which user is on which device start operating on incomplete information.
This is the kind of failure that can be subtle at first. The firewalls do not stop working. Traffic does not stop flowing. But the granularity of control that the security architecture was designed to provide begins to erode quietly until someone notices something is wrong.
Proactive integration monitoring as standing operational discipline
The practical lesson here is straightforward but easy to overlook in the day-to-day management of a complex environment. When you are running cloud-hosted security infrastructure, the components that integrate with your on-premises systems — AD connectors, LDAP integrations, identity federation services — need to be kept current. Not as an aspirational goal, but as a standing operational discipline.
The reason is simple: cloud platforms evolve continuously, and dependent integrations that lag behind create exactly the kind of gap this week surfaced. Keeping EMS and its AD connector on the latest version is not just best practice for feature access. It is the mechanism that keeps your integration surviving your vendor’s upgrade cycle.
For businesses managing their own Fortinet environments, this means adding connector version verification to your regular maintenance checklist. For businesses relying on a managed cyber security provider to oversee these platforms, it means asking whether your provider monitors integration health proactively — or whether they find out about incompatibility the same way you do: when something stops working.
What proactive managed security oversight actually looks like
When an incident like this happens inside a managed service relationship, the response is different from what most businesses experience on their own. We did not find out about the EMS upgrade because the client raised a support ticket. We found out because our monitoring surfaced the AD connector failure, and our engineer was already investigating before the client had fully registered that something was wrong.
That is not a coincidence of timing. It is what continuous monitoring through the Trusted Response Centre is supposed to produce. The vendor upgraded on their schedule. We responded on ours — which happened to be faster.
The broader point is that cloud-hosted security platforms require active management, not passive reliance. Vendors will keep upgrading their platforms because that is how cloud software works. The question is whether your IT environment has someone watching what those upgrades do to your configuration, or whether you are discovering the answer when users start reporting problems.
Cloud-hosted security does not eliminate the need for active oversight — it moves the risk from infrastructure maintenance to integration continuity. The vendor controls the upgrade. You control whether you find out before your users do.
If your organisation is running cloud-hosted security platforms and wants to understand what proactive integration monitoring looks like in practice, speak with our team about how the Trusted Response Centre works.
