Sentinel

The Key

on the Device.

A short reflection for boards and senior executives on the largest quiet liability in Indonesian mobile banking — and the architectural answer that closes it.

Directors, commissioners, and senior executives of regulated Indonesian institutions.

This is not a product brochure.

It is a short note, written for directors, commissioners, and senior executives of Indonesian institutions whose customers or constituents interact primarily through a mobile application. It describes a specific property of how those applications are protected today, the reason that property has quietly become the largest single security liability in Indonesian banking and public service, and what can be done about it.

It is organised as three short chapters. The first describes the situation as it actually is. The second describes three shifts that have recently made this situation urgent rather than theoretical. The third describes an architectural response — what an alternative construction of mobile application security looks like, and what it means for the institution that deploys it.

It is short on purpose. If after reading you would like to examine the technical detail, the regulatory mapping, or the commercial structure, those conversations are available on request.

— The authors

The situation

as it actually is.

Begin with a familiar image. Tens of millions of Indonesians open a mobile banking application in the course of an ordinary Tuesday morning. They key in their PIN. They transfer money, pay bills, subscribe to a mutual fund, check the balance of a child's educational savings. The application, loaded on their device some months or years ago, verifies them, reaches the bank's servers, and executes the transaction.

None of this is remarkable. It is the infrastructure of ordinary Indonesian financial life, and it works, by and large, reliably.

What is worth examining — because it is not well understood outside the technical teams responsible for it — is what actually protects the application during those millions of daily interactions. The answer, uncomfortably, is that the application protects itself using a cryptographic key that lives on the user's device. Not on the bank's servers. Not in a secure facility. On the user's phone, alongside the encrypted application the key is designed to protect.

Every major commercial mobile app protection SDK in this category — DexGuard and iXGuard from Guardsquare, SHIELD from Promon, Arxan from Digital.ai, Zimperium's zShield and zKeyBox, Appdome, AppSealing, Verimatrix, Talsec, and the comparable products across the category — operates on this principle. The key is obfuscated. It is split across multiple locations in the binary. It is mathematically transformed through white-box cryptography. It may be buried under layers of considerable cleverness. But it is, nonetheless, derivable from material present on the device.

The protection key for your institution's most valuable customer-facing application exists, right now, on devices you do not own.

And that means it is, in principle, extractable.

An attacker with sufficient time, a rooted device, and commercial reverse-engineering tools can — with effort but without breakthrough — extract that key. The tools required (Frida, Magisk, IDA Pro, Ghidra) are inexpensive or free, and widely documented. The skill is specialised but not rare; any competent mobile security researcher can perform this work, and increasingly, so can operators in fraud syndicates who have learned the technique from published research. The time required, for a protected banking application, is typically measured in weeks, not years.

And once the key is extracted, it is not extracted only for that one attacker, on that one device. It becomes the master key to every installation of that version of the application in circulation. It is sold. It is shared. It travels.

The protection key for your institution's most valuable customer-facing application exists, right now, on devices you do not own, in environments you cannot inspect, surrounded by tools whose sole function is to extract it.

This is not a theoretical vulnerability. It is not a zero-day awaiting disclosure. It is a structural property of how commercial mobile protection has been built for the last decade. It has been accepted because, until recently, the economics of extraction made it a slow and expensive attack — a cost-raising defence rather than a prevention, but one sufficient for ordinary risk. That era is now ending, for reasons the next chapter describes.

The shift that has

already happened.

Three developments, each ordinary in isolation, combine to make this an urgent rather than a theoretical problem. None is hypothetical. Each is visible in current threat intelligence, current regulatory publications, and current dark-web commercial activity observable to any institutional security team.

The first is the maturation of Android rooting ecosystems. Ten years ago, rooting an Android device required specialised knowledge and carried real risk to the device itself. Today, Magisk, Zygisk, and LSPosed are polished open-source tools with active user communities, tutorial videos in Bahasa Indonesia, and public forums on which the latest root-detection bypass techniques are shared within days of a banking app's release. The gap between the moment a security team deploys a new hardening measure and the moment that measure is publicly bypassed has narrowed, by most public accounts, from months to hours.

