IT infrastructure for Manufacturing SMEs: A practical reference architecture
- Hung Pham
- Jul 28
- 25 min read
Manufacturing SMEs face a different infrastructure challenge from office-based businesses.
In a typical office environment, an IT outage may prevent employees from accessing email, shared files, or business applications. In a factory, the same outage can interrupt production orders, barcode printing, warehouse transactions, quality-control records, machine monitoring, or shipment processing.
This difference changes how the infrastructure should be designed.
A manufacturing IT environment must support office users, business applications, industrial systems, remote vendors, security controls, backup processes, and production equipment that may have very different availability requirements. Some systems can move to the cloud. Others must remain on-site because they depend on low latency, local connectivity, or continuous operation even when the Internet connection is unavailable.
For most manufacturing SMEs, the most practical target is therefore not a fully on-premises or fully cloud-based environment. It is a controlled hybrid architecture that keeps production-critical workloads close to the factory while using cloud services where they improve scalability, resilience, and manageability.
This guide presents a practical reference model for IT teams planning, upgrading, or standardizing infrastructure in a small or medium-sized manufacturing company.
1. Why manufacturing SMEs need a different IT infrastructure model?
A manufacturing SME may operate with a relatively small internal IT team, but the infrastructure it supports can be surprisingly complex.
A single site may contain:
A single site may contain:
Office computers and printers
Wi-Fi access points
ERP and accounting systems
Warehouse and inventory applications
File servers
Domain services
Backup systems
CCTV and access-control devices
Manufacturing execution systems
Engineering workstations
PLCs, HMIs, and industrial gateways
Vendor remote-access connections
Cloud applications
Multiple Internet links
Legacy equipment that cannot be patched frequently
These systems do not have the same operational requirements.
An email platform can often tolerate a temporary loss of local connectivity because it is hosted in the cloud. A production database, barcode-printing service, or manufacturing execution system may need to remain available even if the Internet connection fails. An engineering workstation may require direct communication with specific industrial devices, while a guest Wi-Fi user should have no access to the internal network at all.
The infrastructure design must therefore be based on business and technical dependencies, not simply on a list of devices.
Before selecting servers, switches, firewalls, or cloud services, the IT team should answer several basic questions:
Which systems are required to keep production running?
Which applications must continue operating during an Internet outage?
Which devices cannot be patched or restarted regularly?
Which data flows must pass between the IT and OT environments?
How much downtime is acceptable for each workload?
How much data can the business afford to lose?
Which components currently represent a single point of failure?
These questions create the foundation for the target architecture.
A broader review of servers, storage, connectivity, identity, security, and endpoint management can be found in this guide to building IT infrastructure for businesses.
2. The core layers of a manufacturing IT architecture
A practical manufacturing infrastructure can be divided into several layers. The exact technologies may vary, but the logical structure should remain clear.
2.1. Connectivity layer
The connectivity layer includes:
Internet connections
WAN links between sites
Firewalls
Routers
Core and access switches
Wireless networks
VPN services
SD-WAN, where required
For a small factory, this layer may initially consist of one firewall, one core switch, several managed access switches, and multiple wireless access points.
Even in a small environment, however, the network should not remain flat.
Office users, servers, cameras, guest devices, management interfaces, and industrial systems should be placed into separate network segments. This reduces unnecessary communication between devices and limits the impact of malware, configuration errors, or compromised accounts.
The connectivity layer should also be designed with failure scenarios in mind.
The IT team should evaluate:
Whether a second Internet connection is required
Whether both Internet links follow the same physical cable route
Whether the firewall has a high-availability pair or a tested replacement procedure
Whether the core switch is a single point of failure
Whether critical access switches have redundant uplinks
Whether network-device configurations are backed up
Whether remote access is protected with MFA
For smaller SMEs, full hardware redundancy may not be financially realistic. In that case, recovery speed becomes the priority. A documented configuration backup, a compatible spare device, and a tested replacement procedure can provide more practical value than an expensive high-availability design that the team cannot maintain.
2.2. Compute and application layer
The compute layer hosts the services required by users, applications, and production processes.
Typical workloads include:
Active Directory
DNS and DHCP
ERP
Database servers
File servers
Manufacturing applications
License servers
Print services
Monitoring platforms
Backup servers
Integration services
Virtual machines
Virtualization is often the most practical model for manufacturing SMEs because it reduces hardware dependency and makes backup, migration, and recovery easier.
However, virtualization does not automatically provide high availability.
If all virtual machines run on one physical host, the organization has consolidated several workloads onto a single point of failure. A failure of that host may stop authentication, ERP, file services, production applications, and monitoring at the same time.
The IT team should therefore classify workloads by criticality.
A simple classification model may include:
Tier 1: Production-critical systems that directly affect manufacturing operations
Tier 2: Business-critical systems required for warehouse, finance, or customer processing
Tier 3: Supporting systems that can tolerate a longer outage
Tier 4: Non-critical services that can be rebuilt or restored later
This classification helps determine which systems require replication, faster storage, off-site backup, spare hardware, or disaster-recovery capabilities.
2.3. Storage and data layer
Manufacturing environments generate several types of data:
ERP transactions
Production records
Quality-control data
Engineering drawings
Machine logs
CCTV footage
User files
Database backups
System logs
Configuration files
These data types should not automatically share the same storage platform.
CCTV workloads, for example, can consume large amounts of capacity and generate continuous write activity. Placing CCTV data on the same storage used by ERP databases or virtual machines may create avoidable performance and capacity risks.
The storage design should consider:
Performance
Capacity growth
Redundancy
Backup requirements
Retention periods
Recovery priority
Access control
Encryption
Off-site replication
RAID can protect against some disk failures, but it is not a backup. Replication can improve availability, but it may also replicate corrupted or encrypted data. Snapshots can support fast recovery, but they should not be treated as the only recovery method.
Each protection mechanism solves a different problem.
5.4. Identity and access layer
Identity is one of the most important infrastructure components because it controls who can access systems, applications, devices, and administrative interfaces.
The identity layer may include:
Active Directory
Cloud identity services
Multi-factor authentication
Role-based access control
Privileged accounts
Service accounts
Vendor accounts
Conditional-access policies
Password-management systems
Administrative accounts should be separated from standard user accounts.
An IT administrator should not use the same privileged account to browse the web, read email, and manage production servers. This reduces the risk that a compromised workstation or phishing attack leads directly to administrative access.
The same principle applies to vendors.
A machine supplier should not receive a permanent VPN account with access to the entire production network. Vendor access should be limited by:
Time
Destination
Protocol
Approval
Multi-factor authentication
Session logging
Business purpose
For higher-risk administrative access, a jump server or privileged-access management platform can provide stronger control.
2.5. Security and monitoring layer
Security should not be added after the infrastructure is built.
It should be integrated into the architecture through:
Network segmentation
Firewall policies
Endpoint protection
Patch management
Email security
Vulnerability management
Backup isolation
Log collection
Monitoring
Incident-response procedures
Manufacturing SMEs often focus heavily on endpoint antivirus while overlooking infrastructure visibility.
The IT team should be able to detect:
Internet link failures
Switch and firewall outages
Storage capacity problems
Backup failures
Unusual VPN activity
Repeated authentication failures
Server resource exhaustion
Expiring certificates
Abnormal traffic between network zones
Unauthorized changes to critical systems
Where the internal team cannot maintain continuous visibility, a Network Operations Center model may help centralize infrastructure monitoring and incident escalation.
3. IT and OT should not share a flat network
One of the most common design weaknesses in small manufacturing environments is the flat network.
In a flat network, office computers, printers, cameras, engineering workstations, servers, and industrial devices may all communicate with each other without meaningful restrictions.
This creates several risks.
A compromised office computer may be able to scan or connect to industrial equipment. Malware spreading through a user VLAN may reach systems that cannot be patched. A vendor account may gain broader access than intended. A misconfigured device may generate traffic that affects production systems.
The first technical control is network segmentation.
A practical segmentation model may include:
Zone | Typical Systems |
Office User Zone | Employee computers, printers, IP phones |
Server Zone | ERP, databases, domain services, file servers |
Management Zone | Firewalls, switches, hypervisors, storage |
CCTV and IoT Zone | Cameras, NVRs, access-control devices |
Guest Zone | Visitor and unmanaged devices |
OT Production Zone | PLCs, HMIs, industrial gateways |
Backup Zone | Backup servers and repositories |
DMZ | Public or intermediary services |
VLANs are useful for creating these logical zones, but VLANs alone are not enough.
If every VLAN is freely routed through the core switch, the environment remains broadly accessible. Traffic between sensitive zones should be controlled through firewall policies, access-control lists, or another enforcement point.
The IT team should define:
Which source may communicate with which destination
Which ports and protocols are required
Whether the connection is one-way or bidirectional
Who owns the application
What happens if the connection is blocked
Whether the traffic must be logged
For example, office users may require access to an ERP application, but they do not need direct access to the database server. A manufacturing application may need to read selected production data, but it should not have unrestricted access to all OT devices.
For a more detailed implementation approach, see this guide to enterprise VLAN design and segmentation.
The next section will examine how to separate IT and OT traffic, control vendor access, and decide which workloads should remain on-premises, move to the cloud, or operate in a hybrid model.
4. IT/OT segmentation: Control data flows, not just devices
Separating IT and OT does not mean creating two isolated environments that never communicate.
In most factories, business and production systems need to exchange data. ERP may send production orders to MES. MES may collect output data from machines. Quality-control systems may publish results to business applications. Maintenance teams may require remote access to engineering workstations.
The objective is therefore not complete isolation. It is controlled communication.
A good IT/OT segmentation design should answer four questions:
Which systems need to communicate?
What data must be exchanged?
Which ports and protocols are required?
How will the connection be monitored and revoked?
The IT team should document these data flows before creating firewall policies.
A simple data-flow record may include:
Field | Example |
Source | MES application server |
Destination | ERP integration service |
Protocol | HTTPS |
Port | TCP 443 |
Direction | OT to IT |
Business owner | Production planning |
Technical owner | IT infrastructure |
Availability requirement | Continuous during production hours |
Logging requirement | Allowed and denied connections |
Review frequency | Every six months |
This process prevents the common practice of creating broad rules such as OT to Server: Any.
Broad firewall rules may solve an immediate connectivity problem, but they weaken the purpose of segmentation and make future troubleshooting more difficult.
5. Recommended IT/OT Zone Structure
A practical manufacturing network may use three main security levels.
5.1 Enterprise IT Zone
This zone includes:
Office users
Email and collaboration systems
ERP users
Corporate file services
Internet access
Administrative applications
Users in this zone should not be able to connect directly to PLCs, HMIs, industrial controllers, or engineering interfaces.
5.2. Industrial DMZ
The Industrial DMZ acts as an intermediary between enterprise IT and production systems.
It may contain:
Jump servers
File-transfer gateways
Data historians
Patch repositories
Proxy services
Remote-access gateways
Integration servers
Log collectors
The purpose of the Industrial DMZ is to prevent direct connections between the office network and the production network.
For example, instead of allowing an ERP server to connect directly to a PLC network, production data can be published to an intermediary server. The ERP system retrieves the data from that server without gaining access to industrial devices.
5.3. OT Production Zone
This zone contains the systems involved in production operations:
PLCs
HMIs
SCADA servers
Industrial PCs
Engineering workstations
Machine controllers
Industrial switches
Sensors and gateways
Connections from this zone should be limited to documented business and operational requirements.
Internet access should not be enabled by default. If a device requires updates, time synchronization, licensing, or vendor communication, the traffic should be restricted to approved destinations.
A broader overview of industrial protection controls is available in this guide to cybersecurity solutions for OT infrastructure.
6. Secure remote access for vendors
Vendor access is one of the most important controls in a manufacturing environment.
Machine suppliers and maintenance contractors may need to troubleshoot equipment remotely. However, permanent access accounts, shared passwords, direct port forwarding, and unrestricted VPN access create unnecessary risk.
Remote vendor access should follow a controlled workflow.
A recommended process is:
The business owner submits an access request.
IT approves the destination, time window, and access method.
The vendor connects through VPN with MFA.
The session is restricted to a jump server or specific device.
Administrative activity is logged.
Access is disabled after the maintenance window.
Any configuration change is documented.
Vendor accounts should not remain active indefinitely.
Where possible, the IT team should also prevent vendors from connecting directly from unmanaged laptops to industrial devices. A controlled jump server provides a cleaner security boundary and makes session monitoring easier.
For privileged access involving multiple vendors or critical systems, a Privileged Access Management solution can provide stronger credential control, approval workflows, and session recording.
7. On-Premises, Cloud, or Hybrid: Choose by workload
There is no single correct deployment model for every manufacturing SME.
Some workloads perform better on-premises. Others are easier to operate in the cloud. Many environments benefit from a hybrid combination.
The decision should be made workload by workload.
7.1. When on-premises is more suitable
On-premises deployment is often appropriate when the workload:
Requires very low latency
Must operate during Internet outages
Connects directly to industrial equipment
Processes large volumes of local data
Uses legacy software with limited cloud support
Has strict hardware or licensing dependencies
Requires local storage for performance reasons
Common examples include:
MES
SCADA
Production databases
Engineering file repositories
License servers
Local print services
CCTV storage
Machine-control applications
On-premises systems provide local control and predictable connectivity, but they also require the company to manage hardware, power, cooling, backup, patching, security, and lifecycle replacement.
7.2. When cloud is more suitable
Cloud deployment is often appropriate when the workload:
Must be accessible across multiple sites
Needs rapid scalability
Does not depend on local machine connectivity
Benefits from subscription-based management
Requires high availability beyond one factory
Can tolerate dependence on Internet connectivity
Typical examples include:
Email
Collaboration platforms
Device-management systems
Cloud backup
SaaS ERP
CRM
HR systems
Security monitoring
Remote-support platforms
Cloud services reduce some infrastructure-management tasks, but they do not eliminate IT responsibility.
The IT team still needs to manage:
Identity
Access permissions
MFA
Data retention
Backup
Device compliance
Cloud configuration
Vendor risk
Cost control
A poorly configured cloud environment can be just as difficult to recover as a poorly managed local server.
7.3. Why hybrid is often the best fit
For many manufacturing SMEs, hybrid infrastructure provides the most practical balance.
A hybrid model may keep production-critical systems on-site while moving selected business and support services to the cloud.
For example:
Workload | Recommended Location |
PLC and HMI systems | On-premises |
MES | On-premises or edge |
Production database | On-premises with replication |
ERP | On-premises, cloud, or hybrid |
Cloud | |
Collaboration | Cloud |
Backup copy | Cloud or secondary site |
Identity | Hybrid |
Endpoint management | Cloud |
Monitoring | Hybrid |
File storage | Local with cloud synchronization |
This design allows the factory to continue operating locally while still benefiting from cloud-based resilience, centralized management, and remote access.
The team should avoid migrating systems simply because cloud adoption is a strategic objective. A workload should move only when the target platform improves availability, security, scalability, manageability, or cost.
For a broader comparison, see building a data center versus using cloud infrastructure.
Organizations planning a hybrid migration can also review IPSIP’s cloud infrastructure services.
8. Evaluate every workload before migration
Before moving a workload, the IT team should complete a dependency review.
At minimum, document:
Application owner
Technical owner
Number of users
Peak usage periods
Required network ports
Database dependencies
Authentication dependencies
Storage requirements
Backup method
Recovery requirements
Licensing restrictions
Integration with production equipment
Internet dependency
Expected monthly cloud cost
A workload that appears simple may have hidden dependencies.
For example, an ERP application may depend on:
A local database
Active Directory
A file share
A barcode-printing service
A tax-invoice integration
A warehouse application
A local reporting server
A manufacturing interface
Moving only the ERP application without accounting for these dependencies can increase latency, create unstable integrations, or introduce new points of failure.
The same principle applies when moving a physical server into a virtual machine or migrating a virtual machine to cloud infrastructure. A successful technical migration does not automatically mean the business process will operate correctly.
9. Eliminate single points of failure by business impact
A single point of failure is any component whose failure can stop a critical service.
Manufacturing SMEs often have many single points of failure because infrastructure has grown gradually. The objective should not be to remove every single point immediately. The objective should be to identify and prioritize them according to business impact.
9.1. Internet connectivity
A single Internet connection may affect:
Cloud ERP
Email
Remote support
Site-to-site VPN
Cloud backup
SaaS applications
Supplier portals
A second connection can reduce this risk, but only if the design is genuinely independent.
The IT team should verify:
Different service providers
Different physical routes
Automatic failover
Correct DNS behavior
VPN failover
Application compatibility
Available bandwidth during failover
Two Internet services that share the same last-mile cable may fail at the same time.
For small sites, a 4G or 5G connection may be sufficient for emergency access, but it may not support full production traffic. The failover design should therefore identify which applications receive priority.
9.2. Firewall
A firewall failure can interrupt:
Internet access
VPN connections
Inter-VLAN routing
IT/OT communication
Vendor access
Site-to-site connectivity
A high-availability firewall pair is the preferred solution for critical sites, but it is not the only option.
Where budget is limited, the company should maintain:
A current configuration backup
A replacement device
A documented restore procedure
An inventory of interfaces and cables
A support contract
A tested recovery process
The key question is not only whether the firewall can fail. It is how long the site will remain offline when it does.
9.3. Core Switching
If all servers, production systems, and access switches depend on one core switch, that device becomes a major infrastructure risk.
Possible controls include:
Switch stacking
Redundant core switches
Dual uplinks
Spanning-tree design
Link aggregation
Spare hardware
Configuration backup
The design should be tested during maintenance. Redundant links that have never been tested may not fail over as expected.
9.4. Virtualization Hosts
Virtualization reduces hardware sprawl, but it can also concentrate risk.
If a single host runs:
Active Directory
ERP
Database services
File services
Monitoring
Backup management
then one hardware failure may interrupt the entire business.
Possible improvements include:
A second host
Hypervisor replication
Shared or replicated storage
Image-level backup
Spare hardware capacity
Cloud-based recovery
Application-level replication
The appropriate design depends on the workload’s RTO and RPO.
A Tier 1 production system may require near-immediate failover. A Tier 3 reporting server may be restored from backup later.
9.5. Storage
Storage failures can affect several workloads simultaneously.
The IT team should review:
RAID configuration
Controller redundancy
Power-supply redundancy
Disk-health monitoring
Capacity thresholds
Snapshot policy
Replication
Backup independence
It is important to distinguish availability from recoverability.
RAID improves availability during certain disk failures. It does not protect against ransomware, accidental deletion, database corruption, theft, fire, or administrator error.
9.6. Power and environmental controls
Power-related failures are frequently underestimated.
The infrastructure review should include:
UPS capacity
UPS battery condition
Generator support
Power-supply redundancy
Surge protection
Rack temperature
Cooling
Environmental monitoring
Controlled shutdown
A UPS should be tested under load. A device that appears normal during everyday operation may fail immediately during a real power outage if its batteries are degraded.
9.7. Identity and DNS
A factory may have redundant servers and storage but still depend on a single domain controller or DNS service.
If identity services fail, users may be unable to:
Sign in
Access file shares
Open applications
Authenticate to Wi-Fi
Use VPN
Reach systems by hostname
At least two domain controllers and DNS servers are generally appropriate when authentication is critical to operations.
The servers should not be placed on the same physical host if that host is itself a single point of failure.
9.8. Backup infrastructure
The backup system can also become a single point of failure.
Common weaknesses include:
One backup repository
Backup server joined to the same domain
Shared administrator credentials
No off-site copy
No immutable storage
No restore testing
Backup network open to all users
Backup alerts ignored
Backup infrastructure should be treated as a protected recovery environment, not simply another server on the production network.
10. Build a risk-based redundancy matrix
Instead of purchasing redundant equipment for every system, the IT team can create a risk-based redundancy matrix.
Component | Business Impact | Current Recovery Time | Target Recovery Time | Recommended Control |
Internet | High | 4 hours | 5 minutes | Secondary ISP and failover |
Firewall | High | 8 hours | 30 minutes | HA pair or prepared spare |
Core switch | Critical | 1 day | 30 minutes | Stack or redundant core |
ERP host | Critical | 1 day | 2 hours | Replication or second host |
File server | Medium | 8 hours | 4 hours | Image backup |
CCTV storage | Low | 1 day | 1 day | RAID and spare disks |
Domain controller | High | 8 hours | 15 minutes | Second domain controller |
Backup repository | Critical | Unknown | 4 hours | Off-site immutable copy |
This matrix gives management a clearer view of infrastructure risk.
It also allows the IT team to justify investment in business terms. Instead of saying, “We need another server,” the team can explain that a single host failure may stop production for one day and that replication can reduce the recovery target to two hours.
11. Design principles for manufacturing SME infrastructure
At this stage, several design principles should be clear.
A practical manufacturing infrastructure should:
Separate user, server, management, camera, guest, backup, and OT traffic
Control IT/OT communication through documented firewall rules
Use secure, time-limited vendor access
Keep latency-sensitive production workloads close to the factory
Use cloud services where they improve resilience or manageability
Identify single points of failure by business impact
Align redundancy with RTO and RPO
Maintain current configuration backups
Test failover and recovery procedures
Document dependencies before migration
The strongest architecture is not the one with the most hardware.
It is the one that allows the IT team to understand what will fail, how the failure will affect production, and how quickly operations can be restored.
The next section will cover backup architecture, disaster recovery, monitoring, documentation, and a practical three-stage maturity model for manufacturing SMEs.
12. Backup architecture: Design for recovery, not just retention
A backup system is useful only when the IT team can restore the required service within an acceptable time.
Many manufacturing SMEs technically have backups but still face serious recovery risk because:
Backups are stored on the same network as production systems.
The backup server uses the same administrative credentials as the production domain.
There is no off-site or immutable copy.
Restore procedures have never been tested.
Application dependencies are not documented.
Backup alerts are generated but not reviewed.
Recovery time is estimated rather than measured.
The objective should not be to maximize the number of backup copies. The objective should be to create a recoverable environment.
12.1. Start with RPO and RTO
Every critical workload should have a defined Recovery Point Objective and Recovery Time Objective.
Recovery Point Objective (RPO): The maximum amount of data the business can afford to lose.
Recovery Time Objective (RTO): The maximum time the service can remain unavailable.
For example:
Workload | Example RPO | Example RTO |
Production database | 15 minutes | 1 hour |
ERP application | 1 hour | 2 hours |
File server | 4 hours | 8 hours |
Domain services | 1 hour | 1 hour |
Engineering drawings | 24 hours | 8 hours |
CCTV archive | 24 hours | 24 hours |
Reporting server | 24 hours | 2 days |
These values should be agreed with business and production owners.
The IT team should not define RPO and RTO alone because the acceptable level of downtime and data loss is a business decision.
12.2. Protect workloads according to criticality
Different workloads require different protection methods.
A practical design may use:
Application-aware backups for databases and ERP systems
Image-level backups for virtual machines
File-level backups for shared folders
Configuration backups for network devices
Cloud backup for Microsoft 365 or other SaaS platforms
Replication for high-priority virtual machines
Immutable storage for ransomware resilience
Offline copies for highly critical recovery data
Secondary-site copies for site-level disaster scenarios
Replication should not replace backup.
If data is deleted, corrupted, or encrypted, replication may copy the same damage to the secondary system. Replication improves availability, while backup provides historical recovery points.
Snapshots should also be treated as a short-term recovery tool rather than the only backup method.
12.3. Apply a 3-2-1-1-0 strategy
A traditional 3-2-1 strategy recommends:
Three copies of data
Two different storage media
One off-site copy
A stronger manufacturing backup design can extend this to 3-2-1-1-0:
Three copies of data
Two different storage types
One off-site copy
One offline or immutable copy
Zero unverified backup errors
The final requirement is important.
A backup job marked as successful does not prove that the application can be restored. The IT team must test the recovery process.
12.4. Separate backup administration
Backup accounts should be protected from standard production administration.
Where possible:
Do not use a normal domain administrator account for backup operations.
Use dedicated backup credentials.
Apply MFA to the backup-management platform.
Restrict access to the backup network.
Limit who can delete recovery points.
Send backup alerts to more than one person.
Protect backup configuration files.
Log administrative changes.
The backup repository should not be openly accessible from office-user VLANs.
A ransomware infection on a standard workstation should not be able to browse, delete, or encrypt backup files.
12.5. Test different types of restore
Restore testing should cover more than individual files.
A useful testing schedule may include:
Monthly file restore
Quarterly virtual-machine restore
Quarterly database restore
Semiannual application recovery test
Annual site-level disaster-recovery exercise
For critical systems, the team should record:
Start time
End time
Data recovery point
Restore errors
Missing dependencies
Manual steps
Actual RTO
Corrective actions
The result often reveals hidden problems such as unavailable license servers, expired certificates, missing DNS records, undocumented service accounts, or insufficient storage at the recovery site.
For broader planning, review this guide to building a disaster recovery plan with an IT partner.
13. Disaster recovery must cover more than servers
Backup restores data. Disaster recovery restores business services.
A factory-level disaster may involve:
Fire
Flooding
Extended power loss
Internet disruption
Server-room cooling failure
Ransomware
Hardware theft
Storage failure
Network-core failure
Human error
Supplier outage
A complete disaster-recovery plan should answer:
Who declares a disaster?
Who leads the technical response?
Which systems are restored first?
Where will systems be restored?
How will staff communicate if email is unavailable?
Which vendors must be contacted?
What temporary business process will be used?
How will production restart safely?
How will data integrity be validated?
When will the business return to the primary environment?
13.1. Define the recovery sequence
Recovery order matters because applications depend on other services.
A typical sequence may be:
Power, cooling, and core network
Firewall and WAN connectivity
DNS, DHCP, and identity services
Storage and virtualization platform
Database services
ERP or MES
File and print services
Integration services
Monitoring and security systems
Lower-priority business applications
Restoring an ERP virtual machine before its database, DNS, or authentication services are available will not restore the business process.
The recovery plan should therefore be built around service dependencies rather than individual servers.
13.2. Include manual workarounds
Not every outage can be resolved immediately.
Production and warehouse teams should identify temporary operating procedures, such as:
Manual production-order forms
Offline barcode lists
Temporary inventory logs
Manual quality-control records
Delayed transaction entry
Predefined emergency contact lists
These procedures should be approved in advance.
An improvised workaround during an outage may create inventory errors, duplicate transactions, or incomplete production records.
13.3. Run tabletop exercises
A tabletop exercise is a structured discussion of a simulated incident.
For example:
The primary virtualization host fails at 9:00 a.m. during a production shift. ERP, file services, and the manufacturing database are unavailable. The replacement part will not arrive for eight hours.
The exercise should test:
Decision-making
Escalation
Vendor contact procedures
Recovery priorities
Communication
Documentation quality
Business workarounds
Expected recovery time
Tabletop exercises are less disruptive than full technical tests and often reveal major process gaps.
14. Monitoring: Detect problems before users report them
A manufacturing IT team should not depend on user calls as its primary monitoring system.
Infrastructure monitoring should cover availability, performance, capacity, security, and backup status.
14.1. Network Monitoring
Monitor:
Internet availability and latency
Packet loss
WAN links
Firewall availability
VPN status
Switch uplinks
Interface errors
Spanning-tree changes
Wireless access-point status
Bandwidth utilization
A link may still be technically online while suffering high packet loss or latency. Monitoring should therefore measure quality, not only availability.
14.2. Server and virtualization monitoring
Monitor:
CPU and memory
Storage latency
Datastore capacity
Virtual-machine status
Hypervisor health
Hardware sensors
RAID status
Power-supply status
Operating-system services
Certificate expiration
Time synchronization
Storage thresholds should generate alerts before capacity becomes critical.
A full datastore can stop virtual machines, corrupt applications, or prevent snapshot operations.
14.3. Application monitoring
Monitor services that matter to production, such as:
ERP login
Database availability
MES application status
Barcode-printing service
File-share accessibility
License-server response
Integration-service status
Backup-job completion
A server may be online while the business application running on it is unavailable. Application-level checks are therefore more valuable than simple ping monitoring.
14.4. Security monitoring
Monitor:
Failed logins
Privileged-account activity
New administrator accounts
VPN sessions
Firewall-policy changes
Endpoint-protection alerts
Unusual traffic between VLANs
Large data transfers
Backup deletion attempts
Disabled security services
The monitoring design should prioritize alerts that require action.
Too many low-value alerts create fatigue and increase the chance that a serious event is ignored.
Where the internal team cannot provide continuous monitoring, a 24/7 NOC service can help centralize infrastructure visibility, escalation, and incident tracking.
15. Documentation is part of the infrastructure
Documentation is not an administrative task separate from technical operations.
It is a recovery control.
When a firewall, switch, server, or application fails, the recovery time depends heavily on the quality of the available documentation.
At minimum, the IT team should maintain the following records.
15.1. Network diagram
The diagram should show:
Internet links
Firewalls
Core and access switches
Wireless infrastructure
Server connections
VLANs
WAN links
OT boundaries
DMZ connections
Backup infrastructure
The diagram should reflect the current environment rather than the original project design.
15.2. IP address and VLAN plan
Document:
VLAN ID
Subnet
Gateway
DHCP scope
DNS settings
Purpose
Owner
Firewall policy reference
Avoid assigning addresses without updating the IP plan.
Uncontrolled static addresses create conflicts and make incident response more difficult.
15.3. Asset inventory
Track:
Device name
Device type
Serial number
Model
IP address
Physical location
Operating system
Firmware version
Warranty
Support contract
Business owner
Technical owner
Lifecycle status
The inventory should include industrial PCs, network devices, servers, storage, UPS systems, and critical software licenses.
15.4. Application dependency nap
For each important application, record:
Server or cloud platform
Database
Authentication method
File-share dependency
Network ports
Certificate
License server
External integration
Backup method
Recovery procedure
Business owner
Vendor contact
This document is especially useful during migration and disaster recovery.
15.5. Administrative access register
Maintain a secure record of:
Administrative roles
Named account owners
Emergency accounts
Vendor accounts
MFA status
Access-review date
Approval authority
Passwords should be stored in an approved password vault or privileged-access system, not directly in spreadsheets or diagrams.
15.6. Change log
Record significant changes to:
Firewall policies
VLANs
Server configurations
Application integrations
Backup schedules
Cloud permissions
Administrative accounts
Remote-access settings
The change log helps the team identify whether a recent modification caused an incident.
16. Standardize routine operations
A stable infrastructure depends on repeatable operational processes.
The IT team should define schedules for:
Backup review
Patch review
Firmware updates
Restore testing
Account review
Firewall-rule review
Storage-capacity review
UPS testing
Certificate review
Asset-inventory update
Vendor-access review
Disaster-recovery exercises
Not every system can follow the same patch schedule.
Office endpoints may be patched monthly, while production equipment may require a vendor-approved maintenance window. The difference should be documented as a controlled exception rather than ignored.
For companies with limited internal capacity, Managed IT services for SMEs can support monitoring, maintenance, backup review, helpdesk operations, and infrastructure lifecycle management.
17. A 3-stage maturity model for manufacturing SMEs
A maturity model helps the IT team prioritize improvements without attempting to implement every control at once.
Stage 1: Controlled Basic Infrastructure
This stage is appropriate for a small factory with limited IT staff.
The target environment includes:
Business-grade firewall
Managed switches
Separate VLANs for users, servers, cameras, guests, backup, and OT
Basic firewall rules between zones
Virtualized server environment
Cloud email and collaboration
Local backup
Off-site backup copy
UPS protection
Central asset inventory
Current network diagram
Basic monitoring
MFA for remote access
The key objective is to remove uncontrolled flat-network access, manual backup processes, and undocumented administrative accounts.
Stage 2: Standardized and Recoverable Infrastructure
This stage is appropriate when ERP, MES, warehouse, or production systems have become operationally critical.
The target environment includes:
Two Internet connections
Tested WAN failover
Firewall high availability or a prepared replacement process
Redundant or replicated virtualization
Formal IT/OT segmentation
Industrial DMZ where required
Controlled vendor access
Jump server
Immutable backup
Defined RPO and RTO
Scheduled restore testing
Central monitoring
Central log collection
Patch and change management
Documented disaster-recovery procedures
The key objective is to reduce downtime and create predictable recovery.
Stage 3: Multi-Site and Centrally Managed Infrastructure
This stage is appropriate for manufacturers operating several factories, warehouses, or offices.
The target environment includes:
Standard network architecture across sites
Central identity management
Standard VLAN and firewall templates
SD-WAN or centrally managed WAN
Central monitoring platform
Central backup management
Hybrid-cloud architecture
Cross-site disaster recovery
Central vendor-access control
Privileged-access management
Configuration management
Standard operating procedures
Shared incident-response runbooks
The key objective is repeatability.
A new factory should be able to follow an approved architecture rather than creating an entirely new design.
18. Common infrastructure design mistakes
Manufacturing SMEs frequently encounter the same technical problems.
18.1. Keeping the entire factory on one network
A flat network allows unnecessary communication between office, server, camera, and OT systems.
The solution is functional segmentation with enforced inter-zone policies.
18.2. Buying hardware before mapping dependencies
A new server or firewall may not solve the real bottleneck.
The team should document workloads, traffic flows, recovery requirements, and failure points before selecting equipment.
18.3. Treating VLANs as a complete security control
VLANs create logical separation, but unrestricted inter-VLAN routing defeats the design.
Sensitive traffic must pass through an enforcement point.
18.4. Moving every workload to the Cloud
A cloud-first strategy may create latency, Internet dependency, or integration problems for production systems.
Each workload should be evaluated individually.
18.5. Keeping every workload on-premises
A fully local environment can create high maintenance costs, limited resilience, and difficult multi-site access.
Cloud services may be more appropriate for email, collaboration, backup, device management, and selected business applications.
18.6. Running all virtual machines on one host
Virtualization simplifies management but does not remove hardware risk.
Critical workloads require replication, spare capacity, or a tested recovery process.
18.7. Relying on RAID as backup
RAID does not protect against deletion, ransomware, corruption, or site-level disaster.
Independent backup copies are still required.
18.8. Allowing permanent vendor VPN access
Permanent access increases exposure and weakens accountability.
Vendor access should be approved, restricted, monitored, and disabled after use.
18.9. Ignoring restore testing
Successful backup reports do not prove recoverability.
The team must measure actual restore results.
18.10. Failing to update documentation
Outdated diagrams and recovery procedures can be more dangerous than having no documentation because they create false confidence.
19. Practical implementation roadmap
A manufacturing SME can improve its infrastructure in phases.
Phase 1: Assessment
Document:
Devices
Applications
Network topology
VLANs
Internet links
IT/OT data flows
Backup methods
Administrative accounts
Single points of failure
Recovery requirements
Phase 2: Immediate Risk Reduction
Prioritize:
Backup verification
MFA
Removal of shared administrator accounts
Guest-network isolation
Vendor-access restrictions
Firewall configuration backup
Critical monitoring alerts
Security updates for exposed systems
Phase 3: Segmentation and Standardization
Implement:
VLAN structure
Inter-zone firewall rules
Management network
Backup network
OT boundary
IP address plan
Naming standards
Asset inventory
Change control
Phase 4: Resilience
Improve:
Internet failover
Firewall recovery
Host replication
Off-site and immutable backup
Secondary domain services
Disaster-recovery procedures
Restore testing
Phase 5: Centralized Operations
Introduce:
Central monitoring
Central logging
Automated configuration backup
Patch-management reporting
Vendor-access workflows
Service-level reporting
Capacity planning
This phased model helps the business improve resilience without attempting an expensive full replacement project.
20. Final reference architecture
A practical target architecture for a manufacturing SME may include:
20.1. Connectivity
Two Internet connections
Business-grade firewall
Managed core and access switches
Separate corporate and guest wireless networks
VPN with MFA
Configuration backup
20.2. Network segmentation
Office user VLAN
Server VLAN
Management VLAN
CCTV and IoT VLAN
Guest VLAN
Backup VLAN
OT production VLAN
Industrial DMZ where required
20.3. Compute
Virtualized server environment
At least two domain controllers
Replication or recovery capacity for critical workloads
Separate production and non-production systems where possible
20.4. Data protection
Local backup
Off-site backup
Immutable or offline recovery copy
Application-aware backup
Scheduled restore tests
Defined RPO and RTO
20.5. Security
MFA
Endpoint protection
Controlled administrative accounts
Secure vendor access
Firewall policy review
Patch-management process
Central logging
20.6. Operations
Network and application monitoring
Asset inventory
Dependency documentation
Change log
Incident escalation process
Disaster-recovery runbook
Periodic tabletop exercises
Conclusion
The right IT infrastructure for a manufacturing SME is not the architecture with the largest number of servers, security products, or network segments.
It is the architecture that allows the IT team to answer four questions clearly:
Which systems must remain available to keep production running?
Can an incident in the office network spread into servers or OT systems?
Which workloads should remain on-site, and which should move to the cloud?
Can the organization restore critical services within an acceptable time?
For most manufacturing SMEs, a hybrid model provides the strongest practical balance.
Production-critical and latency-sensitive systems remain close to the factory. Cloud services support collaboration, remote management, backup, and selected business applications. Network segmentation limits lateral movement. Controlled vendor access protects industrial systems. Backup and disaster recovery are designed around measurable RPO and RTO targets.
Before purchasing new equipment, the IT team should create:
A current network diagram
An application inventory
An IT/OT data-flow map
A dependency map
A recovery matrix
A list of single points of failure
These documents provide the foundation for a realistic infrastructure roadmap.
They also allow the IT team to explain technical investment in business terms: production impact, downtime, recovery time, operational risk, and expansion readiness.
Organizations that need support with infrastructure assessment, cloud architecture, monitoring, or ongoing operations can review IPSIP’s IT services for businesses.
-----------------------
Referral
Security Segmentation in a Small Manufacturing Environment: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.28.pdf
Manufacturing Sector Cybersecurity Resources – NIST: https://www.nist.gov/itl/smallbusinesscyber/guidance-sector/manufacturing-sector
Guide to Operational Technology Security – NIST SP 800-82 Rev. 3: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
Cybersecurity Framework 2.0 Manufacturing Profile: https://nvlpubs.nist.gov/nistpubs/ir/2025/NIST.IR.8183r2.ipd.pdf
The State of Ransomware in Manufacturing and Production 2025: https://www.sophos.com/en-us/blog/the-state-of-ransomware-in-manufacturing-and-production-2025
Comments