Why Security Tools Fail When the Network Foundation Is Shaky

Security teams invest in firewalls, endpoint detection platforms and other controls to reduce risk. But those tools rely on something that is easy to overlook: a network that is physically sound, properly designed and consistently managed.

A firewall cannot inspect traffic that never reaches it. An endpoint detection platform cannot report reliably from a device that keeps dropping off the network. And segmentation on a diagram does not create meaningful separation if the switching underneath it is misconfigured or incapable of enforcing it.

That is the security tool dependency problem: controls are only as dependable as the infrastructure they depend on. In my experience across office fit-outs, corporate networks and operational technology (OT), the root cause behind a security gap is sometimes not a sophisticated exploit. It is a loose patch lead, an undocumented switch, a fibre fault or an unexpected path between network zones.

Physical infrastructure is not separate from cybersecurity. It is part of it.

Security starts before the firewall

It is tempting to think of cybersecurity as a stack of software and policies: identity controls, monitoring, endpoint agents and firewall rules. But every packet begins somewhere physical. It travels across copper or fibre, through patch panels and switches, and along a path that should be understood and controlled.

If that path is unreliable or undocumented, security controls inherit the uncertainty. Teams may not know which switch a device is connected to, which VLAN it belongs on, whether a link is carrying traffic for multiple zones, or whether a recent change has created an unintended route.

That uncertainty has practical consequences. A firewall rule may be carefully reviewed, but a device connected through an unmanaged switch can undermine the assumptions behind the design. A monitoring system may show an endpoint as offline, while the actual cause is a failing port or a damaged cable. An incident responder may be looking for malicious activity when the real issue is a loop, a mispatched connection or a link that is flapping.

None of this makes physical faults “just an IT CAT6A cabling shielding required issue”. They can affect availability, visibility and the ability to contain an incident. Those are security outcomes.

How physical layer faults create blind spots

The physical layer is where many network problems first appear: damaged cabling, poor terminations, failing optics, incorrect patching, power problems or environmental issues. Some faults are obvious because a link is down. Others are intermittent, which makes them harder to diagnose and more likely to be mistaken for application or security problems.

Consider a link that drops out briefly several times a day. Monitoring might record gaps. An endpoint detection platform may miss activity during a disconnection, delay a report or show a device as unavailable. A security analyst who relies on that telemetry needs to know whether the absence of data means “nothing happened” or “the endpoint was not communicating”. Those are very different conclusions.

Physical faults can also disrupt the visibility provided by network monitoring and security controls. If traffic is routed over an unexpected path, a sensor might no longer see the flows it was configured to observe. If a connection is bypassing an intended inspection point, a firewall cannot enforce controls on traffic that does not traverse it. The firewall may be healthy and correctly configured; the network path may simply not be what the team believes it is.

Availability failures can become security failures, too. During an outage, people often look for a quick workaround: a spare switch gets plugged in, a device is moved to another port, or a temporary connection is left in place. If that change is not recorded and reviewed, it can create a new route or extend a network zone without anyone intending to do so.

Common warning signs

Intermittent connectivity that is routinely dismissed as “just a cabling issue”.
Unmanaged switches appearing in production, especially in sensitive areas.
Patch panels and ports without clear, current labels.
Devices that move between ports or locations without a corresponding network change record.
Monitoring gaps that are treated as proof that no suspicious activity occurred.
Temporary workarounds that remain in place long after the outage is fixed.

I keep a label maker in my laptop bag because clear labelling is not cosmetic. It helps engineers trace paths, verify changes and respond faster when something fails. Mystery cables are a security smell: if nobody can identify what a connection serves, it is difficult to assess what it could expose.

Segmentation depends on the switching underneath

Segmentation is often discussed as a matter of VLANs, firewall rules and network diagrams. Those are important, but the design has to be implemented by switching and routing equipment that can enforce it correctly. A collection of subnets on paper is not the same as effective separation in production.

Good segmentation starts with a clear understanding of assets and trust boundaries. Corporate user devices, servers, building systems and OT equipment may have different risk profiles and operational needs. The design should specify how those zones communicate, which traffic must be inspected, and which routes should not exist. Switching, routing and firewall configurations then need to make those boundaries real.

There are several ways the foundation can undermine the design. Incorrect VLAN assignments can put devices in the wrong zone. Trunks configured too broadly can carry networks where they are not needed. A misconfigured access port can expose a device to the wrong services. An unmanaged switch can make it harder to control, document or monitor what is connected. And inconsistent configurations can leave one path less protected than the others.

