Start a free trial
Menu

AEP-4845

AEP-4845 soldier system reference architecture for power, electronics and data infrastructure

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.

Edition
A
Published
2026-07

What it is

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.

A recommendation, not an agreement

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.

Seven volumes, one architecture

The publication follows NATO's Architecture Framework (NAF) v3.1, with an added Security View the framework does not itself define.

  • Volume I, Summary and All View - the architecture's aim, its views, how nations agree to use it, and how they feed proposed changes back to its custodian rather than amending it themselves.
  • Volume II, Capability View - eight capability categories (C4, ISTAR, effective engagement, mobility, protection and survivability, sustainability and logistics, education and training, and multi-national interoperability) and the operational activities each supports.
  • Volume III, Operational View - the operational concept a soldier system serves, how a Small Tactical Unit organises and connects, and the volume's own non-functional requirements: environmental, electromagnetic compatibility, ergonomic, organisational, logistic, safety and security.
  • Volume IV, Service Oriented View - the taxonomy of services (power, data exchange, communication, human interface, C4I, sensor and effector) that deliver the capabilities above.
  • Volume V, System View - the longest volume, and the one that carries the bulk of a delivered system's actual requirements, organised by domain: the soldier's own Personal Domain, the Small Tactical Unit Domain, the Inter-Platform Domain where a soldier interacts with a vehicle, and the Joint and Coalition Domain.
  • Volume VI, Technical View - the standards catalogue behind the architecture, mostly informative.
  • Volume VII, Security View - a risk-assessment process and a corresponding set of security mechanisms for a soldier system's key components.

What a delivered system has to provide

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.

An informative technical view, with one binding line

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.

A menu of security measures, not a checklist

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.

What the document does not cover

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.

How we help

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.

Standards it references

Questions

Does AEP-4845 only cover "volume I: summary and all view"?

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.

Is AEP-4845 mandatory for NATO nations?

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.

Can a company be "AEP-4845 certified"?

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.

Does AEP-4845's Security View mandate specific security controls?

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.

What is the difference between AEP-4845 and STANAG 4677 or STANAG 4754?

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.