Guide · For everyone in an aviation organization

Aviation cybersecurity awareness training that works: role-based, short, measured

Aviation already knows how to train people for safety: short, recurrent, scenario-based, and taken seriously by the people at the top. Security awareness training fails when it forgets all four. This guide sets out the principles, the threats that differ by role, a design for sessions people remember, and how to know whether any of it worked.

Key takeaways

  • Annual click-through modules do not change behaviour. Fifteen minutes a quarter, built around what each role actually does, does.
  • Teach three ideas, not thirty: confidentiality, integrity and availability, each with an example from your own operation.
  • Pilots, technicians, engineers, dispatchers and managers face different attacks. Give each group its own two-page brief.
  • Measure the reporting rate, not just the click rate. A team that reports a suspicious email in minutes is safer than one that never clicks.
  • Borrow aviation's just culture. People who report their own mistakes quickly are the control; punishing them removes it.

Why most awareness training fails

The standard corporate model is a forty-minute online module once a year, generic content licensed from a vendor, a quiz with a pass mark, and a certificate. People complete it in the background while doing something else, and the organization records 100% compliance. Then someone in dispatch pays a fraudulent invoice, or a technician plugs a found USB stick into the maintenance laptop, and the post-incident review notes that training was "up to date".

Aviation has known for fifty years that this is not how people learn safety-critical behaviour. Crew resource management and human-factors training are short, frequent, scenario-based, specific to the job, and reinforced by a culture in which reporting your own error is expected. The same principles applied to security produce the same results. I taught network design and security in a classroom before I worked in aviation; the students who retained anything were the ones who had to apply it to a situation they recognized.

Three ideas everyone should own

Security professionals organize the field around three properties. They are worth teaching explicitly because they let people reason about new situations instead of memorizing rules.

PropertyThe question it asksAviation examples
ConfidentialityWho is allowed to see this?Aircraft design data and test results; passenger and crew personal data; the operator's contracts and pricing; the location of high-value aircraft.
IntegrityIs this true, and has it been changed?A maintenance record or release certificate; a performance calculation on the EFB; the GNSS position on the display; a NOTAM; a wire-transfer instruction in an email.
AvailabilityCan we use it when we need it?The maintenance-tracking system on a Monday morning; the dispatch and scheduling tools; the EFB content server; the company's email during an incident.

Notice that in aviation, integrity is usually the property with a safety consequence. That is a useful message in itself: security is not only about secrets; it is about whether the data the crew and the engineer act on is true.

Threats by role

The attacks that reach a pilot are not the ones that reach a maintenance technician, and neither faces what the finance manager faces. A single generic module cannot cover this. Each group needs a two-page brief with the three or four scenarios that apply to it.

RoleWhat they are most likely to faceThe behaviours to teach
PilotsPhishing about rosters, expenses and training records; hotel and FBO Wi-Fi; EFB app prompts and updates; GNSS anomalies in the cockpit that look like equipment faults.Company device only; update on cellular; report odd EFB behaviour; recognize and report suspected GNSS spoofing (see the GNSS guide); verify unusual requests by a second channel.
Maintenance techniciansUSB and data-loader media; diagnostic laptops used for email; vendor remote-access sessions left open; pressure to "fix" a record.Dedicated devices for aircraft and equipment; no unknown media; vendor access switched off after the job; records changed only through the process, with the audit trail intact; report anything that does not match.
Engineers and developersCredential theft aimed at code repositories and cloud consoles; social engineering for design data; malicious packages and dependencies; recruiters and "partners" fishing for technical detail.MFA and password manager without exception; least privilege on repositories; verify before sharing design data; treat unexpected technical questions from outsiders as a signal.
Dispatch and operationsBusiness email compromise: changed bank details, urgent fuel or handling invoices, fake supplier portals; unverified NOTAM or weather sources.Call back on a known number before changing any payment detail; use official sources; slow down when a message is urgent.
Managers and financeCEO fraud, MFA-fatigue prompts, invoice fraud, requests to bypass process "just this once".Two-person approval for payments and payee changes; deny unexpected MFA prompts and report them; model the behaviour you want from everyone else.

Designing training people remember

Short and recurrent

Fifteen minutes every quarter beats an hour once a year. Each session covers one scenario relevant to the group, with a discussion, not a quiz. Rotate topics through the year so that in twelve months each group has seen its four main scenarios once.