Equipment selection matters, but the logo alone is not a security architecture. Organisations may use platforms from Cisco, industrial networking equipment from MOXA, or network visibility products from Garland. Each can play a useful role in an appropriate design. The important questions are whether the equipment supports the required controls, whether it is configured and maintained correctly, and whether its role in the traffic path is documented.

In OT environments, segmentation also needs to respect operational constraints. A control system may require specific communications to keep a process safe and available. Applying a generic corporate template without validating the dependencies can cause outages—or lead teams to create unreviewed exceptions when the template gets in the way. Security design has to work with the real environment, not just the drawing.

Foundation issue Possible security consequence Practical check Unmanaged switch in a production area Reduced control and visibility over connections and traffic paths Identify the device, document its purpose and replace or govern it appropriately Incorrect VLAN or trunk configuration Devices may cross intended trust boundaries Compare live configurations with the approved design and test allowed paths Intermittent cabling or power fault Telemetry gaps, unstable controls or delayed incident response Correlate link events, switch logs and endpoint reports before drawing conclusions Unlabelled patching and undocumented changes Unknown connectivity and slower containment during an incident Maintain accurate port, panel and device records; update them after each change

Firewalls and endpoint detection need a reliable path

Firewalls are essential controls, but their protection depends on traffic passing through the expected interfaces and policies being applied to the correct zones. If the topology is poorly understood, teams may write rules against an inaccurate picture of how systems communicate. That can lead to overly broad exceptions, broken business services or traffic taking a route that avoids the intended inspection point.

Endpoint detection platforms have a different dependency. They rely on agents, operating systems and communications paths to collect and report useful information. A healthy network does not guarantee good endpoint visibility, but an unreliable one makes it harder to distinguish an actual security event from a connectivity problem. If agents repeatedly lose contact, analysts need to know whether that reflects an endpoint issue, a network fault or something more suspicious.

The right response is not to distrust these tools. It is to avoid treating their dashboards as the whole truth. A security alert, a missing heartbeat and a switch port that has been flapping may be related pieces of evidence. Correlating them gives the response team a better picture than relying on any single console.

ACSC guidance and the foundation beneath it

Australian organisations often look to the Australian Cyber Security Centre (ACSC) for practical guidance on reducing cyber risk. Applying that advice effectively requires more than purchasing a product or ticking off a control. Measures such as controlling access, maintaining visibility, separating environments and responding to incidents all depend on knowing what is connected and how traffic moves.

That is why ACSC-aligned security work should be considered alongside network design and operational practices. The guidance is not a substitute for reliable cabling, capable switching, accurate configuration records or disciplined change management. Those foundations make it possible to implement and verify controls consistently.

For example, an organisation cannot confidently enforce separation if it has not mapped the links and devices that connect its zones. It cannot investigate an alert efficiently if asset records are out of date and physical connections are unknown. And it cannot judge whether monitoring is complete if it does not understand where traffic should be visible.

Sound foundations do not make an organisation immune to attack. They do make security measures more dependable—and make it easier to spot when reality no longer matches the design.

Build reliability into security operations

Network reliability should be addressed as part of security planning, not postponed until an incident reveals the gaps. The goal is not to make every environment complicated. It is to make connections deliberate, boundaries testable and failures diagnosable.

Know what is connected. Keep an accurate inventory of switches, endpoints, links and network zones. Record where critical systems physically connect, not only their IP addresses.
Document and label infrastructure. Label patch panels, switch ports and fibre links in a consistent way. Keep diagrams and records current when changes are made.
Control production switching. Avoid unmanaged equipment in production. Where specialist or legacy equipment is necessary, document its purpose, access and limitations.
Validate segmentation in practice. Test whether permitted and prohibited communications behave as the design intends. Review configurations after changes, not only during the initial project.
Correlate security and network evidence. During investigations, compare firewall events and endpoint alerts with switch logs, link state, power events and known maintenance activity.
Plan for failure. Ask the question I ask on every project: what happens at 2am when this fails? Define who can diagnose it, what records they need and how to restore service without creating an unsafe workaround.

The bottom line

Security tools do not operate in isolation. Firewalls need predictable traffic paths. Endpoint detection platforms need reliable communications. Segmentation needs capable switching, correct configuration and a design that reflects the real environment. Monitoring and incident response need trustworthy records of what is connected and where.

Physical layer reliability is therefore a security concern, not a facilities footnote. When cables are unidentified, switches are unmanaged or network paths are poorly understood, controls can become less effective and blind spots can grow. The fix is not another dashboard. It is a sound network foundation, backed by disciplined operations and designs that can be verified.

Before asking whether the security tools are working, ask whether the network beneath them is doing what everyone thinks it is doing. That question can save a lot of time—and, at 2am, a lot of guesswork.