Lilium Post-Restructuring: What the Systems Engineering Record Actually Shows

When Lilium GmbH filed for insolvency in November 2023, the immediate narrative focused on funding. The company had burned through more than €1 billion, failed to secure a last-round bridge, and the German and Bavarian governments declined to step in. That version of events is accurate as far as it goes. But it stops well short of the engineering record.

The restructured entity—Lilium GmbH reconstituted under new ownership after acquisition out of insolvency proceedings—is now continuing development of the Lilium Jet, the same 7-seat, all-electric jet-propelled eVTOL configuration that defined the original program. The aircraft uses a distributed array of electric ducted fans embedded in the wings and canards rather than conventional rotors. That distinction is not cosmetic. It defines the entire systems engineering and certification challenge, and it is the reason the program’s difficulties deserve a more technical reading than the funding narrative provides.

The Architecture That Created the Problem

The Lilium Jet uses 36 electric ducted fan engines arranged across the lifting surfaces. Each engine is independently powered and controlled. In forward flight, the aircraft generates lift conventionally, through wing aerodynamics. In transition and hover, thrust vectoring through the fan array substitutes for conventional rotor lift. There are no mechanical linkages between propulsion units in the conventional sense. The aircraft is, at its control core, a software-dependent fly-by-wire system in which propulsion and flight control are unified into a single functional chain.

This is not an incremental variant of a known configuration. It is a genuinely novel architecture, and that novelty has specific consequences under the certification frameworks that govern it.

ARP4754A, the SAE standard that defines processes for development of civil aircraft and systems, establishes how to assign Development Assurance Levels to aircraft functions based on their failure condition severity. For a conventional aircraft, the mapping from function to DAL is relatively well-trodden—regulatory precedent exists, and applicants and authorities share a common vocabulary about what DAL A means for a flight control computer on a transport-category airplane.

For the Lilium configuration, that precedent does not exist in the same way. When any single ducted fan fails, the flight control system must compensate in real time. When multiple fans fail in correlated patterns—through a common-cause electrical fault, a software defect propagating across motor controllers with shared heritage, or a thermal event in the battery system—the failure space expands rapidly. The functional hazard assessment for this architecture is not a linear exercise. It is a combinatorial one, and the number of failure combinations that must be analyzed at DAL A or DAL B grows with the number of independent propulsion nodes in a way that conventional FHA tooling and conventional program timelines do not accommodate easily.

Lilium’s engineering team understood this. Statements from technical leadership in the period before the insolvency acknowledged the verification scope. What was underestimated—or at minimum, underrepresented to investors and in program scheduling—was how long that verification scope would take to close at the pace the company needed.

ARP4754A at Scale: Where the Process Stress Concentrated

ARP4754A does not certify aircraft. It defines the processes an organization must follow to demonstrate that its systems development was conducted with appropriate rigor. The European Union Aviation Safety Agency, which was Lilium’s primary regulatory authority, was conducting a type certification program against CS-23 amendment 5 (the EASA equivalent of FAR Part 23) with special conditions layered on top to address the novel configuration.

The special conditions process matters here. When an aircraft type does not fit existing certification specifications cleanly, the authority issues special conditions to address the novel features. For Lilium, EASA was developing those conditions concurrently with the applicant’s development work. That concurrency is not unique to Lilium—Joby, Archer, and Wisk have all operated in similar regulatory environments—but it means that requirements were not fully stable at the points in the program when stability would have mattered most for downstream design and verification planning.

Under ARP4754A, the development process flows from aircraft-level functional requirements through system-level requirements to item-level requirements, with verification activities traced back up through that hierarchy. When the top of that hierarchy is unstable—because special conditions are still being negotiated—the traceability chain beneath it is provisional. Engineering teams build toward a target that is still moving, and when the target moves, rework cascades downward through the requirements hierarchy.

This is a well-understood risk in novel-category aircraft programs. Managing it requires active requirements change management infrastructure: tooling that can propagate impact assessments when a special condition changes, verification matrices that flag which downstream activities are affected, and program management that treats requirements volatility as a first-class schedule risk. The evidence available from Lilium’s first program suggests this infrastructure was not as mature as the verification scope demanded.

DO-178C and the Motor Controller Stack

DO-178C is the software standard that governs airborne software development. Its applicability to a distributed propulsion aircraft like the Lilium Jet is not simple. Each motor controller contains software. That software is executing in a flight-critical function—if the motor controller fails open or fails to respond to a commanded change in thrust, the flight control system must detect and compensate. The software criticality level (DAL A or B for flight-critical functions) determines the rigor of the entire software development and verification process for each controller.

