The threat model for a mobile device ecosystem is complex. In addition to the obvious physical attacks on lost or stolen devices and malicious code threats, typical mobile devices integrate a significant amount of code from different organizations into their system images, which are in turn executed on an increasingly complex hardware infrastructure. Both benign mistakes, as well as malicious attacks, could happen on any of these layers, by any of these organizations. Therefore, users as well as app developers and service providers currently have to trust every single one of these organizations. Note that OEMs (original equipment manufacturers) in their role as integrators typically verify their supply chain and components they integrate. However, there are also other parties in the full chain that can tamper with devices after they leave an OEM and before they are in the hands of users. Summarizing, many people could—by honest mistake or malicious intent—tamper with components of a modern smartphone to compromise user security. We call such attacks insider attacks, independently of the motivation or association of these insiders. The basic threat is that insiders have privileged access to some components during the manufacturing or update chain that would allow them to make modifications that third parties could not. This talk will introduce the complexity of the insider attack problem (which is not unique to Android) and introduce some defenses that have already been put in place. In Android, we counter such insider attacks on multiple levels and aim to remove or limit the capability of insiders to harm users, which implies the limiting required trust in many of the involved parties. At the secure hardware level, Android Pie 9.0 introduced insider attack resistance (IAR) for updates to tamper-resistant hardware such as secure elements that is used to validate the user knowledge factor in authentication and for deriving, storing, and using cryptographic key material. Even Google and the respective OEM are technically incapable of distributing modified firmware to such tamper-resistant hardware to exfiltrate user keys without their cooperation. On the system software level, some devices make the hash of their currently running firmware available for (anonymous) local and remote verification. The combination of these features already provide transparency on the system software level and severely limit the possibility of targeted attacks on firmware and system software levels. We continue to work on this problem, and this talk is partially a call to action for the security community to devise additional novel methods to mitigate against insider attacks on components in the mobile device landscape.