Typical Starting Point
The production network, office users, IP cameras, guest network and remote access may have grown within the same security zone. This can reduce visibility and expand the impact of a security incident.
Technical Solution Approach
The current topology, critical production devices, internet links, VPN connections and access requirements are analyzed. New firewall capacity is sized; VLANs and security zones are created; NAT/VPN policies are migrated in a controlled manner and required security services are enabled.
Technical Components in Project Scope
- Production / office / guest / IP camera VLAN separation
- Zone-based firewall policies on the NGFW
- Site-to-site and remote-access VPN
- MFA and controlled administrative access
- Endpoint security with EDR/XDR
- Configuration documentation before and after changes
What Is This Architecture Intended to Achieve?
The objective is to improve network visibility, reduce unnecessary access, control remote access and create a layered design that can help limit the blast radius during an incident.
Related Services and Solutions
Architecture and operating model
In production segmentation, firewall rules enforce an observed and validated communication matrix. Record initiating side, protocol, port, session behavior and production justification alongside addresses. For dynamic addressing, multicast or proprietary protocols, test whether a simple static port list is sufficient. Include flows that only appear during shifts, maintenance or product changes.
Enforce policy on a small cell first under controlled conditions. Required traffic and rollback must be ready for a default-deny approach. Stateful inspection and protocol processing can affect device behavior; test latency, loss and vendor support. Enabling a security feature is not evidence that the physical process works correctly.
Maintain rule justification, owner and review date. Scope management services and supplier maintenance separately from production data flows. Broad temporary exceptions should be closed through change records rather than becoming permanent after handover.
- 1Actual communication matrix
- 2Pilot cell policy
- 3Production and deny tests
- 4Owned rule lifecycle
Design parameters
- Production justification
- Record rule owner, initiator, normal/maintenance scope and review date.
- Pilot and rollback
- Test allow/deny and latency on a small cell; prepare rollback within the production window.
- Production dependency
- Record PLC, SCADA, HMI, MES, ERP, identity and time dependencies. Booted systems do not prove safe production readiness.
- Zones and communication
- Derive required sources, destinations, protocols and directions from actual production flows. Separate management, user and control traffic.
- Maintenance and safety
- Coordinate scanning, updates and failure tests with production owners. Device support and safety requirements affect sequencing.
- Recovery access
- Back up programs, recipes, configuration, licensing and hardware dependencies separately. Identify technical and operational acceptance owners.
Worked example
A MES server needs access to collection services in two cells. Confirm which side initiates connections before granting unjustified bidirectional all-port access. Test production records, recipe changes and maintenance in the pilot cell. Record rejection of unauthorized office-VLAN access to the control network. Check differences before extending the policy to the second cell.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Policy works normally but changeover fails | A changeover-only flow may be absent from observations. | Validate shift, changeover and maintenance flows separately. |
| IT systems are restored but production cannot start | Recipes, control programs, time or field connectivity may be missing. | Compare the dependency list with actual line-startup procedures. |
| New policy interrupts production traffic | Protocol, direction or device behavior may have been modelled incorrectly. | Validate flows using approved observation data; roll back under production-owner approval. |
| Backup exists but field system cannot recover | Hardware, version, licensing or programming-tool dependencies may exist. | Test program and recipe recovery on representative spare equipment. |
Acceptance checks
- The same acceptance test should prove authorized production flow and rejection of unauthorized access.
- Exercise the cutover plan with production and safety owners in an approved test.
- Validate required production flows at application and field levels.
- Reject unauthorized IT-to-OT access in a controlled test.
- Record production restart order with owners and durations.
- Test access to backups, programs, recipes and licensing without the main system.
Related concepts
IT/OT security zones
A zone groups assets with similar operational and security requirements; communications between zones should traverse controlled conduits. An accessible OT device is not necessarily safe to scan or update. Control latency, safety, vendor support and maintenance windows influence decisions. Observe actual PLC and SCADA flows rather than copying IT policies unchanged. Define identity, duration, approval and logging requirements for remote support, and coordinate active tests and cutovers with production owners.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, rather than only a list of equipment. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
RTO and end-to-end recovery time
RTO specifies how soon a service must become usable after an incident. Downloading a backup or booting a VM accounts for only part of that duration. Record detection, approval, infrastructure preparation, data transfer, application startup and business validation separately. Define exactly what starts and stops the test clock. The same technical restore duration can produce different business interruptions when dependencies or access approvals introduce additional waiting.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Primary documentation
How This Scenario Was Prepared
Doz Teknoloji Technical Team
This illustrative technical scenario is based on evaluation criteria used by Doz Teknoloji when planning enterprise IT and infrastructure projects.
About Doz TeknolojiTechnical Criteria + Primary Sources
The scenario was reviewed against NIST ICS security guidance and CISA segmentation practices for OT/IT separation, security zones, DMZs and controlled communications.
Improve Decision Quality
To demonstrate how segmentation decisions can be reasoned about in manufacturing networks without presenting the page as a real customer case.
Content and primary sources were reviewed again.
Related Next Steps
Continue with the relevant technical guide, product/licensing page or project scenario.
Related Enterprise Solutions
Explore the related service and solution pages to plan implementation.
Would You Like to Evaluate a Similar Infrastructure?
Share your current infrastructure, critical systems and project objectives so we can define an appropriate technical scope after a requirements assessment.