NATO cloud tiers: unclassified, secret, and top secret infrastructure architecture

NATO's classification framework divides information into four bands – NATO Unclassified (NU), NATO Restricted (NR), NATO Confidential (NC), and NATO Secret (NS) – with Cosmic Top Secret (CTS) sitting above all of them for the most sensitive alliance information. Each band imposes distinct infrastructure, personnel, and process requirements. Software that operates across more than one tier cannot treat classification as an afterthought; the tier model is load-bearing architecture.

For defense software vendors, understanding how these tiers map to physical infrastructure, network architecture, identity systems, and accreditation processes is not optional. A product that is certified only for NATO Unclassified environments will not be accepted for NATO Secret operations regardless of its technical capability. Conversely, over-engineering a system to Secret standards when Unclassified suffices drives unnecessary cost and schedule risk. Getting the tier mapping right from the beginning is the most consequential architectural decision in a NATO program.

The NATO classification tier model

The NATO security policy, governed by C-M(2002)49 and its successor documents, defines classification levels as markers of the harm that unauthorized disclosure would cause. The practical infrastructure implications of each level are significant:

NATO Unclassified (NU) covers publicly releasable information and internal administrative data that does not require protection beyond standard IT hygiene. NU systems can use commercial cloud services, shared infrastructure, and standard internet-connected networks. The NCIA cloud service catalogue lists approved commercial services for NU workloads. This tier is roughly analogous to the US DoD NIPR (Non-classified Internet Protocol Router) network.

NATO Restricted (NR) is a mid-tier classification for information that, if disclosed, would be disadvantageous to NATO interests. NR is not universally used across all NATO nations – several member states do not have a domestic Restricted equivalent. Infrastructure for NR workloads must be within controlled facilities with access restrictions, but can share physical hardware with other NR workloads from different nations under logical separation controls.

NATO Confidential (NC) covers information whose disclosure would damage NATO interests. NC systems require dedicated logical environments, approved cryptographic systems (typically from the NCIA-approved catalogue), and personnel with a minimum security clearance. NC is roughly analogous to the US SIPR (Secret Internet Protocol Router) network at the lower end.

NATO Secret (NS) is the primary operational classification for sensitive alliance planning, intelligence, and operational data. NS infrastructure must be physically separated from NC and below – separate servers, separate storage, separate networking. Personnel access requires a NATO Secret clearance and need-to-know. Most tactical and operational NATO software operates at NS. The US equivalent is SECRET on SIPR or IL5/IL6 in the cloud context.

Cosmic Top Secret (CTS) and its special caveats (CTS/ATOMAL, CTS/BOHEMIA, etc.) require SCIF-equivalent physical security, full air-gap from external networks including NS, and strictly limited personnel pools. CTS systems are operated only in NATO-controlled or nationally-accredited facilities. No commercial cloud offering, however well-accredited, qualifies for CTS.

Physical separation requirements at each tier

Physical separation requirements are the most concrete expression of classification tiers, and they drive infrastructure cost more than any other factor.

At NATO Unclassified, shared physical infrastructure is permitted. A NU workload can run in a multi-tenant commercial cloud data center alongside non-NATO tenants, provided the cloud service is on the NCIA approved list and logical isolation (VPC, namespace, tenant separation) is correctly configured. This makes NU the only tier where hyperscale commercial cloud is a genuine option without facility-level controls.

At NATO Restricted and Confidential, physical infrastructure must reside in a NATO-accredited facility or a nationally-approved equivalent. The server, storage, and network hardware must be dedicated to NATO workloads – it cannot be shared with commercial tenants or non-NATO government workloads. Within a NATO-accredited facility, NR and NC systems may share hardware under strict logical separation, but the facility itself provides the physical security boundary.

At NATO Secret, physical separation becomes more absolute. NS servers, storage, and networking must be on dedicated hardware that is not shared with NC or NR workloads. The hardware must reside in a facility meeting NATO's TEMPEST requirements (protecting against electromagnetic emanation), with zone-controlled access and CCTV coverage of server rooms. Portable storage media used in NS environments must be tracked, controlled, and handled under NATO's COMSEC (communications security) procedures.

At Cosmic Top Secret, the physical security requirements approach those of a national intelligence facility: full SCIF construction standards, personnel access via two-factor biometric or card systems, Faraday shielding, and no network connectivity to external systems – including other classified networks – without an approved CDS.

