What is SafetyNet and How Does it Improve Android Security?

Google SafetyNet concept; Android logo on safety net

The Google SafetyNet API is a service for verifying the trustworthiness of the Android operating system on a given device mobile device. In this article we will look at the security it brings and how that will change as it is replaced by Google’s Play Integrity API.

SafetyNet Overview

The advantages and disadvantages of using SafetyNet are summarized below and a more in-depth analysis is available in one of our whitepapers here.


  • Verification of the file system: Identification of mobile devices where the software environment has deviated in any way from factory installation, e.g. where the device has been rooted.
  • Free service: There is a limit of 10K attestations per day, which might be a problem for high volume apps but in many cases the SafetyNet service will be helpful in the early stages of development/deployment.
  • Attestation of the running app: The ability to be certain a genuine app is using the SafetyNet service is certainly helpful from a security perspective although it should be noted that attestation of any apps running on rooted devices can’t be trusted. Some sectors consider that rooted phones, where no other security issues are found, are acceptable and for those businesses, SafetyNet may not be useful.


  • Backend integration: The server side is responsible for providing a nonce value to initiate the SafetyNet process and therefore, as highlighted in the Google documentation, it is therefore not possible to implement the verification in an API Gateway, WAF, CDN, etc., which might be an important limitation for some customers.
  • Service Performance: The SafetyNet service does not come with any level of Service Level Agreement (SLA) and there is evidence that the attestation process can take several seconds to complete. These facts mean that it is only practical to use SafetyNet attestation infrequently, impacting the effective level of security, and probably not with high volume apps.
  • Man-in-the-Middle: It should also be noted that there is no protection within the system from interception of the SafetyNet token though a Man-in-the-Middle (MitM) attack, something that may be material when doing a threat assessment of the mobile channel for those businesses that decide to allow rooted devices.

This is all interesting but Google announced in June 2022 that the SafetyNet service would be phased out between June 2023 and June 2024, to be replaced by Google’s Play Integrity API service. 

How Does Play Integrity Change The Picture?

Google Play Integrity is clearly an upgrade of the SafetyNet implementation and the primary purpose of it is to bring Google’s attestation capabilities into line with those of Apple, in the form of the Apple AppAttest system.

However, although there are some enhancements in Play Integrity (for example it supports a wider range of older OS versions compared to SafetyNet), most of the challenges outlined above are still present.

Securing Mobile Businesses

Protecting end-to-end mobile platforms requires a comprehensive layered approach, as detailed in our Mobile Threats whitepaper. The mobile app, device and API all need to be secured and each layer needs to work together. Further, it is important that granular and flexible security policies can be applied and updated over time so that the protection can be tuned to the needs of the business and adjusted based on the activities of bad actors.

Remote attestation is an important component of securing a mobile business – it is significant and both Google and Apple now have services in this area – but it is not an answer on its own. A holistic view, based on an ongoing assessment of the current mobile and API threat landscape, is needed.


If you are considering how to improve the security of your Android platform then Google’s SafetyNet API, now being replaced by Play Integrity, should definitely be in your thoughts. However, you should equip yourself with the necessary information to make the correct decision about if, how and where to use these capabilities. 

Specifically, we would suggest that you answer the following questions during your internal discussions:

  • Do you need to allow rooted phones to use your services because a sufficiently large percentage of your genuine users are running on rooted phones? 
  • Do you want consistent security interfaces for your Android and iOS platforms?
  • Do you develop your mobile apps using cross platform development environment such as ReactNative, Xamarin or Cordova where SafetyNet/Play Integrity plugins may not be available?
  • Does your security posture require assurance that only genuine instances of your mobile app are using your APIs on a per API request basis?
  • Do you need to be certain that your APIs are not being read or manipulated by a Man-in-the-Middle?

We have a lot of knowledge and experience in this space and we would be delighted to help you navigate your way to the most effective set of security layers for your use case. Check out our SafetyNet whitepaper and/or contact us today and speak to one of our security experts so we can help:

*** This is a Security Bloggers Network syndicated blog from Approov Blog authored by David Stewart. Read the original post at: