Security

Zero trust for connected operations

When factories, buildings and networks are connected, network location is no longer a reason to trust a request. What zero trust asks of operational environments.

QDT Editorial2 min read

Traditional security drew a perimeter and trusted what was inside it. Connected operations break that assumption. A plant has contractors on site, gateways reaching the cloud, vendors with remote access and devices that cannot be patched on schedule. Zero trust is the response: stop treating network location as evidence of trustworthiness.

What zero trust says

NIST Special Publication 800-207 describes zero trust as an approach in which no request is trusted by default because of where it comes from. Access to each resource is decided per request, using identity, device state and context, with the least privilege necessary. It is a set of principles, not a product.

  1. Identify

    User, device or service

  2. Assess

    Health, context, risk

  3. Authorise

    Least privilege for this resource

  4. Monitor

    Log, re-check, revoke

FIG.Every request is evaluated; network location alone grants nothing.

Why operational environments are different

Information technology can usually install an agent, enforce multi-factor authentication and patch monthly. Operational technology often cannot: controllers run for years on fixed firmware, availability can matter more than confidentiality, and a security control that interrupts a process is itself a risk. Zero trust in these settings is applied around devices as much as on them.

Practical building blocks

  1. Enterprise and cloud

    Identity provider, ERP, analytics

  2. Demilitarised zone

    Brokered, inspected data exchange

  3. Site operations

    Servers, historians, gateways

  4. Devices and controllers

    Authenticated, patched where possible

FIG.Segmenting a connected operation. Compromise of one zone should not reach the next.
  • Know the estate. You cannot protect devices you have not inventoried. Passive discovery helps where active scanning is unsafe.
  • Segment. Group devices into zones and control the conduits between them, in line with the zones-and-conduits model in IEC 62443. A compromise in one zone should not reach the next.
  • Give everything an identity. Users, services and devices should authenticate individually, with credentials that can be rotated and revoked.
  • Broker remote access. Vendor and engineer access should be time-limited, logged and routed through a controlled path, not a standing VPN.
  • Monitor for the unusual. Baselines of normal device behaviour make deviations visible.
  • Plan recovery. Backups of configurations and tested restoration matter as much as prevention.

Start where the risk is

A full programme is a multi-year effort. A realistic start is to map the highest-consequence assets, close the most exposed remote paths, and introduce segmentation where a failure would hurt most. Each step should be reversible and tested in a window that operations accepts.

How QDT approaches it

QDT's security products and managed services cover cyber-security, managed services and telecom security, and our IoT implementations treat device identity and update paths as part of the architecture. Security posture depends on the environment and the scope of work; we describe controls and practices rather than guarantees.

  • #security
  • #iot
  • #operations

Keep reading

All insights

Start a conversation

Discuss the question behind the article.

Every article starts from a practical operating question. Tell us yours.