Regulatory Reference: SPA.EFB.100
Before we continue to discuss your duties as an Administrator, we must define what you are actually managing.
In the eyes of EASA, not all apps are created equal. The regulation, specifically SPA.EFB.100, divides EFB applications into two distinct categories: Type A and Type B. Understanding this difference is the foundation of your compliance system.
Type A applications are generally document viewers. Think of them as the digital replacement for the paper library. This includes your Operations Manuals (OM-A, OM-B), PDF viewers, or simple lookup tables. The defining characteristic of Type A is that a malfunction or misuse has a minor safety effect. Crucially, AMC2 SPA.EFB.100(b) notes that introducing or modifying a Type A application does not require prior approval from the Competent Authority. You, the operator, manage this internally.
Type B applications are the heavy lifters. These are applications where a failure could have a significant safety impact. This category includes Performance Applications those used for calculating Mass & Balance and Takeoff speeds and also Applications to view Navigation charts and Moving Maps. Because these apps actively calculate data or provide critical navigation information, SPA.EFB.100(a) states clearly: you shall only use a Type B application if you have been granted an approval by the Competent Authority.
You cannot just buy a performance tool and use it operationally tomorrow. You must provide a risk assessment, Human Machine Interface assessment, and training program to the Authority for approval.
As the Administrator, your workload differs for each. For Type A, you are the final authority. For Type B, you are the proposer, and the Authority is the approver. Throughout this course, when we speak of “Risk Assessments” and “Operational Evaluation Tests,” we are almost exclusively talking about Type B applications. Knowing the difference prevents you from over-regulating a PDF viewer or under-regulating a Performance Tool.