ITSAR for WiFi Access Points (Wi-Fi CPE), Explained

What the Wi-Fi CPE ITSAR is

ITSAR — Indian Telecom Security Assurance Requirements — are the per-category security standards issued by the National Centre for Communication Security (NCCS). The Wi-Fi CPE ITSAR is the document that applies to WiFi customer-premises equipment — the category that includes access points and WiFi routers. It converts "is this access point secure?" from a marketing claim into a testable specification: a defined list of security requirements the specific model must demonstrate at a designated security test lab before it can be security-certified for Indian networks.

What the requirements cover

The requirement areas an ITSAR for WiFi equipment addresses read like a checklist of how real-world WiFi compromises happen:

• Secure defaults and credentials — no universal default passwords; forced credential change; controlled password policy.
• Firmware integrity — secure boot behaviour, signed firmware images and protected update mechanisms, so a compromised update path cannot own the device.
• Management-plane hardening — encrypted management access, insecure legacy services disabled, protection of configuration interfaces.
• Wireless security behaviour — support for current WPA generations and protection of management traffic, so the air interface meets modern expectations.
• Access control and roles — authenticated, role-based administrative access rather than a single all-powerful login.
• Logging and audit — security-relevant events recorded in a usable, protectable form.
• Known-vulnerability hygiene — the product and process for addressing published vulnerabilities.

The exact clauses and versions evolve as NCCS updates the document — which is itself a reason buyers should ask vendors which ITSAR version their testing addressed.

How testing and certification work

Security certification runs under the NCCS scheme: the OEM applies for the equipment category, the specific model is tested against the applicable ITSAR at a designated security test lab, and successful testing leads to security certification for that model. Three practical properties matter to buyers: certification is model-specific (a certified sibling does not cover the model you are buying), it is version-anchored (tested against a specific ITSAR release), and it is verifiable — a vendor claiming certification can show the paper. The mandate is being phased in category by category through DoT notifications, so the binding question in any given tender is the current status for Wi-Fi CPE at that date.

Why WiFi equipment gets special scrutiny

Access points hold a uniquely exposed position: they sit on the network edge, speak to unmanaged client devices over the air, are deployed in physically accessible locations, and are administered in bulk. A fleet of compromised APs is simultaneously a surveillance platform and a lateral-movement springboard — which is why the security regime treats WiFi CPE as its own category rather than lumping it with wired gear, and why network-security monitoring and certified hardware are complements, not alternatives.

What buyers should ask vendors

• Which ITSAR version applies to the quoted access points, and what is the certification status for those exact models?
• Show MTCTE certificates and WPC approvals for the same models, in the OEM's name — the MTCTE explainer covers how to verify them.
• Is the vendor a Trusted Source with products on the Trusted Telecom Portal?
• Who owns the firmware, and what is the security-patch commitment in writing?
• Does the device ship under the vendor's own IEEE MAC block — a thirty-second provenance check anyone can run?

Where this sits in the Indian compliance stack

For a WiFi access point, the full file is: MTCTE (technical conformance, TEC), WPC (radio authorisation), ITSAR-based security certification (NCCS), and — for licensed operators — procurement from a Trusted Source. Each answers a different question; the framework explainer maps them, and our certifications page shows the file Immunity maintains.

The Immunity position

NetWave (Lotus Alpha) WiFi 6 access points are MTCTE certified (and CE, FCC & RoHS compliant), carry WPC approvals for their radios, and ship from a Trusted Source with products on the Trusted Telecom Portal — under Immunity's own IEEE MAC block (OUI 50:48:2C:3), with firmware developed and supported in India. For the security-certification status of specific models against the current Wi-Fi CPE ITSAR, ask us — we answer with documents, not adjectives.

The certification journey for an access point, step by step

Wireless products carry a heavier compliance load than any other category in an enterprise network, because they combine a radio, a management plane and a firmware update path in one physically exposed box. Knowing the sequence helps a buyer read a vendor’s answers accurately.

Category and radio scoping. The manufacturer establishes the equipment category and the radio configuration: bands, channel widths, antenna arrangement and transmit power for the Indian market. Radio approval and security certification are separate tracks that both start here, and a variant sold with a different antenna or a different regulatory domain is a different device on both tracks.

Hardware and firmware freeze. Assessment is performed against a named hardware revision running a named firmware build. Wireless products change more often than switches — new chipsets, new radio modules, new client-behaviour workarounds — so the discipline of a controlled baseline matters more, not less.

Evidence preparation. The manufacturer assembles the design documentation the laboratory will read: the secure-boot chain, the signing and update mechanism, the cryptographic inventory, the administrative access model, the default-credential behaviour, the logging design and the vulnerability-handling process. A firm that writes its own firmware produces this from its own records. A firm shipping someone else’s reference design has to request it, and inherits whatever gaps exist.

