How EFB Data Reaches the Cockpit: Charts, Updates & Connectivity

EFB SERIES · PART 4 OF 8 — Technology, Security & Safety · Series Hub · ← Part 3 · Part 5 → (publishes Sep 8)

TL;DR — How does EFB data reach the cockpit? Aeronautical data originates with states and weather centers (ICAO Annex 15 / AIXM), is processed by commercial vendors into ARINC 424-coded databases and chart plates, staged and distributed by the operator’s backend over gate Wi-Fi, cellular or manual docking, verified on the device, and activated on 28-day AIRAC effective dates. Every hop in that chain is a trust boundary — and the device’s ability to prove data authenticity is the integrity question this series keeps circling.

Part 3 ended with a loaded sentence: the platform layer beneath every app is a shared dependency, and compromising it poisons everything above. Today we follow the substance of that dependency — the data itself — on its journey from a surveyor’s desk to a glowing approach plate at 38,000 feet. This is the most infrastructure-flavored post of the series, and deliberately so: you cannot understand the EFB’s attack surface (Part 6) or its defenses (Part 7) without understanding its supply chain.

One cardinal sin frames everything: flying on stale data. The entire apparatus below — cycles, effective dates, staged rollouts, verification — exists to make that sin impossible to commit by accident. Part 6 asks the darker question: could someone make you commit it deliberately?

Where EFB Data Comes From: The Aeronautical Data Chain

EFB data is not “downloaded from the internet”; it descends a formal, regulated pipeline in which every transformation is a potential error — or tampering — entry point.

Table T4.1 — The data chain, stage by stage

Two format names deserve unpacking because the whole industry runs on them. ARINC 424 is the coded navigation-database interchange standard: records for airports, runways, navaids, waypoints, airways and procedures, each with fixed fields your moving map ultimately renders. AIXM 5.1 (Aeronautical Information Exchange Model) is the modern XML-based exchange format states increasingly use to publish source data — the aviation world’s slow migration from telex-era text formats to structured data, with Digital NOTAM and IWXXM (weather) riding the same philosophical shift.

The trust boundaries in the diagram — TB1 through TB4 — mark where data crosses organizational control. They are unremarkable to operations people (that’s just how data flows) and irresistible to security people. Both views are correct; they are the same pipeline seen from two sides, which is the entire premise of this series.

The AIRAC Cycle and Effective Dates

Aeronautical data changes globally on a fixed rhythm: the 28-day AIRAC cycle — effective on the date, regardless of when you received it.

AIRAC (Aeronautical Information Regulation And Control, ICAO Annex 15) chops the year into 28-day amendment cycles — typically 13 effective dates per year. Procedure changes align to cycle boundaries so that, in principle, every cockpit worldwide flips to the same data on the same morning. The operational phrase that matters is “effective, not received”: a dataset is valid from its effective date. Nobody cares that your tablet got the update at 23:40 the night before; at 00:01 UTC on the effective date, the old cycle is expired and the new one is current.

That rule creates two classic traps the whole distribution apparatus exists to manage:

• The cutover flight: depart on the old cycle, land on the new one. Near every effective date, the device must hold both cycles simultaneously — the current database for the flight you’re on, the next database for the flight you’re about to take. Good platforms treat the dual-cycle overlap window as a first-class feature; crews verify cycle status as part of preflight.
• The missed update: a device that failed to sync (dead battery, no connectivity, quota exhausted) carrying yesterday’s truth into today’s airspace. Revision-status screens and expiry alarms exist for exactly this failure — which is fine when the failure is accidental. When Part 6’s attackers spoof the metadata that drives those alarms, this comfort stops comforting.

Table T4.2 — 2026 AIRAC effective dates (all Thursdays, 28 days apart; data is published at least 42 days ahead of effectivity per EUROCONTROL)

Distribution and Upload Paths

Getting hundreds of megabytes into thousands of tablets is a fleet logistics problem solved by a hierarchy of links, from docking cabinets to satellites.

A full terminal-charts-plus-database package runs to hundreds of megabytes per cycle [verify current figures with vendor documentation], which shapes everything: satcom carries deltas, ground links carry the bulk, and manual docking survives as the fallback of last resort.

Table T4.3 — EFB connectivity options compared

Behind the links sits the operator backend: fleet-management and MDM infrastructure (Part 7’s Layer 1/4 territory) that stages rollouts — test devices first, then fleets in waves — pushes delta/differential updates rather than whole databases, compresses, manages per-device quotas, and retries interrupted syncs. The engineering is unglamorous and absolutely load-bearing: a botched staged rollout is, functionally, a fleet-wide availability attack you inflicted on yourself (Part 6’s closing section returns to this).

Version Control and Data Integrity in the Field

Every EFB fleet lives on two version axes at once — application version and data cycle — and they can desync.

The app-version axis is the familiar one: MDM-controlled application releases, tested before fleet deployment. The data-cycle axis is AIRAC’s 28-day drumbeat. The failure class that joins them is subtle: an application too old to parse a new data format. A vendor changes the database schema; the new cycle’s package arrives; last quarter’s app build chokes on it — or worse, renders it wrongly. Mature programs therefore lock the two axes together: approved app versions are validated against upcoming cycle formats before cutover, and the fleet’s version mix is a monitored metric.

On the device, version control shows up as the interface crews actually see: the revision-status screen. Cycle identification, effective window, coverage — verified as part of preflight, with expiry alarms doing quiet sentinel duty. It is worth pausing on what those screens assert versus what they prove. They assert: “this database is cycle 26xx, effective these dates, covering these regions.” They prove it from metadata stored alongside the data. Metadata that is, itself, data — a distinction with a body count in every other domain of information security, and the reason the next section exists.

