The Trusted Telecom Framework, NCCS and ITSAR, Explained

Why India built a security regime for telecom equipment

Telecom networks are critical infrastructure: the same boxes that carry office WiFi also carry payments, government services and emergency traffic. Over the last decade, governments worldwide concluded that the security of that infrastructure depends not only on how equipment performs, but on who designed it, who built it, and who can update it. India's answer is a layered regime — a supply-chain layer that governs vendors, and a testing layer that governs the equipment itself. Most vendor marketing blurs these layers together; buyers evaluating a network purchase need them separated, because each produces a different piece of paper and answers a different risk.

The Trusted Telecom framework: NSDTS in brief

The National Security Directive on the Telecommunication Sector (NSDTS) was approved by the Cabinet Committee on Security in December 2020 and became operational in mid-2021. Its core rule is simple: licensed telecom service providers may induct specified new network equipment only from vendors designated as Trusted Sources, and only their approved Trusted Products. The directive was implemented as an amendment to telecom licence conditions, and it is administered by the National Cyber Security Coordinator (NCSC) under the National Security Council Secretariat, through the online Trusted Telecom Portal. The rule applies to new inductions — it did not force operators to rip out existing equipment — but it decisively reshaped procurement: for a licensed network, an unapproved vendor is simply not purchasable.

Trusted Source vs Trusted Product

The framework designates at two levels. A Trusted Source is the vendor entity itself — assessed on ownership, control and supply-chain integrity. A Trusted Product is a specific product from that source, approved for induction into licensed networks. The distinction matters in procurement: a vendor claiming "we are trusted" should be able to show both its source designation and the approval covering the actual models being quoted. One does not automatically imply the other.

How designation works

Vendors seeking designation submit detailed disclosures through the Trusted Telecom Portal — corporate ownership and control, directors, manufacturing locations, and supply-chain information — on the basis of which the National Cyber Security Coordinator makes the trust determination. The process exists precisely because a network vendor's riskiness is not visible on a datasheet: it lives in who controls the firm, where code is written, and where hardware is built. For Indian OEMs with domestic ownership and manufacturing on Indian soil, the disclosures are straightforward; for complex multinational supply chains, they are not — which is much of the directive's point.

NCCS: India's security certifier for telecom equipment

The National Centre for Communication Security (NCCS), a Department of Telecommunications body headquartered in Bengaluru, owns the equipment-security layer. Its role is distinct from TEC's: where MTCTE tests general technical conformance, NCCS runs the security certification scheme for telecom equipment — defining the security standards (ITSARs), designating the security test labs, and certifying that specific equipment meets the security requirements before it is deployed in Indian networks. Security certification is being phased in category by category, with network elements such as routers and Wi-Fi equipment among the categories addressed, and it is progressively becoming a procurement checkbox alongside MTCTE.

ITSAR: the standards the testing happens against

ITSAR — Indian Telecom Security Assurance Requirements — are the published, equipment-specific security standards issued by NCCS. Each ITSAR defines what a category of equipment must demonstrate: secure boot and update mechanisms, credential and access-control behaviour, protection of management interfaces, logging, resistance to known attack classes, and so on. Equipment is tested against the applicable ITSAR at designated security test labs (see the category guides for WiFi access points and routers & switches), and the result is a security certification for that model. For buyers, ITSAR does for security what Essential Requirements do for technical conformance under MTCTE: it converts a vague promise ("our products are secure") into a testable, certifiable claim tied to a specific standard and model.

How the pieces fit: the full Indian compliance stack

Put together, Indian network equipment sits under five distinct regimes, each answering a different question:

• NSDTS / Trusted Source (NCSC) — who may you buy from? Vendor and supply-chain trust.
• NCCS security certification against ITSAR — is the equipment secure? Security testing of the product.
• MTCTE (TEC) — does the equipment conform? Technical testing against Essential Requirements; see our MTCTE explainer.
• WPC approval — may the radio transmit? Spectrum and RF authorisation for wireless products.
• BIS (CRS) — is it electrically safe? Safety registration.

A vendor's certification file should cover every layer that applies to the product being sold. The layers are not interchangeable, and no foreign mark — CE, FCC or otherwise — substitutes for any of them.

Who must comply — and who should

