How Manufacturers Should Actually Secure ERP Data

A tier-two automotive parts manufacturer lost six days of production after ransomware moved laterally from an infected office laptop into the same network segment as its ERP-connected CNC machines, because nobody had segmented IT and OT (operational technology) networks. Manufacturing has become one of the most heavily targeted industries for ransomware precisely because production downtime is expensive enough that attackers bet on manufacturers paying fast — and the same ERP system that gives real-time visibility into production also, if not architected carefully, gives an attacker a path from a phished email account straight to the shop floor.

The manufacturing-specific risk that generic ERP security advice misses

Most ERP security guidance is written for back-office systems — finance, HR, sales data. Manufacturers carry two additional categories of risk that generic advice doesn't cover: operational technology (OT) convergence, where ERP systems increasingly connect directly to production equipment, PLCs, and MES systems for real-time data, creating a network path between office IT and physical machinery; and intellectual property exposure, where product designs, bills of materials, and proprietary process parameters live inside the ERP and are exactly the kind of data a competitor or nation-state actor has real incentive to steal, distinct from the financial fraud motive behind most generic data breaches.

Network segmentation: the single highest-leverage control

The automotive parts manufacturer's six-day outage happened because there was no meaningful separation between the corporate network (where a phishing email landed) and the OT network (where production equipment lived). Proper segmentation — a demilitarized zone or firewall boundary between IT and OT networks, with the ERP's shop-floor-facing integration passing through a controlled, monitored gateway rather than flat network access — is the single highest-leverage control against exactly this kind of lateral movement. It's also frequently skipped during initial ERP-to-MES integration projects because segmentation adds complexity and cost to a project already under deadline pressure, and the risk feels abstract until it isn't.

Access control for a workforce that isn't all at a desk

Shop floor ERP access has different practical constraints than office access: shared workstation terminals at production lines, workers who need fast badge-based or PIN-based login rather than complex passwords typed on a shared keyboard, and shift-based access patterns. Role-based access control needs to reflect this reality rather than force factory-floor logins through the same password policy designed for office knowledge workers — badge-based authentication tied to individual employee IDs, with activity logged against the person, not the shared terminal, gets both usability and auditability right simultaneously. The failure mode to avoid is a shared generic login used by an entire shift, which makes it impossible to trace who actually made a given change when something goes wrong.

Protecting product design and process data specifically

Bills of materials, CAD-linked product structures, and proprietary process parameters (cycle times, tolerances, material formulations) deserve access controls tighter than general ERP data, because they're the intellectual property that actually differentiates a manufacturer from a competitor who could otherwise replicate the product. Practical steps: apply field-level or document-level permissions so engineering data is visible only to roles that need it, not to every ERP user by default; log and review access to high-value product records specifically, not just system-wide login activity; and — for manufacturers working with external partners or contract manufacturers — use time-limited, scoped data sharing (specific BOM data for a specific part, expiring after the engagement) rather than broad system access for external parties.

Supply chain data sharing without oversharing

Modern manufacturing ERP often shares data with suppliers and contract manufacturers directly — demand forecasts, inventory levels, sometimes design data for co-development. Each external connection is a real risk surface: a supplier's own security posture becomes partially your risk when their systems have access to your ERP data. Practical controls: a formal vendor risk assessment before granting any external ERP data access, not just a signed NDA; scoped API access limited to exactly the data fields a given partner needs, not a broad export; and a defined offboarding process that actually revokes access when a supplier relationship ends, which is a step that gets forgotten more often than it should.

Regulatory and export control considerations

Defense and aerospace manufacturers carry an additional layer: export control regulations restrict who can access certain technical data, including data stored in an ERP system, based on citizenship and location, not just job role. This means access controls sometimes need to enforce citizenship-based restrictions that generic role-based permissions don't naturally handle, and it's worth confirming explicitly with an ERP vendor or implementation partner whether the platform supports this kind of restriction natively (some do, via specialized government-cloud editions) or whether it requires custom configuration. Getting this wrong isn't just a security gap, it's a compliance violation with real legal exposure.

Ransomware response planning specific to a production environment

A generic IT incident response plan usually assumes systems can be taken offline for remediation without an immediate revenue impact measured in the tens of thousands of dollars per hour. A manufacturing ransomware response plan has to account for production continuity explicitly: which systems can fail over to a manual or paper-based process temporarily, what the actual maximum tolerable downtime is per production line before the cost of stopping exceeds the cost of a faster but riskier recovery, and whether backup and recovery procedures have actually been tested against the ERP-to-MES integration specifically, not just the ERP database in isolation. The automotive manufacturer's six-day recovery took as long as it did partly because the incident response plan on file had never been tested against a scenario involving both office and shop-floor systems simultaneously.

A practical checklist

1. Is there a real network boundary between corporate IT and shop-floor OT systems, not just a shared flat network?
2. Does shop-floor ERP access use individual, traceable logins rather than shared terminal credentials?
3. Is access to product design and process data restricted by role, with access to high-value records logged and periodically reviewed?
4. Is there a formal risk assessment and scoped access process for any supplier or partner with ERP data access?
5. For defense/aerospace manufacturers: has export control compliance been explicitly verified with the ERP vendor, not assumed?
6. Has the incident response plan actually been tested against a scenario spanning both office and shop-floor systems?

None of this is exotic security practice — it's the standard playbook of segmentation, least-privilege access, and vendor risk management applied specifically to where manufacturers actually differ from a typical back-office ERP deployment: physical equipment on the network, and intellectual property worth stealing.

Patch management for shop-floor-connected ERP integrations

Security patches for ERP systems get applied on a routine schedule in most IT departments; patches affecting the ERP's connection to shop-floor MES or PLC systems get treated far more cautiously, and often skipped or delayed, because an untested patch has a real chance of disrupting active production if something breaks. This caution is reasonable but needs a defined process rather than indefinite deferral — a staging environment that mirrors the actual OT integration, not just the ERP database, where patches get validated against a realistic production scenario before deployment, and a defined maximum deferral window (60-90 days is common) after which a patch gets applied even without perfect confidence, because unpatched known vulnerabilities are their own growing risk the longer they sit. Manufacturers without this defined process tend to default to indefinite deferral, which is how known, patchable vulnerabilities end up sitting exposed for years.

Coordinate patch windows with production scheduling explicitly — the ideal patch window for OT-integrated systems is a planned maintenance downtime the production team already has scheduled, not an IT-driven timeline that conflicts with an active production run. This requires IT and operations to share a calendar and a genuine seat at each other's planning table, which is as much an organizational fix as a technical one.

Third-party OT security assessments are worth the cost

Most manufacturers have never had their OT network specifically assessed by a security firm with genuine industrial control systems experience, as distinct from a generic IT penetration test that doesn't understand PLC protocols or production safety constraints. A dedicated OT assessment, run outside of production hours or in a non-production test environment, typically costs $15,000-$40,000 depending on facility complexity, and routinely surfaces findings a standard IT audit misses entirely — default credentials still active on a decade-old PLC, an unmonitored remote access connection a vendor's technician set up years ago and never disabled. For a facility of any real size handling either sensitive IP or safety-critical processes, this is worth budgeting as a recurring exercise, not a one-time check.