How to Check If Your Network Is Ready for a Zero-Trust Approach

Zero trust is often described as a change in security policy: verify every request, grant only the access needed, and keep checking that access remains appropriate. But a policy cannot compensate for a network that nobody can accurately map, switches that cannot enforce the intended boundaries, or patch panels full of mystery cables.

Before investing in new controls, check whether the foundations can support them. A zero-trust approach depends on trustworthy information about users, devices, applications and traffic. It also depends on the physical and logical network carrying that traffic. If the foundations are unreliable, security tools may see an incomplete picture, segmentation may fail in unexpected ways, and routine faults can become security blind spots.

This guide structured cabling sets out a practical readiness check for Australian organisations. It covers network segmentation, identity access management, operational technology (OT), endpoint detection platforms and firewalls, with a focus on the infrastructure that makes zero-trust architectures work in practice.

Start with what zero trust means for your network

Zero trust is not a single product or a switch you turn on. It is an approach to limiting access and continually checking whether a user, device or service should be allowed to communicate with a particular resource. Instead of treating everything inside the corporate network as trusted, you make access decisions using identity, device state, policy and context.

That does not mean every organisation needs the same design. A corporate laptop accessing a cloud application, a contractor connecting to a building management system and a controller communicating with an OT historian have different requirements. The aim is to define and enforce appropriate access for each case, while keeping essential services reliable.

ACSC guidance is a useful reference when shaping security controls, but those controls rely on sound network foundations. Identity access management (IAM) cannot reliably control access if accounts and devices are poorly understood. Network segmentation cannot deliver its intended protection if the switching design permits unintended paths. Logging and monitoring cannot tell the whole story if network faults or unmanaged equipment hide traffic.

1. Establish an accurate picture of the network

You cannot protect what you cannot identify. Begin by building a current view of the environment, including office networks, data centres, cloud connections, remote access, wireless, guest access and OT. Include the physical paths as well as the logical ones: switches, routers, firewalls, wireless access points, fibre links, copper runs and any intermediate devices.

Compare what your diagrams say with what is actually installed. Walk the comms rooms and check rack layouts, switch ports, patch panels, uplinks and labels. If a device or cable cannot be confidently identified, treat it as an investigation item rather than assuming it is harmless. A label maker is a small investment compared with tracing an unlabelled link during an outage.

Useful evidence includes:

• An inventory of network devices, operating systems, owners and support status.
• Current physical and logical diagrams, with links, VLANs, routing and security boundaries shown.
• A record of unmanaged switches, temporary connections and equipment with unknown ownership.
• Known communication flows between users, devices, applications and services.
• Dependencies on DNS, DHCP, time services, identity providers and management systems.

Do not assume that a discovery scan will reveal everything. Passive devices, specialist OT equipment and intermittently connected endpoints may be missed or misidentified. Validate findings with system owners and site staff, and agree how to assess sensitive equipment safely.

2. Check the physical layer as a security control

Physical infrastructure is part of cybersecurity, not a separate facilities concern. Cabling, cabinets, power, cooling and access to communications rooms all influence who can connect to the network and whether security controls remain available. Physical layer faults can cause outages, but they can also create security blind spots.

For example, a damaged fibre link may prompt someone to install an unmanaged switch as a quick fix. A poorly documented patch can connect a restricted device into the wrong network. A failing uplink can cause traffic to take an unexpected route, while a mislabelled port can leave an endpoint outside the intended monitoring or policy boundary. These are not merely housekeeping issues; they affect the network’s trust assumptions.

Inspect comms rooms and cable pathways for:

• Unlabelled patch panels, unexplained cables and undocumented connections.
• Unmanaged or unauthorised switches, including devices added during urgent troubleshooting.
• Inadequate physical access controls, environmental protection or resilience for critical equipment.
• Single points of failure in uplinks, power, cooling or key network services.
• Temporary bypasses that have not been removed or formally approved.

Set clear rules for changes: who can patch, how a connection is recorded, how temporary workarounds are approved, and who verifies that they are removed. Test the operational process, not just the equipment. Ask the question I always ask: what happens at 2am when this fails? If the on-call engineer cannot identify the affected link or safely restore service, the design needs more than a security policy.

3. Test whether network segmentation is real

Network segmentation is one of the practical foundations for reducing unnecessary access. It can limit how far an intruder or compromised device can move, and it can help separate users, services, guests, management systems and OT. But drawing VLANs on a diagram does not prove that meaningful boundaries exist.

Review the design from end to end. Check that switching, routing and policy enforcement match the intended zones. Confirm that inter-segment traffic passes through the appropriate controls and that the rules allow only justified communications. A firewall may sit between two networks, yet an alternate route, permissive trunk or misconfigured switch could bypass it.

Readiness question What to verify Are there defined security zones? Document the purpose, owner and expected devices or services in each zone. Can traffic cross zones without an explicit decision? Review routing, trunking, access control lists and firewall rules for unintended paths. Are rules based on business need? Identify broad “any-to-any” access, stale exceptions and rules without an owner or expiry. Can the switching estate enforce the design? Check platform capabilities, configuration consistency, support status and management access. Are OT boundaries handled safely? Validate required flows with OT owners and test changes in a controlled way.

