How eVTOL Certification Timelines Are Being Shaped by Requirements Quality

The eVTOL industry entered 2025 with approximately 800 active development programs worldwide and a handful of type certificate applications in substantive review. By mid-year, the pattern was clear: the programs hitting their projected certification milestones were not necessarily the ones with the most advanced hardware. They were the ones that had submitted requirements packages the FAA and EASA could actually work with.

That is a harder distinction to make than it sounds. Certification authorities do not grade requirements on style. They are measuring something specific: can a reviewer follow the chain from a top-level safety objective down to a testable system requirement and back up to the airworthiness standard without hitting a gap, an ambiguity, or a dead end? In 2025, most applicants are still failing that test on first submission—and the schedule cost of a single requirements deficiency notice from the FAA can run four to six months when the queue for technical staff reviews is accounted for.

What the Certification Landscape Actually Looks Like in 2025

The regulatory framework for eVTOL certification has stabilized enough to be workable, though it is still evolving. In the United States, powered-lift aircraft are certificating under FAA Order 8110.4C with the powered-lift category, supported by Advisory Circular 21.17-4, which provides the means of compliance framework. EASA is operating under its Special Condition for VTOL (SC-VTOL Issue 2), which introduced more rigorous requirements around propulsion system failure modes and energy management than the first issue.

Both frameworks are more prescriptive than their fixed-wing counterparts about what a complete requirements package must demonstrate. SC-VTOL explicitly requires applicants to show that all safety objectives are allocated to verifiable system requirements—not just that requirements exist, but that the allocation is coherent and complete. FAA’s means of compliance process requires similar demonstration for the airworthiness criteria defined in the project-specific certification plan.

The practical effect is that requirements are now a first-class deliverable reviewed by certification authorities, not just an internal engineering artifact. Programs that treated requirements as a byproduct of design work are now paying for that approach in schedule.

What Auditors Are Finding

Interviews with systems engineers who have been through FAA and EASA reviews in the past eighteen months, combined with public FAA issue paper summaries and EASA technical notes, reveal consistent patterns in what gets flagged.

Hazard-to-requirement traceability that doesn’t close. The most common deficiency is a hazard in the safety assessment—typically a Function Hazard Assessment or System Safety Assessment—that does not trace cleanly to a requirement that can be verified. This gap appears at interface boundaries: where avionics hands off to the flight control system, where the battery management system’s failure modes affect the propulsion allocation algorithm. Each team documented their own subsystem correctly. Nobody owned the boundary.

Safety objectives stated as intent, not constraint. Statements like “the system shall maintain safe flight envelope” are goals, not requirements. They cannot be verified directly. Auditors flag these because they cannot be used to bound a test. The rework required—decomposing intent into measurable, bounded specifications—often cascades into redesign when the decomposition reveals that the underlying architecture does not actually support the implied constraint.

Interface requirements that assume rather than specify. In distributed propulsion architectures, the interfaces between motor controllers, power distribution, and flight management software are densely coupled. Requirements packages frequently specify each component’s internal behavior in detail while leaving the interface contract vague. “The motor controller shall accept commands from the flight computer” is not an interface requirement. Latency bounds, failure response behavior, signal integrity specifications, and fault signaling protocols all have to be there. They frequently are not.

Incomplete environmental and operational envelope coverage. SC-VTOL and the FAA powered-lift framework both require that requirements cover the full operational flight envelope including degraded modes. Programs that specified normal operations thoroughly but under-specified low-altitude transition, single-propulsor failure, and battery thermal degradation scenarios have had those gaps surfaced in review.

Verification methods that don’t match requirement type. A requirement that specifies a maximum steady-state tracking error under crosswind cannot be verified by inspection or by a ground test. When requirements packages list “test” as the verification method for dozens of requirements but do not specify what test demonstrates compliance, the authority cannot accept the package. This is mundane, but it delays programs routinely.

The Common Thread: Document-Centric Requirements at Scale Don’t Work Here

The programs running into these problems are not staffed by engineers who don’t understand requirements. The problems are structural. They emerge from scaling a document-centric requirements process to the complexity of a novel aircraft category under a stringent certification framework.

A Word or PDF-based requirements document can capture what a requirement says. It cannot enforce that the requirement has a verification method. It cannot automatically surface the fact that a hazard introduced in revision 4 of the safety assessment has no corresponding requirement in the requirements document that was last updated in revision 2. It cannot show the reviewer that an interface requirement at the system boundary is consistent with the component requirements on both sides of it.