The second is the emergence of a mature economy for extracted application keys, reported by threat intelligence firms covering the region. Keys from banking applications circulate on Russian-language and Indonesian-language marketplaces, with prices varying substantially by target institution and the completeness of the associated documentation. The original extractor is rarely the final user. The key circulates, is resold through brokers, and eventually reaches fraud syndicates operating at industrial scale against the protected user base.

The third is the trajectory of Indonesian financial regulation. OJK POJK 11/2022 on digital banking resilience. POJK 29/2024 on consumer protection in financial services. SEOJK provisions on mobile channel risk management. Bank Indonesia's SNAP framework and the associated SDK requirements. Read carefully — as compliance teams are currently reading them — each of these moves toward an expectation that financial institutions demonstrate device integrity verification, protection against instrumentation, and real-time response to compromised environments. These are expectations that conventional mobile protection SDKs architecturally cannot satisfy. The direction of regulatory travel is clear, even where specific requirements have not yet crystallised into enforceable obligations.

The gap between deploying a new hardening measure and having it publicly bypassed has narrowed, by most public accounts, from months to hours.

Taken together, these three developments collapse a defensive posture that has held, approximately, for a decade. Mobile protection SDKs were designed for a threat environment in which key extraction was slow, rare, and performed by specialists. They are now operating against a threat environment in which extraction is commoditised, the resulting keys are fungible assets, and regulators are moving to require protections the existing architecture cannot provide.

And so the question worth putting to your chief information officer, your security committee, and your board risk committee is not whether your mobile application has been hardened. It almost certainly has. The right question is sharper than that.

What is our exposure the day a single extracted key compromises every installation at once?

For every institution currently relying on conventional mobile protection SDKs, this is not a hypothetical question. It is a scheduled one. The schedule is set by the attackers; the calendar is not shared.

The architectural

answer.

What follows is worth reading as an architectural proposition rather than a product pitch. The question worth proposing is whether a different construction of mobile application protection is possible — one in which the uncomfortable property described in the first chapter simply does not exist.

The principle is a single sentence, and the rest of the architecture follows from it.

The decryption key for a protected application payload should never exist on a user's device without a live server authorisation that has verified hardware-rooted attestation of that specific device.

In ordinary English: the application arrives on the user's phone as encrypted content only. The key to decrypt it is held on the institution's server infrastructure. At the moment the user launches the application, the phone presents cryptographic proof — signed by hardware the attacker cannot forge — that it is a genuine, unmodified device of the kind the institution expects. The server verifies this proof. If it holds, the server delivers a decryption key wrapped specifically to that device's hardware, usable only for that session. The key is used to load the application into memory, and is then immediately wiped.

At no point during or after this sequence does the decryption key rest on the user's device in a form that can be extracted. Static analysis of the application binary yields only ciphertext. Runtime analysis sees a key that exists for the duration of a function call. An attacker with a rooted device, three months of time, and every commercial reverse-engineering tool in existence will not extract a key, because there is no key to extract.

Consider what this means in concrete operational terms. The difference between conventional protection and this architecture is best shown not as a specification comparison, but as two parallel timelines — what happens to an attacker working against a conventionally protected application, and what happens to the same attacker working against an application protected this way.

Illustrative timeline based on the general attack pattern observed across published mobile banking compromises. Specific durations vary by target, attacker skill, and toolchain.

The second timeline does not describe the elimination of all risk. Any serious architecture has residual risks, which we document in detail for technical evaluators. What this timeline describes is the elimination of the specific attack class — patient offline extraction of a master key that compromises the entire installed base — that is responsible for the large majority of consequential published mobile banking incidents. That single change re-orders what matters in the institution's risk posture.

From this architectural shift, three consequences follow. Each is relevant to a different part of the institution's risk posture, and each is worth considering on its own terms.

Risk converts from unbounded to bounded.

