ARP4754B Explained: Changes, Recognition, and Compliance

The FAA has not revised the advisory circular that recognizes ARP4754A, and EASA has not adopted ARP4754B as a formal means of compliance. Both have moved anyway, in documents that are easy to miss and that do not grant the same thing. Which revision forms a program’s certification basis now depends less on the publication date than on what the program is building and which authority it answers to.

The revision itself is easier to absorb than that suggests. Core development principles carry over from ARP4754A intact, so teams fluent in the A revision won’t need to relearn the process. The documentation load is what changed, with two new obligations in the plan set and a formal Change Category assignment behind every modification. This guide covers what changed, where recognition stands today, and how to comply without rebuilding trace evidence before every authority review.

What Is ARP4754B?

ARP4754B, an SAE Aerospace Recommended Practice (ARP), provides system-level guidance for civil aircraft and systems development. SAE International released it on December 20, 2023, titled “Guidelines for Development of Civil Aircraft and Systems,” through the S-18 Aircraft and System Development and Safety Assessment Committee. ARP4754B superseded ARP4754A and appeared alongside the companion safety assessment standard ARP4761A. Its European Organisation for Civil Aviation Equipment (EUROCAE) counterpart is ED-79B, and both documents connect aircraft functions and operating context to development assurance activities.

The standard sits at the top of the development assurance hierarchy. Aircraft requirements flow down to system requirements and then to item requirements, where an item is a hardware or software element with bounded, well-defined interfaces. At the item level, ARP4754B hands off to DO-178C for software and DO-254 for airborne electronic hardware. The standard also references DO-297 for integrated modular avionics and DO-326A for airworthiness security, while ARP4761A supplies the safety assessment methods.

What ARP4754B Changed and What It Now Requires in Writing

The B revision is an alignment release, scoped by the S-18 committee to keep ARP4754B consistent with the simultaneously released ARP4761A, with larger adjustments deferred to a future Revision C. The changes are structural and documentary:

• Moved development assurance level detail: General principles for assigning Functional Development Assurance Levels (FDALs) and Item Development Assurance Levels (IDALs) stay in ARP4754B, but the detailed assignment activities moved to ARP4761A and its EUROCAE counterpart, ED-135. Compliance arguments now depend on both documents cross-referencing coherently.

• Less prescriptive validation and verification: The revision is less prescriptive about which method a program picks and more emphatic about bidirectional traceability and engineering review, with analysis, modeling, and testing all available and more room to justify the mix.

• Unintended behavior in place of unintended function: ARP4754B places stronger emphasis on identifying and mitigating unintended behaviors and on specifying the testing that will find them, including parameters outside the expected range, data bus noise, and interruptions to the electrical supply.

• New named safety analysis methods: The revision added Model-Based Safety Analysis (MBSA) and Cascading Effects Analysis (CEA), neither of which appears in ARP4754A, and it acknowledges the benefits of Model-Based Systems Engineering (MBSE) for safety assessment and requirements work.

• Formal change impact analysis: The expanded Modifications and Reuse section requires a documented change impact analysis assigning each element a Change Category of Unmodified and Unaffected, Affected, Modified, or New, with development assurance activities tied to each category.

• Authority coordination folded into planning: The Certification Authority Coordination chapter has been integrated into Development Planning in Section 3.3, so the compliance methods a program agrees with its authority sit inside the development plan.

For programs on derivative aircraft or supplemental type certificates, each of these items lands in a plan template that already exists and now has to be reissued.

Where FAA and EASA Recognition of ARP4754B Stands

ARP4754A remains the recognized baseline for establishing a development assurance process under FAA Advisory Circular (AC) 20-174, issued September 30, 2011, and most active civil programs still work under it. The FAA’s 2026 Transport Airplane Issues Lists state that “AC 20-174 addresses required aspects of ARP4754B,” under the issue covering unique flight deck failure modes for airplanes certified to Amendment 25-152 and later.

That reads as operational acceptance without a new AC revision, though the FAA has not said so. On the European side, recognition has come document by document. A certification memorandum gives guidance on structured development assurance, an amendment covers European Technical Standard Order (ETSO) articles, and two means of compliance cover unmanned aircraft system (UAS) and vertical takeoff and landing (VTOL) designs.

The six documents differ in what each grants.

SAIL and FDAL are separate scales, one from the risk assessment for unmanned aircraft operations, the other running from A to D.

The two means of compliance and the CS-ETSO amendment let unmanned aircraft, VTOL and ETSO applicants cite a document written for what they are building. CM-DASA-002 covers far more, including CS-25 large aeroplanes, and it names ED-79B as the standard EASA currently recognizes as an acceptable means of compliance (AMC). EASA also states that certification memoranda are issued for information and are not themselves formally adopted AMC or guidance material. A CS-25 applicant can point to that stated position, and a program already in progress should still treat transition as a question for early authority coordination.

How to Comply With ARP4754B

Compliance under the B revision is decided in the plan set, before any development assurance activity produces evidence. Two of the changes land in planning documents, and a third changes how development assurance levels get justified across two standards.

Define the Plan Set With the Authority First

The plan set is what the authority agrees to before development assurance work starts, covering certification, the safety program, development, validation, verification, configuration management, and process assurance. Plan content matters more than the number of documents the plan set is split across, though separate planning documents tend to be easier to reuse. Two obligations belong in the initial plans:

