Start a free trial
Menu

AComP-5639

AComP-5639 protected core networking static environment specifications

Protected Core Segment (PCS) and Protected Core Service Consumer (PCSC) operators building and running the national or coalition network segments that interconnect through NATO's Protected Core Networking (PCN) architecture

AComP-5639 is NATO's static-environment specification for Protected Core Networking, the interface, security, addressing and routing requirements that connect national network segments into a shared core, agreed by nations through STANAG 5639.

Edition
A
Published
2025-12
Evaluated by
self-declaration

What it is

AComP-5639 is the NATO Allied Communications Publication (AComP) that sets the Protected Core Networking (PCN) static-environment specifications: the interfaces, cryptography, addressing and routing that let separately-owned national network segments interconnect into a shared, protected IP core. It defines two roles: Protected Core Segment (PCS) Providers, who together provide the transport infrastructure, and Protected Core Service Consumers (PCSC), who connect to a PCS through a PCN-2 interface; PCSs connect to each other through a PCN-1 interface. The core itself carries no obligation to protect the content of user data - that stays the responsibility of the "Coloured Clouds" that use their own encryption devices - and this document does not cover the deployable, non-static environment, which AComP-5640 specifies separately.

It has no force by itself. It binds through ratification: "the agreement of nations to use this publication is recorded in STANAG 5639," and a nation can ratify with a scope limit, as the recorded reservation shows - Poland's national position restricts PCN in its own networks to Alliance-facing activity, in support of Alliance operations and missions, and excludes other national CIS. Edition A, Version 1 was promulgated in December 2025 and is effective on receipt.

Compliance is graded, not binary

Five characteristics of PCN (mobility, management, protection, federation and transport) are each defined across maturity levels, combining into overall PCN Capability Levels from CL0 to CL4. This edition specifies CL0, a manual, low-investment level of interoperability, and CL1, which adds semi-automated mobility and certificate-based authentication and link protection. An entity that only implements CL0 features "will still be considered compliant with the STANAG"; CL1 is simply the higher target this edition is written to support, and CL2 through CL4 are left for future editions, with CL2's likely shape sketched only as a non-binding roadmap.

Traffic Flow Confidentiality: two types are mandated now

Traffic Flow Confidentiality (TFC) conceals metadata about a communication - who is talking to whom, and traffic volume - not its content. Five TFC types are defined in the document, but only two are actually required at this edition: every PCN-1, PCN-2 and internal link "shall be classified to adhere at minimum to the common set of TFC types," and the types supported "for this STANAG version are: Packet Authentication and Source/Destination Hiding." Colocated links are treated as already meeting all five types through physical and procedural protection; non-colocated links achieve TFC through IPsec. PCS owners do not have this checked by an outside body - they declare which TFC types their own infrastructure supports to their peers through NMCD information exchange.

Addressing, service levels and trust

A single, centralised PCore Address Authority (PAA) allocates PCS identifiers, IPv4 ranges and anycast addresses and resolves conflicts between them, with each PCS also running its own address function for internal allocation. Every PCN-1 and PCN-2 connection needs its own Service Level Agreement, covering at minimum traffic markings, minimum and maximum bandwidth, and maximum delay and delay variation, with service classes drawn from AComP-4711; where a connection has to go live before its SLA is agreed, traffic is marked Low-Priority Data by default rather than left unclassified. Certificates for PCN entities follow X.509v3, signed with RSA 4096 and SHA-384 or EC P384, with revocation through Certificate Revocation List Distribution Points and optional Online Certificate Status Protocol checking; because PCN is federated rather than run by one authority, certificate issuers are required to support trust lists with each other as a minimum, with cross-certification or bridge structures as an option.

PCN-1 and PCN-2: different interfaces, different routing

PCN-1 (between two PCSs) and PCN-2 (between a PCSC and its serving PCS) share the same protection mechanism where the connection is not colocated: an IPsec ESP-protected GRE tunnel negotiated by IKEv2, using AES-256 in GCM mode, a fixed Diffie-Hellman group and SHA-384, with certificate-based authentication at CL1 and a pre-shared key accepted at CL0. Where the two interfaces genuinely differ is routing. PCN-1 uses dynamic routing: BGP-4 is mandatory, hardened with MD5 session authentication, a ban on accepting or advertising default routes, TTL security, and tuned keepalive and detection timers that differ between wired and wireless links. PCN-2, by contrast, "does not support dynamic routing protocols" at all - it relies on static routing, a default route from the consumer side toward the core and specific routes back.

Physical connectivity and autoconfiguration

Every conformant connection point has to support, at a minimum, the Ethernet carrier profile - 1000BASE-T or 1000BASE-LX, with tactical MIL-STD connectors recommended for field deployment - alongside optional profiles for connecting over public or military-provided networks, always inside the same IPsec protection. An optional autoconfiguration mechanism, built on RIPv2 and RIPng, lets two endpoints discover each other and self-provision a GRE tunnel and BGP peering without manual configuration, using a specific coded IPv6 addressing scheme for the discovery exchange itself.

What this document does not cover

Network Address Translation is a clean split rather than a blanket rule: forbidden inside the Protected Core, but allowed at the consumer-facing P-functionality. Holistic cyber security architecture - intrusion prevention, host monitoring, log correlation - is explicitly out of scope; a PCS operator is responsible for that design in their own segment. And several clauses on SLA change handling and end-to-end SLA principles point forward to a Network Management and Cyber Defence STANAG that is still under development, so an implementer following this document alone will find a documented gap rather than a finished management plane.

How we help

AComP-5639 is an operational and technical specification, not a management-system standard: configuring IPsec tunnels, issuing certificates, tuning BGP timers and running a Border Protection Function is network engineering work, done in the equipment itself rather than in software that manages a quality system. ComplyTrain's role is to hold the record that shows the design and operating decisions were made and kept: which PCN capability level a segment implements and why, the Service Level Agreement negotiated for each PCN-1 or PCN-2 connection and any later change to it, the Traffic Flow Confidentiality capability declared to peer operators, and the certificate and trust-list governance the Infrastructure of Trust Authorities depends on, as controlled, versioned documentation with an owner rather than scattered emails and spreadsheets.

What ComplyTrain does not do: it does not configure the IPsec, BGP or NMCD systems themselves, issue or manage the digital certificates, or operate the Border Protection Function. That engineering work, and the SLA and Traffic Flow Confidentiality declarations exchanged between PCS and PCSC operators, stays the responsibility of whoever runs the network.

Which capability level and which surrounding STANAGs a given programme actually has to meet is set by the coalition's own interoperability requirement, not by us. See what else sits alongside AComP-5639 in the standards explorer, and talk to us about the record-keeping behind it.

Standards it references

Questions

Is AComP-5639 mandatory?

There is no general answer. It takes effect for a nation through ratification, recorded in STANAG 5639, and a nation can ratify with a scope limit, as a recorded national reservation in the document shows. Whether it applies to a specific network segment depends on that nation's or coalition programme's own interoperability requirement.

What is the difference between AComP-5639 and AComP-5640?

AComP-5639 sets the PCN specifications for static environments. AComP-5640 sets the equivalent specifications for deployable environments. Both sit under the same PCN Head STANAG, AComP-5637, which describes the overall concept the two documents apply differently.

What is the difference between PCN CL0 and CL1?

CL0 is the minimum, manual level of PCN interoperability, needing the least investment. CL1 adds semi-automated mobility and certificate-based authentication and link protection. This edition of AComP-5639 is written to support CL1, but an entity implementing only CL0 is still considered compliant with the STANAG.

Is there a certification for PCN compliance?

No. The document names no accredited certification body, notified body or government inspection scheme. Conformance is structural - meeting the CL0 floor or the CL1 target - and operational: PCS owners declare their own supported capabilities, such as which Traffic Flow Confidentiality types they support, to peer operators through NMCD information exchange rather than being audited by a third party.

Why does PCN-1 use dynamic routing while PCN-2 does not?

PCN-1 connects two Protected Core Segments and needs BGP-4 to exchange routing information between them dynamically. PCN-2 connects a consumer network to a single serving segment through a fixed relationship, so the document specifies static routing instead: a default route from the consumer side toward the core, and specific routes back.