The most common mobile banking incident under conventional protection is an extracted key that compromises the entire installed base. Under this architecture, that incident class simply does not occur. Individual incidents remain possible — any system has residual risk — but they are localised to specific devices, detectable in real time, and responsive to server-side intervention. The institution's risk profile shifts from we will find out when we find out to we will know within minutes and can respond within minutes.

Regulatory posture moves ahead of the requirement.

The direction of Indonesian financial regulation is toward hardware attestation, device integrity verification, and demonstrable real-time response capability. This architecture was designed against those expectations rather than adapted to them. An institution that deploys it is, in effect, compliant with requirements that have not yet fully hardened — which means the next OJK or Bank Indonesia announcement does not trigger a disruptive SDK replacement programme eighteen months from now.

Incident response collapses from weeks to minutes.

When a compromise is detected under conventional protection, the response loop is to identify the affected version, build a patched application, submit to Apple and Google, and wait seven to fourteen days for approval and user adoption. Under this architecture, the response is a server-side revocation that takes effect on the next application launch. The institution's window of exposure between detection and containment collapses from a fortnight to a few minutes. For a bank processing billions of rupiah an hour on mobile, that is not a technical improvement — it is the difference between a contained incident and a front-page crisis.

Where the conversation

might begin.

If you have read this far, the architectural question has done its work. What remains is whether and how to examine it further.

What we would propose is a 90-minute executive briefing, conducted at your offices and attended by whichever of your senior leadership you would find it useful to include. The briefing covers the architecture in greater depth than this note permits, includes a live demonstration of the protection operating against instrumented attack scenarios, and concludes with a candid conversation about whether and how a formal evaluation might be structured. We will arrange it within two weeks of your request.

If you would prefer that the conversation begin at a technical level instead, we will provide the full product brief and the technical evaluation package under non-disclosure, and your chief information officer's team can begin the evaluation without executive involvement. Either path is available. The choice of which, and whether, is yours.

For planning purposes: a typical institutional deployment runs three to five months from signed engagement to general availability, with pre-contract evaluation typically adding two to four additional months. A serious evaluation of whether Sentinel is the right architectural fit can itself be completed in six to eight weeks.

PT Easysoft Indonesia

Jakarta, Indonesia · nexilis.io

nexilis.support@nexilis.io

Nexilis

Sentinel

Mobile security for regulated institutions — Zero Trust application protection, hardware-rooted attestation, and continuous threat defense, architected for the way attacks actually happen.

PT Easysoft Indonesia

A serious answer to a serious problem.

For every regulated institution running a customer-facing mobile application, the mobile channel is now the single largest source of security incidents. Nexilis Sentinel is built to change that equation at the architectural level.

This document is organized so each reader can find what they need without reading the whole.

— Who this document is for

— What Sentinel is, in one paragraph

Nexilis Sentinel is an integrated mobile security product that combines Zero Trust application protection with continuous mobile threat defense, delivered as a native SDK for Android and iOS with a supporting server-side authorization and intelligence platform. It is built for a specific problem that existing commercial products do not solve: the decryption key for a protected mobile application should never exist on the user's device without a live, hardware-attested server authorization. Every leading commercial mobile app protection SDK in this category — DexGuard and iXGuard from Guardsquare, SHIELD from Promon, Arxan from Digital.ai, Zimperium's zShield and zKeyBox, Appdome, AppSealing, Verimatrix, Talsec, and the comparable products across the category — derives or stores protection keys on the device. Sentinel does not. That single architectural property changes the attacker's economic model from slow and expensive to requires compromising a live attested device in real time.

The decryption key for the protected application payload never exists on a user's device without a live server authorization that has verified hardware-rooted attestation of that specific device.

Why existing protection is not enough.

Commercial mobile protection SDKs have not materially advanced their architectural model in five years. Attackers have.

— Three shifts driving mobile as the dominant attack surface

For every regulated institution running a customer-facing mobile application, the mobile channel is now the single largest source of security incidents. Three structural shifts are driving this. Mobile banking in Indonesia has become the primary banking interaction for the majority of urban bankable adults, concentrating transaction volume on a channel most institutions do not fully control. Android rooting tools — Magisk, Zygisk, LSPosed — have reached a level of maturity where a moderately skilled attacker can bypass conventional root detection in hours. And commercial mobile protection SDKs, which most institutions rely on, have not materially advanced their architectural model in five years.

