MEVOCOPTER
AEROSPACEAviation
cybersecurity

Service · For aircraft and system developers

Security in design for eVTOL and UAS

Authorities now expect the security of an aircraft's systems to be shown, not assumed, and the airworthiness-security process in DO-326A/ED-202A is how they expect it shown. For an eVTOL or a UAS the exposed surface is unusual: a command-and-control link, GNSS as the primary navigation source, ground stations, and software that updates over the air. This engagement builds the security case for those systems early, when changing a requirement costs an afternoon rather than a redesign.

Delivered by Eugene PikFixed scope, fixed quote after a 45-minute call

Is this for you?

  • You are developing an eVTOL, a UAS or an avionics system under a type certificate, a design approval or an operational authorization, and your certification plan mentions security or your authority has raised it.
  • Your architecture is settled enough to draw, but not so settled that requirements cannot change.
  • Your engineers are excellent at flight systems and honest that security is not their specialty.
  • You would rather show an authority a threat model and a requirements set than promise one later.

What you get

  • Security scope and assumptions. What is in and out of the security perimeter, which assets matter to safety, and what is assumed about the operating environment, agreed with your certification lead.
  • Threat model. Threat conditions, attack paths and effects for the C2 link, GNSS and navigation, ground control, data links, maintenance interfaces and software updates, with the safety effect of each traced to your functional hazard assessment.
  • Security risk assessment. Structured in the vocabulary of DO-326A/ED-202A and DO-356A/ED-203A, so it drops into a Plan for Security Aspects of Certification and can be reviewed by an authority without translation.
  • Security requirements. A numbered requirements set with rationale and verification approach, ready for your requirements tool and your traceability.
  • Review notes. Comments on the architecture and on your design documents, and a short list of what to prepare before the first authority meeting.

How it runs

  • Week 1Scoping workshopHalf a day with your certification lead and system architect: what is being certified, under which authority, what security the plan already assumes.
  • Weeks 2–3Architecture and interfacesI work through your diagrams, interface control documents and update mechanisms, and ask the questions an authority's security specialist will ask.
  • Weeks 3–5Threat model and risk assessmentTwo or three workshops of two hours with your engineers; I write between them.
  • Weeks 6–8Requirements and reviewThe requirements set, review notes and a closing session. Timelines vary with the size of the system; the fixed quote states yours.

What I need from you

Architecture diagrams, interface descriptions for the links and ground segment, your certification plan or its draft, and two to four hours a week of your system architect and certification lead during the workshops. Everything is handled under a non-disclosure agreement.

Questions I get asked

Is DO-326A actually required for us?

It depends on the authority and the product. EASA applies ED-202A through AMC 20-42; the FAA uses special conditions and issue papers that reference DO-326A; Transport Canada aligns with both. For UAS the picture is still forming and depends on the operational category. The scoping workshop settles what applies to you, in writing.

Do you do penetration testing?

No. I design and assess; when the security case calls for testing, I write the test scope and work with a test lab you or I select. Keeping design and testing separate is what an authority expects to see.

Can you work inside our requirements and certification tools?

Yes. The requirements are delivered in a form that imports into DOORS, Jama, Polarion or a spreadsheet, whichever you use, with the traceability fields your process needs.

What about the ground control station and the cloud?

They are in scope. For a UAS or an eVTOL the ground segment and the fleet management back end are usually where the real exposure sits, and the threat model treats them as part of the aircraft system.

Start with a 45-minute readiness call

Tell me what you build or operate. You leave the call with your three most important next steps, whether or not we work together; if this engagement fits, a fixed-scope proposal and quote follow within a few days.

Discuss your program
Eugene Pik

Eugene Pik

Founder of Mevocopter Aerospace. M.Sc. in Aviation and Aerospace Sustainability with a specialization in Aviation Cybersecurity from Embry-Riddle; Ph.D. researcher in Data Science at the University of Essex; earlier career in computer support and network security. Full biography · Publications