Must: licensed telecom service providers, for specified equipment inducted into their networks — the licence condition leaves no discretion. Increasingly do: PSUs, government departments and critical-infrastructure operators, whose tenders now reference Trusted Source status and security certification even where the licence condition does not strictly bind them. Should: private enterprises running networks that carry sensitive traffic — hospitals, financial offices, campuses — for whom the framework functions as a free, government-grade vendor-screening tool. If the Government of India will not let carriers buy from an unvetted vendor, an enterprise buyer may reasonably ask why it should.

How buyers verify a vendor's claims

• Ask whether the vendor is a designated Trusted Source, and for evidence of its status and of product approvals covering the quoted models — in the vendor's own name, not a distributor's.
• For security certification, ask which ITSAR the product category falls under and what the certification status is.
• Cross-check the rest of the stack the same way: MTCTE certificate numbers, WPC approvals, BIS registrations — verified on the respective portals, matched to exact models.
• Treat vagueness as data. A vendor operating honestly inside this regime can answer all of the above in one email.

Where Immunity Networks stands

Immunity Networks is a Trusted Source under the Trusted Telecom framework, with products on the Trusted Telecom Portal — and the rest of the stack is in place in Immunity's own name: products MTCTE certified (and CE, FCC & RoHS compliant), WPC approvals for the radios, and manufacturing at GIDC Sanand (Gujarat) with devices shipping under Immunity's own IEEE-registered MAC block. For operators, PSUs and enterprises that have adopted the framework as their screening bar, that means the full portfolio — NetWave WiFi, NetForce Switches, NetGuard Controller and NetCloud Central — clears the compliance conversation before the technical one begins. Talk to us early in your procurement cycle and we will map the paperwork to your tender checklist.

Walking the framework end to end

The five regimes above are easy to list and harder to sequence. In practice a product reaches an Indian enterprise or operator network by moving through two parallel tracks — one about the vendor, one about the equipment — and buyers get into difficulty when they assume progress on one implies progress on the other.

The vendor track begins with disclosure. A manufacturer seeking Trusted Source designation submits information about ownership and control, directorship, manufacturing locations and supply-chain arrangements through the portal, and the determination is made on that basis. Because the assessment is about the firm rather than the box, it does not expire when a product is refreshed — but it also does not travel to a new product automatically. Product approvals are a separate step on the same track.

The equipment track begins with category scoping. The manufacturer establishes which equipment category a model falls into, which drives which requirement documents apply. From there it is a familiar engineering sequence: freeze a hardware revision and firmware build, assemble design evidence, submit serialised samples to a designated laboratory, work through observations, and receive a certification tied to named models and a stated document version.

The two tracks meet at the purchase order. A licensed operator needs both: an approved vendor and an approved product for the specific model being inducted. An enterprise buyer using the framework as a screening bar should ask for both for exactly the same reason — a designation without a matching product approval leaves a gap that only becomes visible during an audit.

Neither track is a one-time event. Corporate changes on the vendor side and firmware or component changes on the equipment side both have consequences. Ask any vendor, including us, to confirm in writing what its current position is on both tracks for the specific models quoted, and what triggers a re-assessment on each.

The documentation a buyer should demand across the whole stack

Because five regimes touch the same purchase, the safest approach is a single compliance annexure that every bidder fills in identically. Ask for the following, per model, before award. Ours are indexed on the certifications page, with the supporting product documents in the downloads library.

• Vendor-level position. Trusted Source status in the manufacturer’s own name, and the listing position of the specific products being quoted. Our own position is set out on the trusted source page.
• Equipment-level security position. The applicable equipment category, the ITSAR version, and the certification status — certified, under assessment, or not applicable — with certificate numbers where held.
• Technical conformance and radio authorisation numbers for the same models, so each can be reproduced from the issuing authority’s own portal.
• Safety registration where the category requires it.
• An exact model list. Variants differ by port count, PoE class, housing, antenna arrangement and regulatory domain. Approvals attach to models, never to a family name.
• Firmware baseline and patch commitment in years, in writing, together with the vendor’s position on the difference between the assessed build and the shipping build.
• Provenance evidence. Manufacturing location, the IEEE MAC block the addresses come from, and whether firmware is written in-house or licensed — the distinction explained on our OEM and ODM page.
• Management-platform posture. Cloud and controller platforms are not hardware-certified, so ask separately about data residency, administrative access control, audit trails and how firmware is signed and distributed to a fleet.
• Support commitments. Indian spares location, escalation path into manufacturer engineering, and the response undertaking for a published vulnerability affecting the platform.

