Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEDP-4858
Engineering teams building or integrating a NATO air vehicle's or ground control station's file-transfer function, where a contract or national authority invokes STANAG 4858
AEDP-4858 is NATO's technical specification for a resilient file delivery protocol used in air-to-ground transfers over degraded networks, agreed by nations through STANAG 4858.
AEDP-4858 is a NATO Allied Engineering Documentation Publication: a technical protocol specification, not a management-system or quality-assurance standard. Its own aim clause states it exists "to promote interoperability in air-to-ground file delivery among North Atlantic Treaty Organization (NATO) systems." It does not define a new protocol from scratch; it requires a file transfer system to "comply with CCSDS File Delivery Protocol (CFDP) Recommended Standard CCSDS 727.0-B-5", the civil space-data standard published by the Consultative Committee for Space Data Systems, and adds a small set of NATO-specific requirements on top of it.
The document itself never names a reader role such as supplier, manufacturer or operator. Its requirements fall on "file transfer systems", which it defines as "any system, such as an air vehicle or ground control station, capable of performing file transfers over a data link" - in practice, the engineering teams that build or integrate that function. AEDP-4858 carries no ratification of its own: "the agreement of nations to use this publication is recorded in STANAG 4858". A STANAG binds a nation, not a company directly, so AEDP-4858 reaches a supplier only when a contract or a national authority invokes STANAG 4858 and, through it, this publication. Edition A, version 1 was promulgated in January 2024 and "is effective upon receipt".
The scope is deliberately narrow: "the protocol specified in this document applies to air-to-ground file transfers", and air-to-air transfer is named and excluded - "other types of transfer, such as air-to-air, are not currently in the scope of this document". The document also states it "does not require use of any specific network or transport protocols, as those are dependent upon the data link used", though conditional requirements apply "when specific other protocols are used" - the UDP framing rule below is one of those.
Three requirements sit on top of the base CFDP protocol. Where a file transfer system also implements STANAG 4586/AEP-84 (Standard Interfaces of Unmanned Aircraft (UA) Control System (UCS) for NATO UA Interoperability), it reuses that ID: "they shall use their STANAG 4586/AEP-84 ID as their CFDP Entity ID". Every Protocol Data Unit carries its own check: "file transfer systems shall include a Cyclic Redundancy Check (CRC) in each PDU in accordance with Section 4.1.1 of the CFDP Standard". Over a UDP network, framing is fixed: "the sending system shall transmit one PDU per UDP packet".
CFDP offers two modes the document calls classes, and roughly half of AEDP-4858 is worked examples for choosing between them. Class 1 is one-way - "no packets are sent from the receiver of the file to the sender of the file" - and suits a receiver that must "maintain radio silence" rather than reveal its position, typically over multicast so "the receiver address does not have to be known in advance." Class 2 is two-way: "these transfers allow the receiver to notify the sender of missed packets so the sender can re-send the missed packets," generally faster because the sender is not sending redundant data on the chance a packet is lost. AEDP-4858 works through four mission pictures - a single two-way ground station, a single silent receive-only station, a mixed pair, and multiple receiving stations - and treats the choice of class as a mission-by-mission engineering decision, not a fixed default.
AEDP-4858 names no inspection, audit or certification mechanism. It states the protocol and framing requirements a file transfer system must meet and says nothing about how, or by whom, compliance with them is checked - no accredited certification body, no government surveillance role, no notified body and no self-declaration process appears anywhere in the document.
AEDP-4858 is an engineering requirement, not a management-system standard: implementing CFDP, carrying the right entity ID and CRC, and choosing the correct transfer class for a mission is systems and software engineering work, done in the design of the file transfer system itself, not in a compliance platform. What ComplyTrain does is hold the documentation and evidence trail around that work: recording which STANAG 4586/AEP-84 ID a system's CFDP Entity ID maps to, keeping the design rationale for which CFDP class a given mission profile uses, and tracing the requirement back to the contract clause that invoked STANAG 4858, so that evidence is ready whenever a customer's quality clause asks for it.
What ComplyTrain does not do: it does not implement CFDP or any other network protocol, it does not perform the systems engineering AEDP-4858 requires, and it makes no claim that a product is "AEDP-4858 compliant" or NATO-qualified - the document describes no scheme to be qualified against. The tier of NATO documentation that actually reaches a contract, and the specific Allied Publications that come with it, are set by the contract and the customer's quality clause, not by this page. The standards explorer shows what else sits alongside AEDP-4858 in the catalogue, and we are glad to talk through what a specific contract requires.
Tell us how you need to work with AEDP-4858 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.
Not on its own. AEDP-4858 is an Allied Engineering Documentation Publication covered by STANAG 4858, and "the agreement of nations to use this publication is recorded in STANAG 4858." A STANAG binds a nation, so AEDP-4858 reaches a supplier only when a contract or a national authority invokes STANAG 4858, not by existing.
No. It requires compliance with an existing civil standard, CCSDS File Delivery Protocol (CFDP) Recommended Standard CCSDS 727.0-B-5, and adds a small number of NATO-specific requirements on top of it: an entity-ID rule linked to STANAG 4586/AEP-84, a mandatory CRC in every Protocol Data Unit, and one PDU per UDP packet when the network is UDP.
No. Its own scope clause is explicit that "other types of transfer, such as air-to-air, are not currently in the scope of this document." AEDP-4858 covers only air-to-ground file delivery.
The document names no certification, audit or accreditation scheme of any kind. It states technical requirements for a file transfer system and does not describe how, or by whom, compliance with them is checked.
Class 1 is one-way, with no return path from the receiver, and is typically used over multicast when a receiver needs to stay silent rather than reveal its position. Class 2 is two-way: the receiver can ask the sender to retransmit anything it missed, which is generally faster because the sender is not pre-emptively sending redundant data. AEDP-4858 walks through four mission scenarios and treats the choice between them as a mission-by-mission decision rather than a fixed default.
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.