How to Protect Mobile Apps With Send IDAnchor on Compromise Using AI

This Knowledge Base article describes how to use Appdome’s AI in your CI/CD pipeline to continuously deliver plugins that Protect IDAnchor on Compromise in Mobile apps.

What is IDAnchor on Compromise?

Send IDAnchor on Compromise is an optional feature in Appdome’s IDAnchor™ suite that delivers the device’s IDAnchor value whenever a threat or attack is detected at runtime. This identity is a unique, tamper-resistant fingerprint created from deep, hard-to-alter attributes of the device and app environment.

Send IDAnchor on Compromise is designed for mobile apps that need to take immediate action when a security issue occurs. For example, if rooting, hooking frameworks, emulator use, or other forms of malicious activity are detected, the app will instantly receive the device’s IDAnchor value. This feature is especially useful in fraud response, session risk scoring, and account protection, where fast, data-driven decisions depend on having a verified device identity associated with the threat event.

How Appdome Protects Mobile Apps With Send IDAnchor on Compromise

Appdome’s dynamic Send IDAnchor on Compromise plugin automatically delivers the device’s IDAnchor value when a runtime threat or attack is detected. Developers can use this identity to assess risk, trigger custom defenses, and improve real-time fraud protection.

Below is a list of metadata that can be associated with each IDAnchor payload, true device attributes, and Advertising ID protections. Additionally, you can retrieve the IDAnchor Threat Events context keys for Android or iOS.

Common Event Keys

IDAnchor Context Keys

True Device Attributes Context Keys

Delivered when Trusted (True) Device Attributes is enabled.

Authentication Attributes Context Keys

Delivered when Trusted (True) Device Attributes is enabled. Learn more.

Advertising ID Protections Context Keys

Delivered when Protect Advertising IDs is enabled. Learn more.

Device Geo Attributes Context Keys

Delivered when Device Geo Attributes is enabled. Learn more.

Use the code snippets below to retrieve the desired context keys’ values.

Android:

IntentFilter intentFilter = new IntentFilter();
intentFilter.addAction("ImmutableDeviceID");

BroadcastReceiver threatEventReceiver = new BroadcastReceiver() {
    @Override
    public void onReceive(Context context, Intent intent) {
        Bundle extras = intent.getExtras();
        if (extras == null) return;

        String DeviceID = extras.getString("DeviceID");
        String DeviceIDDetections = extras.getString("DeviceIDDetections");
        String previousDeviceID = extras.getString("previousDeviceID");
        String installationID = extras.getString("installationID");
        String releaseID = extras.getString("releaseID");
        String teamFingerprint = extras.getString("teamFingerprint");
        String gsfID = extras.getString("gsfID");

        // True Device Attributes
        String trueDeviceManufacturer = extras.getString("trueDeviceManufacturer");
        String trustDeviceManufacturer = extras.getString("trustDeviceManufacturer");
        String trueDeviceModel = extras.getString("trueDeviceModel");
        String trustDeviceModel = extras.getString("trustDeviceModel");
        String trueOsVersion = extras.getString("trueOsVersion");
        String trustOsVersion = extras.getString("trustOsVersion");
        String trueSdkVersion = extras.getString("trueSdkVersion");
        String trustSdkVersion = extras.getString("trustSdkVersion");

        // Protect Advertising IDs
        String trustGAID = extras.getString("trustGAID");

        // Your logic goes here (Send data to Splunk/Dynatrace/Show Popup...)
    }
};

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
    registerReceiver(threatEventReceiver, intentFilter, Context.RECEIVER_NOT_EXPORTED);
} else {
    registerReceiver(threatEventReceiver, intentFilter);
}

iOS:

[[NSNotificationCenter defaultCenter] addObserverForName:@"ImmutableDeviceID" object:nil queue:nil usingBlock:^(NSNotification *org_note) {
    __block NSNotification *note = org_note;

    dispatch_async(dispatch_get_main_queue(), ^(void) {
        NSString *DeviceID = [[note userInfo] objectForKey:@"DeviceID"];
        NSString *DeviceIDDetections = [[note userInfo] objectForKey:@"DeviceIDDetections"];
        NSString *previousDeviceID = [[note userInfo] objectForKey:@"previousDeviceID"];
        NSString *installationID = [[note userInfo] objectForKey:@"installationID"];
        NSString *releaseID = [[note userInfo] objectForKey:@"releaseID"];
        NSString *teamFingerprint = [[note userInfo] objectForKey:@"teamFingerprint"];

        // True Device Attributes
        NSString *trueDeviceManufacturer = [[note userInfo] objectForKey:@"trueDeviceManufacturer"];
        NSString *trustDeviceManufacturer = [[note userInfo] objectForKey:@"trustDeviceManufacturer"];
        NSString *trueDeviceModel = [[note userInfo] objectForKey:@"trueDeviceModel"];
        NSString *trustDeviceModel = [[note userInfo] objectForKey:@"trustDeviceModel"];
        NSString *trueOsVersion = [[note userInfo] objectForKey:@"trueOsVersion"];
        NSString *trustOsVersion = [[note userInfo] objectForKey:@"trustOsVersion"];

        // Protect Advertising IDs
        NSString *trustIDFA = [[note userInfo] objectForKey:@"trustIDFA"];
        NSString *trustIDFV = [[note userInfo] objectForKey:@"trustIDFV"];

        // Your logic goes here (Send data to Splunk/Dynatrace/Show Popup...)
    });
}];

