Cloud Manufacturing: Moving Production Data Off-Premise Safely

A plant manager once told me, half joking, that his historian server was the most valuable thing in the building and also the one nobody wanted to touch. It sat in a closet near the maintenance office, running an operating system two versions past its support date, and it held ten years of temperature curves, spindle loads, and batch records. Meanwhile, corporate wanted that data in the cloud so the analytics team could build yield models. On the other hand, the controls engineers wanted nothing to change. In fact, both sides were right, and that tension is exactly where most cloud manufacturing projects either succeed quietly or fail loudly.

I have spent a good part of my career designing the bridge between plant floors and cloud platforms. Therefore, what follows is not a vendor pitch, and it is not a checklist copied from a framework. Instead, it is how I actually approach moving production data off premises without handing an attacker a new road into the plant.

What Cloud Manufacturing Really Means

The phrase gets stretched in a lot of directions. For example, academics have used it for years to describe a service model where design, quoting, production capacity, and logistics are shared across companies as if they were cloud resources, including capacity for additive manufacturing. Even then, researchers flagged that security is among the hardest problems standing in the way of full adoption of cloud manufacturing, and that observation has aged well.

In practice, however, most manufacturers I work with mean something narrower and more immediate. Specifically, they want to take data that currently lives inside the plant (machine telemetry, quality results, MES transactions, maintenance logs, energy readings) and push it to a cloud platform. There, it can be stored cheaply, analyzed at scale, and shared with people who are not standing next to the line. In addition, some go further and run MES or scheduling applications from the cloud. Finally, a smaller group wants the cloud to send instructions back down to equipment.

Three Cloud Manufacturing Ambitions, Three Levels of Risk

Those three ambitions carry very different risk. Sending data up is one problem. Running business applications in the cloud is a second. Letting the cloud command physical machines, however, is a third, and it deserves far more scrutiny than it usually gets. For this reason, before any architecture conversation, I ask the team which of these they are actually doing. After all, the answer shapes everything else.

Why Cloud Manufacturing Stakes Are Higher on the Plant Floor

In an office network, a breach usually means stolen data and an expensive cleanup. In a plant, by contrast, it can mean a stopped line, scrapped product, damaged equipment, or someone getting hurt. That difference is why operational technology security puts availability and safety ahead of confidentiality, which is almost the reverse of how classic IT security thinks.

What the Numbers Say

Unsurprisingly, attackers understand this. As a result, manufacturing has become a favorite target, precisely because downtime is so painful that companies feel pressure to pay. For instance, Check Point’s analysis counted 1,466 ransomware incidents against manufacturers worldwide in 2025, making it the most targeted sector. Similarly, GuidePoint’s numbers point the same way, with manufacturing accounting for 1,060 victims, or 14 percent of all observed ransomware targets. Moreover, in the United States, manufacturing stayed the most attacked sector for a fourth straight year.

Even so, none of that means you should keep your data in the closet forever. In fact, plenty of those incidents started with phishing emails, stolen VPN credentials, or unpatched edge devices, not with a well designed cloud pipeline. Still, every new connection you create will be tested by people who do this for a living. So design as if that is true, because it is.

Start Your Cloud Manufacturing Project With an Inventory, Not a Vendor

The most common mistake I see is choosing a cloud platform before anyone knows what is actually on the network. Typically, teams sign a contract and receive a slick connector. Then they discover a dozen undocumented PLCs, a vendor modem plugged into a switch behind a panel, and a historian that also happens to be the domain controller for the line.

Simply put, you cannot protect data flows you have not mapped. Fortunately, government guidance has become very direct about this. For example, CISA, the FBI, the UK’s National Cyber Security Centre, and international partners published joint guidance explaining how organizations can use asset inventories and manufacturer resources such as software bills of materials to keep an accurate, current view of their OT systems. In addition, that same guidance covers managing third party risk, securing OT information, and designing architectural controls.

What My Inventory Captures

Accordingly, my working inventory for a cloud manufacturing project captures four things for every asset that will touch the pipeline. First, what it is and what firmware it runs. Second, what protocols it speaks. Third, who can reach it today. Finally, what data it produces. That last column is the one most teams skip; however, it is the one that tells you what you are actually about to move.

Classify Production Data Before It Moves

Not all plant data is equal. For example, a spindle vibration reading is useful to a maintenance model and nearly useless to a competitor. A process recipe for a specialty coating, on the other hand, may represent years of engineering and a real competitive edge. Likewise, product genealogy data in regulated industries may carry legal retention obligations. Consequently, treating all of it the same way leads either to overprotecting cheap telemetry or underprotecting crown jewels.

The Four Cloud Manufacturing Data Tiers

That is why I usually sort production data into four tiers with the plant and quality leads in the room:

Operational telemetry. Sensor readings, cycle counts, and machine states. Because the volume is high and sensitivity is moderate, these are good candidates for early migration.

Quality and traceability records. Inspection results, lot genealogy, and nonconformance reports. In this case, volume is moderate, but sensitivity is higher, and these records are often subject to customer or regulatory requirements.

Intellectual property. Recipes, process parameters, CNC programs, and tooling designs. Similarly, build files from industrial 3D printing and design iterations from your rapid prototyping work belong here. Although volume is low, sensitivity is very high. As a result, these need explicit justification before they leave the building, and often they should not leave at all.

Control data. Setpoints and commands that change physical behavior. Strictly speaking, this is not data to migrate; rather, it is authority to grant. Therefore, treat it as its own decision.

Once the tiers are agreed, each one then gets its own rules for encryption, retention, read access, and which cloud region it may live in. Admittedly, that conversation takes an afternoon. However, it saves months of arguing later.

Design Cloud Manufacturing for One Way Flow First

If I could give manufacturers only one piece of architectural advice, it would be this: start with data flowing out of the plant and nothing flowing back in.

After all, most of the value people want from cloud manufacturing (dashboards, predictive maintenance, yield analysis, energy reporting) only requires reading data. In other words, none of it requires the cloud to reach into the control network.

The Default Architecture

So the default architecture I draw looks like this:

1. First, controllers and sensors stay on their own segmented network at the lower levels of the plant hierarchy, the layers described by the Purdue reference model.
2. Next, a local historian or edge collector inside the plant gathers data from those devices.
3. Then, that collector replicates to a server in an industrial demilitarized zone between the plant network and the corporate network.
4. After that, a gateway in that zone opens outbound connections only to the cloud platform, over encrypted channels, using its own credentials.
5. Finally, no inbound connection from the internet or the cloud ever terminates on the plant network.

Adding a Data Diode

Furthermore, for high consequence environments, I go a step further and recommend hardware enforced one way transfer, often called a data diode or unidirectional gateway, between the plant and the demilitarized zone. Software firewalls, after all, can be misconfigured. Physics, however, cannot. In short, if the device can only transmit light in one direction, no clever attacker in the cloud tenant is going to send a command back across it.

Is this more expensive than plugging a cloud connector directly into a PLC network? Certainly. Nevertheless, it is the difference between a cloud breach being a data problem and a cloud breach being a production problem.

When the Cloud Needs to Talk Back

Eventually, as industrial automation matures in a plant, someone asks for closed loop control. Usually, the analytics model has found a better setpoint, and the business wants it applied automatically. At this point, I slow everyone down.

When writes back to the plant are truly needed, I build them as a separate, narrow path. To begin with, the plant pulls instructions rather than the cloud pushing them. In addition, a local system validates every instruction against engineering limits before anything reaches a controller. Likewise, a human approves changes above a defined threshold. Moreover, every write is logged locally, not just in the cloud. Above all, the whole path can be disabled with a physical or local switch that operations controls, not IT.

In my experience, once teams see what a safe write path requires, many decide that a recommendation displayed on an operator screen is good enough. Quite often, that is the right call.

Identity Is the New Perimeter in Cloud Manufacturing

Traditionally, plant security assumed that anything inside the fence was trusted. Cloud manufacturing, however, breaks that assumption completely. Now the data lives somewhere you do not own, is accessed by people you may never meet, and moves across networks you do not control.

Notably, NIST’s updated guide to operational technology security addresses this shift directly. Specifically, it discusses applying Zero Trust design and tools, as described in NIST’s Zero Trust Architecture guidance, inside OT security architectures. In plain terms, every user, device, and workload has to prove who it is every time, and then it gets only the access it needs.

Identity Rules I Apply on Every Project

Here is how that translates into concrete decisions on my projects:

No shared accounts anywhere in the pipeline. This applies to the edge gateway, the historian, and the cloud tenant alike, because shared logins make investigation impossible after an incident.

Machine identities for machines. Similarly, gateways and collectors authenticate with certificates or managed workload identities that rotate automatically, never with passwords stored in a config file.

Phishing resistant multifactor authentication for humans. This matters especially for administrators of the cloud tenant and anyone with remote access to the plant.

Vendor access through a brokered session. Instead of a permanent VPN account, or worse, a modem in a cabinet, OEMs and integrators get time limited, recorded sessions approved by plant staff.

Separate administration for cloud and plant. In other words, the person who can change cloud storage policies should not automatically be able to reconfigure the edge gateway, and the reverse is also true.

Indeed, identity mistakes are where I see the most real world damage. For example, a single overprivileged service account in a cloud tenant can expose years of production history in minutes.

Encryption and Who Holds the Keys

Today, every major cloud provider encrypts data at rest and in transit by default, and that is genuinely helpful. However, default encryption mostly protects you from someone stealing a physical disk from a data center. It does not, by contrast, protect you from someone who obtains valid credentials to your tenant.

