Mobile App Vetting for Aviation: Securing the Apps Crews Actually Use

TL;DR

Approving a third-party app for operational use is effectively extending trust to that vendor's security practices, and aviation runs on a specific, recurring set of them: Electronic Flight Bag (EFB) and charting apps, crew scheduling tools, ground-ops apps, and Maintenance, Repair, and Overhaul (MRO)/maintenance sign-off software, each with its own permission footprint and update cadence. One-time approval assumes that footprint is static. It isn't. Permission scope creep and app updates that change data flows can shift an approved app's risk profile without triggering a second review, and that's a separate problem from crew or ground staff installing unsanctioned AI tools on their own, outside any approval process at all. Continuous app risk monitoring, through iVerify's NowSecure integration, has to account for both and treats app approval as an ongoing assessment instead of a single checkpoint.

Every App on a Crew Device Is a Vendor Relationship

Approving a third-party app for operational use isn't a one-time technical decision, but an ongoing trust relationship with whoever built and maintains that app. The airline is extending access to operational data, and sometimes crew identity information, to a vendor whose security practices the airline doesn't directly control. That relationship deserves the same ongoing scrutiny as any other vendor relationship, not a single review at approval and then silence.

Most aviation IT teams already apply that ongoing-scrutiny standard to other vendor relationships: a cloud provider gets periodic security reviews, a payment processor gets recertified against compliance requirements on a schedule. However, line-of-business mobile apps rarely get the same treatment, largely because most organizations built their review process around a one-time approval workflow rather than a recurring one. The apps themselves haven't stayed static since that gap opened up. The review process just hasn't caught up to that reality yet.

The Apps Aviation Actually Runs

EFB/charting apps, crew scheduling, ground ops, MRO/maintenance apps

Aviation IT teams are managing a fairly consistent set of app categories across the fleet: EFB and charting software, crew scheduling and communications tools, ground-ops apps for baggage and load control, and MRO or maintenance sign-off apps. Each category serves a distinct operational function, and each is built and maintained by a different vendor with a different security posture.

Original Equipment Manufacturer and third-party vendor apps with broad device permissions

Layered on top of that core set are OEM-provided and other third-party vendor apps, often carrying broad device permissions: camera and scanner access, location, network connectivity, sometimes deep integration with backend operational systems. Broad permissions aren't inherently a problem; most of these apps genuinely need that access to function. The problem is what happens after approval, which is usually nothing, until something goes wrong.

Why One-Time Approval Isn't Enough

Permission creep and app updates that change data flows after initial review

An app approved at version 1.0 with a defined, reviewed set of permissions doesn't stay at version 1.0. Updates roll out, new features get added, new third-party SDKs get integrated for analytics or crash reporting, and the app's actual data flows can shift substantially from what was originally reviewed. The drift is often subtle rather than dramatic: a location permission requested as "while using the app" at initial review quietly expands to "always" in a later update to support a new feature, or a new analytics SDK starts relaying device and usage data to a third-party server nobody evaluated, because the update shipped through the app store's routine channel rather than anything that would prompt a fresh security review. Most aviation IT teams have no systematic process for catching that drift, because the review that happened at initial approval was never designed to repeat.

Rapid AI-feature adoption inside existing apps, changing their risk profile without a new approval cycle

A newer version of this same problem is showing up as vendors add AI-powered features into apps that were already approved months or years ago: predictive scheduling suggestions, automated chart annotations, AI-assisted maintenance logging. NowSecure's own research has flagged this exact pattern industry-wide: AI capability is showing up inside mobile apps faster than most security programs are set up to track it. An app that added an AI feature last quarter may now be sending data to a new third-party model provider that nobody at the airline approved, reviewed, or even knows about, because the change arrived through a routine app update rather than a new procurement cycle.

Unsanctioned AI tools on crew and ground-staff devices

This is a related but distinct risk, worth keeping separate from the feature-creep problem above: apps that were never part of any approval process to begin with. Rather than a vetted app quietly changing, this is a crew member or ground-ops staffer independently downloading an AI note-taking, translation, or scheduling-assistant app onto a device that also carries operational access, with no review of any kind. 

Broader research on this pattern, often labeled "shadow AI," puts real numbers behind how common it is: roughly eight in ten employees report using AI tools their organization hasn't approved, and one analysis found that 89% of enterprise AI usage is effectively invisible to security teams, going undetected for a median of 403 days. That data comes from vendor telemetry across email, browser, and SaaS activity generally, not an aviation-specific study, so it should be read as evidence of a widespread workplace pattern rather than an aviation statistic. But the underlying behavior isn't industry-specific either: an employee's ability to quietly install an unapproved AI tool doesn't stop at the gate or the cockpit door. Where the feature-creep problem is about revisiting apps you already approved, this one is about accounting for apps that were never in that pipeline at all, which means the monitoring approach has to cover both.

What Continuous App Risk Monitoring Looks Like

This is the specific gap continuous app risk monitoring is built to close, and it has to cover both versions of the problem above. Through the NowSecure integration, iVerify provides automated app risk scoring across the fleet, which in practice means static and dynamic analysis of what an app actually does, not just what it asks for: whether data is stored or transmitted securely, whether the app validates certificates properly rather than trusting anything presented to it, what third-party SDKs are embedded and what they do with the data they receive, and whether the permissions an app requests match the behavior it actually exhibits once running. That analysis runs on an ongoing basis against apps that are already approved and in use, and extends to visibility into AI feature adoption inside those apps as it happens rather than whenever someone happens to notice. It also gives security teams visibility into the broader app landscape actually present on the fleet, including AI tools and other apps that were never part of a formal approval process, rather than limiting review to the apps IT already knows about. That risk data also maps against compliance frameworks relevant to aviation IT, including OWASP, GDPR, and HIPAA where clinical or passenger health data intersects with crew or ground operations. As a result, app approval becomes a continuous input into the security program, not a single gate checked once and forgotten.

Where This Connects to Supply Chain Risk

The apps discussed here don't exist in isolation from the vendors that build them. An EFB charting app, a maintenance sign-off tool, or an OEM-provided utility is also a supply chain relationship: the airline trusts that vendor's development practices, update process, and third-party dependencies, not just the specific permissions the app requests. Aviation IT teams already thinking about vendor risk more broadly will find app risk monitoring a concrete, ongoing way to gain visibility into that relationship, rather than treating supply chain risk as separate from the apps actually running on the fleet.

A Starting Checklist for Aviation IT Teams

A few questions worth working through for any team that hasn't formalized ongoing app review: 

• Which apps were approved more than a year ago, and have their permissions or data flows been reviewed since? 

• Do any currently-approved apps use third-party AI features, and if so, is anyone tracking what data those features touch? 

• Separately, is there any visibility at all into unsanctioned AI or other apps crew and ground staff may have installed on their own, outside the approval process entirely? 

• Is app-store review (Apple's or Google's baseline vetting) currently being treated as sufficient ongoing assurance, and if so, is that assumption actually being tested, or just assumed? 

None of these require a full program overhaul to start answering, just an honest look at whether "approved" still means what it meant when the approval happened.

Related reading: Post-Trip Device Hygiene: What to do when crew return from high-risk regions