Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AComP-5639
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.
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.
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 (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.
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 (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.
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.
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.
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.
Tell us how you need to work with AComP-5639 and what you need from it. We will come back to you about what ComplyTrain can do.
Thank you. Your list is on its way to your inbox, and we will come back to you on what working with these standards in ComplyTrain involves, usually within one business day.
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.
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.
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.
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.
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.
One system for the whole compliance programme. Start with the module you need most.
Collect information the same way every time, and decide in advance what happens next.
Know whether your controls are operating, not just whether a policy says they exist.
Turn the compliance work you already know about into a plan with owners, dependencies and dates.
Know what you can offer, and hold the evidence behind every configuration you offer it in.
Eight built-in reports across every module, scheduled, delivered, and filed where the evidence lives.
The sector news that matters to your organisation - read and rated by AI, and delivered as a scheduled digest in your own language.
AI reads the tender pack and pulls out the requirements, deadlines and rules - then helps you draft the response from your own approved content, with you reviewing every step.
One current register of the suppliers and partners you depend on - each risk-assessed, re-assessing itself on schedule, and wired straight into your risk register.
See every requirement you face - across every standard, plus your own contracts and policies - traced to the documents, evidence and processes that satisfy it.
Identify, score, treat and review your risks in one place - with AI to help anyone run a proper assessment, and a defensible trail behind every decision.
Assign training, prove it was understood, and hold the competence records an auditor asks for.
Draft compliance documents with AI, keep every version under control, and export them beautifully branded - all in one place.
Audits, corrective actions, processes and approvals in one quality system, organised around ISO 9001.
Medical device manufacturers operate under more regulatory pressure than almost any other sector outside pharmaceuticals. The rules govern how you design a device, how you make it, how you track it after it ships, and how you respond when something goes wrong.
Learn how EU dual-use export controls apply to encryption, sensors, and software, how classification works under Annex I, and why sending source code by email can count as an export.
A practical way to turn in-your-head risk management into a register that survives staff turnover and answers the risk questions now showing up in tenders.