The Integrity Question

How does an EFB know its chart data is authentic and unmodified? If that question sounds like a PKI question, it is.

Strip away the aviation framing and the pipeline above is a software-update channel, and the security industry solved (conceptually) how to harden update channels decades ago: sign the artifacts, pin the keys, verify before activation, never roll back silently. Mapped to the EFB:

• The chart vendor or operator backend cryptographically signs each data package (a detached signature or signed manifest over the archive).
• The device verifies the signature against pinned keys before activation — trusting only keys embedded in the approved application build, not whatever the network offers.
• Hash manifests (or hash trees over delta chunks) let the device confirm every piece it assembled locally matches what was signed.
• Anti-rollback logic prevents serving the fleet an old-but-validly-signed cycle as if it were current — old signatures stay valid, so version counters must be monotonic.

Now the honest part. Deployment maturity across the industry is uneven: signing practices, key management, and revocation strategy vary by vendor and operator, and aviation has one structural PKI wrinkle everyone else mostly avoids — the aircraft is an offline client. A tablet that verifies signatures against pinned keys is fine without connectivity; anything resembling live revocation (OCSP/CRL checks) struggles at 38,000 feet. Practical designs therefore favor long-lived pinned keys and make revocation rare by construction rather than reachable in flight — a trade-off with consequences Part 7 examines properly.

This post has now walked the full chain twice: once operationally (how updates flow) and once adversarially (where trust could break). That second walk is Part 6. Tomorrow we make it explicit — but first, Part 5 covers the rulebook that governs everything you just read: who allows this system to fly, and what they demand before signing off.

Key Takeaways

• EFB data descends a formal chain: state origination (AIXM/Annex 15) → ARINC 424 processing → operator backend → distribution → verified device activation.
• AIRAC is a 28-day global rhythm with ~13 effective dates per year; data is “effective, not received,” forcing dual-cycle storage near every cutover.
• Distribution is a logistics hierarchy: docks and gate/cellular links carry the bulk; satcom carries deltas; ACARS carries text.
• Two version axes — app version and data cycle — can desync; mature programs validate them jointly before rollout.
• The revision-status screen asserts metadata, not truth; its integrity depends on the signing chain beneath it.
• The integrity toolkit is classic secure-update engineering: signed packages, pinned keys, hash manifests, anti-rollback — deployed unevenly across the industry.
• The aircraft is an offline PKI client: designs favor pinned long-lived keys over reachable revocation.

FAQ

How often are EFB charts updated?
On the 28-day AIRAC cycle — roughly 13 effective dates per year — with urgent corrections issued between cycles when needed. Devices near a cutover must hold both current and next databases simultaneously.

What is the AIRAC cycle?
AIRAC (Aeronautical Information Regulation And Control) is ICAO’s system of fixed 28-day amendment dates. Procedure and chart changes worldwide align to these effective dates so all cockpits switch data on the same morning — “effective on the date, not when received.”

What happens if an EFB misses a chart update?
The device’s revision status shows an expired cycle and alarms flag it; flying on it is prohibited by operator policy. The deeper risk, covered in Part 6, is tampered metadata that makes stale data masquerade as current.

How do pilots update their EFBs?
Fleet-managed devices sync automatically over gate/ground Wi-Fi or cellular overnight; fallbacks include docking cabinets at bases and, in flight, satcom-borne deltas for weather and NOTAM text. Crews verify cycle status during preflight.

Is EFB data signed or encrypted?
Well-implemented pipelines cryptographically sign chart packages (detached signatures or manifests) and encrypt transport; devices verify against pinned keys before activation. Maturity varies across vendors and operators — Part 7’s checklist targets exactly this.

What is ARINC 424?
The interchange format for coded navigation databases: standardized records for airports, runways, navaids, waypoints, airways and procedures. Your moving map’s terrain beneath the symbols is, ultimately, ARINC 424 records rendered.

How big is an EFB chart database?
A full terminal-charts-plus-navigation-database package runs to hundreds of megabytes per cycle, which is why bulk distribution rides ground links and satcom carries only deltas.

References

1. ICAO, Annex 15 — Aeronautical Information Services (AIRAC framework)
2. ICAO, Doc 8126 — Aeronautical Information Services Manual
3. AEEC, ARINC 424 — Navigation System Database Standard
4. EUROCONTROL/ICAO, AIXM 5.1 — Aeronautical Information Exchange Model; IWXXM (weather XML)
5. FAA, Advisory Circular 120-76E (data/revision-control expectations within EFB evaluation)
6. AircraftIT, “EFB Data Security & Connectivity” (aircraftit.com/articles/efb-data-security-connectivity/)
7. EUROCONTROL, AIRAC dates (eurocontrol.int/publication/aeronautical-information-regulation-and-control-airac-dates); Jeppesen update-cycle & effective-dates schedule
8. IETF, RFC 5280 (X.509 PKI) — for the pinned-key verification framing

[← Part 3: EFB Software] · [Series Hub] · Part 5: EFB Regulations & Certification → (publishes Sep 8)

Parts publish daily through September 11 — bookmark the series hub for the full run.

Current as of September 2026 · standards verified against the latest revisions.
Educational reference only — always follow your operator’s approved EFB program and your NAA’s current guidance.
Author: hmmnm.com editorial team · hmmnm.com

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy