BIS, Trusted Sources, and What “Indigenous” Actually Means for IT Procurement

Understanding the Four-Layer Indigenous Compliance Stack

“Indigenous” is a word that gets used in RFPs more than it is understood. For government IT procurement in India, it is not a single standard but a stack of specific, overlapping compliances—each with its own notification, registration window, and enforcement mechanism. PSU IT heads and procurement officers often conflate these layers, leading to disqualified bids, delayed deployments, and supply-chain surprises. The stack consists of four distinct elements: BIS (Bureau of Indian Standards) certification, Trusted Sources and Trusted Products lists managed by NCSC and MeitY, PPP-MII local-content thresholds under DPIIT, and PLI 2.0 manufacturing incentives. Each serves a different policy objective, and nearly all are mandatory in parallel for sensitive government IT deployments.

This post decomposes what “indigenous” actually means in practice, why the stack exists, and which OEM certifications signal genuine compliance versus partial alignment. For procurement leaders, understanding this distinction is the difference between a deployment that clears audit and one that stalls. For investors, the scarcity of OEMs holding all four credentials defines a meaningful competitive moat.

BIS Registration: The Foundation Standard

BIS (Bureau of Indian Standards) certification under IS 13252 and IS 9872 is the baseline requirement for IT hardware sold into government channels in India. IS 13252 specifies the safety and performance standards for desktop and notebook computers; IS 9872 covers keyboard and pointing devices. These are not optional endorsements—they are mandatory pre-qualification marks for any desktop PC, laptop, or peripheral intended for PSU deployment.

The registration process requires third-party testing at BIS-accredited laboratories, documentation of component sourcing, and periodic compliance audits. OEMs must maintain a BIS-registered facility and demonstrate that manufacturing processes meet the Indian Standards’ safety thresholds. For many global OEMs, BIS certification has been a checkbox; for Indian manufacturers, it is the entry ticket. RDP’s registration under IS 13252 and IS 9872, held since 2012, establishes the foundational compliance layer across all product lines. However, BIS registration alone does not satisfy government IT procurement mandates—it is the necessary but not sufficient baseline upon which the other three layers rest.

Trusted Sources and Trusted Products: Security Clearance

Trusted Sources and Trusted Products lists, maintained by the National Critical Information Infrastructure Protection Centre (NCSC) under MeitY, represent a second, distinctly security-focused compliance layer. These lists enumerate OEMs and products that have undergone security assessment for use in government IT networks, particularly in sensitive departments and defence contexts. The difference between the two is important: Trusted Sources lists OEMs whose manufacturing and supply processes have been vetted; Trusted Products lists specific device models that have passed security testing.

Inclusion on these lists is not automatic and does not flow from BIS certification. NCSC conducts independent security audits, reviews supply-chain transparency, and assesses vulnerability-disclosure and patch-management capabilities. Notification GSR 1035(E) under the Information Technology Act and associated MeitY circulars define the eligibility criteria and review timelines. Devices from OEMs not on Trusted Sources lists face procurement restrictions in DoT, defence, and critical-sector deployments—even if they are BIS-registered. This layer reflects India’s sovereign-computing policy objective: ensuring that devices entering sensitive networks come from manufacturers whose operations and security posture can be verified and monitored.

PPP-MII Local-Content Thresholds: Manufacturing Footprint

The Phased Manufacturing Programme under Make in India (PPP-MII), administered by DPIIT, introduces a third layer: mandated local-content thresholds that vary by product category and government buyer. Desktop PCs and laptops fall under PPP-MII Phase 1 and Phase 2 rules, which define Class-I and Class-II local-content requirements. Class-I requires 40% local value addition; Class-II requires 20%. Failure to meet the applicable threshold disqualifies a bid from government tenders that explicitly invoke PPP-MII eligibility criteria—which most PSU IT procurements now do.

Local content is calculated as the percentage of value (not unit count) sourced from Indian manufacturers or suppliers, including labour, assembly, and component sourcing. This is distinct from BIS registration (which is a quality standard) and Trusted Sources (which is a security assessment). PPP-MII exists to drive indigenous manufacturing ecosystem development. An OEM can be BIS-registered and on NCSC’s Trusted Products list but still fail PPP-MII Class-II thresholds if more than 80% of component value is imported. Conversely, meeting PPP-MII thresholds requires transparent supply-chain mapping—which in turn supports Trusted Sources audits. The linkage is real but not automatic. Government RFQs increasingly specify PPP-MII Class-I or Class-II compliance as a qualification gate, making it a hard blocking requirement rather than a preference signal.

PLI 2.0: Manufacturing Incentive and Eligibility Signal

The Production Linked Incentive (PLI) Scheme 2.0 for IT Hardware, notified by DPIIT, is the fourth and most recent layer. PLI 2.0 provides time-bound cash incentives (4–6% of incremental sales value) to manufacturers who meet prescribed manufacturing scale and local-content targets. Unlike BIS, Trusted Sources, or PPP-MII, PLI 2.0 is not a mandatory compliance gate for procurement eligibility—it is an incentive scheme that indirectly signals manufacturing commitment and scale.