Thirty-six motor controllers, each requiring DO-178C compliance at high DAL, with independent verification artifacts for each, represents a verification workload that is not analogous to certifying a single flight control computer. Even if the controllers share a common software baseline—which is the rational architectural choice and was reportedly Lilium’s approach—the certification argument for a shared baseline applied across 36 instances still requires a tool qualification argument, a configuration management record for each instance, and a verification activity that closes the argument for the deployed configuration.

This is tractable. Programs do it. But it is slow and expensive, and it requires the software development process to have been conducted in a way that generates the right artifacts from the beginning. Retrofitting DO-178C process evidence onto software that was developed without full process compliance is substantially more expensive than doing it correctly in the first iteration. There are public indications that some of Lilium’s software development work required rework against DO-178C criteria, though the full scope of that rework has not been disclosed.

What the Industry Took From This

The eVTOL sector has been watching Lilium closely since well before the insolvency, and the technical community has drawn reasonably consistent conclusions. Three lessons appear most frequently in engineering discussions.

Certification strategy is a systems engineering decision. The framing of certification as a regulatory affairs function—something that happens to an aircraft after it is designed—is incompatible with novel-category development. For Lilium, the decision to pursue a jet-propulsion configuration rather than a rotor-based one was an engineering decision that had direct consequences for the regulatory path, the special conditions scope, the FHA complexity, and the DO-178C workload. Those consequences needed to be priced into the program at inception, not discovered during execution. The companies in the eVTOL space that are making the most visible certification progress have embedded certification engineers in their systems engineering teams from program start, not as a downstream handoff.

Requirements traceability is load-bearing infrastructure, not documentation. When special conditions change, the impact has to propagate through a requirements hierarchy in a way that is visible to engineering leadership in time to make decisions. Manual traceability in spreadsheets or loosely linked documents does not do this reliably at the scale of a novel aircraft program. The companies that have built mature traceability infrastructure—bidirectional, queryable, and connected to verification status—are managing regulatory volatility substantially better than those that have not.

Novel configuration complexity compounds with scale. Lilium’s 36-engine configuration was not just novel. It was novel at a scale that multiplied the verification surface. A competitor choosing a simpler configuration with fewer propulsion nodes may accept aerodynamic or performance tradeoffs, but they are buying down certification complexity in a trade that may turn out to be favorable when measured against total program cost and schedule. The eVTOL programs that have reached piloted flight test with the most credible certification timelines have generally chosen configurations that minimize the number of novel elements that must be simultaneously justified.

What the Restructured Program Must Address

The reconstituted Lilium has inherited the same aircraft configuration and, to varying degrees, some of the same engineering team. The fundamental architecture decisions are not being revisited—the Lilium Jet is still the Lilium Jet. That means the restructured program inherits the same verification scope, the same special conditions negotiation with EASA, and the same DO-178C workload that the original program was carrying when it collapsed.

The differences are capital constraints, compressed timeline expectations from new investors, and a regulatory environment at EASA that has been sharpened by several years of novel eVTOL certification experience. EASA is more precise about what it expects from novel configurations now than it was in 2019. That is good for long-term safety outcomes and bad for programs that were hoping ambiguity would allow schedule shortcuts.

For the restructured program to succeed where the original did not, several things must be true simultaneously. The requirements baseline must be stable enough—or the change management infrastructure mature enough—that requirements volatility no longer drives rework at the rate it apparently did in the first program. The DO-178C argument for the motor controller software stack must be closed, not approximated. And the FHA must cover the failure space of the distributed propulsion architecture in a way that EASA accepts as complete, not as a work in progress.

None of these are impossible. They are, however, expensive and slow. The restructured program’s credibility with investors will depend in part on whether its engineering and program leadership can demonstrate that the certification infrastructure supporting those activities is fundamentally different from what existed before—not just better funded, but better organized and better tooled.

Honest Assessment

Lilium built a genuinely ambitious aircraft. The jet-propulsion configuration, if it can be certified and manufactured, offers characteristics—low noise signature, aerodynamic efficiency in cruise, mechanical simplicity relative to rotor-based designs—that are technically real. The engineering team attracted to the program was not naive about the challenge.

What the first program appears to have underestimated was the interaction between architectural novelty, regulatory novelty, and the requirements and verification infrastructure needed to manage both at speed. The cost of that underestimation was not primarily financial in the first instance—it was schedule. Schedule became financial when the bridge round failed.

The eVTOL industry as a whole is a better place for having watched this play out in detail. The lesson is not that ambitious configurations are wrong. It is that the cost of systems engineering infrastructure is not separable from the cost of the aircraft. Programs that treat it as separable—as overhead that can be deferred or minimized to hit near-term milestones—eventually encounter it as a terminal constraint instead of a manageable one.

The restructured Lilium has the opportunity to demonstrate that the same aircraft can be developed with the infrastructure the first program lacked. Whether it has the capital and the time to do so remains the open question.