Customer Managed Keys for Sensitive Data

For this reason, for the higher tiers of data, especially recipes and process parameters, I recommend customer managed keys. These should be stored in a dedicated key management service or hardware security module, with tightly controlled access and logging on every key use. Additionally, for the most sensitive material, consider encrypting at the edge before data ever leaves the plant, so that the cloud platform stores ciphertext it cannot read. Of course, you lose some analytics convenience, so reserve this for data that truly warrants it.

Also, think about the path, not just the endpoints. Data passing through an industrial demilitarized zone, a corporate network, and an internet link should be encrypted the whole way, with certificate validation turned on. Surprisingly, I still find gateways shipped with certificate checks disabled “for testing” and never switched back.

Understand the Cloud Manufacturing Shared Responsibility Line

Generally speaking, cloud providers secure the physical data centers, the hypervisors, and the core services. You, on the other hand, secure everything you configure: identities, network rules, storage permissions, logging, and the data itself. In fact, the provider’s compliance reports describe only their half. Meanwhile, your auditors will ask about yours.

Questions Your Contract Should Answer

Therefore, for manufacturing workloads, I make sure the contract and the architecture answer a few specific questions. First, which regions will the data live in, and does that satisfy customer and export requirements? Second, how long does the provider retain logs, and can you export them to your own security monitoring? Third, what happens to your data if you leave the platform? Finally, who at the vendor can access your tenant, under what circumstances, and how will you know?

Moreover, if an industrial software vendor is providing the cloud application on top of a hyperscaler, you now have three parties in the responsibility chain. So get the boundaries in writing, because vague answers here tend to become very specific problems during an incident.

The Plant Must Run When the Cloud Is Gone

This sounds obvious. Yet I regularly review designs where a cloud outage would stop production. For example, a scheduling application moves to the cloud, the internet link drops, and suddenly operators do not know what to run next. Similarly, a quality approval workflow lives only in a cloud app, and as a result, finished goods sit on the dock waiting.

Therefore, my rule is simple: anything required to safely run the next shift must work with the internet disconnected. To that end, edge systems buffer data locally and forward it when the connection returns. Likewise, critical MES functions keep a local copy or a defined manual fallback. Most importantly, operators actually train on that fallback instead of just reading about it in a binder.

Planning for Ransomware in the Cloud

Furthermore, resilience means planning for ransomware that reaches your cloud tenant. Accordingly, keep immutable backups of critical production records in a separate account with separate credentials. Then test restores on a schedule. After all, an untested backup is a hope, not a control.

Monitoring Both Sides of the Cloud Manufacturing Bridge

Once data is flowing, you need visibility at every hop. For instance, cloud logs tell you who accessed what in the tenant. Meanwhile, network monitoring in the demilitarized zone tells you whether the gateway is behaving. Finally, OT monitoring on the plant network tells you whether anything unusual is reaching the controllers.

Unfortunately, the weak point is usually the gap between teams. On one side, the IT security operations center sees cloud alerts but does not understand OT protocols. On the other side, the controls engineers understand the plant but never see cloud logs. Naturally, attackers live comfortably in that gap. So bring both sets of telemetry into one place, write detection rules together, and run at least one joint tabletop exercise a year where the scenario starts in the cloud and ends on the plant floor. If your team lacks that blend of skills, a partner offering manufacturing IT services can help close the gap.

A Cloud Manufacturing Migration Sequence That Works

Although every plant is different, the sequence I use most often looks like this.

Phase one: discover and segment. First, complete the asset inventory, map data flows, and fix the worst segmentation problems before any new connection is made. In fact, this phase often delivers security value on its own, even if the cloud project stalled tomorrow.

Phase two: low risk telemetry. Next, move operational telemetry from one line or one area through the one way architecture. That way, you prove the pipeline, the monitoring, and the identity model on data that would not hurt much if exposed.

Phase three: quality and traceability. Then expand to higher tier data with stronger controls, customer managed keys, and formal retention policies agreed with quality and legal.

Phase four: business applications. After that, consider cloud hosted MES, ERP integrations, scheduling, or maintenance applications, each with a tested offline fallback.

Phase five: write back, if ever. Finally, and only after the earlier phases are stable, open the narrow, validated, locally controlled path described earlier.

Admittedly, teams always want to skip to phase four. However, the ones that resist that urge end up moving faster overall, because they are not stopping to rebuild trust after a scare.

Cloud Manufacturing Mistakes I Keep Seeing

Some patterns show up so often that they are worth calling out directly.

First, connecting a cloud agent straight to the control network because the vendor’s quick start guide said so. Keep in mind that quick start guides are written for demos, not for plants.

Second, letting the integrator’s engineers keep standing remote access long after commissioning. Instead, access should end when the project ends.

