Security objections kill projects late. Answer them early.
The three questions behind every objection, a concrete segmentation model, an itemised account of what leaves the plant, and where real incidents actually occur.
Security concerns kill monitoring projects late — after the technical evaluation, after budget approval, when an IT or customer audit asks what connects to what. Answering them properly at the start costs an hour; answering them at the end costs the project.
This article sets out the three questions that are actually being asked, and what a defensible answer looks like.
What can reach the machines?
A monitoring system that reads machines must be reachable from them, which means the network path is now part of your risk picture. The answer is segmentation, not assurance.
Can it change anything on a machine?
The distinction between read-only and read-write is the entire conversation for most maintenance managers. Read-only should be architectural, not a setting.
What leaves the plant?
Cycle times, rejection rates and customer job names are commercially sensitive. Where they physically reside is a contractual question for many suppliers.
This is the arrangement most Indian plants adopt, and it answers the first question directly: office IT cannot reach a machine, because there is no route. The monitoring server is the single controlled crossing point, which makes it the one thing to secure properly rather than one of forty.
MachineWise integration reads. It does not write control parameters, does not modify programs and does not command machines. That matters for two separate reasons: it removes the possibility of monitoring causing a production incident, and it removes the argument that monitoring could be used to interfere with a machine under warranty.
Where a standard enforces this architecturally rather than by configuration — MTConnect has no write path at all — that is worth noting in an internal review, because a structural guarantee is easier to defend than a promise about settings. Protocols without built-in security, notably Modbus, are handled by segmentation rather than by the protocol.
| Deployment | Production data | Alerts out | Remote support | Suits |
|---|---|---|---|---|
| Fully isolated | Never leaves | None | None | Defence-linked suppliers, strict customer data clauses |
| On-premises, alerts enabled | Stays on your server | WhatsApp and email notifications only | Available when you permit a session | The common arrangement |
| Cloud-hosted | Resides on vendor infrastructure | Included | Continuous | Multi-site groups prioritising convenience |
The realistic security risk in manufacturing software is not an external attacker. It is the wrong person seeing a figure they should not, and nobody being able to establish afterwards who saw what. Rejection rates by operator, cost data, customer job names — these cause disputes.
Permissions should therefore be granular by module, machine, cell and plant, with genuine read-only viewer roles for auditors and customers, and access logged with user attribution. When a customer auditor asks who could see their job data, the answer should be a report rather than a recollection.
If your plant has an IT function or supplies customers with data clauses, bring them in during the pilot rather than at purchase. The questions above are answerable in an hour with a network diagram, and unanswered they become an objection at exactly the point where momentum matters most.
The commercial framing of the same decision is on the on-premises page, and the practical no-internet arrangements are in monitoring without internet.