Compute options by tier

Commercial and GovCloud (NATO Unclassified). NU workloads can be deployed on commercial hyperscale platforms (AWS, Azure, GCP) using NCIA-approved service offerings. For NATO member nations with domestic sovereignty requirements, national cloud platforms operated by approved providers are preferred. The NCIA Hybrid Cloud provides a managed NU environment for NATO's own administrative and publicly-facing systems.

Sovereign cloud and dedicated tenancy (NATO Restricted / Confidential). The practical compute options for NR/NC workloads are sovereign cloud deployments – nationally-operated cloud infrastructure running on approved hardware in controlled facilities – or dedicated private cloud environments in NATO-accredited data centers. Several NATO nations have established national defense cloud programs: the UK's MOD Managed Cloud Services, France's Cloud au Centre (SFT3), and Germany's Bundeswehr Informationstechnik GmbH (BWI) cloud programme. These platforms are designed specifically to hold NR/NC data and have undergone national accreditation.

Air-gapped sovereign infrastructure (NATO Secret). NS compute runs on air-gapped infrastructure – physically isolated servers with no external network connectivity. Software deployment to NS environments happens via accredited media (encrypted USB, optical disc, or dedicated transfer workstation) through a CDS. Container orchestration at NS tier typically uses a hardened Kubernetes distribution deployed on bare-metal or private hypervisor, with no connectivity to external registries or update channels. All container images must be pre-pulled, verified, and loaded onto air-gapped registries before deployment.

Network architecture and cross-domain solutions

The defining network challenge in a multi-tier NATO deployment is controlling data flow across classification boundaries. Data that originates at NS cannot flow to NU networks without passing through an approved cross-domain solution. The CDS enforces the security policy at the boundary – it is not simply a firewall, but a specialized appliance that applies content inspection, data validation, and format transformation rules defined in the system's accreditation package.

Guard devices are bidirectional filtering appliances that allow approved data types to flow between tiers under defined conditions. A guard might permit sanitized sensor data to flow from NS to NU for wider distribution, while blocking any flow of planning or intelligence data. Guards require a detailed content filtering policy signed off by the accreditation authority, and the policy itself becomes a security artefact that must be version-controlled and audited.

Data diodes are hardware-enforced one-way transfer devices – physically, they contain only a transmitter on the high side and only a receiver on the low side, making it impossible for data to flow in the prohibited direction. Data diodes are used for bulk transfer from high to low (e.g., pushing sanitized tactical logs from NS to NU for analysis) where bidirectional communication is not required. Products like Owl Cyber Defense DualDiode and Waterfall Security Unidirectional Security Gateways are common in NATO-equivalent deployments.

Protocol breaks prevent direct TCP/IP sessions from spanning classification boundaries. Even where a guard permits data to flow, the connection must terminate at the guard and be re-originated on the other side – no end-to-end session is permitted to cross a tier boundary. This has significant implications for real-time applications: streaming video, voice, and sensor feeds that cross from NS to NU must be re-encoded and re-transmitted at the guard, introducing latency and requiring format negotiation.

For Corvus Quantum, which provides secure video and data streaming in defense environments, multi-tier deployments require the streaming pipeline to be implemented as a tiered relay – an NS encoder feeds an approved CDS, which re-originates a sanitized stream at the NU side. The streaming protocol must be CDS-compatible (typically UDP with fixed packet structure that guard content filters can parse), not a stateful session protocol that requires end-to-end TCP.

Identity and access management across tiers

Each classification tier maintains its own PKI (Public Key Infrastructure) trust anchor, and certificates from a lower-tier PKI are not automatically trusted in a higher-tier environment. At NATO Unclassified, standard commercial PKI or national government PKI may be acceptable. At NATO Secret, the identity infrastructure is the NATO PKI – a dedicated certificate authority operated by NCIA that issues certificates to smart cards (NATO CIS tokens) distributed to personnel with NS clearances.

The practical consequence for multi-tier applications is that a user working across tiers must have separate identities and separate hardware tokens for each tier. A system that attempts to share a single identity across NU and NS is not accreditable. Applications must implement separate authentication flows for each tier, with no session token or credential material crossing the tier boundary.

