NATO Interop Implementation Walkthrough, Part 3: STANAG 4774/4778 Classification and Coalition Releasability

The data links from Part 2 move messages. The classification and releasability machinery decides which messages move to whom. STANAG 4774 defines the format for confidentiality labels; STANAG 4778 defines the cryptographic binding that prevents detaching labels from the data they label. Together they are the technical foundation of all NATO coalition data sharing. A platform that gets them right deploys in classified networks; a platform that treats them as a UI mask fails accreditation in the first review cycle. Part 3 covers the implementation discipline.

The pillar-level framing is in The Complete Guide to NATO Interoperability; the broader coalition-sharing patterns in Coalition Data Sharing Challenges; the RBAC foundations in Role-Based Access Control in Defense C2 Systems; the fusion-side propagation in Building a Defense Fusion Pipeline, Part 3.

Step 1: Labels Are Structured Data, Not Strings

The single most common implementation failure is treating classification as a string field — "SECRET", "NATO RESTRICTED" — attached to data records. The STANAG 4774 model is richer and structurally different.

A STANAG 4774 confidentiality label is a structured object with:

• Policy identifier. The classification policy under which the label was assigned (NATO, national, FVEY, EU). A policy defines the valid classification levels and compartments.
• Classification level. An ordered value within the policy — for NATO: UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, COSMIC TOP SECRET.
• Compartments. Named caveats restricting access — operationally significant, programme-specific, often classified themselves.
• Releasability tags. Which nations or organizations may receive the labelled data — FVEY, REL TO NATO, REL TO specific nations.
• Caveats. Additional restrictions (NOFORN, ORCON, others depending on policy).
• Originator. The producing entity, for audit and accountability.
• Creation timestamp. When the label was assigned.

Implement these as structured types with validation. A string "SECRET REL FVEY" parsed at runtime by string-matching is the engineering pattern that fails accreditation. Structured types, schema-validated at every boundary, are the pattern that passes.

Step 2: STANAG 4778 Cryptographic Binding

STANAG 4778 defines the cryptographic binding that ensures a label cannot be detached from the data it labels. The binding is computed by the producer and verified by every consumer; without verification, the label can be stripped, swapped, or tampered with.

The implementation pattern:

Compute the binding at the producing service. When an adapter, fusion service, or other component produces data, it computes the binding over the (label, data) tuple using its signing key. The key is anchored in a hardware-rooted trust store; the signing operation is logged.

Verify on every read. Consumers (the COP, downstream analytics, external API gateways) verify the binding before propagating the data. Verification failures are logged loudly and the data is rejected — not silently downgraded.

Preserve binding across serializations. When data flows onto the message bus, to the database, across the wire to a coalition partner, the binding moves with it. Storage formats accommodate the binding; communication protocols carry it. Stripping for "convenience" is the kind of shortcut accreditation reviewers specifically look for.

Per-attribute binding where required. Some data objects have attributes at different classifications. A track may have UNCLASSIFIED position but SECRET identity. STANAG 4778 accommodates per-attribute binding; the platform implements it where the classification model requires.

Step 3: Classification Propagation Through Fusion and Derivation

Defense platforms produce derived data. A track is derived from multiple source observations; a fused product is derived from multiple intelligence reports. The classification of derived data is computed from the classification of the sources — not assigned independently.

The propagation rules (recap from the fusion series and pillar):

• Classification level: maximum. A derivation from SECRET and UNCLASSIFIED sources is SECRET.
• Compartments: union. A derivation from compartment-A and compartment-B sources carries both compartments.
• Releasability: intersection. A derivation from FVEY-only and NATO-only sources is releasable only to the intersection.
• Caveats: most restrictive. NOFORN on any source makes the derivation NOFORN.

The rules are mechanical. Implement them as a library that every fusion service, adapter, and derivation point calls. Hand-rolled propagation per service drifts and produces inconsistencies that accreditation reviewers catch. A shared, code-generated library that every component uses is the discipline that scales.

Step 4: The Policy Engine

Labels on data are necessary but not sufficient. Access decisions require a policy engine that knows the user's clearance, citizenship, role, and the requested data's classification, compartments, and releasability. Every query against the platform passes through this engine.

The implementation pattern:

Policy as code. Releasability rules expressed in a versioned policy language. Open Policy Agent's Rego is the defensible default; alternatives like Cedar or hand-rolled DSLs exist but introduce maintenance overhead. Policy changes flow through code review, not configuration changes.

Decision evaluation at the query boundary. When a consumer queries the platform, the policy engine evaluates which records are visible and which attributes are visible per record. The result is a filtered view, computed at query time. UI-only filtering — sending the full data to the client and hiding it with CSS or JavaScript — is a Common Criteria violation and an immediate accreditation failure.

Per-decision audit log. Every access decision — user, requested data, classification, result — is logged immutably. The audit log is the evidence base for after-action review, forensic analysis, and accreditation periodic review.

Performance budgets. The policy engine sits on the COP critical path. Decision latency must be sub-millisecond. Caching strategies, pre-compiled policy bundles, per-user policy fingerprints — all matter. A naive policy engine is the most common cause of COP slowness in classified deployments.

Per-attribute decisions where required. The engine evaluates not just whether a record is visible, but which of its attributes are. A track might be visible to a coalition user with position released but identity withheld.

Step 5: Cross-Enclave Data Flows

Defense networks are not single enclaves. A platform operating across NATO RESTRICTED, NATO SECRET, and national-classified networks must move appropriate data between them while preventing inappropriate flows.

The patterns:

Per-enclave platform instances. Each classified enclave runs its own platform instance with its own data store, policy engine, and audit log. The instances are physically separated; the platform does not assume they share state.

Cross-domain bridges. Where data legitimately moves between enclaves — UNCLASSIFIED AIS flowing up to a SECRET enclave, releasability-scrubbed product flowing down to a coalition enclave — the movement goes through an accredited cross-domain solution. The bridge enforces classification rules at the boundary.

One-way diodes where required. For high-to-low data movement, one-way data diodes enforce direction at the network layer. The platform integrates with diode infrastructure rather than implementing its own.

Manual release where automation cannot reach. Some classification decisions cannot be safely automated. Per-product release of HUMINT or compartmented data may require human approval. The platform surfaces the candidate, captures the human decision with attribution, and propagates the approved release with audit.

The detailed coalition data-sharing engineering treatment is in Coalition Data Sharing Challenges.

Step 6: Coalition-Specific Releasability

Different coalitions have different releasability rules. The platform that wants to deploy across multiple coalition contexts must accommodate:

NATO releasability. The standard set of NATO classification levels and the REL TO NATO marking. Most operational platforms target this baseline first.

FVEY-only. The Five Eyes (AUS, CAN, NZ, UK, US) intelligence-sharing arrangement uses classification policies that do not map cleanly onto NATO levels. A platform targeting FVEY contexts implements the FVEY policy alongside NATO.

Bilateral arrangements. Many platforms have bilateral data-sharing arrangements with specific partners. Ukraine, Israel, Korea, Japan all have programme-specific arrangements. The releasability engine accommodates these as specific REL TO markings plus partner-specific compartment access.

EU releasability. EU-funded programmes have their own classification policy (EU CONFIDENTIAL, EU SECRET) that does not collapse onto NATO levels. EDF-funded platforms must accommodate both NATO and EU classification.

The discipline: implement a multi-policy classification engine, not a single policy. The engine knows about NATO, FVEY, EU, and bilateral policies as named entities; data carries the policy it was classified under; the policy engine evaluates access against the user's clearance under each applicable policy.

Step 7: Accreditation Evidence Generation

Accreditation reviewers will not take the platform's word for any of this. They will ask for evidence. The evidence is generated as a side effect of correctly-engineered classification machinery.

The evidence accreditation reviewers find credible:

• Code references showing where classification propagation rules are implemented, with traceability from policy to code.
• Audit log samples demonstrating per-decision logging across the spectrum of access scenarios.
• Test results from the platform's automated test suite covering classification propagation, releasability filtering, and binding verification under adversarial inputs.
• Operational deployment evidence — months or years of production operation with documented incident response, classification spillage prevention, and accreditation periodic review pass-throughs.
• Cross-domain transfer logs demonstrating that movement between enclaves was justified, approved, and recorded.
• Penetration testing reports from red-team exercises specifically targeting the classification machinery.

The DevSecOps discipline that generates this evidence automatically is covered in DevSecOps for Defense Pipelines. The supporting accreditation frameworks (ISO 27001, AQAP-2110, NIST) are covered in ISO 27001 in Defense Software and NATO AQAP-2110 for Software Vendors.

What's Next

Part 3 has implemented the classification machinery. STANAG 4774 labels as structured data, STANAG 4778 binding verified at every boundary, propagation through fusion and derivation, the policy engine enforcing releasability at query time, cross-enclave flows accommodated, multi-coalition releasability supported, evidence generation built in.

Part 4 closes the series with the validation and procurement disciplines: conformance testing, CWIX preparation, the accreditation pathway, and the long-tail maintenance discipline that keeps the platform deployable across multi-year operational lifetimes.