Summary
- Recent Fortinet and Trend Micro cases show how endpoint security and management platforms can become privileged control-plane risk when exploited or abused.
- Security tooling should be assessed by authority, reach, trust, and operational dependency, not only by CVSS score or patch status.
- Mature governance means restricting administrative access, monitoring platform-level changes, and planning for incidents where defensive infrastructure may be degraded or untrusted.
Security products have moved close enough to the core of enterprise operations that they can no longer be governed as ordinary defensive software. Endpoint management consoles, VPN configuration systems, endpoint security agents, detection platforms, and remote response tools now sit inside the machinery of daily operations. They can push software, change policy, collect telemetry, alter access, isolate machines, and shape what an organisation can see during an incident.
Recent disclosures from Fortinet and Trend Micro show how much authority is now concentrated in that layer. Fortinet has confirmed exploitation in the wild of CVE-2026-35616, a critical improper access control vulnerability in FortiClient Enterprise Management Server. The flaw can allow unauthorised code or command execution through crafted requests, and Fortinet has urged affected customers running FortiClient EMS 7.4.5 and 7.4.6 to apply hotfixes.
The operational detail is sharper in Arctic Wolf’s account of exploitation. Its researchers said attackers abused FortiClient EMS deployments to deliver EKZ Infostealer to managed endpoints, with the payload disguised as a Fortinet patch. Malware pretending to be a legitimate update is not new, but the route used in this case is more instructive than the disguise. Attackers were able to lean on a trusted management path, where endpoint infrastructure accepted activity as coming from the system that normally manages it.
Trend Micro’s Apex One bulletin adds a different version of the same problem. The company disclosed several vulnerabilities affecting Apex One and Vision One Standard Endpoint Protection, including CVE-2026-34926, a directory traversal issue in the on-premise Apex One server. The flaw is not the same kind of exposure as Fortinet’s: Trend Micro says an attacker would need access to the Apex One server and administrative credentials obtained by some other method. Even with that condition, the company said it had observed at least one exploitation attempt in the wild, and the vulnerability could allow malicious code to be deployed to agents on affected installations.
Those differences should not be flattened. An unauthenticated critical flaw and a vulnerability requiring prior administrative access do not carry the same immediate risk. Treating every security advisory as if it produces the same exposure leads to poorer decisions, wasted urgency, and, eventually, numbness. Yet the affected system’s role changes the calculation. Once a platform has authority over agents, policies, telemetry, or response actions, the question is not only how an attacker reaches it. The next question is what the platform can do once the attacker is there.
Many organisations still treat security tooling as a protective layer rather than a privileged estate. That assumption made more sense when defensive products were narrower, more local, and easier to separate from wider operations. It is less credible in enterprises where endpoint detection and response, VPN clients, SaaS security brokers, identity integrations, remote management tools, and managed detection services are stitched into daily business. A security console may not be labelled as a domain controller, but it may be able to affect large parts of the estate with comparable speed.
The weakness is often structural as much as technical. Security platforms may be procured by one team, administered by another, supported by a managed provider, and relied upon by incident responders who assume the same tools will remain trustworthy during a crisis. Administrative accounts for those platforms may not be governed with the same discipline as privileged infrastructure accounts, even when the platforms can deploy software, change enforcement settings, or suppress visibility across thousands of devices. In some estates, security tools escape the hardening standards applied to ordinary servers because they are categorised as part of the defence.
That categorisation is increasingly unsafe. Security products need rapid patching, but patching alone cannot carry the whole risk. Endpoint and security management platforms need to be understood as control planes. The relevant questions are architectural: which systems can change policy across the estate, push code, disable protections, alter VPN access, collect sensitive telemetry, or shape incident response? Which platforms would responders still depend on if ransomware, credential theft, or a supplier compromise were already under way?
Those questions bring defensive infrastructure into the same conversation as identity providers, cloud management consoles, CI/CD systems, and privileged access platforms. The technologies differ, but the risk pattern is familiar: concentrated authority creates a wider blast radius. Compromise of a single endpoint is damaging; compromise of the system that manages endpoints can change the shape of the incident.
A stronger operating model would treat security platforms as crown-jewel systems. Administrative access should be separated, tightly monitored, and protected with phishing-resistant multi-factor authentication where possible. Bulk policy changes, agent deployments, remote script execution, sensor disablement, exception creation, and unusual administrative sessions should leave independent evidence, not only logs inside the same platform being administered. On-premise management servers need segmentation and access restrictions that reflect their authority over the endpoint estate, rather than merely their location in the network.
Outsourced security operations need the same scrutiny. Where a managed security provider or incident response partner holds administrative access to endpoint or detection platforms, supplier assurance should examine what the provider can do inside the customer environment, how those actions are authorised, and how they are logged. A contractual promise to protect the customer does not replace an architectural control limiting what happens if a provider account, platform integration, or shared management process is compromised.
Incident exercises also need fewer optimistic assumptions. Many scenarios assume endpoint security remains available, accurate, and trusted. A more realistic exercise includes conditions where defensive telemetry is degraded, the management console is suspected of abuse, agent policy cannot be trusted, or responders need an independent route to validate what is happening. Recovery plans should include the systems used to investigate and contain an incident, not only the business systems damaged by it.
Security tools remain essential, and both vendor and customer responsibilities sit inside the same risk picture. Vendors need secure-by-design engineering, rapid fixes, clear advisories, and supportable upgrade paths. Customers need governance that reflects what the tools can do, not what category they sit in on a procurement form. Endpoint management and security platforms now form part of the machinery through which resilience is delivered. Infrastructure with that level of reach needs controls of its own.
