The boundary problem
Traditional cross-domain solutions sit between two networks and inspect, filter or transform what crosses. They have done important work and will continue to. But they were designed for a world of a few fixed, well-defined boundaries. Modern operations are not like that. A single mission can involve national, coalition and partner networks, deployed and fixed sites, crewed and uncrewed platforms, and teams who need different parts of the same picture.
Every new boundary means another device to buy, accredit, configure and maintain, and every new information flow means another rule set at that boundary. The result is slow change, single points of failure, and information that exists on one side of a boundary but never reaches the people who need it on the other.
What changes with data-centric security
Data-centric security (DCS) moves protection from the network to the data. At DCS Level 3, as described in NATO's ACP 240 guidance, each file, message or video stream is encrypted, carries a cryptographically bound confidentiality label, and can only be opened when policy allows. Espanaro has demonstrated DCS Level 3 for documents and live video at NATO EFDI Accelerator 2.0 (self-assessed, not independently certified).
Once the data protects itself, the network it crosses matters less. The questions that used to be answered by a box at the boundary can be answered by policy, every time the data is requested: who is asking, from where, on what device and network, for what mission, and is this type of data allowed there?
Treat a domain as a set of attributes
The key step is to stop thinking of a domain as only a network, and to describe it instead with attributes. HarbourGuard, Espanaro's attribute-based policy engine, can hold attributes for devices, networks and places as well as for people. A domain then becomes whatever combination of attributes the mission needs.
| Attribute | Examples | What it lets policy decide |
|---|---|---|
| Nation or owner | UK, a named partner nation, a coalition mission | Whether data is releasable to that nation's people and systems |
| Classification | OFFICIAL, SECRET, coalition markings | The highest level of information the device or network may receive |
| Permitted data types | Video yes, raw sensor tracks no; documents but not chat | Which kinds of information may flow there at all |
| User groups | REME LAD, J2 or intelligence cell, force protection, duty officer | Which teams on that domain may see a given feed or file |
| Location | A building, a compound, a vehicle park, a deployed site, a region | Whether information may be opened in that physical place |
| Device type and trust | Command terminal, rugged tablet, sensor, health status | Whether the device itself is trusted to display or hold the data |
| Mission and time | Operation, exercise, mission phase, alert state | Whether access is open now, and when it should close |
Because these are just attributes, they can describe things a network boundary never could. Two teams on the same network can be different domains. A single building can be its own domain. A deployed site can change domain as the mission changes, without re-cabling anything.
What it looks like in practice
These are illustrative examples, not descriptions of specific operations.
Putting the decision in the operator's hands, within policy
Security owners define the rules once in HarbourGuard. Operators then make sharing decisions in the tools they already use. In Consilium, an operator can choose to share a feed with a team, a cell or a partner, and the choices available are only those the policy permits. ByteHarbour enforces the decision on the data itself, so even a mistaken share cannot release information to someone the policy does not allow.
This is the model Espanaro is building across ByteHarbour, HarbourGuard and Consilium: security owners stay in control of policy, operators stay in control of the mission, and every decision is recorded in a tamper-evident audit trail.
Cross-domain and all-domain
Cross-domain sharing is about moving information safely between two security domains. All-domain operations go further: land, maritime, air, space and cyber forces, nations and partners, all needing parts of the same picture at once. Fixed boundary devices struggle to scale to that, because the number of boundaries and flows grows faster than they can be accredited and configured.
Attributes scale differently. Adding a new team, site, partner or platform means describing it with attributes, not installing and accrediting another boundary. That is why data-centric security, combined with attribute-based policy, is the foundation NATO describes for data-centric interoperability (NATO Data Centric Reference Architecture).
Does this replace cross-domain devices?
Not everywhere, and not overnight. Some boundaries will keep dedicated cross-domain solutions, for example where content must be inspected or transformed, or where an accreditor requires a physical control. What data-centric security changes is how many flows need one. For information that is already protected, labelled and governed by policy at the object level, the boundary device no longer has to be the only place the decision is made. Programmes can reduce the number of boxes, simplify the ones that remain, and share information with far more precision than a network boundary allows.
Any change to how information crosses security domains remains a decision for the relevant accreditation authority. Espanaro works with customers and their accreditors to evidence how data-centric controls meet their requirements.
Where to start
- Pick one information flow that is slow or blocked today, such as a camera feed a support team cannot see
- Describe the people, devices, networks and places involved as attributes
- Write the policy once, and let operators share within it
- Measure time to share, and the number of manual releases avoided
Espanaro can demonstrate this on your scenario. Request a demonstration or read more about decision advantage.
Common questions
How does data-centric security help with cross-domain sharing?
With data-centric security, each item of data is encrypted, labelled and opened only when policy allows. The decision about who may receive it can be made wherever it is requested, rather than only at a fixed network boundary, which reduces how many information flows depend on dedicated cross-domain devices.
What attributes can describe a domain?
A domain can be described by nation or owner, classification, permitted data types, user groups such as a REME LAD or J2 cell, physical location such as a building or site, device type and trust, and mission or time. HarbourGuard evaluates these attributes against policy on every request.
Does data-centric security replace cross-domain solutions?
Not everywhere. Some boundaries will keep dedicated cross-domain solutions, for example where content must be inspected or transformed. Data-centric security reduces how many flows need one, and any change remains a decision for the relevant accreditation authority.
How do policy rules and playbooks work together?
HarbourGuard policy decides what is allowed. Consilium playbooks decide what should happen next, such as raising an alert, sharing a feed with a team or requiring acknowledgement. ByteHarbour enforces the policy on the data itself, so a playbook can never release data the policy does not permit.