Why eVTOL Certification Is Taking Longer Than Anticipated
When Joby Aviation, Archer, Lilium, Wisk, and Volocopter filed their initial certification plans, the optimistic projections read like product roadmaps: entry into service by 2024, commercial operations by 2025. It is now mid-2026, and not one passenger-carrying eVTOL has received full FAA type certification. Some programs have been cancelled. Others have burned through capital reserves on regulatory rework. A few are genuinely close — but “genuinely close” in this context means 12 to 24 more months.
This is not a story about one company’s engineering failure. It is a story about an entire industry underestimating what certification actually demands, and a regulatory apparatus doing something it has never fully done before: writing the rules for a new category of aircraft in real time, while simultaneously evaluating applications against those rules.
Understanding why timelines have slipped requires examining four distinct problem domains: the complexity of FAA Special Conditions, the absence of airworthiness precedent for novel propulsion architectures, unresolved debates over software and hardware Design Assurance Level determination, and the organizational immaturity of first-time Part 21 applicants. These problems compound each other. Progress in one domain often surfaces new issues in another.
FAA Special Conditions: Negotiating Rules That Do Not Yet Exist
Part 23 of the Federal Aviation Regulations was revised in 2017 to adopt performance-based standards, which gave the FAA more flexibility to certify novel designs. But eVTOL aircraft are sufficiently novel that even the revised Part 23 framework does not map cleanly onto distributed electric propulsion, fly-by-wire flight controls with no mechanical reversion, and multi-rotor configurations with no autorotation capability in the traditional sense.
The FAA’s mechanism for handling this is Special Conditions: additional airworthiness requirements issued when existing regulations are inadequate. Special Conditions are not unusual — they have been issued for composite structures, advanced avionics, and unconventional configurations before. What is unusual is the volume and interdependency of Special Conditions required for a full eVTOL type certificate.
For a typical eVTOL applicant, Special Conditions must address: high-voltage electrical systems (battery packs, inverters, motor controllers operating at 400-800V DC), electromagnetic interference from multi-motor architectures, distributed propulsion failure mode analysis with no single mechanical analogue in the Part 23 rule set, and the airworthiness of software-defined flight control systems that have no mechanical backup.
Each Special Condition requires FAA engineers to draft proposed language, publish it for public comment, adjudicate responses, finalize the language, and then — critically — reach agreement with the applicant on how compliance will be demonstrated. That last step, the means of compliance, is where programs stall. When both parties are working from first principles, reaching agreement on an acceptable test methodology can take months. Multiply that by dozens of Special Conditions and the timeline implications become structural, not incidental.
The FAA has acknowledged the problem. Its MOSAIC rulemaking initiative and the formation of the Emerging Aviation Safety Team (EAST) both represent institutional responses to this bottleneck. But institutional responses operate on regulatory timescales, and companies are burning cash on operational timescales.
Novel Propulsion Architectures and the Absence of Precedent
Distributed electric propulsion — the use of six, eight, twelve, or more independently driven rotors or propellers — is the defining technical characteristic of most eVTOL configurations. It is also the characteristic for which airworthiness certification has the least established precedent.
Traditional failure analysis frameworks assume a small number of propulsion units. Loss of one engine on a twin-engine aircraft has a defined, extensively analyzed consequence set. Loss of one motor on a twelve-motor aircraft opens a combinatorial analysis space that existing Advisory Circulars do not address systematically.
This matters for two related reasons. First, demonstrating that a distributed propulsion system meets a defined safety objective — typically a probability of catastrophic failure below 1×10⁻⁹ per flight hour — requires a methodology that regulators and applicants agree is valid. When no methodology has been previously accepted, both sides must develop and validate one together. Second, the software-defined nature of most eVTOL flight management systems means that the boundary between “propulsion failure” and “flight control software failure” is architecturally blurred. A motor controller fault that triggers flight control law reconfiguration is both a propulsion event and a software event. Assigning responsibility for that failure mode to a single ARP4761 analysis domain is not straightforward.
Battery energy storage adds another layer. FAA certification of lithium-ion battery systems for propulsion — as opposed to auxiliary power — requires thermal runaway containment analysis, state-of-charge monitoring reliability assessment, and demonstrated behavior across the full operational envelope. None of this has a clean precedent in fixed-wing or rotorcraft certification history. The Boeing 787 battery incidents in 2013, though involving a different application, are the most relevant recent data point regulators reference — which illustrates how thin the precedent base actually is.
DAL Determination: Where Software Meets Regulation
DO-178C, the software certification standard most applicants are working to, requires that software be assigned a Design Assurance Level (DAL) from A through E based on the severity of the failure condition the software’s malfunction could cause. DAL A software — whose failure could contribute to a catastrophic condition — requires extensive, documented, independently verified development evidence. It is expensive and time-consuming to produce.
The debate in eVTOL programs is not about whether DO-178C applies. It is about which software components require DAL A treatment, and whether the failure independence architecture of a distributed system allows some functions that would be DAL A in a conventional aircraft to be argued down to DAL B or C.
This is a legitimate engineering argument, not a shortcut. A system with twelve independent motor channels, each with independent power electronics and independent flight control authority, has genuine architectural redundancy that a single-engine piston aircraft does not. If the failure of any one channel cannot propagate to other channels, and if loss of any one channel does not constitute a catastrophic failure condition, then the software governing that channel may not need to meet DAL A. The argument is architecturally coherent.
The problem is that regulators are not yet uniformly persuaded, and the evidence required to support such an argument is substantial. Demonstrating independence — true independence, not assumed independence — requires analysis of common-cause failure modes, common-mode software errors, shared power buses, shared data buses, and environmental stressors that could affect multiple channels simultaneously. Building that evidence base is itself a multi-year effort.
Multiple programs have reported that early DAL determination agreements with the FAA were revised as certification progressed and the independence arguments proved harder to fully substantiate than originally scoped. Each revision triggers rework in development documentation, test plans, and verification evidence packages.
Organizational Immaturity: The Part 21 First-Timer Problem
The most underreported driver of schedule slip is organizational. Most eVTOL OEMs are, at their core, technology startups that decided to certify an aircraft. That sentence contains a category error that took most of them several years to fully appreciate.
A startup optimizes for speed, iteration, and learning through prototypes. Part 21 certification optimizes for documented traceability, configuration control, and evidence completeness. These are not just different speeds — they are different organizational cultures, different hiring profiles, different toolchains, and different definitions of “done.”
The FAA has been explicit about this in program review feedback. Audit findings across multiple eVTOL programs have cited inadequate requirements traceability, insufficient configuration management discipline, and incomplete means of compliance documentation. These are not findings about engineering quality. An applicant can have excellent engineers and still fail a compliance audit because the documentation architecture does not meet the evidentiary standard the FAA requires.
The issue is structural. Requirements traceability in a Part 21 context means being able to demonstrate, for every certification requirement in the approved certification basis, an unbroken chain from that requirement to a design artifact, from that artifact to a test or analysis, and from that test or analysis to an approved result. When that chain has gaps — when requirements were written in a Word document that was never formally linked to the design, or when test results exist but cannot be traced back to a specific requirement — the FAA cannot accept the evidence package.
Many eVTOL programs built their early development on tools suited for agile software development: Jira, Confluence, GitHub Issues. These tools are excellent for their intended purpose. They are not designed to maintain the bidirectional traceability, formal baselining, and audit trail that Part 21 compliance requires. The cost of migrating from a startup toolchain to a compliant requirements management infrastructure mid-program — while preserving traceability continuity — has been one of the most painful and time-consuming corrections multiple programs have made.
How the Industry Is Responding
The response to these compounding challenges has followed two broad patterns: companies that treat regulatory engagement as an adversarial legal negotiation, and companies that treat it as a collaborative technical problem-solving process. The latter group is performing better.
The most effective programs have invested in dedicated certification engineering functions — not regulatory affairs staff, but engineers who understand both the technical system and the regulatory framework well enough to translate between them. They have stood up formal systems engineering organizations early, rather than retrofitting systems engineering onto a product that was already largely designed.
On requirements management specifically, the shift has been toward tools that treat requirements as graph-structured models with explicit dependency and traceability links, rather than as documents with manually maintained RTM spreadsheets appended. When a Special Condition changes — which happens throughout a certification program — a model-based requirements system can immediately surface every downstream artifact affected. A document-based system requires a human to remember to check.
Tools like Flow Engineering have entered this space with architectures built around exactly this model: requirements as interconnected nodes in a live system graph, with AI-assisted impact analysis when upstream requirements change. For programs dealing with hundreds of interdependent Special Conditions, derived requirements, and means of compliance documents, that kind of traceability infrastructure is not a convenience — it is what allows a small certification team to maintain compliance integrity across a system of the required complexity.
The companies showing the most progress have also fundamentally changed how they hire. The industry initially hired heavily from software and aerospace startups. The cohort now advancing through certification milestones has augmented those teams with engineers from legacy programs — people who have sat in FAA DER review meetings, who have written compliant verification cross-reference matrices, who understand the difference between a test that demonstrates engineering confidence and a test that generates approvable compliance evidence.
Honest Assessment
eVTOL certification will happen. The physics work, the technology is real, and the FAA is genuinely engaged — EAST, the updated AC for powered-lift, and the incremental type certificate grants already issued for some components all represent progress. The delays are not evidence that the category is technically unviable.
But the industry entered this process with a systematic underestimate of what first-principles regulatory negotiation demands, and an overestimate of how quickly organizational culture can shift from startup agility to certification discipline. The companies that acknowledged those gaps early and invested in closing them — in requirements management infrastructure, in certified systems engineering talent, in honest regulatory engagement — are the ones within sight of a certificate today.
The ones still revising their means of compliance documentation, still arguing about DAL determinations, still migrating requirements out of Confluence and into auditable systems — they have another two to four years of hard work ahead of them. Not because the FAA is unreasonable, but because they are now paying, with interest, for shortcuts that felt reasonable in 2020.
The lesson for the next wave of advanced air mobility applicants — and for the autonomy, urban air logistics, and hybrid-electric regional programs now filing LOIs — is to treat certification as a systems engineering problem from day one, not a documentation problem you solve at the end.