ITSAR for Routers and Switches, Explained

What the ITSAR for wired network equipment is

ITSAR — Indian Telecom Security Assurance Requirements — are per-category security standards issued by the National Centre for Communication Security (NCCS). For wired infrastructure, the relevant documents cover equipment categories such as IP routers and LAN switching, phased in through DoT notifications. The premise is the same as for wireless: security stops being a brochure adjective and becomes a per-model test result, produced at a designated security lab against a published requirement set.

What the requirements cover for switches and routers

• Control-plane protection — the switch's own brain must survive hostile traffic: protection for management and control protocols, resistance to protocol-level abuse and resource exhaustion.
• Hardened management access — encrypted administrative access, legacy plaintext services disabled, authenticated and role-based administration rather than shared logins.
• Firmware and boot integrity — signed images, protected update paths, and a boot process that rejects tampered software.
• Segmentation behaviour — the features enterprises rely on for isolation (VLANs and related controls) behaving correctly under attack, not just under demo.
• Logging and audit — security events captured reliably enough to reconstruct an incident.
• Vulnerability handling — a working process for addressing published CVEs in shipped firmware.

As with all ITSARs, clauses and versions evolve; the version tested against is part of what a buyer should record.

Why wired gear gets its own scrutiny

A compromised access point owns a floor; a compromised core switch owns the building. Switches and routers see every VLAN, carry management traffic for everything else, and live in racks nobody looks at for years — the perfect persistence point. That asymmetry is why security regimes worldwide, India's included, treat wired infrastructure as certifiable security equipment rather than plumbing, and why availability design and security certification belong in the same conversation when specifying a core.

Testing and certification, briefly

The mechanics mirror the Wi-Fi CPE process: OEM application under the NCCS scheme, model-specific testing at a designated lab against the applicable ITSAR, certification on success. The same three buyer-relevant properties hold — model-specific, version-anchored, verifiable — and the same caveat: the mandate phases in by category, so check the current status for the equipment class in your tender window.

What buyers should ask

• Which ITSAR category and version applies to the quoted switches or routers, and what is the certification status for the exact models?
• Show the MTCTE certificates for the same models — how to verify them is covered in the MTCTE explainer.
• Is the vendor a Trusted Source with products on the Trusted Telecom Portal?
• What is the firmware security-patch commitment, in years, in writing — and who actually writes the firmware? (The OEM vs ODM question decides who can honour it.)
• For PoE estates powering cameras and APs: does the quoted PoE budget hold with security features enabled, not just in the datasheet's best case?

Where this sits in the stack

For wired equipment the Indian file is: MTCTE (TEC technical conformance), ITSAR-based security certification (NCCS), and — for licensed operators — Trusted Source procurement. No WPC is needed for non-radio gear. The framework explainer maps the whole regime; the certifications page shows Immunity's file.

The Immunity position

NetForce L2 and L3 switches and the NetGuard Controller are MTCTE certified (and CE, FCC & RoHS compliant), supplied by a Trusted Source with products on the Trusted Telecom Portal, manufactured at GIDC Sanand, and shipped under Immunity's own IEEE MAC block (OUI 50:48:2C:3) with firmware owned and supported in India. For security-certification status of specific models against the applicable ITSAR, ask us — we will answer with the documents your evaluation needs.

The certification lifecycle for a switch or router, step by step

Buyers usually meet security certification as a single line in a compliance sheet. Understanding the sequence behind that line explains most of the awkward answers vendors give, and tells you which questions are reasonable to press on.

Category determination. Wired equipment is not one bucket. An access-layer LAN switch, an aggregation or core switch with routing, and an edge router sit in different equipment categories with different requirement sets. Before anything else, establish which category each quoted model falls into. If a vendor cannot answer that crisply for its own product, the rest of the conversation will not improve.

Design and firmware freeze. Security assessment is performed against a specific hardware revision running a specific firmware build. Manufacturers freeze that combination, serialise the samples and place them under configuration control. This is why a certificate cannot be stretched across a later hardware revision without a fresh look, and why ‘same product, newer board’ is a claim worth testing.

Evidence preparation. This is the phase that separates manufacturers from re-badgers. The laboratory expects design documentation, a description of the secure-boot chain, the cryptographic inventory, the administrative access model, the logging architecture and the vulnerability-handling process. A company that owns its firmware can produce these from its own repository. A company that licenses a reference design has to ask someone else, in another time zone, and wait.

Laboratory assessment. Testing at a designated security laboratory combines documentary review with hands-on work against the sample: attempting protocol abuse against the control plane, probing the management interfaces, checking that disabled legacy services are genuinely disabled, and confirming that segmentation and logging behave as documented rather than as advertised.

Observation closure. Findings are raised, the manufacturer responds, and where a fix is needed the affected area is re-assessed. For wired equipment the commonest observations cluster around management-plane hardening and default configurations — things that are cheap to fix at design time and painful to fix once a product has shipped in volume.

