Atom Cybersecurity — two practices, one standard
ITAR • DDTC • US Munitions List

The technical data is controlled. So is who can see it.

If you manufacture or export defense articles — or hold the drawings, specifications, and source data behind them — the International Traffic in Arms Regulations govern how that technical data moves and who is allowed near it. Get the architecture wrong and an ordinary support ticket can become a reportable export violation. Atom builds the enclaves and access controls that keep ITAR data compliant while your engineers keep working.

The basics, correctly

What ITAR actually is.

The International Traffic in Arms Regulations are administered by the US Department of State through the Directorate of Defense Trade Controls (DDTC). They control the export of defense articles, defense services, and the technical data tied to them — everything enumerated on the US Munitions List (USML).

“Technical data” is the part that catches software and IT teams off guard: blueprints, drawings, specifications, and documentation required to design, produce, or maintain a defense article are controlled even when nothing physical ever ships. Violations carry heavy civil and criminal penalties — substantial per-violation fines, and, for willful violations, prison time. This is a strict regime, and intent is not always a defense.

  • Regulator — US State Department, via the Directorate of Defense Trade Controls (DDTC).
  • Scope — defense articles, defense services, and technical data on the US Munitions List.
  • Technical data — drawings, specs, and documentation to design, produce, or maintain a USML item.
  • Penalties — significant civil fines per violation and criminal exposure for willful breaches.
  • Registration — manufacturers and exporters of USML items generally must register with DDTC.
The “who” question

Who is allowed to see the data?

ITAR restricts access to technical data to US persons. Giving a non-US person access — even inside your own building, even without anything leaving the country — can itself be an export.

Definition

What counts as a “US person”

  • US citizens
  • Lawful permanent residents (green-card holders)
  • Protected individuals — certain asylees and refugees

A visa holder on staff, an offshore developer, or a foreign-national support engineer at your cloud vendor is generally not a US person for ITAR purposes.

The trap

The “deemed export”

Disclosing controlled technical data to a non-US person is treated as an export to that person’s country — a deemed export — even if the data never leaves US soil.

In practice that means a foreign-national administrator with backend access, an unrestricted file share, or a helpdesk in the wrong region can constitute an unauthorized export. The control is not just your firewall — it is who holds the keys and who can reach the data, all the way down the stack.

ITAR §120.54

Why properly encrypted data can live in the cloud.

For years the open question was whether storing ITAR technical data in a commercial cloud was itself an export, because the provider’s foreign-national staff could theoretically reach it. ITAR §120.54 answered it: sending, storing, or moving technical data is not an export when the data is properly end-to-end encrypted — because a non-US person can only ever touch ciphertext.

This carve-out is the entire basis for compliant cloud architecture. But it is conditional, and the conditions are technical. Miss one and you are back to a potential deemed export. The three prongs must all hold:

How Atom implements this →

The three conditions
  • a

    End-to-end encryption

    The data is encrypted end to end, with no access by the cloud provider or any intermediary to the unencrypted content.

  • b

    You hold the keys

    The sender or data owner retains exclusive control of the decryption keys. The provider cannot decrypt on your behalf.

  • c

    No clear-text exposure

    No unencrypted technical data is accessible to non-US persons at any point — including the cloud provider’s own staff.

ITAR 22 CFR §120.54

The environment

CUI enclaves and why GCC High became the default.

Microsoft’s Government Community Cloud High (GCC High) has become the de facto environment for contractors handling CUI and ITAR/export-controlled data — because it is built to keep the data inside US boundaries and reachable only by screened US persons.

01

US data boundary

GCC High stores data in US-sovereign data centers and is operated by screened US-person personnel — the operational answer to the US-person access requirement, not just a marketing label.

02

Enclave strategy

You do not have to drag your whole company into GCC High. An enclave isolates CUI and ITAR data into a defined boundary — identity, storage, and collaboration — leaving the rest of the business where it is. Smaller boundary, tighter control, fewer controls to prove.

03

Data-boundary control

The enclave is only as good as its edges. Conditional access, labeling, data-loss prevention, and disciplined external sharing keep controlled data in the boundary and non-US persons out of it.

Two regimes, one enclave

How CMMC and ITAR fit together.

They are different regulators asking different questions, and many contractors must answer both at once.

CMMC is a Department of Defense program. It governs how you protect CUI — the controls, the evidence, the assessment.

ITAR is a State Department regime. It governs who can access defense technical data — US persons only, keys included.

Build the enclave once, correctly, and it can carry both: NIST SP 800-171 controls for CMMC and US-person access plus §120.54 encryption for ITAR.

See the CMMC 2.0 roadmap →

CMMC — the HOW
  • Regulator: DoD
  • Protects: CUI
  • Measure: NIST SP 800-171
  • Proof: C3PAO assessment
ITAR — the WHO
  • Regulator: State / DDTC
  • Protects: technical data
  • Measure: US-person access
  • Proof: controls & records
What we do

How Atom helps you stay on the right side of ITAR.

We are a security and compliance enablement partner — not your export-control counsel and not a C3PAO. What we build and operate is the technical machinery that makes the regulation hold in practice: the enclave, the access model, the keys, and the monitoring that proves it stayed controlled.

Legal classification of your articles and USML jurisdiction stays with your counsel. Everything downstream of that decision — the architecture and the day-to-day operation — is where we live.

Talk through your enclave →

  • Enclave design — stand up and configure a CUI/ITAR boundary, typically Microsoft GCC High, scoped tightly around the controlled data.
  • US-person access controls — identity, conditional access, and segmentation so only screened US persons reach technical data, upstream and down.
  • Encryption & key management — end-to-end encryption with customer-held keys, implementing the §120.54 conditions so the provider never touches clear text.
  • Monitoring — managed detection, logging, and alerting on the boundary to catch access anomalies and support any incident reporting.
  • Documentation — the policies, data-flow records, and evidence that show — to an assessor or an auditor — that access stayed controlled.
Get the architecture right

One enclave. Both mandates. No deemed exports.

Request a readiness assessment. We’ll map where your technical data lives, design the US-person-controlled enclave, and implement the encryption and key management that keep ITAR data compliant — while satisfying CMMC in the same boundary.

Request a Readiness Assessment