Multi-factor authentication is mandatory at all tiers above NU. At NC/NS, the standard is certificate-based authentication using a hardware token (PKI smart card) plus PIN – biometrics may supplement but cannot replace the certificate factor. Password-only authentication is not accepted at any classified tier. For web-based applications deployed in NS environments, mutual TLS with client certificate authentication is the baseline, with no exceptions for developer or service accounts.

Privileged access management at NS tier typically requires jump servers (privileged access workstations, PAWs) that are physically and logically isolated from standard user workstations, with all privileged sessions recorded and subject to audit. The PAW environment itself must be part of the accredited system boundary.

Software certification and the NATO accreditation process

Software operating at NC or NS tier must be certified through NATO's security accreditation process, managed by the NATO Security Accreditation Authority (SAA) – the body within NCIA responsible for approving systems for operation within NATO networks. The accreditation process follows NATO's INFOSEC Technical Baseline (ITB), a set of security requirements covering access control, cryptography, audit, vulnerability management, and configuration management.

The accreditation package includes a System Security Plan (SSP) documenting the system boundary, data flows, and security controls; a risk assessment mapping residual risks to the ITB; a Configuration Management Plan; and an Incident Response Plan. For software deployed in national facilities under bilateral agreements, the national Designated Accreditation Authority (DAA) – equivalent roles exist in the UK (DSO), Germany (BSI), France (ANSSI), and other member states – may conduct the accreditation in place of NATO SAA, but the standards applied must meet or exceed the ITB.

Vendors should plan for multiple accreditation cycles. Initial accreditation typically involves a first submission, a findings report from the SAA, a remediation period, and a re-submission – the complete cycle routinely takes 12–24 months for NS systems. Every major software release that changes the system boundary, introduces new data flows, or alters cryptographic implementations may trigger a partial re-accreditation. Building accreditation maintenance into the product development lifecycle – not treating it as a one-time event – is essential for programs with multi-year operational horizons.

Deployment patterns for multi-tier applications

The dominant architectural pattern for multi-tier NATO software is the tiered relay: a single logical application with separate deployments at each classification tier, connected by approved CDS for controlled data exchange. Each tier-specific deployment is an independent accredited system, even if it runs the same codebase. Changes to shared components must be re-qualified in each tier's accreditation package before deployment.

Data sanitization before cross-tier downgrade is the most technically complex element of this pattern. A reporting application that aggregates NS operational data for distribution to NU networks must implement a sanitization workflow that strips classified fields, removes embedded metadata (EXIF data in imagery, author information in documents, GPS coordinates in sensor logs), converts data to formats that cannot carry embedded classified information, and logs each transfer with sufficient audit detail to reconstruct the provenance of every item that crossed the boundary.

Automated sanitization can handle structured data (database records with defined field classifications) but is inadequate for unstructured data (natural language documents, imagery, audio). For unstructured data downgrade, a human review step – a trained classification reviewer inspecting the sanitized output before it crosses the boundary – is typically required by accreditation authorities. Software can assist the reviewer (highlighting probable classified passages, flagging imagery containing equipment or personnel), but the review decision must be attributable to a named, accountable individual.

For vendors whose products integrate with zero-trust architectures in NATO environments, the tier model adds a dimension to the standard zero-trust model: in addition to verifying identity, device posture, and request context, the policy engine must also enforce data classification-based access controls – ensuring that a user authenticated at NS cannot inadvertently exfiltrate NS data through an application interface exposed at NU. This requires classification labels to be attached to data objects at the point of ingestion and enforced through the entire application stack, including caches, queues, and temporary storage.

What this means for defense software vendors

The NATO tier model is not an abstract compliance framework – it is a set of hard engineering constraints that determine what you can build, how fast you can deploy it, and how you must architect every data flow. Vendors who treat it as a checkbox exercise discover its implications late, when remediation is most expensive.

The most important practical steps are: define your target tier at the outset of architecture design, not after development; engage the NATO SAA or national DAA in pre-accreditation consultations before submitting a formal package; build your CDS interface design in parallel with your application design, not after it; and treat accreditation maintenance as a continuous engineering function, not a one-time program milestone.

For products such as Corvus Quantum that stream classified data across or within NATO networks, the tier architecture defines the entire streaming topology – encoder placement, CDS integration points, relay node security requirements, and the latency budget available after accounting for CDS inspection overhead. These are not parameters that can be optimized after the fact; they must be designed into the system from the first architecture review.