The UK’s National Cyber Security Centre (NCSC) released landmark guidance on cross-domain architecture in April 2026, fundamentally reshaping how government bodies, critical infrastructure operators, and enterprise security teams should approach secure data movement between environments of different trust levels.
If your organisation handles sensitive data across multiple network zones — whether that means connecting classified government systems to commercial platforms, linking IT to Operational Technology (OT), or bridging cloud services with on-premises environments — this guidance directly affects your security architecture.
This blog breaks down everything you need to know: what changed, why it changed, the six new design principles, key concepts, and what your team should do next.
What Is NCSC Cross-Domain Architecture Guidance?
The NCSC’s new guidance — titled Cross Domain Approach and Architecture — provides a comprehensive framework for safely enabling data flows between systems with different trust levels. It is designed to help developers, integrators, and risk owners understand how cross-domain security works and how to implement it effectively.
Crucially, the guidance reframes cross-domain security not as a single product or appliance, but as an end-to-end architectural approach. According to the NCSC, cross domain is not just a single appliance which sits between two networks — it is a structured method for understanding and mitigating risks within data flows so organisations can meet their business objectives.
The guidance is structured across four core pages:
- What is cross domain?
- Cross domain concepts
- Cross domain architecture
- Cross domain design principles
Why Did NCSC Update Its Cross-Domain Guidance?
The original NCSC security principles for cross-domain solutions (13 principles) have served their purpose for many years, particularly in defence and intelligence sectors. However, they were developed for a different threat landscape and a different technology era.
The NCSC cites several key drivers behind the updated guidance:
1. A More Capable and Persistent Threat Environment
Attackers today are more sophisticated, more persistent, and more resourceful than ever before. The guidance explicitly acknowledges that adversaries now have the capability to develop or acquire attacks targeting zero-day vulnerabilities and to chain multiple attacks together to achieve their objectives. AI-enabled vulnerability discovery is accelerating the pace at which attackers can find and exploit weaknesses, leaving organisations with shrinking windows to respond.
2. Greater Exposure of Critical National Infrastructure
Critical national infrastructure (CNI) — including energy grids, water systems, transportation networks, and healthcare systems — is increasingly connected and therefore increasingly exposed. The original point-solution model of cross-domain security is no longer sufficient for environments where connectivity is pervasive and adversaries specifically target CNI.
3. Supply Chain and Unknown Vulnerability Risks
Modern digital supply chains introduce components, software, and services from third parties that organisations cannot fully audit. Unknown vulnerabilities embedded in supply chains can undermine traditional boundary-based security controls. The new guidance reflects this reality by promoting layered, architecture-wide assurance rather than reliance on a single trusted product.
4. The Evolution of Modern Systems
Organisations today operate across hybrid cloud environments, multi-vendor technology stacks, and interconnected digital services. The old guidance was designed for more static, perimeter-focused architectures. The new framework is built for dynamic, distributed, modern systems.
Key Concepts in the New NCSC Cross-Domain Framework
Before diving into the six design principles, it is essential to understand the core concepts that underpin the entire framework.
Zones of Trust
A zone of trust is a collection of systems or services that share a broadly similar security posture. Every organisation operates across multiple zones — from internal business systems, to cloud platforms, to the internet — each carrying different levels of assurance and risk. The goal of cross-domain architecture is to enable safe data movement between these zones without compromising the integrity of any zone.
Trust Boundaries
A trust boundary exists wherever two zones of trust connect. The nature and strength of controls applied at a trust boundary should reflect the sensitivity of the data crossing it and the sophistication of the threats relevant to that environment.
Control Points
Control points are the specific locations within an architecture where security functions are applied to data as it traverses trust boundaries. Effective cross-domain architecture places control points deliberately, ensuring that assurance is built progressively through the data flow rather than at a single chokepoint.
The Pipeline Model
The NCSC describes cross-domain as a sequence of functions — often referred to as a pipeline — that builds 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 end-to-end approach means assurance is gained across the entire flow, not at a single point.
This pipeline model represents a significant conceptual shift from the older cross-domain solution (CDS) model, which treated security as a point-in-space problem. Under the pipeline approach, every stage of the data journey is a security consideration.
The 6 New NCSC Cross-Domain Design Principles Explained
The heart of the new guidance is six design principles that replace the legacy 13-principle framework. These principles are technology-agnostic, architecture-first, and applicable to any organisation operating in high-threat environments.
Principle 1: Understand and Minimise Data Transfer
Transfer only what is necessary to achieve the required business outcomes. Organisations should choose simple protocols and strip unnecessary information where possible. This reduces the attack surface, limits covert channel risks, and strengthens overall system assurance. Each data flow should be considered separately based on its specific characteristics and risk profile.
Practical implication: Before designing any cross-domain data flow, document precisely what data is needed, why it is needed, and what format it must be in. Any data element that cannot be justified should not cross the boundary.
Principle 2: Gain Trust Across the Entire Stack
All data should be considered untrusted at its origin, from the physical network layer to application context. Organisations should layer sequential security controls to progressively build confidence in all data that enables the flow. This includes terminating or inspecting all meaningful data — defined as specific content at each layer plus associated control data such as routing information or API parameters. Any content that could be interpreted as program logic — and therefore potentially lead to remote code execution — must be treated with particular scrutiny.
Practical implication: Security controls should not be concentrated at a single layer. Network-layer inspection, protocol validation, content filtering, and application-layer verification should all be applied in sequence.
Principle 3: Defend Against Compromise of Cross-Domain Functions
The components performing cross-domain functions are themselves high-value targets. Organisations must assume that attackers will specifically attempt to compromise these components. Defences should include hardware-based controls where appropriate, strong configuration management, and the principle of least privilege for all cross-domain functions.
Practical implication: Data diodes and hardware enforcement mechanisms may be required in the highest-risk environments. Software-only controls may be insufficient where adversaries are capable and persistent.
Principle 4: Limit the Impact of Compromise
Assume that some element of the cross-domain architecture may be compromised at some point. Design the architecture so that any compromise is contained and cannot cascade through the entire system. This means separating cross-domain functions from core business systems, minimising the permissions and privileges available to cross-domain components, and designing for resilience.
[ Practical implication: Segmentation, isolation, and blast radius minimisation are not optional extras — they are fundamental design requirements for cross-domain architectures.
Principle 5: Ensure Visibility and Control
Organisations must maintain comprehensive visibility into what data is crossing their trust boundaries and be able to detect and respond to anomalous activity. Audit logging, monitoring, and alerting must be built into the architecture from the outset, not bolted on as an afterthought.
Practical implication: Cross-domain pipelines should generate detailed logs of all data flows. Anomaly detection should be configured to flag unexpected data types, volumes, or patterns at each control point.
Principle 6: Enable Ongoing Assurance
Cross-domain security is not a one-time implementation — it is an ongoing practice. Organisations must establish processes for regularly reviewing and updating their cross-domain architecture as the threat landscape evolves, as technology changes, and as business requirements shift. Assurance activities should be embedded into the operational lifecycle, not treated as a pre-deployment checklist.
Practical implication: Schedule periodic architecture reviews specifically focused on cross-domain components. Engage with the NCSC’s Principles-Based Assurance (PBA) process for formal validation of cross-domain products.
What Has Been Deprecated? The Transition from Legacy CDS Principles
The 13 legacy security principles for cross-domain solutions are now deprecated for new end-to-end architectures. This is a significant change that organisations designing new systems must understand.
However, the NCSC has clarified that the legacy principles are not simply abandoned. They remain in use for Principles-Based Assurance (PBA) of existing cross-domain products in the medium term. The original import and export data design patterns are also being deprecated and will, over time, be replaced by new cross-domain patterns.
What this means in practice:
- If you are designing a new cross-domain architecture from scratch, use the new six-principle framework.
- If you are assessing or procuring a cross-domain product, the legacy 13-principle PBA process still applies in the near term.
- Watch for NCSC updates as the PBA approach is updated to align with the new design principles.
Who Does the NCSC Cross-Domain Guidance Apply To?
The guidance is written primarily for organisations that face a high-threat environment — where the harm from a security compromise would be significant, and where attackers have the capability to develop or acquire targeted exploits. This includes:
- UK government departments and agencies
- Critical national infrastructure operators (energy, water, transport, healthcare, finance)
- Defence and intelligence sector organisations
- Large enterprises handling sensitive personal, financial, or operational data
- Technology integrators and security architects building systems for any of the above
The NCSC also notes that cross-domain is increasingly relevant beyond traditional defence and intelligence contexts. Any organisation where the threat model assumes systems will be under targeted attack — and where harm from compromise would be serious — should apply this guidance.
Cross-Domain Architecture vs Zero Trust: How Do They Relate?
Many security professionals will notice significant conceptual overlap between the NCSC’s cross-domain guidance and Zero Trust Architecture (ZTA) principles. Both frameworks reject the idea of a trusted interior perimeter and both emphasise continuous verification, least-privilege access, and layered controls.
However, they address different problems. Zero Trust is primarily concerned with identity and access management — verifying who can access what, regardless of network location. Cross-domain architecture is primarily concerned with data flow security — ensuring that data can move safely between environments of different trust levels without either compromising the receiving environment or leaking information from the sending environment.
In practice, a mature security architecture will implement both. Zero Trust principles govern how users and devices access resources, while cross-domain controls govern how data moves between system zones. The NCSC’s guidance on both topics should be read in conjunction
Frequently Asked Questions (FAQs)
What is a cross-domain solution (CDS)?
A cross-domain solution (CDS) is an architectural technique and set of supporting technologies used to build secure connectivity between systems that have different trust levels. The NCSC’s new guidance reframes CDS from a point-solution product to a comprehensive architectural approach.
Is the NCSC cross-domain guidance mandatory?
For UK government departments and many critical national infrastructure operators, NCSC guidance carries significant weight and is often embedded in regulatory requirements. For private sector organisations, it provides a best-practice framework. Whether formally mandatory or not, non-compliance in high-threat environments represents a significant security risk.
What is the difference between a data diode and a cross-domain solution?
A data diode enforces unidirectional data flow through physical design, preventing any reverse data path. While data diodes are a valuable component of cross-domain architectures in high-risk environments, the NCSC clarifies that data diodes alone provide directionality rather than comprehensive security and should not be treated as a complete cross-domain solution.
Will the NCSC publish more detailed implementation guidance?
Yes. The NCSC has confirmed that further guidance is planned, covering step-by-step design processes, technology selection, and standardised cross-domain patterns that can serve as reusable templates across different use cases.
Conclusion: Why This Guidance Matters Now
The NCSC’s updated cross-domain architecture guidance represents a maturation of the UK’s approach to high-security data flow management. Moving from 13 prescriptive product-focused principles to six architecture-first design principles reflects how the threat landscape and technology environment have fundamentally changed.
For organisations operating in high-threat environments, this guidance is not optional reading — it is the blueprint for defensible, resilient, and future-proof cross-domain security. The pipeline model, the zone-of-trust framework, and the six design principles together provide a practical, technology-agnostic foundation for architects and risk owners alike.
The most important takeaway is this: cross-domain security is not a box you buy. It is an architectural discipline you practice — continuously, systematically, and with a clear-eyed view of the threats you face.
