NCSC’s 5 OT Architecture principles: Put Into Practice with Avassa

Reflections based on NCSC’s five OT architecture principles.

Operational technology environments have their own reality when it comes to security, shaped by legacy and long-lived systems, insecure or unauthenticated protocols, limited visibility, and a strong human operational factor. Those in charge of OT security quickly realize that OT environments can’t be treated like cloud systems, and without a clear and consistent view of assets and behavior, they cannot be secured effectively.

The UK National Cyber Security Centre (NCSC) outlines five principles for creating and maintaining a definitive record of OT architecture. They are straightforward, but when applying them in the OT field, they require structure and tooling built for OT constraints which isn’t outlined in the principles as is.

The Avassa Edge Platform is built with those constraints in mind. The platform provides a structured model of sites, hosts, and applications, and the company is ISO 27001-certified, meaning its supporting processes, controls, and handling of sensitive information follow an established security management framework.

In this article, I elaborate on the five NCSC principles and describe how an edge orchestration platform like Avassa’s can support their practical application in an OT setting.

1. Define processes for establishing and maintaining the definitive record

NCSC’s first principle is simple:

Have one reliable, maintained record of your OT architecture.

That includes the assets, relationships, configurations, and information about where workloads actually run.

In many OT environments, this is harder than it sounds. Information is spread across spreadsheets, operator notes, vendor documentation, and “tribal knowledge.” When you work at scale, that model breaks quickly.

In the Avassa Edge Plaform, sites, hosts, applications, versions, configurations, and secrets are all represented as first-class objects. Everything has a stable identity and can be queried through the API, CLI, or UI. The platform tracks the declared and actual states, so you always know what should run and what is running.

More importantly, this is not a snapshot—it’s a process. Every change flows through controlled operations that can be logged, reviewed, and audited. That makes the “definitive record” something you maintain continuously, not something you reconstruct during an incident.

2. Establish an OT information-security management program

The second NCSC principle emphasizes implementing a security management program, for example, based on ISO 27001. This establishes processes and tools for protecting information in the OT environment. Architectural data, configurations, and credentials are inherently sensitive.

An orchestration platform gives you a natural place to enforce structure around this:

• Role-based access controls define who can deploy what and where.
• Integration with SSO/IdP ensures OT operations follow the same governance as IT.
• Secrets and certificates, often scattered across OT servers, are handled centrally and distributed securely.
• Every change, whether made through pipeline or operator action, produce an audit record.

The Avassa Edge Platform doesn’t replace an ISMS, but it provides a reliable, structured source of information for the parts of the OT environment that it manages.

3. Identify and categorise assets to support risk-based decisions

The third principle requires that the organisation should understand what assets exist, how critical they are, and how they relate. This is essential for prioritizing security and operational decisions.

The Avassa Edge platform provides a structured asset model:

• Sites: logical or physical OT locations.
• Hosts: compute resources inside the site.
• Applications and services running on those hosts.
• Dynamic devices attached to workloads.

Metadata and labels let you capture business or operational context. You can classify sites and hosts by criticality, map applications to production lines, or tag workloads that interact with safety-critical systems.

This allows practical risk-based operations. For example, you can roll out updates to low-criticality sites first, or apply stricter policies on workloads that interact with OT control systems.

It gives you a clear view that supports real decision-making rather than assuming everything is equal.

4. Identify and document connectivity within your OT system

The forth principle recommends that all OT connectivity should be identified and documented.

Connectivity is where many OT environments become complicated. ISA-95 segmentation, DMZs, firewalls, and vendor-specific networks make inbound access unreliable or impossible. NCSC’s point is that you must understand these flows rather than make assumptions.

The Avassa Edge Platform fits naturally into this model because communication is outbound-initiated from OT sites. The platform does not require inbound ports to be opened, and it tolerates intermittent connectivity. This aligns well with segmented environments where OT→DMZ→IT is the only safe direction.

At the application level, the configuration defines what services expose, what endpoints they talk to, and how certificates are used. This effectively gives you a live, declarative record of connectivity on top of the existing OT network.

All application-level ingress and egress is defined declaratively in the workload specification and site configuration. This gives precise control over what ports and protocols are exposed locally, what external systems a workload is allowed to contact. Combined with site-local autonomy, it provides a predictable boundary at each OT site rather than relying on ad-hoc firewall rules or manual configuration.

It won’t replace a detailed OT network diagram, but it removes ambiguity about how applications communicate across layers and which systems depend on which endpoints.

5. Understand and document third-party risks

Finally, the fifth principle requires having complete control over third-party risks. Third-party software, whether from vendors, integrators, or open-source components, introduces risk. In OT environments, this risk is amplified because systems run for long periods and deployments are geographically distributed.

The Avassa Edge Platform provides a clear, structured way to track and govern third-party components. Every application version and container image has an explicit origin, and images must come from known registries (central or site-local). All deployments go through controlled mechanisms, which makes it straightforward to answer questions such as:

• “Where do we run version X of vendor Y’s component?”
• “Which sites are affected by CVE-1234?”
• “What third-party workloads are deployed today?”

Platform policies can limit image sources, enforce signatures, and constrain resources and network exposure for external or less-trusted components. Avassa’s multi-tenancy model adds another layer of control by regulating exactly what third parties can access, down to specific sites, applications, or operations — without granting broader system privileges.

Local configuration changes can be applied directly through the platform, reducing reliance on USB drives or manual updates on OT hosts. Out-of-band access can usually be avoided by using the ISA-95 proxy pattern and the platform’s tuneling features, both designed to operate within segmented networks without opening inbound paths.

This creates a consistent environment for managing supplier risk, applying SBOM data, and handling vulnerability scanning and remediation across the entire OT deployment.

Applying NCSC’s OT Security Principles at the Edge

The NCSC principles are focused on structure: having an accurate, controlled, and secure view of your OT architecture. Without that structure, it becomes difficult to manage lifecycle, assess risk, or respond to incidents.

An orchestration platform such as the Avassa Edge Platform gives you a practical foundation for applying those principles: a consistent model of your sites and workloads, controlled change, strong identity management, and operational behaviour designed for segmented and unreliable networks.

A useful next step is to take these five principles and compare them with your current OT deployment. Where is the “definitive record” today? How much depends on manual updates or assumptions? Those gaps are where structured edge-orchestration helps the most.

Learn more about the security aspects of our system in this Security Data Sheet.