Keep the request symmetrical and it becomes trivial to send to a whole bidder list: ask any vendor, including us, to confirm certification and designation status in writing for the specific models quoted. A vendor operating honestly inside this regime can complete that annexure in a single email.

Turning the framework into tender language

The most common drafting failure is a single sentence requiring ‘all applicable statutory certifications’. It sounds comprehensive and enforces nothing, because it never obliges a bidder to say which regimes apply or to produce a number. Four changes make the clause work.

Separate the vendor question from the equipment question. One clause on Trusted Source designation and product listing; a second, distinct clause on equipment security certification and technical conformance. Bidders who blur them in their response are then visibly non-responsive rather than merely vague.

Require declarations at bid stage, not at supply. Certificate numbers cost a genuine bidder nothing to provide up front. A promise to produce them later is where disputes are born.

Write per category, across the whole bill of quantities. Wireless line items carry radio authorisation as well as security certification — the detail is in the Wi-Fi CPE walkthrough and on the NetWave access point page. Wired line items follow the route described in the routers and switches walkthrough, with our specifications on the NetForce switching page. Gateway and security-appliance lines, such as a NetGuard controller, carry their own set. A consolidated view of the categories we manufacture is on the products page, and the certified equipment buyer’s guide contains a requirement matrix you can lift into the annexure.

Carry it into the contract. Make continued validity a condition of each delivery instalment, make post-award substitution conditional on fresh verification, and allocate the cost and schedule impact if a requirement revision or a change in vendor status lands mid-rollout.

Checking that a designation or certificate is genuine and current

Verification across this stack is clerical work, and the discipline is to do it in the same order every time.

• Reproduce every claim from its own source. Each regime has its own register or portal. A claim that cannot be found at source is unverified, no matter how the document is presented.
• Check names, not brands. Designations and certificates should be in the manufacturer’s legal name. Where a distributor, trading arm or sister company appears instead, ask for the corporate relationship in writing before award.
• Check the product listing separately from the vendor designation. These are two different records, and the gap between them is the single most common weak point in a bid response.
• Match model strings character for character against the quotation, the delivery challan and the product label.
• Record document versions. Requirement documents are revised; knowing which revision you are buying against is part of the audit trail.
• Read validity against your full schedule, including warranty, support and any option quantities you may exercise later.
• Inspect a physical unit. Label, model marking and MAC prefix should agree with the paperwork and with the manufacturer’s registered IEEE block.
• Treat vagueness as data. Ambiguity in a compliance answer is itself an answer, and it is usually cheaper to act on it before award than after.

What changes when equipment is imported rather than made in India

This framework is, at heart, about supply chains, so the origin question sits closer to the surface here than in any other part of Indian compliance. Two things change when equipment is imported.

The first is disclosure complexity. The vendor track asks who owns and controls the firm, where code is written and where hardware is built. For a manufacturer with domestic ownership and an Indian factory those questions have short answers. For a layered multinational supply chain they do not, and the resulting assessment takes longer and is revisited more often. That difficulty is not an accident; it is much of what the directive was designed to surface.

The second is response time after installation. Where a certificate sits with an overseas principal and the Indian entity is an authorised representative, a fix for a published vulnerability, a re-assessment after a component substitution, or a written clarification for an auditor all queue behind an engineering calendar you do not control. If the local representation changes, parts of the file may need reissuing.

Domestic manufacture shortens those loops and makes provenance auditable. Our own production sits at GIDC Sanand in Gujarat, with engineering in Powai, Mumbai. It is worth saying plainly, though, that a locally assembled product built on a white-label reference design carries the same opacity as a direct import. The question that actually discriminates is design and firmware ownership, which is what the OEM versus ODM test is for.

Public buyers should also keep local-content classification under the Make-in-India order in its own column. Local content measures value addition; the Trusted Telecom framework measures supply-chain trust; ITSAR measures equipment security. Three different questions, three different answers, and conflating any two of them produces an evaluation that will not survive scrutiny.