— What commercial SDKs do not protect against

The leading commercial mobile app protection products — DexGuard and iXGuard from Guardsquare, SHIELD from Promon, Arxan from Digital.ai, Zimperium's zShield and zKeyBox, Appdome, AppSealing, Verimatrix, Talsec, and the comparable products across the category — share a common architectural limitation. All of them derive or store the protection key on the client device. The key may be obfuscated, split, white-box-encrypted, or tied to device characteristics; it is nonetheless present. An attacker with sufficient time, a rooted device, and standard reverse-engineering tools can — and regularly does — extract it. Once extracted, the protection scheme is defeated for every installation of that version of the application.

This is how most published mobile banking attacks unfold: not through novel vulnerabilities, but through patient extraction of protection keys from commercially protected applications. The commercial SDK raises the cost of attack; it does not eliminate it.

What Indonesian regulators now expect

OJK POJK 11/2022 on digital banking resilience, POJK 29/2024 on consumer protection, SEOJK provisions on mobile risk management, and Bank Indonesia SNAP all require financial institutions to demonstrate device integrity verification, protection against instrumentation, and real-time detection of compromised environments. Conventional SDKs can claim partial compliance; they cannot demonstrate the cryptographic properties regulators increasingly expect.

Four outcomes that change the equation.

These are the outcomes Sentinel is designed against and the outcomes it is measured against. Each is architecturally specific, not aspirational.

Nexilis Sentinel is the only productized mobile security SDK where a stolen device, with stolen credentials, still cannot decrypt the protected application.

Twelve layers on Android, eight on iOS.

Each layer is independent and additive. The chain between Layers 1–6 delivers the architectural advantage: hardware attestation gates Zero Trust authentication, which gates key delivery.

— Android protection layers

— iOS protection layers

App launch to key delivery, in six steps.

This flow executes on every application launch. There is no cached or offline fallback. The nonce makes replay cryptographically impossible; the key wrap makes interception pointless.

The cryptographic chain an attacker would need to break

To obtain a decryption key, an attacker would need to simultaneously: forge an attestation certificate chain signed by Google or Apple root CAs; replay a nonce that the server tracks as single-use; compromise the device's hardware-rooted keypair without detection; and do all of this within a TLS session pinned to the Sentinel server's certificate. Each of these is individually hard; the conjunction is, in practice, the reason offline attacks against Sentinel do not succeed.

Protecting the user, not only the application.

The Shield module extends Sentinel into active threat defense for the end user. It catches the attacks that reach customers through channels outside the application itself.

Why k-anonymity matters to regulators and customers

The Shield identity monitoring architecture is designed so that even Nexilis cannot know which specific identifiers a particular user has registered. The server receives a five-character hash prefix that maps to hundreds of possible underlying identifiers; the full match happens on-device. This satisfies the data minimization principles embedded in POJK 29/2024 and PP 71/2019, and makes the product defensible under the increasingly strict privacy obligations banking supervisors are imposing on third-party processors.

The two rows that define the gap.

The comparison below draws on each vendor's published architecture documentation. Two rows — offline attack surface and key extractability — determine real-world resistance to the attacks responsible for most published mobile banking compromises.

The capabilities that warrant specific attention are server-side key delivery (Layer 6), per-install binary diversity (Layer 4.5), and server-side logic execution (Layer 6.5). These are the properties that change the attacker's economic model from slow and expensive but eventually successful to requires compromising a specific, live, attested device with valid user credentials — and even that compromise yields nothing useful against any other installation.

The four named competitors are representative of the category and shown for comparison detail; the architectural observations apply equally to Appdome, AppSealing, Verimatrix, Talsec, and other commercial mobile app protection SDKs in the same category, each of which stores or derives the protection key on the client device.

What Sentinel does not directly compete against