Grant, then maintenance. Certification is issued against named models and a stated version of the requirement document. It then has to be maintained across firmware releases and component changes. Ask any vendor, including us, to confirm certification status in writing for the specific model you intend to buy, together with what happens to that status when the next firmware release ships.

The evidence pack to demand for wired equipment

For switching and routing, the documentation a buyer should collect goes a little beyond the generic certification pack, because the management plane is where the risk concentrates. Ask for all of the following, in one bundle, before award. Ours are indexed on the certifications page, with datasheets and configuration guides in the downloads library.

• Certificate numbers, not images. Numbers can be checked independently on the issuing authority’s portal. Screenshots cannot.
• The ITSAR category and document version each quoted model was assessed against, so you know which revision of the requirements you are buying compliance with.
• An exact model list. Port count, PoE class and uplink variants are frequently separate SKUs. The certificate must name the SKU on your quotation, not the series.
• The firmware baseline. The assessed build, the shipping build, and a written statement on the delta. Follow it with the committed security-patch period in years.
• The secure-boot and image-signing description. Who holds the signing keys, how an update is authenticated by the device, and what the device does when presented with an unsigned image.
• The administrative access model. Role separation, per-administrator accounts, encrypted transport, and confirmation that plaintext legacy management services are off by default rather than merely disable-able.
• The logging specification. Which security events are recorded, where they can be exported, and whether the record survives a device reboot or a factory reset.
• The vulnerability-handling process. How published CVEs affecting the platform are triaged, and the route by which fixes reach a customer already in production.
• Provenance. Manufacturing location, the IEEE MAC block the addresses come from, and whether firmware is written in-house or licensed — the test set out in our OEM and ODM page.
• Trusted Source position for anything destined for a licensed operator’s network, explained on our trusted source page.

The wording that keeps everyone honest is symmetrical: ask any vendor, including us, to confirm in writing — on letterhead, model by model — what is certified, what is in progress and what is not applicable. Compare the written answers rather than the marketing decks.

Putting ITSAR language into a switching tender

Most tenders for wired equipment still specify ports, speeds and PoE budget, and leave security to a single unenforceable sentence. Three changes fix that without making the document unwieldy.

Make security certification an eligibility condition, per category. Draft it as: the bidder shall state, for each quoted model, the applicable equipment category, the ITSAR version, and the certification status — certified, under assessment, or not applicable — supported by certificate numbers where certification is held. Where certification is mandated for the category, non-compliance is a disqualification rather than a scoring deduction.

Specify the management plane explicitly. Certification sets a floor; your configuration standard sits on top of it. Require encrypted administrative access only, per-administrator authentication with role separation, centralised log export, signed firmware images, and a documented process for CVE response. These are testable at factory acceptance, which makes them worth writing down.

Bind continued validity into the contract. Wired estates are refreshed in phases across several years. Make continued certificate validity a condition of each delivery instalment, make substitution subject to fresh verification, and state who bears the cost if a scheme revision lands mid-rollout.

Where the same tender covers access points and a gateway alongside the switching, keep one certification column in the bill of quantities so every line carries its own obligation. Wireless line items pick up radio approval as well — the detail is in the Wi-Fi CPE ITSAR walkthrough and on the NetWave access point page — while a NetGuard controller line carries the gateway obligations. Our switching specifications are laid out on the NetForce switching page, and the full portfolio on the products page. For the umbrella view across all categories, the certified equipment buyer’s guide carries a requirement matrix you can lift straight into a bid document.

Verifying that a certificate is genuine and still current

Verification of wired-equipment paperwork takes minutes and catches the great majority of problems. Run it before award, and again before each phase of a staged delivery.

• Reproduce the certificate from the source. Search the number on the issuing authority’s own portal. If the record cannot be found, treat the document as unverified regardless of how convincing it looks.
• Reconcile the holder to the manufacturer. Certificates held by a trading entity or a channel partner create a chain of title you will have to evidence during an audit. Ask for the relationship in writing.
• Compare model strings exactly. On switching, a single character often separates a PoE variant from a non-PoE variant, or a 10G-uplink SKU from a 1G one.
• Check the requirement version. A certificate against an earlier ITSAR revision is a fact to record, not automatically a defect — but it should be recorded.
• Read validity against the delivery plan. A certificate expiring inside your rollout window is a planning problem if you find it now and a dispute if you find it later.
• Inspect a physical sample. Model marking, serial format and MAC prefix on a demonstration unit should all agree with the paperwork and with the manufacturer’s registered IEEE block.

Imported switching versus domestically manufactured

Certification obligations follow the equipment, so importing does not remove them. What importing changes is the distance between you and the people who can act on a security finding.

Where the certificate is held by an overseas principal and an Indian entity acts as authorised representative, every remedial loop crosses a border. A CVE affecting the switching platform, a re-assessment after a silicon or power-supply substitution, or a clarification your auditor wants in writing all queue behind an engineering calendar you do not control. If the local representation changes hands, parts of the file may need reissuing, and the buyer usually discovers this at the worst possible moment.

