EASA SORA SAIL 3 and 4: Why UAS Manufacturers Must Design for Compliance from Day One
- Anne-Lise Scaillierez
- Jun 29
- 6 min read
EASA recently hosted a two‑day workshop on UAS design compliance for SAIL 3 and SAIL 4 operations in the Specific Category. The sessions were dense, practical, and revealing, especially for UAS designers and manufacturers who intend to operate their own aircraft or sell platforms to operators seeking SAIL 3 or SAIL 4 authorisations.
One of my main take-aways after those 2 days is extremely clear:
If a UAS is not designed from day one with SORA SAIL design requirements in mind, achieving SAIL 3 or SAIL 4 approval later becomes extremely difficult.
This reality may still be poorly understood across the industry. Below is a clear, structured breakdown of what SORA demands and why “SAIL‑by‑design” is now a strategic necessity on the commercial market.
Understanding SORA: Who Bears the Burden, Operator or Manufacturer?
Under the SORA methodology, it's technically the operator who applies for permission to fly. The risk profile of the mission they want to fly determines a number called the SAIL, the Safety Assurance and Integrity Level. Think of it as a dial that runs from "low risk, low assurance, low scrutiny" to "high risk, high assurance, heavy scrutiny," and the higher the dial goes, the more the operator has to prove.
To prove it, the operator has to satisfy a list of Operational Safety Objectives, or OSOs. These split cleanly into two families:
Operator OSOs — the human and organisational side of the house:
Organisational competence
Pilot training
Procedures
Maintenance
Operational mitigations
Design OSOs — the engineering side of the house:
UAS design quality
Reliability
Safety engineering
System integrity
Software assurance
At SAIL 1 and SAIL 2, almost all of that weight sits on the operator's shoulders. But climb to SAIL 3 or SAIL 4, where risk is higher and automation plays a bigger role, and a substantial portion of the burden shifts onto the organisation that built the aircraft. That shift is the crux of everything that follows.
Why SAIL 1–2 Are Easily Accessible from a UAS Manufacturer's Perspective
At SAIL 1–2, SORA assumes:
Max Loss of Control (LoC) rate for the operation: 10⁻² per flight hour (1 per 100 hours)
Assumed portion attributable to design, as opposed to human error in primarily remotely-piloted operations: 10%, giving a design LoC target of 10⁻³ per flight hour.
This is considered achievable with:
standard engineering
a single flight controller
no formal software assurance
no redundancy
As a result, operators can often self‑declare compliance using the UAS manual. This could create a false sense of security for manufacturers who assume their current design approach will scale to SAIL 3 or 4.
EASA SORA SAIL 3 and 4: a Completely Different World for UAS Manufacturers
Once you leave Low risk SAIL 1 and SAIL 2, EASA SORA SAIL 3 and 4 introduces stringent design‑related OSOs, starting with OSO #5, which simply states that the UAS must be "designed considering safety and reliability." Innocuous-sounding, but it's the OSO that possibly does the most damage to unprepared manufacturers.
OSO #5 Requirements by SAIL
SAIL | OSO #5 Requirement |
1–2 | Not required |
3 | Low robustness |
4 | Medium robustness |
SAIL 3 Design Requirements: “No Single Failure Leads to Loss of Control”
SAIL 3 does not prescribe a fixed list of redundant systems. Instead, it applies a risk‑based design assurance philosophy:
No single failure shall cause a catastrophic loss of control.
To demonstrate that, a number of Means of Compliance are acceptable:
Redundancy of safety‑critical components
Service history / fleet reliability data
Component qualification (industrial‑grade GNSS, mature power systems)
FHA, FMEA, FTA demonstrating failure tolerance
Fail‑safe behaviours (e.g., controlled landing on failure detection)
Architecture justification
EASA’s examples of UAS design at SAIL 3
EASA shared some examples of UAS design architectures that could meet SAIL3 OSO#5 low robustness assurance, and they demonstrated an architectural rigor substantially beyond the average SAIL 2 UAS on the market:
3 independent flight controllers, with at least one dissimilar
2 dissimilar GNSS receivers
Dual batteries
Independent power paths
Please note that OSO#5 does not explicitly demand that kind of redundancy in the design architecture.
However, for a platform with insufficient flight-hour history behind it, this kind of architectural rigor and design assurance is probably the path to SAIL 3.
The alternative is to first accumulate the required level of flying hours in SAIL 2. This approach also requires careful planning, to ensure that the data's validity will be accepted by the authorities.
SAIL 4 Design Requirements: Where DAL C Software Assurance Appears
At SAIL 4, the bar rises again. EASA’s examples for flight controller configurations include:
SAIL 4 Acceptable Configurations
1 FC/AP with:
10⁻⁶ FH⁻¹ reliability, and
DAL C software development
2 similar FC/APs with:
10⁻³ FH⁻¹ reliability each, and
DAL C software development
2 dissimilar FC/APs (no DAL) plus a Decider FC/AP:
each with 10⁻³ FH⁻¹ reliability,
Decider developed to DAL C
It was mentioned, informally, that EASA may be open to alternative assurance arguments if DAL C can't be fully achieved. What might be acceptable is unclear at this stage.
Managing Design Changes should be Part of your Design Strategy to Avoid Hidden Traps
Once you've achieved your SAIL 3 or SAIL 4 statement of compliance, that compliance isn't permanently locked in. Any change to a safety-critical function can invalidate it and trigger a fresh review.
Manufacturers should consider "smart design" and architecturally separate:
safety‑critical functions (flight control, power, navigation)
mission functions (payload, UI)
This allows mission‑related updates without jeopardising the validity of SAIL compliance.
The EASA Review Process and DVR Costs
SAIL 1–2
No UAS Designer Statement of Compliance
Operator can self‑declare
SAIL 3
Declarative Statement of Compliance by the UAS Designer
EASA DVR optional (mandatory only for M2 mitigations)
NAA of the country of the Drone Operator applying with that UAS is not responsible for the UAS SoC, but the NAA may request supporting information considering they are delivering a SAIL 3 operational authorisation with that drone.
SAIL 4
Evidenced Statement of Compliance by the UAS Designer
EASA DVR mandatory
EASA DVR Fees
SAIL 3 DVR: €62,460 (estimate)
SAIL 4 DVR: €166,560 (estimate)
The list of EASA DVR is not public, each drone designer can decide to make its DVR public or not. However, we can consider:
several DVRs for M2 mitigations and containment
only one full SAIL 3 Design DVR for Thales UAS 100
SAIL 3 is declarative to expedite approvals, but the UAS Designer’s core obligations remain exactly the same.
EASA has progressively shifted SAIL 3 oversight from centralised review to National Aviation Authorities (NAAs), and now toward manufacturer self‑declaration against the published Means of Compliance. This evolution is driven by limited regulatory resources and the slow market uptake of SAIL 3 operations.
While the process is significantly simplified, with no scrutiny from either an NAA or a third‑party assessor such as a Notified Body or an RAE(F), the responsibility does not diminish. The UAS Designer must still fully and effectively comply with all applicable requirements. In the event of an incident, the legal accountability for demonstrating genuine compliance with the UAS Design requirements as stated in the Statement of Compliance rests with the manufacturer.
Conclusion: in SAIL 3 and SAIL 4, SAIL‑by‑Design is a Strategic Imperative.
For European manufacturers in particular, there's an uncomfortable asymmetry at play: many can't point to the kind of extensive real-world flight-hour history that established commercial drone makers, particularly large Asian or US manufacturers, can use to argue their reliability is "proven by service."
Without that track record, the only road left into SAIL 3 and SAIL 4 territory is design assurance built in from the start.
That's the strategic reality behind "SAIL-by-design."
It doesn't have to mean over-engineering every single subsystem to the highest possible standard.
There's real skill in figuring out exactly where assurance needs to be concentrated, and where well-chosen, low-cost commercial-off-the-shelf components can keep the aircraft affordable.
But it does mean making that decision deliberately, at the start of a design process, rather than discovering the gap after the aircraft is already flying.
Manufacturers who internalise this now will be positioned to dominate the professional and BVLOS markets as they mature.
If you would like to explore SAIL 3 or SAIL 4 requirements and "Smart-SAIL-by-Design" for UAS manufacturers, contact us here. We always welcome a discussion.
Sources and further reading.
Primary references for the regulations and frameworks cited in this article. All documents below are public and freely accessible from the issuing authority. Anyone authoring a UAS submission should be working from the current published version of each.
EASA – Specific Category (Official Portal)
EASA – SORA AMC/GM (Acceptable Means of Compliance & Guidance Material)
JARUS – SORA (Original Methodology)
JARUS – SORA Package (All Documents)
EASA – Design Verification (DVR) Overview
EASA – Drone Design Verification for M2, Containment, SAIL 3/4
EASA – Means of Compliance (MoC) for SAIL III & IV
EASA – AMC/GM to Part‑UAS (Includes design expectations)
EASA – Acceptable Means of Compliance for Light UAS
Comments