• Authority coordination: ARP4754B addresses this inside the development planning process, so the plan set has to name who owns the coordination and which compliance methods it covers.

• Unintended behavior mitigation: Plans have to treat identification and mitigation of unintended behavior as an auditable artifact, with the testing level and testing types named.

Capturing both in the initial plans tells a reviewer where the program’s decisions were made, so the review can start at the plan with nothing to reconstruct.

Assign FDAL and IDAL Across Two Documents

The safety team assigns the FDAL at the function level based on the most severe failure condition the Functional Hazard Assessment (FHA) identifies. Each hardware or software item implementing that function then receives an IDAL, which sets the DO-178C or DO-254 objectives that apply downstream. Table A-1 of ARP4754B lists those objectives by level.

Some combinations of high assignments call for development and verification to be carried out independently of each other. Where a program proposes reducing a development assurance level (DAL) because members of a functional failure set are independent, the safety analysis has to substantiate that independence, and ARP4761A now carries the detailed method. Substantiating that independence across two standards makes the two-document dependency more than a filing question.

The B revision “refines the application of DALs throughout the system lifecycle,” as Cary Bryczek, Director of Solutions Architecture for Aerospace and Defense at Jama Software®, put it. Reassessment follows a change that alters the architecture, the requirements, or the safety assumptions an assignment rested on.

Trace Consistency Is What Review Evidence Has to Show

Review evidence has to show one consistent decision across every artifact in the development assurance chain, and ARP4754B expects distinct validation and verification evidence inside it. Validation confirms the requirements are correct and verification confirms the implementation meets them. Validation evidence includes matrices and summaries, while verification relies on procedures, results, matrices, and problem reports. A review that cannot tell the two apart will be asked for records that were never separated.

The chain runs from aircraft-level functions through system requirements, item allocation, design, and verification evidence. Consistency is hardest to demonstrate when those artifacts live in disconnected documents, and the junction where system requirements become software requirements is where it comes apart first.

Traces held in spreadsheets and siloed tools can stay invisible until an auditor samples them, and rebuilding one under review pressure pulls engineers off scheduled work. Allocation drift is harder to catch, because item-level changes never make it back into the FHA or the Preliminary System Safety Assessment (PSSA), and the safety-critical failure modes on record stop matching the aircraft the program is building. A spreadsheet matrix can look complete while hiding stale links and outdated baselines, and when an upstream requirement changes, nothing marks the downstream items as out of date.

How Jama Connect Supports ARP4754B Compliance

Jama Connect® for Airborne Systems comes pre-configured with element types matching the levels of requirements ARP4754B calls out, and with frameworks and templates aligned to ARP4761A, DO-178C, and DO-254. Aircraft functions, safety requirements, development items, and verification evidence then sit in one traceable chain inside a web-based requirements management and traceability platform. Teams working that way build validation matrices, verification summaries, and configuration baselines from live project data instead of assembling them before a review.

Change Impact Analysis is where that structure matters the most. When a requirement or design element changes, Jama Connect’s impact analysis identifies every downstream artifact affected, and its suspect link mechanism flags each of those linked items as suspect, so the next reviewer sees which parts of the chain are unexamined. Live Traceability™ makes that visible before System Safety Assessment (SSA) or Designated Engineering Representative (DER) review, while there is still time to act. A Change Category assignment has to rest on that assessment before an element can be classified as Unmodified and Unaffected rather than Modified.

Establishing the Certification Basis Before the First Authority Review

Because the authority documents recognizing ARP4754B differ in what each grants, a program now argues its certification basis with a specific document behind it. A UAS or VTOL applicant can name the means of compliance that already recognizes ED-79B and expect a short conversation. A CS-25 applicant has EASA guidance to point at and no adopted means of compliance behind it, so the case still gets made in the planning phase.

Whichever position a program is in, its evidence has to be current on the day it is asked for. For teams reconstructing trace evidence by hand ahead of each authority review, Jama Connect keeps that chain current as requirements and verification records change, and you can start a free 30-day trial to see how.

Frequently Asked Questions About ARP4754B

Does AIR4757 change what ARP4754B requires?

AIR4757 does not change what ARP4754B requires. Issued June 10, 2026, it is an SAE Aerospace Information Report (AIR) that clarifies areas of ARP4754B and ED-79B needing explanation in practice. Its contents are recommendations. They are not regulatory requirements, so a program’s agreed certification basis is unaffected. Where it affects an activity a program planned differently, the plan set should record the decision as it would any other change to an agreed baseline.

How do ARP4754B and ARP4761A work together?

ARP4754B supplies architecture definitions to ARP4761A, which runs the safety analyses and feeds DAL assignments and safety requirements back into development. The DAL assignments determine which DO-178C and DO-254 objectives apply at item level. Within the V-model, the FHA and PSSA work top-down on the left while the SSA verifies implemented designs bottom-up on the right, with Common Cause Analysis across both.

Do requirements management tools used on ARP4754B programs need qualification?

Qualification depends on intended use and what the program’s certification basis says, not on the tool category, and the authority makes the call. What a program relies on the tool to do without further checking determines the answer, which is why two programs can reach different conclusions. Settling that while selecting requirements management tools changes what evidence a program keeps, and Jama Connect qualification planning should document the approach the authority agreed.

This article was authored by Mario Maldari and published on September 3, 2026.