Third, treating the edge gateway as an appliance nobody patches. In reality, it is a server with an internet connection, so patch it like one.

Fourth, storing every piece of data forever simply because storage is cheap. In fact, retention without purpose increases what you lose in a breach and what you must produce in a legal dispute.

Finally, assuming the cloud provider handles security. They handle their part; however, the configuration mistakes that expose manufacturer data almost always belong to the customer.

Where Standards Fit

In my own work, I lean on a handful of references consistently. For example, NIST’s Guide to Operational Technology Security expanded its scope from industrial control systems to OT in general and updated its threats, vulnerabilities, risk management practices, and recommended tools. In addition, it provides tailored control baselines for low, moderate, and high impact OT systems, which makes it practical for deciding how much protection a particular line or process needs. Likewise, the ISA/IEC 62443 series gives a common language for zones, conduits, and security levels that both plant engineers and vendors understand. Furthermore, CISA’s recent guidance offers eight principles for designing, securing, and managing connectivity into OT environments, which speaks almost directly to the cloud connectivity questions manufacturers face.

Of course, standards will not design your architecture for you. Nevertheless, they will give you vocabulary, a defensible baseline, and something to point to when someone asks why the project needs a data diode.

Final Thoughts on Cloud Manufacturing

To sum up, cloud manufacturing is not inherently risky, and keeping everything on premises is not inherently safe. In fact, that historian in the closet, running an unsupported operating system with a shared password taped to the monitor, was arguably the biggest risk in the building. As a result, moving its data to a well designed cloud platform made that plant safer, not less safe.

Ultimately, the difference comes down to intent. First, know what you have. Next, decide what data deserves which protection. Then let data flow out before you let anything flow in, treat identity as your perimeter, and make sure the plant keeps running when the internet does not. If you do those things patiently and in order, the cloud becomes what it should be: a place to learn from your production data, rather than a new door into your production line.

Frequently Asked Questions About Cloud Manufacturing

What is cloud manufacturing?

Essentially, cloud manufacturing is the use of cloud platforms to store, analyze, and share production data and, in some cases, to run manufacturing applications such as MES or scheduling. In addition, it can describe shared manufacturing capacity offered as a service. For a deeper research view, see the IEEE Cloud Computing overview on cloud manufacturing security.

Is cloud manufacturing safe for production data?

Yes, it can be, provided the architecture prevents the cloud connection from becoming a path into the control network. Specifically, one way data flow, strong identity controls, and encryption with customer managed keys are the core safeguards. As a starting reference, see NIST’s Guide to Operational Technology Security.

What is a data diode and does cloud manufacturing need one?

A data diode is hardware that physically allows data to travel in only one direction. Therefore, it is strongly recommended where a compromise could affect safety or cause major downtime, although it is less critical for low consequence telemetry. For more on OT remote access and segmentation, see 12 Questions and Answers About NIST SP 800 82.

Should the cloud ever send commands to plant equipment?

Only through a narrow, validated path where the plant pulls instructions, local systems enforce engineering limits, and operations can disable the path locally. In practice, many manufacturers find that recommendations shown to operators deliver most of the value with far less risk. For a security architecture perspective, see Making the Case for OT Cybersecurity.

What should I do before choosing a cloud manufacturing platform?

First, build an accurate inventory of your OT assets and data flows. For guidance, see CISA’s Creating and Maintaining a Definitive View of Your OT Architecture.

Why are manufacturers targeted so heavily by ransomware?

Mainly because downtime is extremely costly, which pressures victims to pay quickly. Furthermore, many plants run older systems that are hard to patch. For recent industry data on this trend, see Ransomware Attacks Set New Records in 2025, Hitting Manufacturing the Hardest.

References

1. NIST. Guide to Operational Technology (OT) Security: NIST Publishes SP 800 82, Revision 3
2. SecurityWeek. NIST Publishes Final Version of OT Security Guide
3. CISA. Creating and Maintaining a Definitive View of Your Operational Technology Architecture
4. HSToday. CISA and UK National Cyber Security Centre Release Joint Guidance for Securing Operational Technology Systems
5. Smart Industry. Ransomware Attacks Set New Records in 2025, Hitting Manufacturing the Hardest
6. IT Brief UK. Manufacturing Leads Ransomware Targets in 2025 Report
7. Esposito, Castiglione, Martini, Choo. Cloud Manufacturing: Security, Privacy, and Forensic Concerns. IEEE Cloud Computing, 2016.
8. Siemens Digital Industries Software. How Data Security in the Manufacturing Industry Relies on Cloud Technologies
9. Corsha. NIST SP 800 82 Revision 3: Making the Case for OT Cybersecurity
10. Independent Banker (ICBA). CISA Releases Operational Technology Guidance
11. Security Scientist. 12 Questions and Answers About NIST SP 800 82