Two product categories sit adjacent to in-app protection without being direct competitors. Mobile Threat Defense products — Lookout, Pradeo, Zimperium's zDefend — operate at the device level rather than the application level and address a different attack surface; Sentinel integrates this capability through the Shield module rather than competing against it. API request attestation products — Approov (CriticalBlue) — implement server-side cryptographic proof of app genuineness for API authentication; Sentinel extends the same architectural principle from API requests to the protected application payload itself. Institutions currently using either category can complement rather than replace their existing investment.

Honest about what it does and does not protect.

This is the threat model Sentinel is designed and audited against. The residual risks are named, not hidden. No architecture is unbreakable, and any supplier suggesting otherwise is overstating what is achievable.

Sentinel is not claimed to be unbreakable. What the architecture materially achieves is the elimination of the offline attack surface — the largest and most common attack class — and the reduction of online attacks to an operational problem: one that can be detected, logged, revoked, and responded to in real time rather than through an application-store update cycle.

Eleven to nineteen weeks, signed engagement to general availability.

The eleven-to-nineteen-week range covers commercial Trusted Channel deployments from contract signature to production; sovereign TrustLink deployments for government and defense typically run 18–28 weeks due to additional infrastructure coordination. Pre-contract activities (executive briefing, technical deep dive, scoped proof-of-concept) typically add 8–16 weeks before signed engagement.

— Implementation timeline

— Operational considerations

The architectural properties that make Sentinel distinctive also introduce operational implications worth naming explicitly. The current generation of the product handles each of the scenarios below through documented mechanisms; detailed behaviour is covered in the technical evaluation package.

Play Integrity tier and hardware attestation coverage

Sentinel's strongest configuration requires the highest Play Integrity verdict tier on Android (which requires hardware-backed attestation, supported on GMS-certified devices from recent manufacturers) and Apple DeviceCheck App Attest on iOS (supported on devices running iOS 14 and later with Secure Enclave). On Android devices that cannot reach the highest tier — older devices, some regional-vendor devices without full GMS certification — Sentinel applies a configurable degraded trust path: the device is granted application access at a lower trust tier with correspondingly reduced transaction limits, rather than being excluded outright. The exact tier logic is defined per institution during Discovery.

Built for Indonesian regulation, first.

Sentinel is designed to satisfy Indonesian financial services regulation and Indonesian government data protection regulation directly — not adapted from foreign frameworks.

Detailed control mapping

A detailed control-mapping document, showing each regulatory provision and the specific Sentinel architectural layer or capability that satisfies it, is available under mutual non-disclosure as part of the technical evaluation package. Institutions with active procurement cycles can receive this package within forty-eight hours of signed NDA.

Three tiers, one platform.

Sentinel is the platform; Trusted Channel and TrustLink are the commercial tiers under which institutions acquire it. Per-active-device annual subscription includes the full SDK, server platform access, threat intelligence, breach data, platform updates, and operational support.

— Included with all tiers

Platform updates addressing new threats, device models, and Android / iOS releases

Threat intelligence feeds, phishing signature updates, and dark-web breach data

Standard operational support during Jakarta business hours; 24×7 for production-severity incidents

Quarterly security posture review and anomaly reporting

Annual architecture review with the institution's security team

Specific pricing discussed per engagement

Per-device pricing, volume tiers, multi-year discounts, and professional services rates are established per engagement following the initial discovery phase. Indicative commercial envelopes are available on request under mutual non-disclosure. Sentinel is competitive with commercial SDK alternatives on total cost of ownership, with materially stronger architectural protection and regional specialization.

The conversation starts here.

Institutions evaluating Sentinel typically follow a three-stage process from initial conversation to signed engagement.

PT Easysoft Indonesia

Jakarta, Indonesia · nexilis.io

nexilis.support@nexilis.io

This document and the technical specifications it summarizes are the confidential property of PT Easysoft Indonesia. Distribution to parties outside the receiving institution requires written authorization. Specific architectural details, adversarial audit findings, and regulatory control mappings are provided to qualified institutional evaluators under mutual non-disclosure as part of the technical evaluation package.