Near the end of Microsoft's roadmap for disabling NTLM sits a list of concrete steps for identity, security and application owners. One item on it ends up with developers: mapping dependencies and prioritising remediation, which "may include reaching out to application developers to update critical applications". For an in-house Android app that still answers an NTLM challenge, that sentence is the whole brief.
The Windows side of the move is well documented. Enhanced NTLM auditing shows where NTLM is still used. IAKerb and a local KDC are due in the second half of 2026 for Windows Server 2025 and Windows 11 24H2. With the next major Windows Server release, network NTLM is disabled by default (Microsoft, 29 January 2026). None of that runs on a phone. An Android app that authenticates to an intranet service with NTLM keeps doing so until its code changes.
This post is for the people who maintain those apps and for the IT leads who have to plan the switch. The first post in this series sets out Microsoft's full plan and what it means for mobile devices.
The October 2026 change to BlockNTLMv1SSO concerns Windows devices and NTLMv1-derived single sign-on credentials. It does not reach into your Android app. The date that matters for the app is the later one. Once a server runs a release with network NTLM disabled by default, an NTLM handshake from the app gets no answer, unless someone re-enables NTLM on that server through policy. Microsoft has not put a year on that release and says its timelines may change.
That leaves time, but not an open-ended amount. Kerberos support in an app is a code change, a test cycle and a release through the UEM, and it only helps once the Kerberos side on the device is in place too.
On Android, the Kerberos identity lives in an authenticator app on the device, such as Hypergate Authenticator, and is exposed through the standard Android account framework. Hypergate Authenticator runs on Android Enterprise devices from Android 7.0 and requests its tickets directly from the Key Distribution Center on your domain controllers. In our webcast of 23 September 2026 (in German, free recording after registration), Hypergate described two ways of doing that: PKINIT with a user certificate distributed through the MDM, or user name and password.
The SDK is the app-side piece. When your app calls a Kerberos-protected service, the SDK asks that account for a SPNEGO negotiate token for the service's principal name and hands it back as a string. Your app puts it in the Authorization: Negotiate header and the request is authenticated. According to Hypergate, the app never sees a password and never stores credentials. Which servers may receive tokens is set by IT through a managed configuration, not in the code.
The SDK is published on Maven Central as com.hypergate:sdk; the current release is 1.6.0. Source and documentation are on GitHub under the MIT licence.
Two changes bring the SDK into a project. The app's build.gradle gets the dependency implementation "com.hypergate:sdk:1.6.0". If the app has no app restrictions of its own, AndroidManifest.xml gets a meta-data entry android.content.APP_RESTRICTIONS pointing to @xml/hypergate_sdk_restrictions. If it already ships restrictions, you copy the entries from hypergate_sdk_restrictions.xml into your own file.
After that, the app exposes three managed configurations that IT sets in the UEM console:
The allowlist has a practical side effect for release planning. Narrowing the set of servers that may receive tokens is a change in the UEM, not a new app version.
If your app is hybrid, built with Cordova or Capacitor, or shows internal services in a WebView, the setup above is the whole integration. Every WebView in the project then answers HTTP Negotiate challenges on its own, for page loads and AJAX requests alike. For Cordova, Hypergate publishes a plugin and a sample app.
One exception: a hybrid app that sends its HTTP requests through a native plugin instead of the WebView. That plugin is a native client and takes path 2.
For native HTTP calls, your code requests the token. The SDK offers one method in four variants along two axes, blocking or not, and with or without UI:
The pattern is the same for every HTTP library: request a token for the service principal, set the header, send. In the README, the call is a single line, Hypergate.requestTokenSync(activity, "HTTP@myhost.com"). The OkHttp sample wraps it in an interceptor that builds the principal name as "HTTP/${request.url.host}" and adds Authorization: Negotiate to each request. The Volley sample does the same in getHeaders(). Hypergate describes this interceptor as the part that replaces an NTLM library or hand-written challenge-response code in the app.
For servers that negotiate over several round trips, requestTokenBundle* variants accept the server's previous token (incomingAuthToken) and an opaque spnegoContext, and return the raw AccountManager bundle. Hypergate.hasAccount(context) tells you at start-up whether an account exists, so the app can show a clear message instead of failing on the first request.
Errors arrive as a HypergateException with a numeric code and an English message. The one you are likely to meet first is 101, "no accounts found". According to the README, it usually means the app's package name is missing from the Hypergate discoverability list. That is fixed in the UEM console, not in code.
The SDK only works if the device already has a Kerberos identity. In practice that means four things:
Proof comes from the domain controller. When the Authenticator signs in, event 4768 records the ticket-granting ticket. When the app requests a token for a service, event 4769, "A Kerberos service ticket was requested", appears in the Security log with account, service name and client address. It requires "Audit Kerberos Service Ticket Operations" (Microsoft Learn). On the target server, the NTLM events for that user should stop at the same time. How to find those events is covered in the second post in this series.
The server-side NTLM events show which services mobile users still reach with NTLM. Once an in-house app is identified, ISEC7 SPHERE can track it from version 20.9.0 as a "Monitored application" and show which users and devices have it installed. That tells you who is affected by each app release.
Hypergate makes the Authenticator and the SDK and offered a free proof of concept of around 30 days in the same webcast. Your developers integrate the SDK. ISEC7, a Hypergate partner for Germany, the United Kingdom and the United States, rolls out the Authenticator and the managed configurations through your existing UEM, whether that is Microsoft Intune, Ivanti, Omnissa Workspace ONE, BlackBerry UEM, SOTI or 42Gears.
Admins who will roll out the Authenticator can prepare with our Android training. Anything specific to your own apps can go straight to us through the contact page.