Laboratory assessment. Designated laboratories combine documentary review with hands-on testing: forcing credential change on first boot, attempting to load an unsigned image, probing management interfaces for legacy plaintext services, checking wireless behaviour against current expectations, and confirming that security events are actually recorded and exportable.

Observation closure and grant. Findings are raised and answered, affected areas are re-tested, and certification is granted against named models and a stated requirement version. For wireless the recurring findings are unsurprising: default credentials, over-permissive management access, and update paths that trust too much.

Maintenance. Firmware for access points moves quickly. Ask any vendor, including us, to confirm certification status in writing for the specific model, and to state how that status is maintained across the firmware releases you will actually run in production.

The documentation pack to demand for wireless

Wireless purchases attract more paperwork than any other category because three separate regimes touch the same box. Collect the following as one bundle before award; ours are indexed on the certifications page with the supporting datasheets in the downloads library.

• Certificate numbers for every track. Technical conformance, radio authorisation and security certification are three different documents. Ask for the numbers so each can be reproduced from the issuing authority’s own portal.
• The ITSAR category and version the model was assessed against, so you know which revision of the requirements your compliance rests on.
• The exact model and variant list. Indoor and outdoor housings, different antenna configurations, and different regulatory domains are commonly separate SKUs. Certificates attach to models, not to a product family name.
• The firmware baseline and patch commitment. Assessed build, shipping build, a written statement on the difference, and the committed security-patch period in years.
• Secure-boot and image-signing description. Who holds the keys, how the device authenticates an update, and what happens when an unsigned image is presented.
• Default-credential behaviour. Confirmation that there is no universal default password and that credential change is enforced on first configuration, demonstrated on a sample unit rather than asserted in a datasheet.
• The administrative access and role model, including whether management traffic can be confined to a dedicated VLAN and whether administrative accounts are individual rather than shared.
• Logging specification. Which security events are recorded, how they reach a collector, and what survives a reboot or reset.
• Provenance. Manufacturing location and the IEEE MAC block the device addresses are drawn from — the thirty-second check described on our OEM and ODM page.
• Trusted Source position where a licensed operator is involved, set out on our trusted source page.
• The management platform’s posture. Controllers and cloud platforms are not hardware-certified, so ask separately about data residency, administrative access control, audit trails and how firmware is distributed to the fleet.

Keep the request even-handed and it becomes easy to send: ask any vendor, including us, to confirm certification status in writing for the specific model quoted, naming what is certified, what is under assessment and what is not applicable.

Writing wireless certification into a tender

Wireless tenders tend to be long on coverage requirements and short on compliance language. Four additions close the gap.

State all three tracks separately in the eligibility section. Require the bidder to declare, per model, the technical conformance certificate number, the radio authorisation number, and the security certification status against the applicable ITSAR with its version. Bundling them into one sentence about ‘all applicable certifications’ gives you nothing to enforce.

Specify by category and coverage, not by competitor datasheet. Describe the environment — density, client mix, indoor or outdoor, PoE class available — and require certification for the applicable category. Copying a rival specification line for line narrows the field without improving the outcome, and invites challenge. Our own category specifications are on the NetWave access point page, and the wider portfolio on the products page.

Include the supporting infrastructure in the compliance table. A wireless rollout is rarely wireless alone. The access switching that powers and aggregates the fleet carries its own obligations — set out in the wired-equipment ITSAR walkthrough and on the NetForce switching page — and a NetGuard controller or equivalent gateway carries a third set. Give each line in the bill of quantities its own compliance column. The certified equipment buyer’s guide has a requirement matrix you can adapt directly.

Carry the requirement into the contract. Make continued validity a condition of each delivery instalment, make post-award substitution subject to fresh verification, and state who bears the cost if a requirement revision lands mid-rollout. Wireless estates get extended and topped up for years after the original award.

How to check a wireless certificate is genuine and current

Three tracks means three verifications, and all of them are clerical work that a procurement officer can do without engineering support.

• Reproduce each certificate from its own source. Search the number on the issuing authority’s portal. A document you cannot find at source is unverified, however professional the PDF looks.
• Reconcile the holder to the manufacturer. Certificates in the name of a distributor or trading arm create a chain of title you will have to evidence later. Get the corporate relationship in writing.
• Match model strings exactly, including regional suffixes. On wireless, a suffix commonly marks a different regulatory domain, a different antenna set or a different radio module.
• Check that the radio approval matches the radio you are buying. Band support and power class differ between variants of the same family.
• Read validity dates against the rollout calendar, including any option quantities you may exercise later.
• Inspect a sample unit. Label, model marking and MAC prefix should agree with the paperwork and with the manufacturer’s registered IEEE block. This catches relabelled imports faster than correspondence ever will.

Imported access points versus domestically manufactured

The obligations attach to the equipment, so an imported access point is not exempt from anything. What changes is the response time on the things that go wrong after installation.