Segmentation depends on capable switching and correct design. Features such as VLANs, access controls, authentication and monitoring need to be available, configured consistently and supported by the operational team. The right equipment varies by environment: Cisco may be part of a corporate switching and routing estate, while MOXA products may be relevant in industrial environments. The brand is not the security control. Configuration, lifecycle management and fit for purpose are what matter.

Likewise, specialist visibility products such as those from Garland may be considered where teams need access to network traffic for monitoring or security analysis. Whatever the platform, confirm that its placement and connections do not introduce a new bypass, failure point or unmonitored path.

4. Align identity access management with network access

Zero-trust architectures need dependable identity. Review how staff, administrators, contractors, service accounts and devices are identified and authenticated. Check that access is removed promptly when roles change or accounts are no longer needed. Privileged access deserves particular attention: shared administrator credentials make it difficult to establish who did what and to apply least privilege.

Assess whether IAM is connected to the access decisions you intend to make. Can you distinguish an employee-owned device from a managed corporate endpoint? Can a contractor receive narrowly scoped, time-limited access? Are administrators required to use stronger authentication and separate privileged accounts? Are service accounts owned, documented and reviewed?

Identity alone is not enough. An authenticated account on an unmanaged or compromised device may still present significant risk. Define which device attributes matter, how they are checked, and what happens when a device is unknown, non-compliant or unable to report its state.

5. Check endpoint and network visibility

Firewalls and endpoint detection platforms are important tools, but they are only as effective as the coverage and context they receive. Confirm which endpoints are enrolled, which network zones are monitored, and whether alerts reach a team that can investigate and respond. Identify gaps such as unsupported operating systems, unmanaged devices, OT assets that cannot run agents, and remote endpoints that connect only occasionally.

Check that network and endpoint records can be correlated. If an alert identifies a suspicious device, can the team determine its user, switch port, location, assigned address and recent connections? If a device disappears from monitoring, will anyone notice? Agree how sensor failures, logging interruptions and endpoint exclusions are handled.

Use controlled tests to validate the whole chain: detection, triage, containment and recovery. For OT or safety-critical environments, coordinate tests with operational owners and follow change and safety processes. An alert that nobody sees—or cannot connect to a physical port or asset—is not useful visibility.

6. Treat OT and corporate networks as related, not identical

OT environments often include equipment with long lifecycles, strict availability requirements and communication patterns that differ from office IT. That does not mean they should be left as a flat, trusted network. It means segmentation and access changes need to https://stateofseo.com/how-to-pick-patch-leads-that-do-not-cause-packet-loss/ be designed with an understanding of process dependencies and operational risk.

Identify which systems need to communicate, which connections are remote, and how vendors gain access. Separate management paths where practicable, restrict remote access to approved methods, and monitor permitted flows. Avoid making untested changes simply to achieve a neat diagram. In many environments, a staged approach—starting with visibility and documented flows—is safer than immediately enforcing restrictive rules.

7. Make readiness a repeatable process

A readiness review is not a one-off audit. Networks change as sites expand, equipment is replaced and urgent workarounds accumulate. Put ownership and review cycles around diagrams, inventories, firewall rules, switch configurations, IAM policies and physical access. Record exceptions with a reason, accountable owner, compensating control and review date.

A practical sequence is:

1. Discover: inventory assets, document connections and identify unknowns.
2. Stabilise: remove unauthorised devices, correct labels and resolve unsupported or high-risk infrastructure.
3. Design: define zones, access requirements, identity signals and monitoring needs.
4. Validate: test paths, policies, failover and detection using controlled scenarios.
5. Improve: address gaps in priority order and reassess after material changes.

Signs you are ready to progress

You do not need a perfect network before beginning a zero-trust programme. You do need enough visibility and control to make changes safely. Useful indicators of readiness include:

• Network assets, physical connections and ownership are documented and regularly checked.
• Unknown links, unmanaged switches and temporary workarounds are investigated and controlled.
• Segmentation boundaries are designed, tested and enforced by supported equipment.
• Access rules have clear business owners and are reviewed for unnecessary permissions.
• IAM can distinguish users and relevant device states, with appropriate handling for exceptions.
• Firewalls and endpoint detection platforms provide useful coverage, and alert paths are tested.
• OT changes are coordinated with operational teams and account for safety and availability.
• There is a workable response when a link, device, identity service or monitoring control fails.

Build on foundations you can trust

Zero trust is not a replacement for good network engineering. It makes good engineering more valuable—and exposes the cost of neglecting it. Clear diagrams, controlled physical access, capable switching, well-designed network segmentation and disciplined identity access management give security policies something reliable to act on.

Start by finding the unknowns. Trace the links, verify the boundaries, review who can connect and confirm that monitoring sees the assets that matter. Fix the unlabelled patch panels and mystery cables before they become the explanation for your next incident. When the physical and logical network are understood, zero-trust architectures become a practical programme of measured improvements rather than a promise resting on assumptions.