An industrial manufacturer runs converged IT, operational technology, remote support and cloud-hosted security services. It asked us for a remote threat analysis and risk assessment covering segmentation, administrative access, identity resilience, remote connectivity, monitoring and recovery readiness.

The challenge

The manufacturer had invested in firewalls, centralized authentication, remote-support capabilities, network access controls and passive OT monitoring. Its architecture diagrams showed separation between enterprise, site infrastructure, management and production environments.

What remained unclear was whether the controls worked together as intended. The organization needed practical answers:

  • Where was network segmentation actually enforced?
  • Could internal traffic bypass an expected inspection point?
  • Which administrative and vendor-access paths could reach operational systems?
  • What would happen if centralized identity or connectivity services failed?
  • Could existing monitoring detect and reconstruct activity across IT and OT boundaries?
  • Which risks needed immediate containment, and which needed further operational validation?

The goal was to connect technical conditions to credible attack paths and their potential operational consequences.

How we assessed it

We worked remotely and designed the assessment to keep production running undisturbed.

Reconstructing the environment from evidence

We consolidated network and security-device configurations, firewall and routing policies, topology records, identity and authentication settings, remote-access information, asset and software data, monitoring and logging configurations, and input from operational stakeholders.

Every conclusion was classified as one of four kinds:

  • Directly observed
  • Inferred from supporting evidence
  • Requiring runtime or version validation
  • Requiring a controlled operational test

That kept assumptions from being presented as confirmed facts.

Mapping zones, conduits and dependencies

We organized the environment into functional security zones: enterprise services, site infrastructure, administrative functions, operational services, control-system networks, remote-support paths and shared security dependencies. Communications between zones were examined as conduits. For each one we asked where traffic entered and left, which device enforced the policy, how identities were authenticated, and what telemetry would exist during an incident.

The method drew on IEC 62443 zone-and-conduit principles, MITRE ATT&CK for ICS and cross-sector practice. These frameworks informed the analysis. The engagement was not a certification or a compliance audit.

Comparing intended design with effective traffic paths

Topology diagrams show design intent. Routing tables, interfaces, access-control rules and firewall policies show where traffic can actually travel. We compared the two to find places where the effective path could differ from the expected security path.

Conceptual diagram: traffic from enterprise services passes an inspection firewall on its way to production, while traffic from a management zone is routed locally at a Layer 3 boundary and reaches production without passing the firewall.

An upstream firewall drawn between two network areas cannot inspect traffic that is routed locally at a downstream Layer 3 boundary. Where that happens, enforcement has to move to where the traffic is: switch access-control lists, routing separation, internal security zones or a deliberately designed segmentation firewall.

Building scenario-based risks

Related conditions were combined into attack scenarios with one structure:

Scenario structure: threat source, access path, control weakness, affected asset or process, operational consequence.

This showed how several moderate weaknesses could combine into a more significant operational risk. We also separated systems that could be affected from confirmed vulnerability exposure. Where a software version, runtime behavior or exploit prerequisite could not be demonstrated, the uncertainty became a validation requirement.

Turning findings into a roadmap

Recommendations were grouped into immediate containment, near-term engineering and longer-term resilience. Each major recommendation carried its proposed closure evidence: configuration read-back, path testing, software-version confirmation, credential-rotation records, controlled failover exercises, monitoring verification or accountable owner approval.

What the assessment found

Segmentation existed in design; enforcement needed stronger assurance. The environment had multiple logical segments, but configuration evidence raised credible concerns that some internal traffic could avoid the inspection point stakeholders expected it to cross. The remediation question moved from "Is there a firewall?" to "Which control evaluates this packet path?" We recommended validating routing behavior and enforcing policy at the actual Layer 3 boundaries.

Identity and administrative access formed one connected attack surface. Centralized authentication improved accountability and also created dependencies on shared identity services and connectivity. During a partial or full loss of those services, local fallback accounts, broadly reused credentials and inconsistent emergency-access controls could open alternate administrative paths with less oversight. The roadmap calls for unique emergency credentials, tightly controlled storage, strong authentication, restricted administrative reachability and controlled testing of primary, secondary and local fallback behavior.