Wireless firmware is patched frequently, and a fleet of access points is the part of an estate most likely to need an urgent update. Where the certificate and the source code sit with an overseas principal, every request — a fix for a published vulnerability, a re-assessment after a radio-module substitution, a written clarification for your auditor — is scheduled by someone else. Where the local entity is an authorised representative rather than the manufacturer, a change of representation can require parts of the file to be reissued.

Manufacturing in India shortens the loop and makes provenance auditable: a factory you can visit, a bill of materials the manufacturer controls, and firmware engineers who can join a call. Our access points are built at GIDC Sanand in Gujarat with engineering in Powai, Mumbai. Local assembly is not by itself an assurance advantage, though. An access point screwed together locally from a white-label design offers the same visibility as an import, which is why the useful test is design and firmware ownership rather than the address on the carton. The OEM versus ODM explainer sets out how to run that test in a few minutes.

Public buyers should keep local-content classification under the Make-in-India order in a separate column from certification. The two measure different things, and a product can satisfy one while falling short on the other.

Timelines and what they mean for project planning

Published durations vary by category, laboratory load and submission quality, so we describe the shape rather than invent numbers.

Radio and conformance work is comparatively contained once samples are lodged. Security assessment is the variable element, because its length depends on how much design evidence the manufacturer already holds. Wireless has an additional wrinkle: because firmware moves quickly, the gap between the assessed build and the build you will deploy tends to be wider than on switching, and closing that gap in writing is part of the planning conversation.

For a project manager this translates into three rules. Anchor go-live dates only to certificates that exist today. Put long-lead certified items at the front of the procurement calendar, since they set the critical path for cabling, power and commissioning teams. And where a rollout will span a requirement revision, allocate the cost and schedule impact of re-assessment in the contract rather than discovering it during phase three.

If you are planning a campus or multi-site wireless deployment and want a dated, model-by-model position to map against your milestones, ask our engineers for the current file.

Common procurement mistakes on wireless

• Accepting a family certificate for a specific variant. Indoor, outdoor and different antenna configurations are usually different SKUs and different certificates.
• Checking one of the three tracks. A valid radio approval says nothing about security assessment, and a technical conformance certificate says nothing about either.
• Scoring compliance instead of gating it. Where certification is a legal requirement for the category, it belongs in eligibility, not in a weighted matrix.
• Overlooking the controller and cloud platform. The management plane administers the whole fleet and is not hardware-certified. Evaluate it on residency, access control, audit trail and firmware distribution instead of skipping it.
• Ignoring the firmware delta. The build that was assessed is rarely the build you will run. Get the vendor’s position on that difference in writing.
• Leaving the patch commitment commercial. A multi-year security-patch undertaking is a technical control and should be evaluated as one.
• Allowing substitution after award. An equivalent access point is a different certificate, and frequently a different manufacturer.
• Buying the radio and forgetting the estate. Access switching, power budget and the gateway all carry their own compliance obligations. Cover them in the same bill of quantities.

A wireless buyer’s checklist

• Equipment category and radio configuration identified for every quoted variant.
• Technical conformance, radio authorisation and security certification status stated separately, per model, in writing.
• ITSAR version recorded alongside the security certification status.
• Every certificate number reproduced from the issuing authority’s own portal.
• Certificate holder reconciled to the manufacturer, with the corporate chain documented where names differ.
• Model strings matched character for character, including regional and antenna suffixes.
• Firmware baseline recorded and the security-patch period committed in years.
• Secure boot, image signing and unsigned-image behaviour described and demonstrated on a sample.
• No universal default credentials, with forced credential change verified on a sample unit.
• Administrative access model confirmed: encrypted transport, individual accounts, role separation, management traffic confinable to its own VLAN.
• Log export destination, retention and reset behaviour tested at factory acceptance.
• Management platform assessed on data residency, access control, audit trail and firmware distribution.
• Trusted Source position stated wherever a licensed operator is involved.
• Manufacturing location and IEEE MAC-block ownership evidenced on a physical sample.
• 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 for any option quantities exercised later.

Wireless is the category where compliance paperwork is heaviest and where shortcuts are most tempting. Ask any vendor, including us, to answer every line above in writing for the exact models quoted, and let the quality of the written answer decide the shortlist.

Frequently asked questions

Does CE or FCC certification cover ITSAR requirements?

No. CE and FCC are foreign regimes; ITSAR-based security certification is Indian and separate. Well-certified products hold the international marks alongside the Indian stack, not instead of it.

My deployment is a private campus, not a telecom network. Should I care?

The mandate binds licensed operators, but the requirements describe what a securely engineered access point looks like. Enterprises increasingly reference them in RFPs for exactly that reason.

Can a vendor self-declare ITSAR compliance?

Certification requires testing at designated labs under the NCCS scheme. A self-declaration is a claim; a certificate is evidence. Ask for the evidence.

What if the quoted model's certification is "in process"?

Then the tender decision is about dates: make certification (or a contractual commitment with penalties) a condition of award or delivery, and verify before acceptance.