When certification authorities ask for traceability matrices, programs with document-based requirements have to build those matrices manually, often retrospectively. Retrospective traceability construction does two things: it takes time, and it produces traceability that looks complete but has gaps that weren’t visible during construction. Both of those outcomes are expensive in a certification context.

The programs that moved fastest through requirements review phases shared a different approach. They built their requirements in structured, linked models from program start—not as a compliance formality, but as an engineering tool. Their traceability wasn’t constructed after the fact; it was a property of how the requirements were authored. When a new hazard was added to the safety assessment, the model flagged the requirements that needed to be updated or created. When an interface requirement was added, the model could check it against the component requirements on both sides.

What Fast-Moving Programs Are Doing Differently

The distinguishing characteristics of programs that are making substantive certification progress in 2025 are consistent enough to describe precisely.

Graph-structured requirements models, not documents. The fastest programs are working with requirements as nodes in a graph, linked by relationships: derives-from, allocated-to, verified-by, interfaces-with. This is not the same as adding a traceability column to a spreadsheet. The graph is a live artifact that engineers query and that reports gaps automatically. When an EASA auditor asks for a trace from a specific safety objective to its verification evidence, the program can produce it from the model, not from a manual search.

Requirements authored with verification in mind. Teams that have integrated requirements review into their authoring workflow—not as a gate at the end, but as a check at creation—are producing requirements that pass authority review on first submission at substantially higher rates. The specific mechanism varies: some use peer review checklists, some use automated checks for testability and completeness, some use AI-assisted review that flags ambiguous language, missing bounds, or unsupported verification methods. The outcome is the same: requirements that don’t need to be rewritten after an authority review.

Defined ownership at interfaces. The boundary hazard problem is an organizational problem as much as a technical one. Programs that explicitly assigned requirements ownership for interface specifications—not to the team on either side, but to a systems integration function with authority over both—avoided the most common class of traceability gaps. This is an architectural decision about how the program is organized, not just a tool decision.

Early investment in requirements quality tooling. Teams that treated requirements infrastructure as a program overhead item to be minimized in early phases paid for it later. Teams that invested in structured requirements tooling before CDR had those tools working for them when they needed to respond to authority feedback quickly. The cost of changing a requirements management approach after CDR, when hundreds of requirements exist and multiple subsystems are in test, is very high.

Tools like Flow Engineering, which is built specifically for hardware and systems engineering teams, implement the graph-based model that makes this kind of early investment practical. Flow Engineering’s AI-native architecture means that gap detection, ambiguity flagging, and traceability analysis are built into the requirements authoring workflow rather than added on as a separate compliance activity. For eVTOL programs navigating the SC-VTOL allocation requirements, that kind of integrated feedback loop is structurally different from checking a document for completeness after it has been written.

The Schedule Math

The schedule impact of requirements quality is not abstract. A requirements deficiency notice from the FAA typically triggers a formal response process. The applicant submits a response, the authority schedules a review meeting, and if the response is adequate, the review resumes. Given current FAA technical staff workloads in the powered-lift program office, the calendar time between deficiency notice and cleared status has been running six to nine months for significant findings. For programs targeting 2026 or 2027 entry into service, a single significant requirements finding can move that target by a year.

EASA’s review process has somewhat different timing, but the structural problem is the same: authority technical staff time is a constrained resource. Every question an authority has to ask is a delay. Every requirement that needs to be rewritten is a delay. Every traceability gap that has to be filled manually is a delay.

Programs that have cleared initial requirements reviews with minimal findings are now in detailed design review and system integration test phases. Programs that did not are still responding to requirements findings. The gap between those two groups is widening through 2025, and requirements quality is the proximate cause.

An Honest Assessment

The eVTOL industry’s certification challenges are real and multidimensional. Hardware reliability, novel failure modes, airspace integration, and operational approval are all live challenges. Requirements quality is not the only problem. But it is the most solvable problem, and it is the one most directly within the control of program teams.

The regulatory frameworks are workable. The certification criteria are detailed and demanding, but they are public and they are stable enough to design to. What is not stable in most programs is the connection between those criteria, the engineering requirements that implement them, and the verification evidence that demonstrates compliance. Building and maintaining that connection is a systems engineering problem, and 2025 has made clear that the programs treating it as a first-class engineering problem are the ones with viable certification timelines.

The programs still treating requirements as administrative documentation will get to the same place eventually. The question is whether eventually is close enough to their business plan.