TL;DR
- RBI’s device-locking rule for NBFCs sets four eligibility conditions, not one.
- The device must be the one the loan financed, and the loan agreement must expressly permit restriction.
- Restriction has to follow the staged timeline: nothing before 30 days past due, full restriction only past 60.
- The locking mechanism itself must be certified by the device’s OEM or its operating-system platform, where certification is available, the condition this piece covers.
- Skip that fourth condition and every other safeguard (notice periods, essential-function protections, wrongful-restriction compensation) sits on top of unverified technology.
This piece cites RBI’s NBFC-specific 2026 amendment (paragraph 100S) from secondary-source reporting, not a primary RBI text we’ve been able to fetch directly. Treat the paragraph citation as high-confidence, not primary-confirmed.
Most compliance teams reading RBI’s new device-locking rule stop at the parts that are easy to operationalize: the 30-day and 60-day thresholds, the one-hour unlock window, the ₹250-per-hour compensation cap. Those get built into a workflow. The fourth condition, the one about who certifies the locking mechanism itself, tends to get treated as a vendor’s problem rather than the NBFC’s own compliance exposure. It isn’t. The NBFC is the regulated entity here, not the software vendor, and an examiner asking “who certified this mechanism” is a question the NBFC has to answer, not forward.
What the rule actually says about certification
RBI’s amendment sets out four conditions an NBFC has to meet before it can restrict a financed device’s functionality. The device has to be the one the loan actually financed. The loan agreement has to expressly permit the restriction. The restriction has to follow the staged timeline, nothing before 30 days past due, full restriction only past 60. And the locking mechanism itself has to be certified by the device’s Original Equipment Manufacturer or the operating-system platform, where such certification is available.
That fourth condition is doing something the first three aren’t. The first three are procedural: things an NBFC’s own policy and workflow can guarantee. The fourth depends on a claim made by whoever built the locking software, verified by a party outside the NBFC’s control. An NBFC can write a perfect Board-approved policy and still fail this condition if it never asked its vendor for proof.
Why an uncertified mechanism is a real liability, not a technicality
An uncertified locking mechanism doesn’t fail safely. It fails in ways that create the exact harms the rest of the rule exists to prevent. A mechanism that hasn’t gone through a manufacturer’s or platform’s own certification process has a real chance of blocking functions the rule says must always stay open: incoming calls, SMS, emergency services. It can also fail to release on schedule, which is what triggers the compensation obligation in the neighboring paragraph covering wrongful restriction, ₹250 an hour, capped at the loan amount.
So certification isn’t a separate technical checkbox sitting next to the compliance rule. It’s the mechanism by which the compliance rule actually holds. Every protection downstream, the essential-function carve-out, the one-hour reversal, the compensation cap, assumes the software behaves the way it’s supposed to. Certification is the only evidence that assumption is safe to make.
What “certified by the OEM or the platform” means in practice
This isn’t a self-declared claim from the vendor’s own marketing page. Android’s device-management ecosystem runs through Google’s own certification programs (Android Enterprise Recommended, and the underlying device-admin and work-profile APIs a locking mechanism has to integrate with correctly). Apple’s iOS runs a narrower, more restrictive Mobile Device Management framework, and a locking mechanism aimed at iOS has to operate inside Apple’s own MDM constraints rather than around them.
What counts as evidence, in either case, is a formal listing, partnership, or compliance attestation from the manufacturer or platform itself, something an NBFC’s procurement or legal team can point to and say “here is where this vendor is recognized,” not a line in a sales deck. If a vendor can’t produce that, the honest answer to “is this certified” is no, and the NBFC has to treat it that way.
The conditional escape hatch, and why it’s risky to lean on
The rule’s own wording softens this: certification is required “where such certification is available.” That phrase exists because certification programs don’t cover every device and OS combination equally, older Android forks, some enterprise-only OEM builds, and certain custom ROMs may have no formal certification path at all.
That’s a real gap in the rule, not a loophole to use freely. An NBFC that deploys an uncertified mechanism on the reasoning that certification “wasn’t available” for that device needs to be able to show it actually checked, and that the gap was in the market, not in its own vendor selection. Choosing the cheaper, uncertified option when a certified equivalent exists for the same device class doesn’t qualify as “unavailable.” A device-locking program that leans on this exception as a default, rather than an exception, is building its compliance posture on the weakest reading of the rule.
A vendor evaluation checklist before signing
Before an NBFC signs with a device-locking software vendor, or renews with one already deployed, the certification question needs a direct answer, not an assumed one. At minimum, an NBFC should ask which OEMs and OS platforms a specific mechanism is certified against, and whether the vendor can produce that certification in writing. For any device class the vendor’s software will run on but isn’t certified for, the next question is whether a certified alternative exists elsewhere in the market, and if so, why it isn’t being used instead. A third question covers failure behavior: how does the mechanism respond if a certification lapses, an OS update breaks the integration, or a device falls outside every certified pathway, does it fail toward restriction or toward release. And critically, does the vendor’s platform log and timestamp certification status per device model, so that record exists the day an examiner asks for it, rather than being reconstructed after the fact.
That last point is where this stops being a one-time procurement question and becomes an ongoing governance one. Certification status isn’t static, OS updates and OEM program changes can move a device in or out of coverage over the life of a loan book. An NBFC needs a live, auditable record of which mechanism was certified against which device, and when that status was last checked, sitting in the same governance layer that already tracks model approvals and maker-checker sign-off. That’s the kind of evidence an examiner will ask for on the device-locking condition specifically, and it’s exactly what a platform built around immutable audit trails and governance-by-design is meant to produce without a manual reconstruction exercise every time.
Where this sits inside the bigger device-locking obligation
This certification condition doesn’t stand alone. It’s one of four conditions inside the same rule covered in full in “RBI’s Device-Locking Rules: What NBFCs and Banks Must Build Before January 2027,” which walks through the staged restriction timeline, the essential-function protections, and the compensation and reversal mechanics that certification exists to safeguard. Treat this piece as the deep-dive on the condition that piece covers in a single line, not a replacement for it.
Sources
- corporateprofessionals.com, “When the Recovery Call Comes: RBI Rewrites the Rules of Engagement for NBFCs” (paragraph 100S’s four conditions, including OEM/OS certification, quoted directly)
- Business Standard, “RBI extends recovery norms deadline, eases certification timeline” (corroborates a device-locking mechanism certification requirement exists alongside the separate IIBF agent-certification timeline)
