Certified Networking Equipment in India: The Buyer's Guide

The requirement matrix: what applies to what

Indian compliance is category-dependent. The working matrix for a typical enterprise or public purchase:

• WiFi access points — MTCTE + WPC (radio) + security status against the Wi-Fi CPE ITSAR + Trusted Source (for licensed operators).
• L2/L3 switches — MTCTE + security status against the applicable wired-equipment ITSAR + Trusted Source (operators). No WPC — no radio.
• Gateways / security appliances — MTCTE + wired-equipment security requirements + Trusted Source (operators); plus the logging behaviour public-WiFi rules expect, covered in our log-compliance guide.
• Cloud management platforms — not hardware-certified themselves; evaluate operator trust (vendor's Trusted Source status), data residency and audit trails instead.
• Public buyers add: local-content class (Class-I/II) under the Make-in-India order — the mechanics are in our GeM guide.

Copy-paste tender clauses

Adapt these two clauses and most of the compliance risk in a networking purchase disappears:

Clause 1 — certification. "All quoted equipment shall hold valid MTCTE certification, and WPC approval where the equipment contains a radio transmitter, in the name of the OEM, for the exact model numbers quoted. Certificate numbers shall be submitted with the technical bid and will be verified on the respective government portals. For equipment categories where security certification under the NCCS scheme is mandated, the bidder shall state the certification status against the applicable ITSAR, and certification (or a contractually bound commitment with penalties) shall be a condition of acceptance."

Clause 2 — provenance and support. "The bidder shall state whether the OEM is a designated Trusted Source under the Trusted Telecom framework and whether the quoted products appear on the Trusted Telecom Portal. The OEM shall confirm in writing: ownership of the device firmware, the security-patch commitment in years, the location of Indian RMA stock, and an escalation path to the OEM's own engineers."

The 30-minute verification

• Minutes 1–10: take the submitted MTCTE certificate numbers and verify them on TEC's portal — valid, in the OEM's name, exact models. Anything that fails here fails everything.
• Minutes 10–15: for radios, match WPC approvals to the same models.
• Minutes 15–20: check the vendor's Trusted Source claim and product listings as applicable.
• Minutes 20–25: run a MAC lookup on a demo unit — does the hardware resolve to the vendor's own IEEE registration or to an unrelated factory? The OEM vs ODM test in one step.
• Minutes 25–30: ask for the firmware changelog. A real OEM has one; a label has excuses.

Mapping the matrix to products

Applied to Immunity's portfolio, the matrix reads: NetWave WiFi 6 access points — MTCTE certified (and CE, FCC & RoHS compliant), WPC-approved radios; NetForce L2 and L3 switches — MTCTE certified; NetGuard Controller — MTCTE certified with DoT-aligned portal logging; all supplied by a Trusted Source with products on the Trusted Telecom Portal, manufactured at GIDC Sanand, under Immunity's own IEEE MAC block (OUI 50:48:2C:3), managed by NetCloud Central operated for Indian deployments. Security-certification status against current ITSARs is model- and date-specific — request the current file and we will map it to your checklist line by line.

Red flags that end evaluations early

• Certificates in a trading company's name with no OEM chain.
• "Similar model" certificates offered for the quoted SKU.
• Refusal to share certificate numbers "until PO".
• A "local" product whose MAC lookup resolves to an overseas ODM.
• Warranty promises with no Indian RMA stock location attached.

How the testing and certification process actually works

Procurement teams often treat certification as a yes-or-no field in a bid sheet. It helps to understand what sits behind that field, because the shape of the process explains why certificates are model-specific, why they carry validity dates, and why ‘our next revision will be covered’ is not the same thing as compliance today.

Step one — scoping. The manufacturer determines which category the product falls into. Category drives everything downstream: an access point with a radio, a fanless L2 switch and a security gateway follow different routes even when they share a chassis family. Getting the category wrong at the start is one of the commonest reasons a certification file arrives late.

Step two — design freeze and sample preparation. Test laboratories assess the exact hardware and firmware build presented to them. Changing the wireless module, the switching silicon, the power supply or, in security testing, the firmware image can invalidate work already completed. Manufacturers therefore freeze a build, allocate serialised samples and hold them under configuration control for the duration of the campaign.

Step three — laboratory testing. Conformance testing is carried out by designated laboratories against the published requirements for that category. Part of the work is bench measurement — emissions, power, interface behaviour. Part of it is documentary: the laboratory reads design documents, declarations and configuration guides. Security testing under the NCCS scheme adds a structured evidence review, which is why it generally runs longer than radio or safety testing.

Step four — observations and closure. Almost every meaningful test campaign produces observations. The manufacturer responds, sometimes with a design fix and a re-test of the affected area. From the buyer’s point of view this is the least predictable phase, and it is the phase vendors are most tempted to compress in their sales messaging.

Step five — grant and listing. Once the file is closed, the certificate is issued against named model numbers with a stated validity. Where the scheme maintains a public portal, the grant becomes verifiable by anyone holding the certificate number. That is the buyer’s leverage: you never have to accept a compliance claim on trust.

Step six — surveillance and change control. Certification is not a one-time event. Hardware revisions, component substitutions and firmware changes can trigger re-assessment. Ask any vendor, including us, to confirm in writing how certification is maintained when a bill-of-materials change is forced on them by component availability.

The documentation pack a buyer should demand

The gap between a defensible purchase and a risky one is usually a documentation gap. Before releasing a purchase order, insist on a single pack containing the items below. Any competent manufacturer can assemble it within a few working days; ours are indexed on the certifications page and in the downloads library.

• Certificate copies with numbers, not screenshots. You need the number in order to verify independently. A PDF with the number cropped out, or an image pasted into a slide deck, is not evidence.
• An exact model-number mapping. The SKU on the certificate must be the SKU on the quotation, on the delivery challan and on the product label. Family names are marketing; certificates attach to models.
• Validity dates and the scheme revision. Requirement documents are revised over time. A certificate issued against an earlier revision is not automatically wrong, but you should know which revision you are buying against.
• A firmware baseline statement. Which firmware version was assessed, which version ships today, and the vendor’s written position on the difference between them.
• Provenance evidence. Manufacturing location, the IEEE MAC block the device addresses are drawn from, and whether the vendor writes its own firmware or licenses it. Our OEM versus ODM explainer covers how to read this, and the OEM/ODM page sets out what we design and build ourselves.
• Trusted Source position. For anything that will sit in a licensed operator’s network, the vendor’s status under the Trusted Telecom framework and the listing position of the specific product. Our trusted source page explains what the designation does and does not mean.
• Support and patch commitments. Years of security patching, the Indian RMA stock location, and a named escalation path into the manufacturer’s own engineering team.

The framing that works best in correspondence is deliberately even-handed: ask any vendor, including us, to confirm certification status in writing for the specific model you intend to buy, on letterhead, with certificate numbers included. A vendor unwilling to do that has told you something useful about the file.

Writing certification requirements into a tender or RFP

The two clauses above do most of the work, but the way they sit inside the wider document decides whether they survive evaluation. Four drafting habits make the difference.

Put certification in the eligibility section, not the scoring section. Where a certificate is a legal requirement for the category, treat it as a pass or fail gate. Scoring it out of ten invites a bidder to trade compliance against price, and asks an evaluation committee to make a judgement it is not equipped to make.

Require certificate numbers at bid stage. ‘Will be produced at the time of supply’ is the phrase that produces disputes six months later. Numbers in the technical bid cost a bidder nothing if the certificates are genuine.

Specify the category, not the brand. Write ‘managed L2 access switch, 24 × 1G with PoE+ and uplinks, holding valid certification for the applicable category’ rather than copying a competitor datasheet line for line. Category-based drafting keeps the tender defensible and widens the field. You can see how we structure category specifications on the NetForce switching page and the NetWave access point page.

Carry the requirement into the contract. Add a clause making continued certificate validity a condition of each delivery instalment, with a stated remedy. Tenders that effectively certify only the first carton are common; staged rollouts run for years.

Where a rollout mixes access points, switching and a security gateway, make the certification requirement a column in the bill of quantities so every line carries its own obligation. A NetGuard controller line item carries different obligations from a passive optic, and the requirement matrix at the top of this article is the fastest way to fill that column in. A consolidated view of what we manufacture sits on the products page.

How to check that a certificate is genuine and current

Verification is a clerical task rather than a technical one, and it works best when the same person does it every time so the habit sticks.

• Start from the portal, not the PDF. Type the certificate number into the issuing authority’s own search. A document that cannot be reproduced from the source is not a certificate; it is a picture of one.
• Match the holder name to the OEM. A certificate in the name of a distributor, a trading arm or a sister company creates a chain you will have to prove later. Ask for the corporate relationship in writing wherever the names differ.
• Match the model string character for character. A trailing suffix often marks a different radio, a different power class or a different regional variant.
• Read the validity window against your delivery schedule. A certificate valid today but expiring inside your rollout window is a planning issue rather than a disqualification — but only if you notice it now.
• Cross-check a physical unit. Label, model marking and MAC prefix on a demonstration device should all agree with the paperwork. This five-minute check catches relabelled imports more reliably than any amount of correspondence.

What changes when equipment is imported rather than made in India

Certification obligations attach to the equipment and to the entity placing it on the market, so an imported product is not exempt. What changes is who holds the file, how quickly it can be amended, and what happens when something goes wrong.

With an imported product the certificate frequently sits with an overseas principal while the Indian entity acts as an authorised representative. That arrangement is entirely legitimate, but it lengthens every loop. A firmware fix, a re-test after a component substitution, or a clarification for your auditor all travel through a foreign engineering calendar. If the local partner changes, parts of the paperwork may have to be reissued.

Domestic manufacture shortens those loops and makes provenance easier to evidence: a factory address you can audit, a bill of materials the manufacturer controls, and firmware written by people you can put on a call. Our own production sits at GIDC Sanand in Gujarat, with engineering out of Powai in Mumbai. That is not automatically a compliance advantage, though — a locally assembled box built from a white-label design carries exactly the same opacity as an import. The real test is design ownership rather than the address on the carton, which is what the OEM/ODM test is for.

Public buyers should also keep local-content classification under the Make-in-India order separate from certification in their evaluation sheet. A product can be fully certified and still fall short of a Class-I local-content threshold, or meet the threshold while its certification file is incomplete. Two columns, never one.

Timelines and what they mean for project planning

We deliberately avoid quoting week counts here, because real durations vary by category, by laboratory load and by how clean the submission is. What you can plan around is the shape of the curve.

Radio and conformance testing is comparatively predictable once samples are with the laboratory. Security certification is usually the long pole, because it involves evidence review cycles whose length depends on the quality of the manufacturer’s own engineering documentation. A vendor with mature internal documentation moves through it quickly; a vendor assembling that evidence for the first time does not.

For project managers there are three practical consequences. First, never build a go-live date on a certificate that does not yet exist — if a product is described as ‘under certification’, plan the phase without it and treat its arrival as upside. Second, sequence long-lead certified items ahead of everything else in the procurement calendar, because they set the critical path. Third, if a rollout will run across a scheme revision, agree in the contract who bears the cost and the delay of any re-certification.

If you are scoping a multi-site deployment and want a current, dated certification position on specific models mapped against your milestone plan, ask our engineers for the file rather than working from a datasheet. We will state what is held, what is in progress and what is not applicable, model by model.

Common procurement mistakes

• Accepting a family certificate for a specific SKU. The most frequent mistake, and usually the most expensive one to unwind.
• Letting the technical committee score compliance. Compliance is binary. Scoring it converts a legal requirement into a negotiation.
• Verifying once at bid stage and never again. Multi-year rollouts outlive certificates, and nobody re-checks unless the contract says so.
• Confusing certification with security. A certificate records that a product met a defined bar on a defined date. It does not configure your network or manage your credentials. The Wi-Fi CPE ITSAR walkthrough and the wired-equipment ITSAR walkthrough set out what the bar actually covers.
• Ignoring the management plane. Controllers and cloud platforms are not hardware-certified, so buyers often leave them out of the compliance conversation entirely. Ask instead about data residency, audit trails, administrative access control and how firmware is signed and distributed.
• Treating support as an after-sales nicety. A multi-year security-patch commitment is part of your security posture, and it belongs in the technical evaluation rather than the commercial annexure.
• Allowing substitutions after award. An equivalent model is a different certificate. Make substitution subject to fresh verification in the contract.

A practical buyer’s checklist

• Category identified for every line item in the bill of quantities.
• Certificate numbers received with the technical bid, not promised for later.
• Every number verified on the issuing authority’s own portal.
• Holder name reconciled to the OEM, with the corporate chain documented wherever they differ.
• Model strings matched character for character against the quotation.
• Validity dates checked against the full delivery, warranty and support schedule.
• Trusted Source position stated in writing wherever a licensed operator is involved.
• Firmware baseline recorded, along with the committed patch period in years.
• Manufacturing location and MAC-block ownership evidenced, not asserted.
• Indian RMA stock location and escalation path named in the contract.
• Local-content class assessed separately from certification, for public buyers.
• Re-certification cost and delay allocated in the contract for rollouts spanning a scheme revision.

Work down that list and compliance risk in a networking purchase stops being a matter of trust and becomes a matter of record. Ask any vendor, including us, to answer every line in writing for the exact models quoted, and then compare the answers rather than the brochures.

Frequently asked questions

We are a private company — which of this is mandatory for us?

MTCTE and WPC attach to the equipment being sold, so they apply regardless of buyer. Trusted Source procurement binds licensed operators; private buyers use it as a free screening bar.

Can we just buy on price and fix compliance later?

Certification is model-specific and cannot be retrofitted by the buyer. Equipment without the file stays without it — and the discount rarely survives the first failed audit.

How current is "current"?

Mandates phase in and ITSAR versions update. Verify status in your tender window, and for staged deliveries make continued validity a contract term.

Where do we start?

Put Clause 1 and Clause 2 in the bid, run the 30-minute verification on what comes back, and the field usually sorts itself.