Building a C2 System from Scratch, Part 4: Interop, Security, and Deployment

Parts 1 through 3 built a platform that ingests sensor data, fuses tracks, and presents them to operators. Part 4 is the work that distinguishes a prototype from a deliverable: NATO interoperability bridges so coalition partners can exchange data; classification labelling and releasability enforcement so the platform can handle classified information; the DevSecOps pipeline that produces accreditation evidence as a side effect of building software; and the deployment patterns that get the platform onto operational networks ranging from GovCloud to air-gapped tactical nodes. After Part 4, the platform is operationally deployable.

For the architectural framing on interop, security, and procurement, see The Complete Guide to NATO Interoperability and The Complete Guide to Defense Cybersecurity.

Step 1: NATO Interoperability Bridges

The running example platform must exchange data with coalition partners. The brigade-level scope makes three interop bridges essential and the rest deferrable.

CoT bridge. Cursor on Target is the tactical lingua franca. The platform exposes a bidirectional CoT bridge: tracks flow out as CoT messages for ATAK/WinTAK clients and partner systems; CoT messages flow in and become tracks. The bridge is a thin adapter on top of the message bus — it reuses the adapter pattern from Part 2. Schema validation is strict; malformed CoT is rejected with a logged error rather than silently passed through. The integration details are in Cursor on Target (CoT): The XML Standard Behind Tactical Awareness Apps and ATAK Plugin Development.

MIP4-IES mapping. For exchange with national C2 systems above brigade, MIP4-IES is the schema. The bridge is heavier than CoT: the mapping between the canonical track schema and MIP4 entities is dense, version-tracked, and unforgiving in conformance testing. Build the mapping as a separate service with its own round-trip test harness — see MIP4-IES: The NATO Ground Standard. Resist the temptation to embed MIP4 concepts in the canonical schema; the schema stays clean, the mapping carries the complexity.

STANAG 4559 ISR consumer. If the platform consumes national-source imagery, the 4559 NSILI service interfaces are required. The implementation is well-defined; the engineering effort is mostly in handling the imagery store, the metadata mapping into the track store, and the bandwidth management on tactical links — see STANAG 4559 Implementation.

For Link 16 and similar tactical data links, the practical pattern is to integrate through a hardware MIDS terminal with a vendor API rather than implementing the J-series radio stack in software. The brigade-level scope rarely justifies the engineering. See Link 16 Tactical Data Links: Engineering View.

Step 2: Classification Labelling and Releasability

Every data object the platform produces carries a confidentiality label. STANAG 4774 defines the labelling format; STANAG 4778 defines the cryptographic binding that prevents detachment. Together they are the foundation of all coalition data sharing.

The engineering integration:

• Source classification is carried by every adapter. The adapter knows the classification of its source and tags every track update with it.
• Effective classification is computed in the fusion engine. A track derived from a SECRET radar return and an UNCLASSIFIED AIS report is SECRET. A track derived from FVEY-only and NATO-only sources is releasable only to the intersection.
• Releasability tags are carried alongside classification — a list of nations or organizations cleared to receive the data.
• Policy engine evaluates every query: given the user's clearance, citizenship, role, and the requested data's classification, releasability, and compartment, is access permitted? Open Policy Agent is one defensible implementation; the engine is decoupled from the application layer so policy changes do not require code releases.
• Enforcement at every layer — API boundary, database query, message-bus subscription. Never only at the UI. The RBAC integration pattern is in Role-Based Access Control in Defense C2 Systems.

The broader engineering treatment of coalition data sharing — including the policy engine pattern and the operational anti-patterns to avoid — is in Coalition Data Sharing Challenges.

Step 3: DevSecOps Pipeline

The pipeline that builds and ships the platform must produce accreditation evidence as a side effect. Retrofitting evidence to an ad-hoc pipeline is a multi-year project; baking it in from day one is a sprint.

The pipeline stages for the running example:

• Source-control hooks. Commit signing required. Pre-commit hooks reject secrets in code, run lint and format checks.
• CI build. Reproducible builds — same inputs produce same outputs. Build artefacts are content-addressed (SHA-256 of contents as identifier).
• Static analysis. Language-specific linters; security-focused static analysis (Semgrep, CodeQL, language-specific tools). Findings gating the build, not just advisory.
• Dependency scanning. Every direct and transitive dependency checked against CVE databases. Findings trigger build failures with documented exception process for unfixable issues.
• SBOM generation. SPDX or CycloneDX SBOM for every artefact, published to a registry alongside the artefact. See SBOM in Defense Procurement.
• Container hardening. Minimal base images (distroless or scratch where possible). Non-root users. Read-only filesystems. Image-signing with cosign or equivalent.
• Test gates. Unit, integration, contract, performance, and adversarial test suites. Coverage targets enforced; performance regression gates the release.
• Signed releases. Every release artefact signed; the signature chain anchored in a hardware-rooted trust store.
• Evidence collection. Test results, SBOMs, scan reports, build logs all collected and stored against the release. The accreditation file is built from the collection automatically.

The detailed pattern for adapting commercial DevSecOps to accreditation cycles is in DevSecOps for Defense Pipelines. The ISO 27001 baseline that supports it is in ISO 27001 in Defense Software Development; the NATO AQAP-2110 quality management layer in NATO AQAP-2110 for Software Vendors.

Step 4: Deployment Across the Spectrum

A brigade-level C2 platform deploys across a spectrum of environments. The same artefacts must work in each.

Secure cloud. Azure Government, AWS GovCloud, equivalents. Kubernetes-orchestrated, with managed services for the message bus and databases where the classification permits. The pattern is in GovCloud Architecture for Defense.

On-premises classified network. Self-hosted Kubernetes cluster on national-classified infrastructure. The pipeline accommodates the network's update cadence — typically slower than commercial cloud, with package mirrors and approval gates between dev and prod.

Tactical edge. Single-node or small-cluster deployments on ruggedized hardware. k3s or systemd-nspawn rather than full Kubernetes. Resource constraints and intermittent connectivity drive architectural choices. The mesh-networking side is in MANET Military Mesh Networking; the radio-integration side in Tactical Radio Software Integration.

Air-gapped deployment. Fully disconnected networks. Updates arrive through controlled transfer media (one-way diodes, signed update packages on physical media). The pattern is documented in Air-Gapped Deployment for Defense. The discipline most easily overlooked: build the offline package format and the update verification flow into the platform from day one, not after the first air-gapped customer asks.

The unifying principle is that all four deployment models use the same artefacts. Different deployments use different orchestration, different update cadences, different network topologies — but the binaries and the configuration are the same. Variant binaries per deployment are a recurring source of accreditation failures.

Step 5: Testing, CWIX, and Operational Validation

A platform that has never been tested with coalition partners is not interoperable, no matter what the conformance test results say. The validation hierarchy:

• Unit and integration tests in the CI pipeline. Cover the canonical schema, adapter parsing, fusion correctness, COP rendering invariants. Gate every release.
• Conformance tests against standards. CoT well-formedness, MIP4 round-trip, STANAG 4559 imagery exchange. Automated where the standard permits; manual where it requires human-in-the-loop scenarios.
• Bilateral integration tests with at least two coalition partners. Run early and often. The ambiguities in standards surface here before they surface at formal exercises.
• CWIX and equivalent annual exercises. Submit relevant test cases. Passing CWIX is the strongest interoperability signal available short of operational deployment.
• Operator-in-the-loop validation. Real operators using the platform against realistic scenarios. The test that distinguishes operationally-survivable from demo-grade software. The discipline is in Testing Mission-Critical C2 Systems.

The broader engineering posture for mission-critical platforms — long-tail maintenance, technical debt management, hiring cleared engineers — is in Mission-Critical Software Architecture, Technical Debt in Defense Systems, and Security Clearance for Software Teams.

Closing the Series

Four parts ago this was a blank repository. We chose scope and architecture, designed the canonical track schema, picked a tech stack, built the fusion engine, rendered the Common Operational Picture, and now we have closed the loop with interop, security, and deployment. The platform produces trustworthy tracks, displays them to authorized operators, exchanges them with coalition partners under classification controls, and ships through a pipeline that generates accreditation evidence automatically.

The series has stayed at the level of architectural decisions and engineering principles. The specific implementations — choice of fusion algorithm, choice of frontend library, choice of message bus — are defensible but not unique. Different choices made for sound reasons produce different but equally valid platforms. The decisions that do not vary are the structural ones: four-layer architecture, canonical track schema, lifecycle management, classification at every layer, evidence-generating pipeline, deployment spectrum.

For the broader architectural framing of any C2 build, see the pillar guide: The Complete Guide to Command and Control (C2) Systems. For deep dives on the individual layers, the focused articles linked throughout this series. For procurement context, the market and procurement pillars: Defense Data Fusion, NATO Interoperability, AI in Defense, Defense Cybersecurity.