Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AComP-5640
Network engineering teams and PCS/PCSC owners building or operating a Protected Core Networking segment in a deployable mission environment
AComP-5640 sets NATO's PCN-1 and PCN-2 interface, authentication, addressing and carrier requirements so different nations' network segments can interconnect in deployable, federated mission environments.
AComP-5640 is the NATO Allied Communications Publication that defines the interoperability specifications for Protected Core Networking (PCN) in deployable mission environments. It exists so that separately-owned national network segments, called Protected Core Segments (PCSs), can plug into each other and into a shared federated core without every nation building or trusting a single network. The document says its own objective is "to define the Interoperability Specifications (ISpecS) of the PCN interfaces and PCS characteristics applicable to deployable mission environments." It covers deployable connections specifically, distinguishing its own scope from the "Deployable and Static environments" the wider PCN concept spans.
The document binds through STANAG 5640: "The agreement of nations to use this publication is recorded in STANAG 5640." AComP-5640 itself creates no direct obligation on a company. It reaches an implementer when a national or NATO programme decides a network segment has to interconnect over PCN-1 or PCN-2, whether that comes from a mission requirement, a Federated Mission Networking commitment, or a contract that names the document. A nation can also ratify with reservations rather than adopt the whole document: this edition's Record of Specific Reservations shows Denmark excepting two Traffic Flow Confidentiality types for satellite links "as current national systems don't have the necessary bandwidth yet."
PCN-1 connects two Protected Core Segments to each other. PCN-2 connects a Protected Core Service Consumer (a national or mission network, via its "P-functionality") into a Protected Core Segment. Both interfaces follow the same basic pattern when the connecting entities are not physically co-located: mutual authentication using IKEv2 with X.509 certificates, a GRE tunnel protected by IPsec ESP in transport mode, and AES-256-GCM encryption over a 384-bit elliptic-curve key exchange. Where entities are co-located at a single point of interconnection, a simpler native IP link with implicit, procedural authentication is permitted instead, and is treated as meeting the full range of Traffic Flow Confidentiality by virtue of the physical controls around it.
One difference between the two interfaces is easy to miss: PCN-1 runs BGP-4 as its mandatory routing protocol, but "the PCN-2 interface does not support dynamic routing protocols. Routing over the PCN-2 is based on static routing" - a default route from the consumer side and specific advertised subnets from the core side.
The document defines five types of Traffic Flow Confidentiality (TFC): Per-Packet Authentication, Source/Destination Hiding, Precedence Hiding, TFC Padding and Traffic Volume Hiding. Only two are mandated in this edition: "Supported TFC types for this STANAG version are: Packet Authentication and Source/Destination Hiding." PCS owners declare which TFC types their own infrastructure supports to their peers "via NMCD information exchange" rather than through any external assessment. Traffic Volume Hiding is explicitly not yet supported: the document notes that mechanism is left for a future version.
Every PCN entity (E-nodes, P-functionalities, NMCDs) authenticates using X.509v3 certificates issued by an Infrastructure of Trust Authorities, with a signature algorithm of RSA 4096 with SHA-384, or EC P384 (EC P521 optional), and certificate revocation supported via CRL, with OCSP as an option. Because PCN is federated, there is deliberately no single trust authority: multiple trust authorities issue certificates to different segments, and a trust relationship (at minimum, trust lists) has to be established between them before entities on different sides can connect.
Every connection needs a Service Level Agreement covering, at minimum, traffic markings, minimum and maximum bandwidth, maximum transfer delay and maximum delay variation, built on the traffic classes and QoS model in STANAG 4711. Where a connection has to go live before its SLA is fully negotiated, all traffic is marked Low-Priority Data by default rather than left unclassified.
The document is explicit about scope it deliberately leaves out. Information confidentiality of the actual payload is not PCN's job: the Protected Core is "a non-classified network" that "will not provide information confidentiality and integrity of the consumer data/payload," which stays the responsibility of the consumer's own cryptographic units. Likewise for security architecture in general: "offering a holistic cyber security architecture is out of the scope of PCN. PCS operators are responsible for developing and implementing a robust cyber security design in their PCS." PCN requires a border protection function that whitelists a specific, narrow protocol set (BGP, BFD, ICMP, and RIPng where autoconfiguration is used) at each interface, not a general security programme. Network Address Translation is forbidden inside the shared core but allowed at the consumer-facing edge, and every PCN entity has to stay synchronised to UTC within 1200 milliseconds, both concrete, checkable numbers rather than general guidance.
There is no accreditation, certification or notified-body scheme for AComP-5640. Conformance is expressed as being "PCN-compliant," and the document defines that operationally, not institutionally: an entity "shall implement PCN-1 interface, PCN-2 interface, or both" depending on its role, and whether it actually interoperates is what proves it, not an audit. The one place the document uses the word "certify" is the TFC capability declaration PCS owners exchange with their peers through the NMCD, which is a technical self-declaration, not a compliance certificate issued by any authority.
AComP-5640 leans on a small set of other NATO publications and a long list of IETF protocol standards. STANAG 5637 and its Allied Publication, AComP-5637 - the PCN "Head STANAG" - carry the overarching PCN architecture this document only summarises for completeness. STANAG 4711 / AComP-4711 supplies the traffic classes and QoS model this document's SLA requirements are built on. STANAG 4290 / AComP-4290 supplies the tactical connector standard named for field Ethernet deployments. Outside our catalogue, the document repeatedly points at STANAG 5655 / AComP-5655, the Network Management and Cyber Defence Specification, which is still "under development" and is where the NMCD interface this document only sketches is meant to be fully defined, and at a Standards Related Document for STANAG 5637's PCN address schema, also under development. The protocol mechanics themselves come from IETF RFCs: IKEv2 (RFC 7296, with its algorithm profile in RFC 8247), GRE (RFC 2784, extended by RFC 2890), ESP (RFC 4303), X.509 certificates and CRLs (RFC 5280), OCSP (RFC 6960), BGP-4 and its extensions (RFCs 4271, 4760, 2545, 6793, 1772), Bidirectional Forwarding Detection (RFC 5880, RFC 7419), the Generalized TTL Security Mechanism (RFC 5082), and private addressing (RFC 1918, RFC 4193).
AComP-5640 is published by the NATO Standardization Office and listed in the NATO Standardization Document Database, free of charge. NATO's documents are not sold by ComplyTrain and we host no copies.
AComP-5640 is a network interface specification, not a management system a company gets certified against, and there is no mapping we could honestly claim to it. The work it describes - configuring IKEv2 and IPsec, standing up GRE tunnels, running BGP sessions, issuing and rotating X.509 certificates, negotiating SLAs, whitelisting a border-protection profile - is network engineering, carried out by the people building and operating the Protected Core Segment. ComplyTrain does not configure or operate that infrastructure, and it does not perform the interoperability testing that proves a connection actually works.
What ComplyTrain supports is the procedural and evidentiary side of that work: a controlled place to hold a PCS or PCSC's connection and configuration procedures, its certificate lifecycle and trust relationship procedures, and its negotiated SLA records, together with training records for the engineers who implement PCN-1 and PCN-2, and an audit trail showing those procedures were followed and kept current.
In defence, which interconnection requirements apply to a given segment are set by the programme and the mission network agreement it operates under, not by AComP-5640 alone or by us. See the standards explorer for what sits alongside AComP-5640 in NATO's Protected Core Networking document set, and talk to us about how ComplyTrain can support the evidence trail your programme needs.
Tell us how you need to work with AComP-5640 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.
AComP-5640 is NATO's Allied Communications Publication defining the interoperability specifications for Protected Core Networking (PCN) in deployable mission environments: how separately-run national network segments authenticate, protect and route traffic to interconnect with each other and with consumer networks.
Not by itself. The nations' agreement to use it is recorded in STANAG 5640, and a nation can ratify with reservations against specific requirements. AComP-5640 reaches an implementer only when a national or NATO programme's network segment has to interconnect over PCN-1 or PCN-2, whether that comes from a mission requirement or a contract that names the document.
PCN-1 connects two Protected Core Segments to each other. PCN-2 connects a consumer network's "P-functionality" into a Protected Core Segment. Both use the same authentication and tunnelling model when not co-located, but PCN-2 uses static routing only, while PCN-1 requires BGP-4.
No. The document describes no accreditation, certification or notified-body scheme. Conformance is expressed as being "PCN-compliant" - implementing the specified interface - and is proven by actual interoperability, not by an external audit.
Edition A, Version 2, promulgated 2 April 2025 by the NATO Standardization Office. It supersedes Edition A, Version 1.
From the NATO Standardization Document Database, which lists it free of charge. NATO's documents are not sold by ComplyTrain and we do not host copies of them.
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.