TL;DR

• RBI’s device-locking rules require RE and vendor OEM certification before deployment, but no named certification program exists in the published rule text.
• This is a real compliance gap for gadget-financing NBFCs building or buying lock software today, not a future problem.
• Device locking works reliably only on Android in current MDM architecture. iOS presents a structurally different technical path.
• No enforcement guidance exists yet for lenders using pre-2027 lock SDKs without OEM sign-off.
• Model Governance can log and prove when and how a certified locking decision was applied. It does not certify or select the locking mechanism itself.

The Rule Text Says OEM Certification Is Required. It Doesn’t Say by Whom.

Per secondary reporting on RBI’s device-locking guidelines, including coverage by Inc42, regulated entities (REs) and third-party device-locking vendors are required to obtain certification from the device or operating system platform’s OEM before deploying device-locking technology in gadget financing. That is the confirmed language: certification, from the OEM, before deployment.

What the rule text does not do is name who runs that certification, what it tests, or how a lender proves it holds one. No source we’ve reviewed identifies a specific program: not Android Enterprise, not Samsung Knox, not Google Device Trust, not Apple Business Manager. There is no RBI circular annexure listing approved certifiers. There is no published checklist. As of this writing, “OEM certification” is a requirement with no enumerated definition attached to it.

For a compliance team at a gadget-financing NBFC, that has real teeth. It means the interpretation work of what counts as certified currently sits with the lender and the vendor, not with the regulator. If RBI later decides a given vendor’s self-attestation doesn’t meet the bar, the lender that signed the contract is the one holding the exposure. This is the practical stakes of “OEM certification device locking software banks NBFC” as a live compliance question right now, not a settled one.

What Certification Plausibly Means in Practice, and What It Doesn’t Yet

In the absence of an RBI-endorsed checklist or approved vendor list, compliance and engineering teams are reasonably looking at existing industry device-management frameworks as reference points. Android Enterprise, Samsung Knox, and Google Device Trust are the frameworks most commonly cited in market conversation as plausible proxies for OEM certification.

That needs a flag attached to it every time it’s said out loud internally: these are unofficial industry practices, not an official regulatory pathway. None of them is confirmed by RBI as satisfying the rule. Using one of these frameworks may be a reasonable, defensible engineering choice. It is not the same as having a regulator-recognized certification, and framing it that way to an auditor or examiner overstates what’s actually been confirmed.

The honest position for a compliance memo right now reads something like this: “we have selected [framework] as our best-available interpretation of the OEM certification requirement, pending regulatory clarification.” That’s a materially different sentence than “we are OEM-certified,” and the difference matters if RBI ever asks.

The Android and iOS Asymmetry the Rule Text Doesn’t Address

This is general MDM-architecture industry knowledge, not an RBI-specific finding. No RBI document or legal analysis we’ve reviewed addresses this gap directly, but it’s a structural fact of how mobile operating systems work, and it has direct consequences for how OEM certification plays out across a gadget-financing NBFC’s device mix.

Device locking in the field today works reliably on Android because Android Enterprise’s Device Owner and kiosk APIs allow a provisioned third-party app to take device-wide lockdown control. A lending app, with the right enterprise provisioning, can restrict or brick a financed Android phone remotely. That’s the mechanism most EMI-phone-lock products rely on.

iOS does not offer an equivalent path for a third-party app acting alone. Apple confines that level of control to its own Supervised Mode and MDM stack, and invoking it requires the device to be enrolled in an MDM profile at the time of sale, before it leaves the retail environment. A lending app cannot retroactively claim that level of control over an iPhone sold through a standard retail or EMI channel after the fact.

The consequence for gadget-financing NBFCs is direct: a lender financing iPhones may be looking at a structurally different, and possibly currently nonexistent, compliant technical path compared to a lender financing Android devices. That’s worth surfacing to product and legal teams now, before it turns into a live default-recovery incident.

The Open Question on Existing Lock Vendors

India’s EMI-phone-lock market has operated for years with third-party device-locking SDKs, some of them well established, none of them formally OEM-certified under the standard the rule now names, as far as public reporting shows. That’s a known, long-standing feature of the current market.

What’s genuinely unresolved is what happens to that installed base. No source we’ve reviewed discusses enforcement consequences, grandfathering provisions, or a transition timeline for lenders currently running uncertified third-party lock SDKs. The rule’s plain text logically forecloses uncertified vendors from operating past the compliance date most reporting cites as January 1, 2027. That reading is ours, drawn from the plain text. RBI has not issued a confirmed position on transition mechanics.

This is a question compliance teams should be raising with legal counsel and their RBI liaison now, directly, rather than waiting for it to surface in an examination. Treat it as an open item to escalate today, well before an examination brings it up on someone else’s terms.

Where a Governance Platform Fits, and Where It Doesn’t

iTuring’s Model Governance module does not certify devices, vendors, or locking software. It is not an MDM, and it does not select or evaluate which locking mechanism a lender or vendor should use.

What it does do is create an immutable, maker-checker-approved audit record of which locking vendor and certification claim was in effect at the point of deployment, when that claim was last verified, and by whom. That record surfaces on demand, which matters directly for RBI’s 2024 Model Risk Management framework, which requires account-level model explainability whenever an examiner asks for it.

The practical upshot: if RBI later asks a lender to prove when and how it verified a vendor’s OEM certification, the documentation trail is what Model Governance delivers. The underlying decision about which locking mechanism is actually certified, and by whom, remains the lender’s and vendor’s call to make and defend. Governance software applied to this question is a proof layer. It does not substitute for doing the certification homework in the first place.

A Practical Checklist Before You Sign a Device-Locking Vendor Contract

Ask these directly, in writing, before signing or renewing:

• What OEM certification do you hold, and who issued it? Get the name of the certifying body in the contract, not a marketing claim.
• If you don’t hold formal OEM certification, what framework are you relying on instead (Android Enterprise, Knox, or another), and is that documented as an interim position rather than a compliance claim?
• Do you have a distinct, working mechanism for iOS, or does your product only function on Android? If iOS-only support doesn’t exist, get that in writing so procurement and risk both know the actual coverage gap.
• What is your transition plan if RBI issues enforcement guidance before January 2027 that requires re-certification or vendor replacement? Whose cost and timeline is that?
• Can you produce a verifiable, timestamped record of your certification status on demand for an RBI examiner, not just a sales deck claim?
• Who at your organization is our named point of contact if RBI issues clarifying guidance mid-contract, and what’s the SLA for updating us?