U.K. National Cyber Security Centre (NCSC) released new cross-domain guidance aimed at helping government, industry and the wider security community design and deploy secure data flows across differing trust environments, shifting away from legacy ‘point solution’ models toward a pipeline-based approach that builds assurance at every stage of data movement. The updated approach introduces core concepts such as zones of trust, trust boundaries and control points, while emphasizing flexible, layered security controls and deprecating older design patterns and principles for new architectures, though these will remain in use for assurance in the near term as the transition unfolds.
The revised guidance is designed to ensure that cross domain is easier to implement so it can be more widely adopted across disparate sectors. It reflects how modern systems operate and how organizations now use technology to deliver essential services. At its core, cross domain is about safely enabling business functions, even when those functions span systems with different levels of trust. This could include importing documents, enabling video communications, or interacting with services hosted in other environments, such as over APIs.
“We will build on this guidance to provide more details on how to architect and implement cross domain products, and are looking to include topics such as a step-by-step guide to designing cross domain architectures, covering the key stages and considerations you need to take; guidance on selecting appropriate technology to implement dross domain functions; and standardised cross domain patterns which will provide repeatable templates that will be applicable across a number of use cases,” Duncan M, principal security architect, wrote in a Tuesday NCSC blog post. “We’ll let you know when this guidance is ready. In the meantime, we hope you find the cross domain guidance useful when designing your organization’s data flows across zones of trust.”
Rather than focusing on fixed boundaries or specific technologies, the new approach looks at the end‑to‑end architecture needed to make these functions secure and reliable. A central part of this approach is developing an explicit understanding of what data flows are required, how systems are connected, and which threats are relevant, both individually and when systems are linked.
Cross domain uses a sequence of functions, often referred to as a pipeline, to build confidence in data as it moves between trust zones. Each function prepares the data so the next stage can safely process it, or ensures that only valid data leaves a zone. This ensures assurance is gained across the entire flow, not at a single point.
As a security approach for safely managing data flows between systems with different trust levels, cross domain enables organizations to operate across multiple zones of trust, spanning from internal networks to cloud platforms and the internet, separated by trust boundaries wherever they connect. In standard commercial settings, conventional security architecture is usually adequate. However, when systems face targeted attacks and handle sensitive data, basic boundary controls fall short. Cross domain provides a structured, threat-aware method to design controls that hold up even against active adversaries trying to bypass them.
In short, cross domain enables essential business operations securely by acknowledging that different parts of an architecture carry different trust levels, and that data moving between them requires careful, deliberate control under high-threat conditions.
In cross-domain environments, trust reflects the level of confidence in a system or network, with the NCSC defining a ‘zone of trust’ as a group of components sharing a similar security posture within a defined boundary. Trust is relative, shaped by the observer’s perspective and the zones they manage. Data entering a zone is treated as import, requiring controls to block harmful or malicious inputs, while data leaving is export, where controls focus on preventing sensitive or unauthorized leakage. Crucially, even seemingly one-way data flows often involve hidden bi-directional exchanges, meaning security controls must account for both directions simultaneously.
Traditional cross domain solutions were built as single high-assurance devices enforcing controls at one fixed boundary between two networks. This worked for simple architectures with binary trust relationships, but modern environments are far more complex, as they now span multiple trust zones under different ownership, with varying assurance levels and threat exposures. A single enforcement point is no longer adequate.
Modern cross domain architecture instead treats the boundary as a pipeline of functions, each called a control point, that progressively reduce risk and build trust in data as it moves between zones. The more robust points in this pipeline are called security control points, which must resist compromise from malicious data, prevent that data from propagating further, avoid cross-session contamination, and enforce directional data flow. Their required robustness is determined by the system’s threat model and the organization’s risk tolerance.
Within any cross domain flow, control points exist at two levels. Logical control points define what security functions must be enforced at each stage, such as validation or transport termination, without specifying how. Implementation components are the actual technologies that carry out those functions; a single component may cover multiple logical control points, or vice versa. The placement of control points and choice of components is shaped by the specific threats present at each stage of the flow, and because import and export flows are asymmetric in nature, their control points and assurance requirements will differ accordingly.
Shifting to an architectural lens, cross-domain security is an end-to-end design approach that governs and mitigates the risks associated with business data moving between distinct zones of trust. When moving data between these zones, assurance is not gained at a single point, but through the pipeline of layered controls distributed between the source and destination of the data flow. Each stage in the pipeline should be designed to ensure that the next stage can safely process its inputs.
To reduce the risk of unsafe data being passed into critical functions, the NCSC detailed that controls should be applied at the appropriate points in the architecture. For instance, validating network protocols where networks physically connect, verifying session protocols before application handling, and confirming data format safety before business logic processes it.
“The architecture should be constructed from multiple components. Where these components provide a security critical function, they should be single purpose and suitably hardened,” the agency detailed. “This maintains flexibility, reduces component attack surface and avoids unnecessary complexity. While these components may be deployed on shared hardware, it should be possible to reason about the security properties of individual components (as opposed to having a monolithic technology stack providing multiple security functions).”
There may be use cases where it’s appropriate to implement the architecture within a single, physical appliance, similar to how cross domain products have traditionally been developed. However, there are an increasing number of uses for cross domain technologies, which may require flexible architectures. As the number of use cases for cross domain technologies increases, there is a need for more flexible architectures.
To achieve this, the NCSC added that organizations may have look beyond implementations that combine the end-to-end control points in a single platform, appliance or application. “This also requires recognising that not all components in the path will be under the same management. Infrastructure, identity services, DNS, time sources and other dependencies may be outside your administrative control, but these are still critical to the secure operation of the cross zone flow. Understanding ownership boundaries and the trust assumptions they create is key to managing the overall risk.”
The NCSC provided six design principles for cross domain architecture. The first is to understand and minimize data transfer, meaning only the data necessary to achieve the required business outcome should be transferred. Simple protocols should be chosen and unnecessary information stripped out, which reduces the attack surface, limits covert channel risks, and improves overall assurance. Different data flows should be considered separately based on their specific characteristics.
The second principle is to gain trust across the entire stack. All data should be treated as untrusted at its origin, from the physical network layer up to application context. Sequential security controls should be layered to progressively build confidence in data, achieved by terminating or inspecting all meaningful data, including content, control data such as routing information or API parameters, and anything that could be interpreted as program logic and potentially trigger unintended processing or remote code execution. Trust may need to be re-established at the same layer more than once, depending on the sequence of components in the flow.
The third principle is to only export understood and expected data. Export flows should be minimised and controlled to reduce the risk of sensitive data leaking across boundaries. Where the threat model requires it, layered and deliberate authorisation and validation mechanisms should be implemented to prevent unintended export while still meeting operational needs.
The fourth principle is to minimize the wider impact of compromised components. Designers should consider what an attacker could gain by compromising any component in the cross domain flow, particularly lower-assurance components such as data transformers. Even where a compromise does not threaten the more trusted zone directly, it could enable data theft, integrity loss, or allow the component to be used as a pivot point for further attacks.
The fifth principle is to make key security controls simple. The attack surface of components that perform key security functions should be reduced to increase confidence in their correct operation. Each key security component should perform only a single function to minimise the risk of compromise.
The sixth principle is to design for observability and manageability. Cross domain architectures should have observability and manageability built in from the outset to support security monitoring and integration. Data flows should be clearly traceable end-to-end, with operations on the data recorded and session information correlatable back to the initiator. Components throughout the flow should be straightforward to deploy, configure, and update, even where they span multiple boundaries.
The NCSC also warned this week that organizations delivering critical services must urgently prepare for a ‘severe cyber threat’ environment, as increasingly capable adversaries combine rising intent with advanced technologies such as AI to carry out disruptive attacks on nationally significant targets. This comes as a severe cyber threat can result in attacks that lead to extended operational downtime, with direct customer impact, significant financial loss, long-term reputational damage, and increased risks to public safety and national security.