Built from your own incidents

The phishing email that actually reached your dispatch team last month is a better teaching case than any vendor's example. Anonymize it and use it. Near-misses reported by staff become next quarter's material, which also rewards reporting.

Delivered by someone credible to the audience

Pilots listen to a chief pilot, technicians to a quality manager, engineers to a lead engineer. Prepare the briefs centrally, deliver them through the people each group already trusts, and keep the security specialist in the room for questions.

Tied to a procedure

Every session ends with the exact thing to do: the address to forward a suspicious email to, the number to call about a lost device, the form for reporting a suspected GNSS event. Awareness without a procedure produces anxiety, not action.

Inside the safety culture, not beside it

Aviation's just culture, in which honest errors are reported and learned from, is the most valuable security control the industry has. Extend it explicitly: a technician who reports that they plugged in an unknown USB device ten minutes ago has given you the chance to contain an incident. Treat that report the way you treat a voluntary safety report. Put cyber hazards into the safety management system's reporting channel so that people use the path they already know.

Measuring it

Phishing simulations are the standard tool, and they are useful if you measure the right thing. The click rate tells you how convincing your test was. The reporting rate and the time to first report tell you whether the organization can catch a real attack. A team where three people report the email within five minutes is protected even if two others clicked, because the security contact can act before the damage spreads.

Run simulations quarterly, vary the difficulty, never name and shame, and publish the reporting rate to the whole company. Add two other measures: the number of voluntary security reports per quarter (you want it to go up), and the results of the tabletop exercise, which tests the people who have to act on the reports.

A year of training on one page

QuarterAll staff (15 min)Role briefs (15 min each)Measurement
Q1Confidentiality, integrity, availability with our own examples; how to report.Pilots: EFB and Wi-Fi. Technicians: media and devices. Engineers: accounts and repositories. Ops and finance: payment fraud.Baseline phishing simulation; reporting rate published.
Q2Last quarter's real incidents and near-misses, anonymized.Pilots: GNSS anomalies. Technicians: vendor remote access and records integrity. Engineers: supply chain and dependencies. Ops: verifying sources.Phishing simulation; voluntary reports counted.
Q3Ransomware: what it does to us and the manual-mode procedure.Group-specific parts of the incident plan.Tabletop exercise with the incident team.
Q4Lost devices, travel, personal accounts and home networks.Refresh of the scenario each group found hardest.Phishing simulation; year-on-year comparison; plan the next year.

Questions I get asked

How often should aviation staff get security training?

Fifteen minutes a quarter, built around what each role does, beats an annual click-through module. The aim is a habit of reporting, not a completion certificate.

What should everyone know?

Three ideas: confidentiality, integrity and availability, each illustrated with an example from your own operation, so that a technician understands why an altered record matters and a pilot understands why a wrong chart matters.

Should training differ by role?

Yes. Pilots, technicians, engineers, dispatchers and managers face different attacks, from EFB tampering and altered maintenance records to design-data theft and fraudulent payment instructions, and each group needs its own two-page brief.

How do we measure whether training worked?

Track the reporting rate and the time to report suspicious messages, not just the phishing click rate. A team that reports within minutes is safer than one that never clicks. Keep a just culture so that people report their own mistakes.

How I can help

My security training for aviation staff is role-based: sessions for pilots, technicians, engineers and office staff built from your own operation, plus phishing simulations with a before-and-after report. I write the briefs so that your own leads can deliver them afterwards.

Ask about training
Eugene Pik

Eugene Pik

Founder of Mevocopter Aerospace. Taught computer network design and security at a college in Israel before moving into aviation; M.Sc. in Aviation and Aerospace Sustainability with a specialization in Aviation Cybersecurity from Embry-Riddle. Publications · ORCID

References

  1. NIST SP 800-50 Rev. 1, Building a Cybersecurity and Privacy Learning Program.
  2. ICAO Annex 17, Security, on security awareness training; ICAO Annex 19, Safety Management, on safety reporting culture.
  3. Center for Internet Security. CIS Critical Security Controls v8.1, Control 14: Security Awareness and Skills Training.
  4. Pik, E. (2024). Airport security: the impact of AI on safety, efficiency, and the passenger experience. Journal of Transportation Security, 17, 9. DOI: 10.1007/s12198-024-00276-6