Domestic manufacture shortens those loops. A factory address can be audited, the bill of materials is under the manufacturer’s control, and firmware questions can be put to the engineers who wrote the code. Our own switching is built at GIDC Sanand in Gujarat with engineering based in Powai, Mumbai. That said, domestic assembly is not automatically an assurance advantage: a box screwed together locally from a white-label reference design carries the same opacity as a direct import. The distinguishing question is design and firmware ownership, which is precisely what the OEM versus ODM test is built to answer.

For public-sector buyers there is a second, separate axis. Local-content classification under the Make-in-India order measures value addition, not security. A switch can satisfy a Class-I local-content threshold and still have an incomplete security file, or hold current certification while falling short on local content. Keep them as two independent columns in the evaluation sheet.

Timelines, phasing and project planning

We do not publish week counts, because genuine durations depend on the equipment category, laboratory availability and the quality of the manufacturer’s submission. The planning-relevant facts are structural rather than numerical.

Conformance testing on wired equipment is comparatively contained once samples are lodged. Security assessment is the variable, because its length tracks how much evidence the manufacturer already has on the shelf. A team that documents its secure-boot chain and cryptographic inventory as a matter of course moves through review quickly. A team assembling that material for the first time, from a supplier’s reference design, does not.

Three planning rules follow. First, never anchor a go-live date to a certificate that does not yet exist; if a model is described as under assessment, plan the phase without it. Second, put long-lead certified items at the front of the procurement calendar, because they define the critical path for the rest of the build. Third, where a rollout spans a scheme revision, decide in the contract who carries the cost and the schedule impact of re-assessment rather than arguing about it later.

If you need a dated, model-by-model position on switching and routing to map against your milestone plan, ask our engineers for the current file. We would rather give you a precise answer with dates on it than a general reassurance.

Procurement pitfalls specific to wired estates

• Buying the series, certifying the SKU. Switching families sprawl into dozens of variants. A certificate for one variant says nothing about the one on your purchase order.
• Treating access-layer switches as commodity. Access switches outnumber everything else in a campus and are the least supervised devices in the estate. They deserve the same management-plane questions as the core.
• Ignoring the unmanaged tail. Small unmanaged switches slip in under desks and in cabinets. They may sit outside the mandate, but they are still inside your network. Record them, or ban them.
• Accepting equivalence after award. An ‘equivalent model’ is a different certificate and, often, a different manufacturer. Make substitution conditional on fresh verification.
• Confusing conformance with security assurance. Technical conformance and ITSAR-based security certification are separate tracks producing separate documents. Ask for both statuses by name.
• Leaving firmware support out of the technical evaluation. The patch commitment is a security control. If it lives only in the commercial annexure, nobody scores it.
• Forgetting the management platform. Cloud and controller platforms are not hardware-certified, so they escape scrutiny by default. Ask instead about data residency, administrative access control, audit trails and how firmware is signed and distributed.
• Verifying once. A multi-year refresh outlives certificates. Build re-verification into each delivery milestone.

A wired-equipment buyer’s checklist

• Equipment category identified for every switching and routing line item.
• ITSAR version and certification status stated in writing, per model, with certificate numbers where held.
• Technical conformance certificates supplied alongside, for the same models.
• All numbers reproduced from the issuing authority’s own portal, not from vendor PDFs.
• Certificate holder reconciled to the manufacturer, with the corporate chain documented.
• Model strings matched character for character to the quotation and the delivery challan.
• Firmware baseline recorded and the security-patch period committed in years.
• Secure-boot, image-signing and CVE-handling processes described in writing.
• Administrative access model confirmed: encrypted transport, per-administrator accounts, role separation, legacy plaintext services off by default.
• Log export destination and retention behaviour confirmed and tested at factory acceptance.
• Trusted Source position stated wherever a licensed operator is involved.
• Manufacturing location and IEEE MAC-block ownership evidenced.
• Indian spares location and escalation path into manufacturer engineering named in the contract.
• Local-content class assessed separately from certification, for public buyers.
• Re-verification scheduled at each delivery milestone, and re-assessment costs allocated in the contract.

Run that list and the security file for a wired estate stops depending on anybody’s good intentions. Ask any vendor, including us, to answer each line in writing for the exact models quoted, and let the completeness of the answers do the shortlisting.

Frequently asked questions

Do unmanaged switches need this?

The regime targets specified categories of network equipment; the practical buyer's rule is that anything with a management plane deserves the management-plane questions, whatever the mandate status.

We already buy MTCTE-certified switches. Is that enough?

MTCTE answers technical conformance. Security assurance is the NCCS/ITSAR track. Ask for both statuses; they are different documents.

Does Trusted Source status certify the switch itself?

No — Trusted Source is vendor-level designation; product-level security certification is the ITSAR track. A rigorous tender references both.

How do we verify any of this?

Certificate numbers in the OEM's name, checked on the respective government portals, matched to the exact models quoted — before award, not after delivery.