Prerequisites for Using Appdome's Send IDAnchor on Compromise Plugins:

To use Appdome’s mobile app security build system to Protect IDAnchor on Compromise , you’ll need:

• Appdome account (create a free Appdome account here)
• A license for Send IDAnchor on Compromise
• Mobile App (.ipa for iOS, or .apk or .aab for Android)
• Signing Credentials (see Signing Secure Android apps and Signing Secure iOS apps)

How to Implement Protect IDAnchor on Compromise in Mobile Apps Using Appdome

On Appdome, follow these 3 simple steps to create self-defending Mobile Apps that Protect IDAnchor on Compromise without an SDK or gateway:

1. Designate the Mobile App to be protected.

   1. Upload an app via the Appdome Mobile Defense platform GUI or via Appdome’s DEV-API or CI/CD Plugins.

   2. Mobile App Formats: .ipa for iOS, or .apk or .aab for Android
   3. Send IDAnchor on Compromise is compatible with: Obj-C, Java, JS, C#, C++, Swift, Kotlin, Flutter, React Native, Unity, Xamarin, and more.

2. Select the defense: Send IDAnchor on Compromise.

   1. Create and name the Fusion Set (security template) that will contain the Send IDAnchor on Compromise feature as shown below:
      

      Figure 1: Fusion Set that will contain the Send IDAnchor on Compromise feature
      

      1. Follow the steps in Sections 2.2-2.2.2 of this article to add the Send IDAnchor on Compromise feature to your Fusion Set via the Appdome Console.

      2. When you enable IDAnchor™ you'll notice that the Fusion Set you created in step 2.1 now bears the icon of the protection category that contains Send IDAnchor on Compromise.

         

         Figure 2: Fusion Set that displays the newly added Send IDAnchor on Compromise protection
         Note: Annotating the Fusion Set to identify the protection(s) selected is optional only (not mandatory).

      3. Open the Fusion Set Detail Summary by clicking the “...” symbol on the far-right corner of the Fusion Set. Copy the Fusion Set ID from the Fusion Set Detail Summary (as shown below):

         Figure 3: Fusion Set Detail Summary

      4. Follow the instructions below to use the Fusion Set ID inside any standard mobile DevOps or CI/CD toolkit like Bitrise, Jenkins, Travis, Team City, Circle CI or other system:

         1. Refer to the Appdome API Reference Guide for API building instructions.
         2. Look for sample APIs in Appdome’s GitHub Repository.

   2. Add the Send IDAnchor on Compromise feature to your security template.

      1. Navigate to Build > IDAnchor tab > Android IDAnchor section in the Appdome Console.

         Like all other options in ONEShield™, Send IDAnchor on Compromise is turned on by default, as shown below:

         Figure 4: Selecting Send IDAnchor on Compromise
         Note: The App Compromise Notification contains an easy to follow default remediation path for the mobile app end user. You can customize this message as required to achieve brand specific support, workflow or other messaging.

      Toggle On IDAnchor™ > Send IDAnchor on Compromise.
      

      Figure 4: Selecting Protect IDAnchor on Compromise

   3. Initiate the build command either by clicking Build My App at the bottom of the Build Workflow (shown in Figure 4) or via your CI/CD as described in Section 2.1.4.

   Congratulations!  The Send IDAnchor on Compromise protection is now added to the mobile app

3. Certify the Send IDAnchor on Compromise feature in Mobile Apps

   After building Send IDAnchor on Compromise, Appdome generates a Certified Secure™ certificate to guarantee that the Send IDAnchor on Compromise protection has been added and is protecting the app. To verify that the Send IDAnchor on Compromise protection has been added to the mobile app, locate the protection in the Certified Secure™ certificate as shown below:

   Figure 5: Certified Secure™ certificate

   Each Certified Secure™ certificate provides DevOps and DevSecOps organizations the entire workflow summary, audit trail of each build, and proof of protection that Send IDAnchor on Compromise has been added to each Mobile app. Certified Secure provides instant and in-line DevSecOps compliance certification that Send IDAnchor on Compromise and other mobile app security features are in each build of the mobile app.

   

   Figure 6: DefenseOS™

   DefenseOS™ manages and coordinates Appdome defense capabilities in protected mobile apps. To learn more about DefenseOS and its runtime modules, see Understanding DefenseOS™.