Extraction, evaporation and crystallisation need reliable control while raw material quality, steam demand and process conditions keep changing. Cloud-connected optimisation therefore raises legitimate questions. Who can access the control system? Which values can the optimisation layer change? What happens when communication fails or a supplier account is compromised?

Effective sugar factory OT cybersecurity starts with clear answers to those questions. A useful architecture defines where control resides, how information crosses boundaries and how the factory continues operating when an external service becomes unavailable.

Is It Safe to Connect a DCS to a Cloud Optimisation Layer?

Yes, provided the connection is engineered, assessed and operated with appropriate safeguards. No architecture eliminates every risk. The objective is to prevent a cloud connection from creating uncontrolled access to production or an unacceptable dependency on external availability.

For a supervisory architecture, the DCS should retain responsibility for basic control. Protective functions and safety systems must remain independent of cloud optimisation. Ask one question of any design: which independent layer prevents a dangerous plant state if the optimiser sends wrong commands, unauthorised commands or no commands at all?

The supervisory layer receives selected measurements and, where authorised, proposes or supplies bounded operating targets. Consider evaporation: an optimiser may calculate a target that improves the balance between throughput and steam consumption. The local control system should still enforce operating limits, validate the target and allow operators to disable optimisation at any time.

An isolated DCS reduces exposure to external networks, but engineering laptops, removable media and maintenance access still need management. NIST's OT security guidance (NIST SP 800-82) emphasises protection that respects operational reliability and safety.

The Three Architectures: Visibility, Advisory and Closed Loop

The first decision concerns the optimisation layer's authority. Three modes have different operational consequences and each requires separate acceptance criteria.

Read-only describes application permissions, not physical communication direction. An OPC UA session can exchange requests and responses even when writes are prohibited. Hardware-enforced unidirectional transfer is a different, stricter architecture.

Advisory mode also carries process risk. An incorrect recommendation can influence production when an operator follows it. Recommendations need timestamps, validity conditions and clear indicators when inputs are unreliable.

Moving to closed-loop operation should be a deliberate project milestone. For an extraction application, acceptance testing should include scenarios for bad measurement quality, delayed messages, an unavailable optimiser and targets outside agreed operating limits.

What OPC UA Actually Secures, and What It Does Not

OPC UA provides mechanisms for authenticating applications, signing messages and encrypting communication. User authentication and authorisation can further restrict access. These capabilities depend on implementation and configuration. Selecting OPC UA does not by itself establish a secure connection.

For production interfaces, specify approved security policies, signed and encrypted communication, managed certificate trust and the minimum necessary permissions. Avoid automatically trusting unknown certificates. Assign responsibility for certificate renewal and revocation before commissioning. The OPC Foundation provides practical security recommendations covering these decisions.

In a sugar plant, local validation should assess allowable ranges, rates of change, operating modes and measurement freshness. A target appropriate during steady operation may be inappropriate during start-up or cleaning. OPC UA does not replace endpoint hardening, network segmentation or incident response. Protecting a connection and protecting the systems at either end are complementary responsibilities.

Where the Edge Layer Sits and Why That Matters

An edge layer provides computing close to the process. Depending on the application, it can collect measurements, check data quality, run models and manage communication with external services. Its location must be explicit: an industrial computer connected to both the control network and the internet can create an unintended bridge unless traffic paths and permissions are tightly controlled.

Wherever the optimiser runs, on site or in the cloud, three rules hold. There is no unrestricted route from the cloud to DCS controllers. Every target is validated by the local control system before it acts. When the optimiser or connection disappears, the DCS returns to its own control in a known state.

Connections initiated from the site towards approved external endpoints can still carry incoming application messages. Connection direction alone does not prevent remote influence. Message permissions and validation remain essential regardless of which side opened the session.

For campaign operation, specify the response to each failure scenario. Loss of cloud connectivity might suspend reporting while a locally hosted model continues running. Loss of valid measurements might require optimisation to disengage. An edge failure should trigger the agreed local fallback. Test these behaviours before enabling automatic writes, including reconnection: old queued commands must not become valid simply because communication returns.

IEC 62443 Zones and Conduits Applied to a Sugar Plant

IEC 62443 provides a framework for industrial automation and control system security. IEC 62443-3-2 addresses defining the system, dividing it into zones and conduits, assessing risks and establishing target security levels. A zone groups assets with common security requirements. A conduit groups the communication channels between zones.

Applying these concepts requires more than drawing a boundary around "the factory". An illustrative arrangement for a sugar producer could be structured as follows.

The risk assessment may require additional separation for safety systems, utilities, engineering access or individual process areas. A VLAN alone does not establish an effective security boundary. Conduits should have documented purposes, endpoints, protocols and permissions: reading juice measurements does not justify access to controller programming functions.

This illustrative architecture is not evidence of certification, an achieved security level or compliance with IEC 62443.

What NIS2 Means for European Sugar Producers

NIS2 Annex II includes food businesses engaged in wholesale distribution and industrial production and processing. Sugar manufacturing can therefore fall within scope. Covered Annex II entities are generally classified as important unless another provision makes them essential.

Scope generally includes medium-sized and larger entities. Assess size using the applicable EU enterprise rules, including relevant linked or partner enterprises. A single factory's headcount is insufficient to determine scope. Confirm classification and obligations under national implementing law.

Connecting to the cloud does not itself create NIS2 applicability, and remaining disconnected does not remove obligations. NIS2 concerns organisational resilience across relevant systems. To prepare for compliance, an optimisation project should produce usable evidence: responsibilities, an asset inventory, approved access paths, recovery procedures and supplier escalation arrangements.

A Security Checklist for Evaluating Any Optimisation Vendor

Ask for documents and demonstrations that your IT, OT and production teams can review together. Run through a campaign scenario during evaluation: the cloud connection fails while throughput is changing and an operator switches control mode. A credible supplier explains the expected behaviour and demonstrates it during acceptance testing.

1. Architecture. Can the supplier show components, trust boundaries and every required communication path, including support and updates?
2. Permissions. Which tags are readable or writable? Can technical controls prevent all other writes?
3. Process authority. Where are limits enforced? How can operators withdraw optimisation authority and identify the active control mode?
4. Failure behaviour. What happens during lost connectivity, stale measurements, certificate expiry, service restart and edge failure?
5. Remote support. Are access sessions individually authenticated, time-limited, approved and logged? Can the factory revoke access immediately?
6. Updates. How are software and model changes authenticated, tested, approved and rolled back? Who can authorise an emergency campaign update?
7. Recovery. What is backed up, where is it protected and when was restoration last demonstrated?
8. Incident coordination. Who is reachable outside office hours during campaign, and how fast? Distinguish acknowledgement time, technical response and restoration commitments.
9. Data governance. Which data leaves the site, where is it stored, who can access it and what happens when the contract ends?

Request evidence for claims about certification or independent testing, including scope, version and exclusions. A certificate for one component does not establish the security of the installed system.

Frequently Asked Questions

Want to Know More?

Bring these questions to a first discussion with Sucrosphere. Our integration documentation covers the interfaces, network boundaries and campaign availability commitments in detail. Our white papers include the technical architecture behind our hybrid on-site and cloud approach.

This article is part of the Sucrosphere series on sugar factory digitalisation. Related reading: How to Evaluate a Sugar Automation Vendor: The Questions That Actually Matter, and How Does Sucrosphere Approach Sugar Factory Automation Differently?