Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEP-4845
Soldier system providers and sub-system or device suppliers building a nation's dismounted soldier system to NATO's reference architecture
AEP-4845 sets out NATO's seven-volume reference architecture for a soldier's power, electronics and data infrastructure, which nations use to derive their own target architecture rather than adopt directly.
AEP-4845 is the NATO Allied Engineering Publication that sets out the Soldier System Reference Architecture for Power, Electronics and Data Infrastructure, usually abbreviated NSSRA: an architecture, defined at NATO level, for the electrical, electronic, data and security infrastructure a dismounted soldier wears and carries. The record behind this page holds the complete publication - all seven volumes, all Edition A, promulgated together on 8 July 2026 - not only the summary volume its own cover page names. Nations do not implement NSSRA as written; they use it to derive their own national Target Architecture, and it is that derived document, appearing in a national programme or a contract, that actually reaches a supplier.
AEP-4845 is unusual among Allied Engineering Publications in how it acquires force. Most AEPs sit under a Standardization Agreement (STANAG), which nations ratify. This one sits under a Standardization Recommendation, STANREC 4845, and the document is direct about what that means: "as a STANREC, these requirements are recommended to be used when procuring or developing a target architecture for a DSS," and "by signing the STANREC, these requirements are not compulsory." Every numbered requirement in the System View volume carries one of three types - Recommended, Optional for Enhancement, or Required if a related enhancement is chosen - and even the "Recommended" type is non-mandatory in the STANREC sense. That does not make the architecture toothless: individual requirements are still written with "shall," and a nation's own Target Architecture, once it exists, can turn any of them into a genuine contractual obligation on a supplier.
The publication follows NATO's Architecture Framework (NAF) v3.1, with an added Security View the framework does not itself define.
Volume V is where a supplier meets concrete requirements. The DSS core has to offer defined connection ports and exchange data through a broker-based messaging architecture built on the reference's own data model; a soldier application is expected to be based on open interfaces "to promote open competition and avoid vendor lock-in." Where a soldier system talks to another nation's soldier system, the architecture defines a Loaned Radio arrangement, provided by the hosting nation and built around STANAG 4677; where it talks to a vehicle, its interface has to be "compliant with STANAG 4754" under STANAG 4754, NATO's generic vehicle architecture. Human interface devices, sensors and weapon-mounted effectors each carry their own port and connectivity requirements, and effector devices mount to the vehicle-and-weapon rail standard STANAG 4694. None of this page states a pin assignment, a voltage, a data rate or a message format - the point for a supplier is that a given port, protocol family or interoperability arrangement is required to exist, and where in the architecture it sits; the technical detail lives in the volumes themselves.
Volume VI compiles the standards the rest of the architecture draws on - general NATO conventions, safety, testing, power and product-conformity standards, plus standards mapped to specific System View sections - and says so plainly of the general categories: "the set of standards is just informative, hence they are not described further." Even its more detailed technical profile is offered as "a list of recommended standards, which guides and constrains the implementation," not a set of binding requirements in its own right. The one clear exception: the volume states that a DSS's vehicle interface "shall therefore be interfaces with the vehicle compliant with STANAG 4754" - a single binding line inside an otherwise informative volume. Some of the standards this volume points to had not themselves been ratified when this edition was written: it names STANAG 4851 as a connector still going through NATO's ratification process, and lists STANAG 5069 and STANAG 4681 in the same still-being-ratified state.
Volume VII runs an IT security risk-assessment process against a soldier system's key components, then sets out a corresponding set of security mechanisms. It is explicit about the kind of document it is: it "does not assume any classification level" and instead "gives a wide range of technical security measures from which a subset may be chosen in order to reduce the risk for the classification level and architectural specifics chosen for a desired DSS Target Architecture." Its safeguards are overwhelmingly written as "should" rather than "shall" - separation of management functionality from user functionality, isolation of security functions, trusted paths for high-assurance connections, and similar measures are all offered this way. Two are the exception: the safeguards covering denial-of-service protection and the confidentiality and integrity of transmitted information are both worded as things a soldier system must do, sitting inside an otherwise should-based table. The volume also states plainly that external users are not identified or authenticated into a soldier system at all - only internal, registered users and devices are accommodated - and that accepting whatever risk remains once chosen safeguards are applied is a decision for management, not something the document adjudicates itself.
AEP-4845 names no certification, accreditation or test-house scheme for assessing an organisation against it. Volume VI's own conformity-related standards table offers a supplier's declaration of conformity (ISO/IEC 27005's risk-management approach and ISO/IEC 17050-1/17050-2's declaration model) only as "guidance to be considered," entries in an explicitly informative list, not a mandated scheme. It does not fix connector pin-outs, voltages, data rates, message formats or security-mechanism configuration detail on this page: those live in the volumes' own tables and are engineering work for the team building to them.
AEP-4845 is a technical reference architecture, not a document any single supplier implements wholesale: NATO expects a nation to turn it into its own Target Architecture first, and it is that document, not AEP-4845 directly, that reaches a supplier through a tender or a contract. Once it does, the engineering itself - the ports, the data exchange architecture, the interoperability radio arrangement, the chosen security safeguards - is design and integration work, not something a compliance platform performs. What ComplyTrain does for that kind of work is hold the evidence trail around it: a record of which of the architecture's Recommended, Optional and Required-if-chosen requirements a programme adopted and why, traceability from a target-architecture requirement to the design decision and test result that satisfies it, the security risk-assessment output and the safeguards chosen from Volume VII's menu, and training records for anyone whose work touches the interfaces. That evidence is what a nation's own programme office, or a prime contractor further up the chain, will ask a supplier to produce.
What ComplyTrain does not do: it does not design the soldier system's power, data or communication interfaces, build the data model implementation, run the security risk assessment itself, or decide which of the architecture's optional requirements a programme should adopt. Those stay engineering and programme-management decisions.
Which of AEP-4845's volumes and requirement types apply to a given programme is set by the nation's Target Architecture and the resulting contract, not by us. See what else sits alongside AEP-4845 in NATO's soldier-system and land-armaments family in the standards explorer, and talk to us about the evidence trail behind it.
Tell us how you need to work with AEP-4845 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.
No. Volume I is one of seven volumes that make up the complete publication, all promulgated together at Edition A. The other six cover the capability view, the operational view, the service oriented view, the system view (where most of a delivered system's requirements sit), the technical view, and a security view.
No, not in the way a Standardization Agreement is. AEP-4845 sits under a Standardization Recommendation, STANREC 4845, and the document itself says that signing the STANREC does not make its numbered requirements compulsory. A requirement becomes binding on a supplier only once a nation has built it into its own Target Architecture and a contract or tender names it.
No. The document names no certification, accreditation or test-house scheme by which an organisation is assessed against it. Its conformity-related standards table offers a supplier's declaration of conformity as one item on an explicitly informative list, not a mandated certification.
Mostly not. Volume VII gives a wide range of security measures for a soldier system, written overwhelmingly as recommendations to choose from according to the classification level and architecture a nation is building. Two of its numbered safeguards, covering denial-of-service protection and the confidentiality and integrity of transmitted information, are worded as things a soldier system must do rather than should.
AEP-4845 is the reference architecture for a soldier's own power, electronics and data infrastructure. STANAG 4754 (and its AEP-4754) is NATO's separate vehicle architecture, invoked wherever a soldier system interfaces with a vehicle; STANAG 4677 is the separate standard for dismounted-soldier command-and-control interoperability that AEP-4845's own data model and interoperability-radio arrangement build on. All three work together but are not the same document.
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.