Timelines and what they mean for project planning

We avoid publishing durations, because the honest answer varies by track, by category and by how much evidence a manufacturer already holds. What can be planned around is the shape.

Vendor designation is a corporate-disclosure exercise whose length depends on how legible the ownership and supply chain are. Equipment security certification is an engineering-evidence exercise whose length depends on documentation maturity. Technical conformance and radio authorisation are the most contained, once samples are lodged. The three run at different speeds, which is why a vendor can be genuinely correct in saying one is complete while another is still in progress.

For programme managers this produces three planning rules. Anchor go-live dates only to approvals that exist today; if something is described as in progress, plan the phase without it and treat arrival as upside. Sequence long-lead certified items first, because they set the critical path for civil, power and commissioning work. And where a rollout will span a scheme revision or a corporate change on the vendor side, allocate the cost and schedule consequences in the contract rather than negotiating them under pressure later.

If you want a dated, model-by-model position across all the applicable tracks mapped against your milestone plan, ask our engineers for the current file. A precise answer with dates on it is more useful to a procurement committee than a general assurance.

Common procurement mistakes with this framework

• Reading vendor designation as product approval. The most frequent error in the whole regime. They are separate records and both should be evidenced.
• Reading security certification as technical conformance, or the reverse. Different authorities, different documents, different questions.
• Accepting a foreign mark as a substitute. International marks sit alongside the Indian stack rather than in place of any part of it.
• Writing one catch-all compliance sentence. If the clause does not name the regimes and demand numbers, it will not be enforceable at evaluation.
• Scoring compliance instead of gating it. Where a regime binds the category, it belongs in eligibility.
• Verifying once, before award, and never again. Multi-year rollouts outlive certificates and can outlive corporate structures.
• Leaving the management platform out entirely because it is not hardware-certified. Evaluate it on residency, access control, audit trail and firmware distribution instead.
• Allowing post-award substitution without fresh verification on both tracks.
• Treating patch commitments as commercial terms. A multi-year vulnerability-response undertaking is a security control and belongs in the technical evaluation.

A practical buyer’s checklist for the whole stack

• Equipment category identified for every line in the bill of quantities.
• Applicable regimes listed per line: supply-chain trust, security certification, technical conformance, radio authorisation, safety registration.
• Vendor designation evidenced in the manufacturer’s own legal name.
• Product listing evidenced separately, covering the exact models quoted.
• ITSAR category and document version recorded alongside security certification status.
• Every certificate number reproduced from the issuing authority’s own portal before award.
• Model strings matched character for character across quotation, challan and label.
• Firmware baseline recorded and the security-patch period committed in years.
• Vulnerability-response undertaking stated in writing, with a named escalation path.
• Manufacturing location and IEEE MAC-block ownership evidenced on a physical sample.
• Management platform assessed on data residency, access control, audit trail and firmware distribution.
• Indian spares location named in the contract.
• Local-content class assessed in its own column, for public buyers.
• Re-verification scheduled at each delivery milestone and before any option quantity is exercised.
• Cost and schedule impact of a mid-rollout scheme revision allocated in the contract.

Used this way, the framework stops being regulatory background noise and becomes a practical screening tool that any buyer can operate. Ask any vendor, including us, to answer each line in writing for the exact models quoted — and then compare the written answers rather than the presentations.

Frequently asked questions

Is Trusted Source approval mandatory for private enterprise networks?

No — the licence condition binds telecom service providers. But PSU and government tenders increasingly reference it, and private buyers are free to (and increasingly do) use it as a vendor-screening criterion.

Does NCCS certification replace MTCTE?

No. They are complementary: MTCTE covers technical conformance under TEC, NCCS covers security certification against ITSAR. Depending on the equipment category and phase-in status, a product may need both.

What does an ITSAR actually contain?

Equipment-specific security requirements — secure boot and updates, access control, management-interface protection, logging and more — that the model must demonstrably meet at a designated security test lab.

How do I check a vendor's status?

Ask for evidence of Trusted Source designation and product approvals in the vendor's own name, plus certificate numbers for MTCTE and WPC, and verify each on the relevant government portal before award.