Data Sovereignty in Defense: What It Means and Where It Breaks

Introduction

If you work on a defense or aerospace program, you know the rules about how sensitive data is handled. A program can follow every one of them and still leave a gap in a place most teams never think to check.

The frameworks tell you what to protect. They say much less about the devices at the edge of your network, which is where data quietly leaves the perimeter in practice. This article gives a plain overview of the frameworks, explains the question that location alone does not answer, and points at the gap most programs miss.

What you will learn

• ■  Which frameworks shape data handling in defense and aerospace
• ■  Why a directive and a regulation are not the same thing
• ■  What the CLOUD Act changed about where data sits
• ■  Where sovereignty tends to break in practice

The Frameworks at a Glance

Skim takeaway: the US frameworks govern specific categories of data. The European ones govern cybersecurity practice, and only through national law.

The US Side: ITAR and CMMC

ITAR governs the export of defense articles and related technical data. The part that surprises people is that export does not require a border. Releasing controlled technical data to a foreign person counts as an export even inside the United States, which is why the question of who can reach the data matters more than where it sits.

CMMC is a different kind of instrument. It is a verification program, codified at 32 CFR Part 170, that establishes how the Department of Defense assesses whether contractors and subcontractors have implemented required cybersecurity standards for Federal Contract Information and Controlled Unclassified Information, the label for data that is sensitive but not classified. Its scope and rollout have changed more than once, so check the current rule rather than any summary.

What each one is about:

• ■  ITAR: a category of data and who may be given access to it
• ■  CMMC: the cybersecurity practices an organization can demonstrate

The European Side: NIS2 and National Law

NIS2 is a directive, not a regulation. That distinction does real work. A regulation applies directly across the EU. A directive has to be written into each member state's own law first, which means the binding text is national, and the details differ from country to country.

In Germany, NIS2 was transposed through the NIS2UmsuCG, which replaced the BSI Act (BSIG). The Federal Office for Information Security (BSI) is the competent authority and publishes guidance and a scope self-assessment for companies that need to work out whether they are covered.

For a program that spans several European countries, the underlying directive is shared, but the obligations differ by country.

The CLOUD Act: Why Location Is Not the Whole Answer

Programs often treat a data center's country as the end of the sovereignty question. The CLOUD Act is the clearest reason it is not.

The CLOUD Act amended the US Stored Communications Act. Under it, a covered provider must preserve, back up, or disclose data in its possession, custody, or control when compelled by valid US legal process, regardless of whether that data is located inside or outside the United States. The server's country is not the deciding factor. Whether a provider is covered turns on whether it is subject to US jurisdiction and can technically reach the data, not simply on where it is headquartered. The Act also sets out limited grounds on which a provider may move to quash or modify that process.

None of this makes external hosting unworkable. It does mean that a data center in your own country, operated by someone else, answers the residency question and leaves the control question open.

Questions location alone does not answer:

• ■  Which legal entity holds the contract, and where is it subject to jurisdiction?
• ■  Who holds the encryption keys?
• ■  Who at the provider can technically reach the data?
• ■  Who else in the program has a copy?

Where It Actually Breaks: The Endpoint

Most programs get the server side right. The gap is usually further out.

A defense program is rarely one organization. Primes, subcontractors, suppliers and design partners all touch the same sensitive data, and each brings its own infrastructure and its own security posture. You can run a tight environment and still have exposure through a party you do not control. That is worth mapping, but it is not where most programs are surprised.

The surprise is the device. Headsets, tablets and field hardware are mobile, often shared, and regularly used outside the building. When an application runs on the device itself, the data has to travel there to be useful, which puts it on a piece of hardware that leaves the perimeter by design. Device policy and access controls manage that exposure. They do not remove it.

Hololight's XR pixel streaming technology inverts the arrangement. The application runs and renders on a server inside the organization's own infrastructure, and what reaches the device is an encrypted stream of rendered images. The model files stay on the server. If a headset is lost, shared or taken off site, there is nothing on it to expose, because nothing was ever put there.

Conclusion

Data sovereignty in defense is usually described as a compliance problem, and the frameworks are where most programs start. They are worth knowing, and the official sources above are the place to read them. But a program can satisfy every one of them and still be carrying exposure at the edge, because the frameworks say little about the headset in a technician's hands. The useful question is not only where the data is stored. It is which devices the data has to travel to in order to be used, and whether it has to travel at all.

See how pixel streaming keeps XR data inside your infrastructure

Last updated: November 9, 2026

Sources

1. 1.  U.S. Department of State. International Traffic in Arms Regulations, 22 CFR Part 120. Electronic Code of Federal Regulations. ecfr.gov/current/title-22/chapter-I/subchapter-M/part-120
2. 2.  U.S. Department of Defense. Cybersecurity Maturity Model Certification (CMMC) Program, 32 CFR Part 170. Electronic Code of Federal Regulations. ecfr.gov/current/title-32/subtitle-A/chapter-I/subchapter-G/part-170
3. 3.  European Union. Directive (EU) 2022/2555 (NIS2 Directive). EUR-Lex. data.europa.eu/eli/dir/2022/2555/oj
4. 4.  Congressional Research Service. "Cross-Border Data Sharing Under the CLOUD Act," Report R45173. congress.gov/crs-product/R45173
5. 5.  U.S. Department of Justice. "CLOUD Act Resources." justice.gov/criminal/cloud-act-resources
6. 6.  Bundesamt für Sicherheit in der Informationstechnik. "NIS-2-regulierte Unternehmen." bsi.bund.de/dok/nis-2