There’s a question that sits at the heart of modern mobile security:
In a mobile channel full of threats and increasingly sophisticated fraud, how can we know which signals we can really trust?
At the very same time that organizations rely more heavily on client-side signals to authenticate the user, collect telemetry, and detect indicators of fraud, attackers have become skilled at spoofing these signals. Deepfakes, malware, emulators, and automated attacks all exploit the same weakness; people being over-reliant on assumptions about device and runtime integrity.
In this edition of the Licel Layers Bulletin, we’re explaining the answer to the question above from three different angles. We’ll share with you how DexProtector is evolving toward a more granular, context-aware attestation model - and enabling risk-based responses. Our end-of-year trends piece explores how the mobile trust gap widened in 2025 and why trusted signals are key to narrowing it again in 2026. And we'll tell you why protecting mobile APIs enables confidence in the signals.
What's new with Licel's solutions?
DexProtector
The start of 2026 will see early releases of DexProtector 16, which includes a revamped core on Android and more advanced device attestation mechanisms across both platforms, including new checks which extend coverage for Dopamine2-roothide, Magisk forks, TrickyStore, and specific image injection techniques used by fraudsters to bypass ID verification.
We’re preparing for the release of DexProtector 16, scheduled to roll out in early 2026. This is a major new update driven by fundamental reinforcements to the core architecture, especially on Android, alongside a firm focus on introducing new, more sophisticated device attestation mechanisms across both Android and iOS.
Device attestation identifies indications that a device may be compromised and therefore an untrustworthy source of information, particularly when it comes to sensor data used for authentication and ID verification, even when the app itself hasn’t been directly tampered with. This includes indicators of root or jailbreak, custom firmware, emulators, malware, potentially harmful apps, and tools or modules designed to hide their presence.
In the early days of mobile app security, root and jailbreak detection was relatively straightforward: apps could simply look for known files or attempt privileged operations. Over time, however, as detection techniques have become more sophisticated, concealment and spoofing techniques have become more advanced in parallel. Toolkits have proliferated and evolved; many have wide popularity and devoted users: on Android, Magisk, including all of its forks and modules, remains popular, along with APatch, KernelSU, and others. On iOS, palera1n, checkra1n, Dopamine, Roothide, Dopamine-roothide, and many more.
As a result, the cat-and-mouse game is faster and more complex than ever. Our research team tracks hundreds of variant configurations, factoring in different stacks, versions, and settings. Each variant may require different detections and responses, to the extent that it makes less and less sense to talk about ‘root detection’ or ‘jailbreak detection’ as a single concept.
At the same time, there has been a realization among organizations that a rooted or jailbroken device is one possible risk factor among many, and the best way to handle the risk is dependent on a whole range of contextual details.
Increasingly, what’s needed for device attestation is a context-aware approach: mechanisms and responses that are tailored to the particular runtime conditions in which the app is executing, and the risks involved in that particular session. For example, many toolkits target specific OS versions, in some cases only a very narrow range, such as iOS 15.0 to iOS 15.4.1. This enables us to be more precise in both detection mechanisms and in responses, both in-app and server-side.
That’s why DexProtector 16 represents an important continuation of a shift towards a context-aware attestation approach: delivering granular signals that support risk-based decisions rather than blanket verdicts, and enabling flexible, targeted handling.
Early releases will introduce new checks which extend coverage for Dopamine2-roothide, Magisk forks, TrickyStore, and specific image injection techniques used by fraudsters to bypass ID verification.
They are aimed at providing signals which can be updated and refined at high speed and can inform risk-based decisions, and are underpinned by a fundamental principle behind DexProtector: the app’s own integrity must be assured in order for detection signals to be trustworthy, protected against tampering, suppression, or spoofing, so that decisions are based on reliable evidence.
Attack trends
Why Trusted Signals Are the Key to Closing the Widening Mobile Trust Gap
For too long now, there has been an assumption that certain signals - camera input, biometric checks, or device model, for example - are inherently reliable and trustworthy. It’s a flawed assumption, because attackers can spoof and tamper with these signals - with precision and, more than ever before, at scale.
The result of this is a disconnect between what the backend typically assumes to be true and what is actually happening on the front lines, inside the mobile application itself. A trust gap has opened up and is steadily widening. And the timing couldn’t be worse, because the stakes are getting higher by the day. Mobile apps are now the gateway for national digital identity systems, regulated payment ecosystems, and new forms of authentication and authorization.
The cost of trusting the wrong signal, therefore, has never been higher.
In our end-of-year trends article, we take a deep dive into the why the mobile trust gap has widened in 2025, and we set out our vision for reclaiming mobile trust in 2026.
You can read it below:
Mobile API Protection: From Afterthought to Necessity
A significant and underplayed aspect of the problem of trust in the mobile channel is finding a solution to how the server can authenticate a mobile application. Various solutions have been attempted to solve this problem, but they tend to reach the same fundamental limitation. What the server is authenticating is not an app but rather a credential: a string, or a signature or certificate produced with a key that the app holds.
Trust in the mobile channel can’t depend on insecure apps or static secrets, because the mobile client is a target that attackers will have ample opportunity to observe, instrument, and manipulate.
Compounding the issue, many backends continue to serve outdated app versions, quietly allowing attackers to target weaker releases long after stronger protections exist.
To establish real trust in the mobile channel, backend systems need more than credentials. They need evidence: is this a genuine app, is it up to date, and is it running with integrity?
That’s the challenge Mobile API Protection now has to solve.
In the article below we explain why it’s such an important protection mechanism for the mobile channel.
Thanks for reading this edition of the Licel Layers Bulletin. We'll be back next month with more product improvement updates and threat intelligence insights.
