Platform
Modules
By sector
By sector
By standard
Blog
News
Events
AEP-67
Programme managers and systems engineers building or acquiring an electronic, firmware or software-based system for a NATO programme, and the suppliers, operators and maintainers who support it
AEP-67 is NATO's engineering guidebook for building system assurance, justified confidence a system works as intended and resists exploitable vulnerabilities, into a programme's life cycle through a documented assurance case of claims, arguments and evidence.
AEP-67 is the NATO Allied Engineering Publication that tells a programme how to engineer "system assurance" into an electronic, firmware or software-based system across its whole life cycle. It defines system assurance as "the justified confidence that the system functions as intended and is free of exploitable vulnerabilities, either intentionally or unintentionally designed or inserted as part of the system at any time during the life cycle." It is a guidebook rather than a specification, and it is carried by STANREC 4808: the recommendation of nations to use it is recorded there, which means AEP is Allied Engineering Publication, and reaches a supplier the way any Allied Publication does, because a specific NATO programme's own agreement calls for it.
The current edition is Edition B, Version 1, promulgated October 2017, superseding the original Edition 1. It is unclassified and free of charge, published by the NATO Standardization Office for the CNAD's Life Cycle Management Group.
AEP-67's organising idea is the assurance case: a linked set of claims about a system's critical assurance properties, arguments that justify each claim, and evidence that supports each argument. A claim has to be a clear, testable statement, not an action, and it decomposes into sub-claims until each connects to retrievable evidence. The guidebook sets out minimum conditions for the case: it has to be relevant to the system's actual operating environment, claims have to be justified by arguments and arguments by evidence, and the whole case has to be built iteratively and kept alive throughout the life cycle rather than written once and filed away. It also has to be delivered with the system at handover, not left behind with the development team. An auditor working from this document does not look for a single sign-off; they look for a traceable chain from a stated claim, through its argument, to named evidence.
The guidebook is scoped tightly to security-related assurance: confidentiality, integrity, availability, authentication, accountability (including non-repudiation) and auditability. It says so directly, and just as directly says what is out of scope: "it does not address assurance for quality, safety, or dependability," though it notes that an adversary able to subvert a system's security can, as a side effect, undermine those other properties too. It also treats assurance as a property of the whole system rather than of any one part: a system built entirely from well-assured elements is not automatically assured, because assurance depends on how the parts are combined, not only on how each was built.
Where elements are bought rather than built in-house, AEP-67 asks the acquirer to weigh a supplier's reputation, qualifications, processes and tools, and to prefer standards-based interfaces and defence-in-depth so that one weak supplier cannot undo the whole system. Commercial and government off-the-shelf elements get particular attention, because an acquirer typically has little influence over an off-the-shelf product's future direction, and the guidance expects supplier-selection evidence, defect history, product assessments, relevant certifications the supplier already holds, to be written down and kept traceable.
The work breakdown structure is expected to name assurance activities explicitly: threat assessment, assurance-case development and maintenance, assurance-focused peer review, static and binary source-code analysis, and penetration testing. Major decision gates have to pass measurable assurance criteria, such as static-analysis results and red-team findings, before a programme proceeds. Risk management draws on named vulnerability sources (the Common Vulnerabilities and Exposures, Common Weakness Enumeration and Common Attack Pattern Enumeration and Classification catalogues) and treats probabilities qualitatively rather than numerically, because an intelligent adversary does not behave like a random failure and can choose the worst moment to attack. Configuration management has to produce an audit trail of who changed what and when, kept immutable to support accountability, apply least privilege to changes, and run a patch-triage process that weighs the risk of a known vulnerability against the risk of an unproven patch. Information management requires marking and protecting assurance-sensitive material and coordinating tightly with configuration management.
Requirements analysis separates intrinsic functions, which deliver the mission, from defensive functions, which protect it, and grades the system's criticality from Highest, where compromise causes catastrophic mission failure within seconds to minutes (Table 3-4), down to Low. Architectural design works through concrete techniques: least privilege, isolation and containment, monitoring and response, tolerance to partial failure, identification and authentication, cryptography, and ten named anti-tamper mechanisms running from tamper-evident seals to enclosures that zero their data if someone drills into them. Implementation is organised around named threat sources, an unintentional defect, a rogue authorised developer, an unauthorised intruder, a compromised supplier, each paired with countermeasures such as compiler warnings enabled from the start, static and dynamic analysis tooling, and paired development with peer review. Verification and validation call for a documented strategy covering static analysis, fuzz testing, penetration testing and red-teaming, and, for the most critical elements, formal proof techniques, carried out by people with the specific skills to interpret the results. Transition requires the installed system to be hardened, unnecessary services disabled, and delivery protected against tampering through chain of custody and tamper-evident packaging. Operation and training require users to be trained on what to do and what not to do, including recognising social engineering, and the system to be monitored for drift from its expected configuration. Maintenance requires patches to be authenticated, sometimes through a public key built into the deployed system, and requires that a correction never itself introduce a new vulnerability. Disposal requires sanitisation proportionate to sensitivity, up to incineration, since a well-resourced adversary may otherwise recover data from overwritten or degaussed media.
An auditor working from AEP-67 is, in the end, looking for a live set of cross-referenced artefacts rather than a certificate: a criticality determination, a work breakdown structure that names assurance tasks, static-analysis and peer-review records, red-team results, training records, and a disposal record, all traceable back to the claims in the assurance case.
AEP-67's own structure is built throughout on ISO/IEC 15288:2008, the systems and software engineering life cycle standard, and its Annex A surveys related civil information-security management work, ISO 9001, ISO/IEC 27001, ISO/IEC 27002 and ISO/IEC 27005, as background rather than as requirements the guidebook itself imposes. It is carried by STANREC 4808, the NATO recommendation that records nations' agreement to use it.
AEP-67 is an engineering guidebook, not a management-system standard: the work it demands, architecting for least privilege, writing secure code, running static analysis and penetration tests, hardening a system before transition, sanitising media at disposal, is systems and security engineering, carried out by engineers, not by a compliance platform.
What it demands throughout, though, is a controlled, evidenced record connecting every assurance claim to an argument and to named evidence, and that is where ComplyTrain fits. It gives a supplier or programme office a controlled-document home for the assurance case itself and the plans that feed it: the verification and validation strategy, the configuration-management strategy, the disposal strategy. Training records showing staff completed assurance and social-engineering training sit alongside it, as does the audit trail of who approved which version of which document, the kind of record a configuration-management process built around AEP-67 needs regardless of the tooling underneath it.
ComplyTrain does not run static-analysis tools, does not perform a penetration test or red-team exercise, and does not write or review source code; that stays with the engineering team. Using it does not by itself demonstrate that a programme has met the guidebook's expectations.
Which tier of assurance a specific NATO programme expects, and whether AEP-67 is invoked at all, is set by that programme's contract and quality clause, not by us. See what else sits alongside it for a defence programme in the standards explorer, and talk to us about the evidence trail behind it.
Tell us how you need to work with AEP-67 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 by itself. AEP-67 is carried by STANREC 4808, a NATO recommendation rather than a ratified commitment, so nations are invited to use it rather than obliged to. It reaches a specific supplier only when a programme's own agreement or contract calls for it.
No. AEP-67 names no certification scheme and no accredited body. It is a guidebook describing how to build and evidence an assurance case as part of ordinary systems engineering, reviewed at the programme's own technical reviews rather than assessed by an external certifier.
AQAP-2110 sets NATO quality assurance requirements for a supplier's management system, evaluated by a Government Quality Assurance Representative against a contract. AEP-67 is narrower and more technical: engineering guidance for building security-related system assurance into the system itself, not a management-system requirement.
AEP-67 defines it as the justified confidence that a system functions as intended and is free of exploitable vulnerabilities, whether inserted intentionally or unintentionally, at any point in its life cycle. It covers confidentiality, integrity, availability, authentication, accountability and auditability, and it explicitly excludes quality, safety and dependability as separate topics.
Yes. Its scope names electronic hardware, firmware and software elements together, including sensors, information processors and communication elements, and it treats assurance as a property of the whole system rather than of software alone.
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.