However, PLI 2.0 registration has become a de-facto credential for credibility in government procurement narratives. Procurement committees often view PLI 2.0 eligibility as evidence that an OEM meets DPIIT and revenue-generation expectations, has been vetted for local-content capacity, and is committed to long-term India-focused manufacturing. The scheme launched in April 2023 and has enrolled a limited number of OEMs globally. For Indian manufacturers like RDP, PLI 2.0 eligibility strengthens the narrative around indigenous supply-chain viability, even though it is not a direct procurement blocker. It also opens revenue streams that improve capital allocation for scaling local manufacturing capacity—which in turn supports PPP-MII compliance.

How the Stack Works in Practice: A Procurement Scenario

Consider a typical PSU IT refresh: the IT head needs to procure 5,000 desktop PCs for branch offices. The RFQ specifies: (a) BIS certification under IS 13252; (b) NCSC Trusted Products list inclusion or Trusted Sources list inclusion; (c) PPP-MII Class-II (20% local content minimum); (d) PLI 2.0 registration preferred. A global OEM can meet (a) easily, and if it has set up a local assembly line, can meet (c). However, if it has not undergone NCSC security assessment—which typically takes 6–12 months and requires disclosure of firmware sources, supply-chain partners, and patch timelines—it will be disqualified at the (b) gate. The OEM’s global reputation and global supply chain are irrelevant if the device model is not on the NCSC list.

Conversely, an Indian OEM without BIS certification or with inadequate local-content sourcing will fail (a) or (c) and be disqualified before any procurement conversation begins. The “indigenous” threshold is not rhetorical—it is the intersection of all four compliance stacks. An OEM holding all four credentials—BIS registration, Trusted Sources/Products inclusion, PPP-MII Class-I (40%+) local content, and PLI 2.0 registration—is rare in India’s IT hardware market. That rarity is both a supply-chain vulnerability for government procurement and a strategic moat for OEMs that hold all four.

RDP’s registration across BIS (IS 13252 / IS 9872), inclusion on NCSC Trusted Sources lists, PPP-MII Class-I local-content documentation, and PLI 2.0 eligibility across its AI PC and desktop PC portfolios represents an end-to-end indigenous stack. This is not simply a “Made in India” marketing claim—it is a verified, audited, multi-layer compliance posture that meets every government IT procurement mandate in parallel. As government buyers increasingly exercise “indigenous” procurement preferences, as highlighted in our deeper exploration of why organisations are choosing Made-in-India IT hardware, the OEMs that hold all four credentials become the only viable option for sensitive, at-scale deployments.

Why the Stack Exists: Policy Drivers and Audit Reality

The indigenous compliance stack did not emerge by accident. Each layer reflects a distinct government policy objective: BIS ensures quality and safety standards aligned with Indian conditions; Trusted Sources and Trusted Products enforce sovereign supply-chain security; PPP-MII drives manufacturing ecosystem growth and dependency reduction on import substitution; PLI 2.0 incentivises capital investment in domestic manufacturing. Together, they form a coherent policy architecture—one that took 15+ years to develop but is now fully enforced in government IT procurement.

From an audit perspective, government procurement committees are now required to verify compliance across all four layers. A single missing credential can trigger a full tender re-run. A device BIS-certified but not on the Trusted Sources list will be flagged in post-award compliance audits. PPP-MII documentation—often the most labor-intensive to assemble—is now routinely requested and verified. This is not theoretical; it is happening in real procurement cycles across PSUs, defence departments, and critical-sector ministries. Procurement officers who understand the stack avoid disqualifications. Vendors who can navigate all four layers simultaneously become the preferred default.

Conclusion: The Rarity of Genuine Indigenous Credentials

“Indigenous” in Indian government IT procurement is a specific technical achievement, not a nationalist sentiment. It requires simultaneous compliance with quality standards, security vetting, local-content thresholds, and manufacturing-scale incentives. Few OEMs in India hold all four credentials in parallel across product lines. This is partly due to the recent consolidation of these rules (Trusted Sources and PLI 2.0 are post-2022 additions), and partly due to the investment and transparency required to pass multiple independent audits.

For PSU IT procurement leaders, the takeaway is clear: verify all four layers before bid qualification. For OEMs, building indigenous credibility is not a single initiative but a multi-year journey across compliance, supply-chain transparency, local manufacturing, and security posture. And for investors looking at India’s IT hardware ecosystem, the OEM that holds all four credentials simultaneously is the one that has solved the hardest problem in government procurement—and that competitive edge will persist.

Table: Indian IT Procurement Compliance Framework — Requirements, Applicability, and Penalties

Related Reading

For how these compliance layers play out in live tenders, see the GeM playbook for PSU IT heads. The sovereign-compute foundation they protect is explored in sovereign AI starts with sovereign compute. To verify RDP’s full compliance stack, visit rdp.in/contact.