Remote-support paths needed clearer control and ownership. Approved remote-access mechanisms coexisted with support paths governed to a different standard. We traced each chain end to end:

  1. How the user or vendor authenticated
  2. Where the session entered the environment
  3. Whether it passed an approved broker or jump point
  4. Which management or operational assets it could reach
  5. Whether the activity was attributable and logged
  6. What happened if a central dependency became unavailable

Recommendations include time-bound vendor access, explicit source and destination restrictions, stronger session accountability and periodic recertification of every remote-support path.

Installed monitoring still needed the right traffic. A passive OT monitoring capability was installed but was not receiving the traffic feed it needed to observe important industrial communications. The investment existed; the telemetry did not. Security tools should be tested against the scenarios they are expected to detect, so the roadmap covers sensor traffic, coverage of key east-west and north-south flows, alert ownership and representative detection testing.

Logging and time integrity limited incident reconstruction. Incomplete central logging and inconsistent time synchronization made it hard to correlate activity across identity, firewall, switching, remote-access and operational systems. We recommended trusted time sources, central forwarding of security-relevant records, defined retention, and a test of whether events can be reconstructed across platforms.

Asset, software and resilience evidence was incomplete. The available information did not give a fully authoritative inventory of assets, software versions, dependencies or recovery requirements. Each gap was recorded as a governed work item: authoritative discovery, software-lifecycle verification, dependency mapping, recovery objectives and controlled resilience testing. Full business-impact and process-consequence data were not available, so risk ratings stand as technical priorities until operational stakeholders validate them.

The roadmap

Immediate containment

  • Rotate exposed or broadly reused administrative credentials.
  • Restrict unnecessary management and remote-access exposure.
  • Protect sensitive technical evidence and configuration material.
  • Restore the traffic feeds and logging critical monitoring depends on.
  • Verify high-priority software exposure against authoritative vendor information.

Near-term engineering

  • Enforce segmentation at the actual routing and traffic boundaries.
  • Replace broad communication rules with least-privilege policies.
  • Broker and constrain privileged remote access.
  • Strengthen authentication fallback and emergency-access controls.
  • Centralize security-relevant logs and establish reliable time synchronization.
  • Validate identity, monitoring and connectivity failover in controlled change windows.

Longer-term resilience and governance

  • Maintain an authoritative asset, software and connectivity inventory.
  • Reduce single points of dependency in identity, management, logging and monitoring.
  • Introduce recurring access reviews and configuration assurance.
  • Exercise incident-response and recovery procedures safely.
  • Assign owners, target dates, dependencies and acceptance authority to material risks.
  • Require implementation evidence and effectiveness testing before lowering a risk rating.

What the manufacturer received

  • An architecture baseline grounded in configuration evidence
  • A zone-and-conduit model for evaluating segmentation
  • Attack-path narratives with their assumptions stated
  • A prioritized, scenario-based risk register
  • A record of evidence gaps and the validation each one needs
  • A phased technical remediation roadmap
  • Defined evidence for showing whether each recommended control works

The assessment established what needs to change, why it matters, and what the organization must prove before a risk can credibly be considered closed. Risk reduction is measured after the work is done and verified.

Lessons for industrial organizations

  1. Diagrams describe intent; packet paths reveal enforcement. Validate segmentation against routing and policy evidence.
  2. A boundary reduces risk only when an effective control governs the traffic crossing it. VLAN count measures something else.
  3. Identity paths are security conduits too. Assess central authentication, local fallback, shared secrets and remote administration together.
  4. Confirm what your monitoring can see. Check that sensors receive the right traffic and can detect the scenarios that matter.
  5. Make uncertainty explicit. Confirmed findings, probable exposure and validation gaps each need different treatment.
  6. Lower residual risk after verification. A rating moves once a control is implemented and its effectiveness is shown.
  7. Close findings with an owner, evidence and an authorized treatment decision. A recommendation alone is where closure starts.

A credible OT risk assessment explains how the environment actually works, shows how weaknesses combine, and gives engineering and leadership a shared basis for deciding what to address first. For this manufacturer, it replaced assumptions with evidence and a practical roadmap for measurable improvement.

If your diagrams and your configurations might tell different stories, ask about an OT assessment or see how we approach OT security.