Consistent, Verified Trust Under Pressure.

This month we’ve launched the first public releases of DexProtector 16.1.

In these updates, we’ve focused on fundamental reinforcements, starting with the DexProtector Runtime Engine (DRE) itself; version 16.1.6 incorporates new self-protection mechanisms that help the DRE withstand analysis and tampering attempts. This provides the strongest foundation for RASP, attestation, and anti-fraud measures during the protected app's runtime.

In version 16.1.6 we’ve also introduced improved detection and evasion of process tracing utilities, which attackers use to observe and manipulate security-critical operations, while version 16.1.9 reinforces device attestation to mitigate spoofing via modules such as TrickyStore, extending coverage across Android device models. On iOS, we've also introduced new detections for Frida modules in 16.1.9, strengthening defenses against instrumentation tools used to tamper with runtime processes and bypass security controls.

For apps using Certificate Transparency (CT) checks, 16.1.6 includes an update to ensure compatibility with the newer tiled log format. This enables CT checks to validate modern SCT formats correctly. If you’ve renewed or reissued certificates recently, we recommend updating apps in production soon with DexProtector 16.1. That way you can refresh the embedded log list and account for the newer CT logs that began to be deployed through late 2025 and early 2026.

Continuing the theme of network security, in 16.1.9, we've also introduced a new network security policy option to enforce use of recommended secure cipher suites, blocking connections that don’t meet current cryptographic standards. We've also extended Public Key Pinning and Certificate Transparency checks to TLS over raw TCP socket connections, bringing DexProtector's powerful network security capabilities to apps that rely on custom networking stacks.

And finally, DexProtector 16.1.6 also added support for .NET 9 (Xamarin), ensuring protection for newer Xamarin/.NET asset formats, so teams can take advantage of new features, and ongoing performance and runtime enhancements.

All of these updates combined ensure that DexProtector stands up to the latest threats targeting mission-critical, high-value mobile applications. We’re big believers in continuous security and not standing still in a world where attacks are constantly evolving. And this is what independent laboratories and the most stringent regulatory requirements demand, too; which is why we’re so thrilled that DexProtector has now been evaluated and approved by EMVCo for the sixth consecutive year.

Keep reading to find out more.

We’re pleased to share that DexProtector has once again been evaluated and approved by EMVCo under the SBMP SPT category; one of the most demanding mobile application security standards in the industry.

EMVCo is a global technical body collectively owned by payment giants like Mastercard, Visa, Discover, JCB, Union Pay, and AMEX. It re-evaluates solutions against evolving requirements year after year, and so requires continuous adaptations and improvements to meet stringent standards that define the latest attack techniques, new platform behaviors, and new expectations around client-side integrity.

This approval provides independent confirmation that DexProtector continues to deliver reliable, certifiable protection against tampering, reverse engineering, and hostile runtime environments, among other threats.

For organizations developing wallet apps or payment SDKs, this certification not only gives them an EMVCo-approved protection component that satisfies SBMP security requirements, but can also help shorten their own evaluation processes.

Its significance extends across industries and applications, since EMVCo approval remains the strongest independent marker out there of a protection tool's robustness, based on expert analysis and rigorous testing.

Think about a scenario where you’re planning to meet up with an acquaintance; a friend of a friend who you’ve met once before years ago and have a photo of somewhere on your phone. Now imagine that this person shows up at the place you arranged to meet and they look more or less the same - similar height and build, similar style. But you can’t shake off the suspicion that something feels off.

If you were in this scenario, you’d probably do a bit of probing. You might ask after the friend you both have in common, recall the events of a party you both attended, and generally seek some kind of continuity in behavior, context, shared history.

Somehow it has become acceptable in mobile security not to probe for this wider context to make sure we’re talking to who we think we are. Instead, if a single expected value (like a hash) matches, then we assume that an application is the genuine article.

This is one of two fundamental flaws in authentication today; checks are too static, too shallow. They don’t do enough to account for the complexity and sophistication of threats that target modern mobile devices.

The other flaw is that our obsession with (and reliance on) the mobile device has blinded us from the long-agreed principle that the second factor should live on a different device altogether.

Here at Licel, we think we collectively need to start asking different questions if we want authentication to work again. We explain why in detail in our latest article: The Mobile Authentication Illusion.