Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEP-4671
Unmanned aircraft system Applicants and their engineering teams working toward a Type Certificate from a National Military Certifying Authority
AEP-4671 (USAR) sets NATO's airworthiness requirements for fixed-wing military UAS between 150 and 20,000 kg MTOW, the basis a National Military Certifying Authority uses to certify a specific design.
AEP-4671 is the NATO Allied Engineering Publication that sets out the Unmanned Aircraft Systems Airworthiness Requirements, referred to throughout the document as USAR. It is Edition B Version 1, promulgated April 2019, and it is the publication STANAG 4671 exists to put into force: the STANAG is nations' ratification agreement, and USAR is where the actual technical requirements live. USAR is "intended primarily for the airworthiness certification of fixed-wing military Unmanned Aircraft Systems (UAS) with a maximum take-off weight (MTOW) between 150 and 20,000 kg" (clause 1.1), though a Certifying Authority may apply it outside that band "where considered applicable."
USAR does not start from a blank page. Its own introduction states "it is the intention of this document to correspond as closely as practicable to a comparable minimum level of airworthiness for fixed-wing aircraft as embodied in documents such as EASA CS-23" (clause 1.2.1), and most of its requirements are based on CS-23, tailored to unmanned systems, with USAR's own paragraph numbering following CS-23's structure. An Applicant may instead propose tailoring from CS-VLA or the larger-aircraft CS-25, subject to the Certifying Authority's acceptance. USAR is also explicit about the boundary this creates: "military aircraft are not specifically required to comply with civil airworthiness regulations as agreed in the ICAO Convention on International Civil Aviation" (clause 1.2.1) - USAR borrows the civil codes' structure and rigour without importing civil aviation law's authority over military aircraft.
USAR addresses two parties directly: the Applicant, who designs the UAS and assembles the compliance evidence, and the Certifying Authority, a National Military Certifying Authority that reviews that evidence and issues the Type Certificate. USAR defines the term broadly: "throughout this document, the term 'Type Certificate' refers to any document issued by a National Military Certifying Authority that within the regulatory framework of that Nation certifies compliance" (clause 1.1) - in practice this covers a Release To Service, a Military Aircraft Type Qualification Certificate, or a Flight Permit, whatever a nation's own military airworthiness process calls it.
Before the detailed requirements can be applied, the Applicant and the Certifying Authority agree a Type Certification Basis, and establish a Design Usage Spectrum and any Special Conditions at the beginning of the certification process. The certificate is granted to the design, not to the company that produced it: engines and propellers each need their own Type Certificate or an accepted qualification, separate from the overall UAS certificate, and a modification or a new intended mission can require the UAS to be re-certified for it.
Book 1 carries the requirements themselves, arranged in subparts that follow the CS-23 pattern: General (Subpart A); UA Flight, covering proof of compliance, weight and load-distribution limits, performance and flight characteristics (Subpart B); UA Structure, covering general and flight loads, ground loads, and fatigue evaluation (Subpart C); UA Design and Construction, covering materials, control systems, landing gear, fire protection and parachute design (Subpart D); UA Powerplant, covering engine, propeller and fuel, oil and cooling systems (Subpart E); Equipment, covering navigation architecture, environmental control, HIRF protection and the system safety assessment (Subpart F); Operating Limitations and Information, including the UAS Flight Manual (Subpart G); the Command and Control Data Link, covering architecture, latency and link-loss strategy (Subpart H); and the UA Control Station, covering the crew workplace, minimum crew and recorders (Subpart I). A set of appendices supports specific requirements: landing-condition load cases, a self-extinguishing-materials test procedure, the format for Instructions for Continued Airworthiness, and HIRF test environments among them.
Every USAR paragraph in Book 1 has a matching Book 2 paragraph, the Acceptable Means of Compliance, spelling out one accepted route to satisfying it - a reference document, a test method, an analysis approach - without being the only route the Certifying Authority may accept.
USAR lets an Applicant show compliance by analysis, test, simulation, inspection or similarity to an already-certificated design, largely as the Applicant proposes and the Certifying Authority agrees. The central compliance mechanism for equipment, systems and installations is the system safety assessment required by USAR.1309: "the UAS must be designed to reduce the risk to people including UAS crew, ground staff and third parties to a level acceptable to the Certifying Authority" (USAR.1309(a)), through a functional hazard assessment that classifies failure conditions by severity, from No Safety Effect through Catastrophic. Book 2 names SAE ARP 4761, or alternatively MIL-STD-882, as the accepted methodologies, and compliance with the resulting requirements "may be shown by analysis and, where necessary, by appropriate ground, flight, or simulator test" (USAR.1309(c)(4)). Software normally has its safety aspects demonstrated against DO-178C/ED-12C, and complex hardware against DO-254/ED-80, each with an alternative route open where the Certifying Authority agrees one.
One requirement worth naming because it runs against an assumption a reader might bring to unmanned systems: USAR requires the UAS to integrate an emergency recovery capability, and explicitly rules out explosive in-flight destruction of the aircraft as an acceptable way of providing it.
USAR's introduction states plainly that cybersecurity and sense-and-avoid sit outside its scope, alongside other areas it deliberately excludes - worth knowing, since both are commonly assumed to sit inside "UAS airworthiness." A compliance programme built around USAR needs a separate basis for those.
USAR cites STANAG 4671 with mandatory force for structural strength: "the UA must meet the strength requirements of STANAG 4671" (AMC.U304 2(b)(2)) - the same STANAG whose ratification is what makes USAR a national certification basis in the first place. Elsewhere it points to NATO material as background rather than a requirement: AEP-29, printed in the document as "AEP-29 (NATO STANAG 3856)," for guidance on precipitation-static effects; STANAG 3634 for runway friction and braking conditions; and STANAG 4586 for the design of the UAS communications system. Outside the NATO catalogue, Book 2 cites civil aviation material, including EASA CS documents, FAA Advisory Circulars, and standards such as DO-160, DO-178C and the SAE ARP series, consistently as material an Applicant "may" cite or base evidence on, not as binding requirements in their own right.
Meeting AEP-4671 is engineering and airworthiness work: an Applicant's design and quality functions produce the structural, systems-safety, software and hardware evidence the publication calls for, agree a Type Certification Basis with the Certifying Authority, and carry that evidence through to the UAS Flight Manual and Instructions for Continued Airworthiness that follow the Type Certificate into service.
What ComplyTrain does for that kind of work generally is give a design or quality organisation one auditable place to hold the procedures behind that evidence: document control for the Type Certification Basis and its supporting analyses, training records for the engineers and inspectors carrying out the substantiation work, and the review, non-conformance and corrective-action trail a Certifying Authority's representative would expect to see when asking how a piece of evidence was produced.
ComplyTrain does not design an unmanned aircraft system, run the structural or system safety analyses AEP-4671 calls for, or certify that a UAS meets it. Airworthiness assessment and the Type Certificate itself are the Certifying Authority's to grant, on evidence the engineering work itself has to produce.
Which parts of AEP-4671, or of the wider STANAG 4671 and USAR framework, actually apply to a given programme is set by the contract and the customer's certification basis, not by us. Browse the explorer to see what sits alongside AEP-4671, and talk to us about holding the evidence trail once you know what your programme requires.
Tell us how you need to work with AEP-4671 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.
STANAG 4671 is the NATO ratification agreement; AEP-4671 Edition B, referred to as USAR, is the publication that actually carries the unmanned aircraft systems airworthiness requirements. Ratifying STANAG 4671 is how a nation commits to implementing AEP-4671.
No company holds a certificate against AEP-4671. A National Military Certifying Authority reviews an Applicant's compliance evidence and issues a Type Certificate, or an equivalent document such as a Release To Service, to the UAS design itself, not to the manufacturer as an organisation.
It is written for fixed-wing military unmanned aircraft systems with a maximum take-off weight between 150 and 20,000 kg (clause 1.1), though a Certifying Authority may apply it outside that range where it considers it applicable.
No. The document states plainly that cybersecurity and sense-and-avoid sit outside USAR's scope, so an Applicant needs a separate basis for those areas.
It becomes a nation's certification basis once that nation has ratified and implemented STANAG 4671, and it applies to a specific programme once a National Military Certifying Authority adopts it for that programme, not on a fixed calendar date, and not directly on a supplier without that step.
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.