Insights
The first sign isn’t an alert.
It’s a new admin account.
No one remembers creating it. No ticket. No change request. No reason for it to exist at all. And yet, there it is, sitting inside the system that’s supposed to control access to everything else.
At first glance, nothing seems wrong. The firewall is still running. Traffic is flowing. Users are logging in without issue. There are no outages, no ransom notes, no obvious indicators of compromise.
But the damage has already started.
In recent campaigns targeting Fortinet FortiGate appliances, attackers have exploited unpatched vulnerabilities to quietly create unauthorized administrative access and extract configuration data. From that point forward, they are no longer outsiders trying to break in. They are operating inside the control layer of the network itself. This marks a critical shift in how attacks unfold. Security infrastructure, once treated as the strongest line of defense, is now becoming the primary target. For MSPs supporting SMB environments, this changes the equation entirely. Protecting endpoints and users is no longer enough. The systems designed to enforce security must now be secured with the same level of scrutiny.
When Security Appliances Become Entry Points
Security appliances—such as firewalls, VPN gateways, and secure access systems—are designed to sit at the center of an organization’s security architecture. They control how traffic flows, how users connect, and how access is granted across the environment.
In recent months, attackers have increasingly targeted vulnerabilities in widely deployed security appliances, including Fortinet FortiGate systems. These campaigns aren’t focused on disrupting operations immediately. Instead, they’re designed to establish quiet, persistent access at the infrastructure level.
One commonly observed technique involves exploiting authentication or interface vulnerabilities to create unauthorized administrative accounts. Once these accounts are in place, attackers can interact with the appliance as if they were legitimate administrators. This includes accessing configuration files, reviewing policy settings, and understanding how traffic is routed and secured within the environment.
Configuration data is particularly vulnerable. It can reveal VPN settings, authentication methods, IP ranges, and integrations with identity providers or other systems. With this level of visibility, attackers gain a detailed map of the network without needing to scan it directly.
This type of access changes the nature of the breach. Instead of working from the outside in, attackers begin from a position of control within the security layer itself. The appliance becomes both the vantage point and a gateway, allowing them to observe, plan, and move without raising immediate suspicion. For MSPs, this introduces a different kind of risk. Security appliances are often treated as stable, trusted components once deployed. When those systems become entry points, the assumptions that underpin network security need to be reevaluated.
Why Attackers Target Security Infrastructure
Security appliances sit in a unique position within an environment. They are not just another system to protect. They are responsible for enforcing how everything else is protected.
That position makes them exceptionally valuable to attackers.
From a single appliance, it’s often possible to understand how users authenticate, how traffic flows between systems, and how access is granted or restricted. These systems frequently store configuration data that reflects the organization's broader security architecture, including integrations with identity providers, VPN settings, and access policies.
This level of visibility removes much of the guesswork attackers typically rely on. Instead of probing the network and triggering detection mechanisms, they can study the environment from a trusted vantage point.
Once access is established, the next phase is internal reconnaissance. Attackers begin mapping systems, identifying high-value targets, and understanding which pathways allow movement between applications or environments. Because this activity is performed through legitimate administrative access , it often blends into normal operational behavior. Security infrastructure also enables a form of persistence that is difficult to detect. Administrative accounts created within these systems can remain active without interfering with day-to-day operations. At the same time, attackers can leverage built-in tools and functions to move laterally or extract data without introducing foreign software. This approach, often described as “living off the land,” allows them to operate within the boundaries of what the system is designed to do. For MSPs, the implication is clear. When a security appliance is compromised, the attacker is not just gaining access to a single system. They’re gaining insight into how the entire environment is secured, along with the ability to operate within it using trusted mechanisms.
Why SMBs and MSPs Are Especially at Risk
The risks associated with compromised security appliances are shaped as much by the environment as by the vulnerability itself. In SMB environments, security infrastructure is often deployed to provide immediate protection, then left largely unchanged as the organization grows.
Over time, configurations that were appropriate at deployment may no longer reflect how the business operates. Administrative access expands to accommodate new users, integrations are added to support additional tools, and patching schedules compete with day-to-day operational demands.
In many cases, SMBs operate without the regulatory or compliance requirements that drive more formal security practices. Processes such as periodic access reviews or vendor security assessments are not always established, which can lead to gaps in how access is granted, maintained or monitored over time.
Security controls in these environments often evolve based on immediate operational needs rather than a consistent governance model. As a result, access to critical systems may persist longer than intended, and changes to infrastructure may not be reviewed with the same level of scrutiny.
Visibility into these systems is also limited. Many SMBs don’t monitor administrative activity on security appliances in the same way they monitor endpoints or user accounts. As a result, unauthorized changes—such as the creation of new administrative accounts—may go unnoticed if they don’t immediately disrupt operations.
For MSPs, the challenge extends across multiple environments.
Each client may have a different configuration, patching cadence, and approach to administrative access. Some environments enforce such strong authentication controls, while others rely on shared credentials or legacy access methods. Maintaining consistency across these environments requires time and coordination, both of which are often constrained by operational demands.
This variability creates gaps that are difficult to track. A vulnerability in one appliance, a delayed patch in another, or an overlooked administrative account in a third can all introduce risk. Because these systems sit at the center of network control, the impact of a single compromised appliance can extend beyond one user or one application.
In this context, the challenge is not just securing individual devices. It’s maintaining consistent control over how critical infrastructure is accessed across all environments.
How These Attacks Actually Unfold
The initial entry point is often a known vulnerability that hasn’t yet been patched or fully mitigated. Exploitation does not require significant disruption. A successful request against an exposed interface is enough to establish privileged access to the appliance.
From there, control is expanded quietly.
Administrative accounts may be created or modified to ensure continued access. Because these changes are made through the system’s own management interface, they can appear indistinguishable from routine administrative activity. In environments where multiple individuals have administrative access, identifying the origin of these changes becomes even more difficult.
Configuration data is typically accessed next. These files provided a detailed view of how the environment is structured, including authentication methods, network segmentation, VPN configurations, and connections to other systems. This stage functions as internal reconnaissance, allowing attackers to understand where valuable data resides and how it can be reached.
Once this information is gathered, the appliance itself becomes a staging point. Access can be used to move into connected systems, monitor traffic patterns, or identify opportunities to escalate privileges further. Because these actions rely on legitimate access and built-in functionality, they rarely trigger the types of alerts associated with malware or external intrusion. The timeline of the attack can extend over days or weeks. During that time, activity remains consistent with normal system behavior, making it difficult to distinguish between authorized use and malicious intent—espeically in environments where administrative access isn’t tightly controlled or centrally monitored.
Where Traditional Security Practices Fall Short
Security appliances are typically deployed with the expectation that they’ll enforce protection consistently over time. In practice, the controls surrounding these systems often evolve unevenly.
Patching remains one of the most widely recommended defenses, but it’s rarely immediate. Updates may be delayed to avoid operational disruption, scheduled around maintenance windows, or deprioritized when no active issues are visible. This creates exposure windows where known vulnerabilities remain accessible longer than intended.
Administrative access introduces a separate layer of risk. Credentials are sometimes shared across teams, reused between systems, or managed outside of a centralized identity framework. Over time, it becomes difficult to track who has access, how that access is authenticated, and whether it still aligns with current responsibilities.
Visibility into administrative activity is also limited. While appliances generate logs, those logs aren’t always aggregated, reviewed, or correlated with identity activity across the broader environment. Without a clear view of authentication events and configuration changes, unauthorized actions can remain undetected.
Configuration management presents another challenge. Each appliance may be configured slightly differently depending on when it was deployed, who set it up, or which client environment it belongs to. These differences introduce inconsistencies in how security controls are applied and maintained.
Taken together, these gaps point to a broader issue. Security infrastructure is often protected through device-level controls, while access to that infrastructure is managed separately—or not managed consistently at all.
The Role of Identity in Securing Security Infrastructure
Security appliances are designed to enforce policy across an environment. At the same time, they depend on administrative access to function. That access becomes the control point through which the entire system can be configured, modified, or bypassed.
Securing the appliance therefore depends on controlling who is’ allowed to operate it.
Identity provides the structure for that control, aligning with Zero Trust principles where access is continuously verified rather than implicitly trusted.
Rather than relying on locally managed credentials or appliance-specific authentication, access to administrative interfaces can be governed through centralized identity policies. This allows authentication requirements, access conditions, and privilege levels to be defined consistently across environments instead of being configured independently on each device.
Strong authentication is one part of that model. Requiring multi-factor authentication for administrative access reduces the likelihood that compromised credentials alone can be used to gain control of critical systems. The effectiveness of this control increases when it’s applied uniformly across all environments and not limited to select users or devices.
Access conditions add another layer of control. Restricting administrative access based on IP ranges, time of day, or expected usage patterns helps ensure that privileged actions occur only within defined boundaries. When access attempts fall outside those conditions, additional verification can be required or access can be denied entirely.
Device trust further narrows the scope of access. By allowing only approved devices to interact with administrative interfaces, organizations can prevent login attempts from unrecognized systems—even when the credentials are valid. This becomes particularly relevant in scenarios where credentials are exposed through phishing or other forms of social engineering.
Access policies can also be aligned with defined user groups and privilege levels. Limiting administrative capabilities to specific roles reduces the number of accounts that can make critical changes and helps contain the impact of a compromised identity. Together, these controls shift security away from individual devices and toward a consistent model for managing access to critical infrastructure. The appliance continues to enforce policy, but identity determines who has the authority to define and modify that policy in the first place.
How HENNGE Identity Secures Access to Critical Infrastructure
Administrative access to security appliances is often managed locally, using credentials that are specific to the device. Over time, this approach creates inconsistencies in how access is controlled, especially across multiple environments.
HENNGE Identity introduces a centralized layer for managing how users authenticate before reaching administrative interfaces. Instead of relying solely on appliance-native login mechanisms, access can be routed through a federated identity provider that enforces consistent authentication policies.
This allows administrative access to be governed with the same level of control applied to other critical systems.
Multi-factor authentication can be enforced uniformly for privileged users, reducing the likelihood that compromised credentials alone can be used to gain control of a security infrastructure. Because policies are applied centrally, these controls remain consistent across environments rather than depending on individual device configurations.
Access conditions can be defined to limit when and where administrative actions are allowed. Restrictions based on IP ranges, time windows, or expected usage patterns help ensure that access occurs within controlled parameters. Attempts that fall outside these conditions can be blocked or require additional verification.
Device certificates provide an additional layer of assurance. By requiring administrative access to originate from approved devices, organizations can prevent login attempts from unrecognized systems. This reduces the effectiveness of credential-based attacks, even when valid usernames and passwords are obtained.
Access can further be structured through user and group-based policies. Defining administrative roles clearly limits who can make changes to security appliances and reduces the number of accounts with elevated privileges.
Centralized logging also improves visibility into administrative activity. Authentication events and access patterns can be monitored across environments, making it easier to identify unexpected behavior and investigate potential compromise.
For MSPs managing multiple client environments, these controls create a consistent model for securing access to critical systems. Administrative access is no longer defined by individual device settings, but by identity policies that can be applied and maintained at scale.
Securing the Systems That Secure Everything Else
Security infrastructure has traditionally been treated as a fixer layer of protection. Once deployed and configured, it’s expected to operate quietly in the background, enforcing policy and blocking threats.
The assumption no longer holds.
As recent FortiGate campaigns demonstrate, these systems are now being targeted directly. When attackers gain access to security appliances, they’re not just bypassing defenses—they’re operating within them. Visibility, control, and trust all shift in their favor.
Protecting these systems requires more than patching vulnerabilities or maintaining configurations. It requires controlling how access to them is granted, monitored, and restricted over time. Identity-driven controls bring consistency to that process, ensuring that administrative access is limited, verified, and continuously evaluated.
For MSPs, this represents a broader responsibility. Securing endpoints and applications remains important, but the systems that enforce security policies must now be treated with the same level of scrutiny. Consistent access control across environments becomes essential to maintain that trust.
If you’re evaluating how to better protect security infrastructure across your client environments, HENNGE Identity helps enforce strong authentication, apply context-aware access controls, and secure administrative access to critical systems.
To learn more about how HENNGE Identity can strengthen your approach to infrastructure security, contact us to start a conversation. You can also subscribe to the blog for ongoing insights into emerging cybersecurity threats affecting MSPs and SMBs.
